Een van de belangrijkste problemen bij de ontwikkeling en daaropvolgende exploitatie van microservices is de competente en nauwkeurige configuratie van hun instanties. Naar mijn mening kan een nieuw raamwerk hierbij helpen . Hiermee kunt u een aantal routinematige applicatieconfiguratietaken heel elegant oplossen.
Als je veel microservices hebt, en elk ervan heeft zijn eigen configuratiebestand/bestanden, dan is de kans groot dat je een fout maakt in een van deze, wat heel moeilijk kan zijn om op te sporen zonder de juiste vaardigheden en een logsysteem. De belangrijkste taak die het raamwerk zichzelf stelt, is het minimaliseren van dubbele instantieconfiguratieparameters, waardoor de kans op het toevoegen van een fout wordt verkleind.
Laten we eens kijken naar een voorbeeld. Laten we zeggen dat we een eenvoudige applicatie hebben met een configuratiebestand YAML. Dit kan elke microservice in elke taal zijn. Laten we eens kijken hoe het raamwerk op deze service kan worden toegepast.
Maar laten we eerst, voor meer gemak, een leeg project maken in Idea IDE, nadat we de plug-in microconfig.io erin hebben geïnstalleerd:
We hebben de configuratie voor het starten van de plug-in ingesteld. U kunt de standaardconfiguratie gebruiken, zoals in de bovenstaande schermafbeelding.
Onze service heet orde, en in een nieuw project zullen we een vergelijkbare structuur creëren:
Plaats het configuratiebestand in de map met de servicenaam - applicatie.yaml. Alle microservices worden in een soort omgeving gelanceerd, dus naast het maken van een configuratie voor de service zelf, is het noodzakelijk om de omgeving zelf te beschrijven: hiervoor zullen we een map maken omg en voeg daar een bestand aan toe met de naam van onze werkomgeving. Het raamwerk zal dus configuratiebestanden maken voor services in de omgeving dev, aangezien deze parameter is ingesteld in de plug-ininstellingen.
Bestandsstructuur ontwikkelaar.yaml het zal heel eenvoudig zijn:
mainorder:
components:
- orderHet raamwerk werkt met configuraties die gegroepeerd zijn. Kies voor onze service een naam voor de groep hoofdorde. Het raamwerk vindt al deze groepen applicaties in het omgevingsbestand en creëert configuraties voor al deze applicaties, die in de corresponderende mappen worden gevonden.
In het service-instellingenbestand zelf bestellen Laten we voorlopig slechts één parameter specificeren:
spring.application.name: orderLaten we nu de plug-in uitvoeren en deze zal de vereiste configuratie voor onze service genereren volgens het pad dat is opgegeven in de eigenschappen:
Men kan en zonder een plug-in te installeren, downloadt u eenvoudigweg de raamwerkdistributie en voert u deze uit vanaf de opdrachtregel.
Deze oplossing is geschikt voor gebruik op een buildserver.
Het is vermeldenswaard dat het raamwerk het perfect begrijpt eigendom syntaxis, dat wil zeggen gewone eigenschappenbestanden die samen kunnen worden gebruikt in YAML configuraties.
Laten we nog een service toevoegen betaling en de bestaande ingewikkelder maken.
В bestellen:
eureka:
instance.preferIpAddress: true
client:
serviceUrl:
defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100В betaling:
eureka:
instance.preferIpAddress: true
client:
serviceUrl:
defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100Het grootste probleem met deze configuraties is de aanwezigheid van een grote hoeveelheid copy-paste in de service-instellingen. Laten we eens kijken hoe het raamwerk zal helpen er vanaf te komen. Laten we beginnen met het meest voor de hand liggende: de aanwezigheid van configuratie eureka in de beschrijving van elke microservice. Laten we een nieuwe map maken met het instellingenbestand en er een nieuwe configuratie aan toevoegen:
En laten we nu de regel aan elk van onze projecten toevoegen #inclusief eureka.
Het raamwerk zal automatisch de eureka-configuratie vinden en deze naar de serviceconfiguratiebestanden kopiëren, terwijl er geen afzonderlijke eureka-configuratie zal worden gemaakt, omdat we deze niet in het omgevingsbestand zullen specificeren ontwikkelaar.yaml. Dienst bestellen:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100We kunnen de database-instellingen ook naar een aparte configuratie verplaatsen door de importregel te wijzigen in #include eureka, orakel.
Het is vermeldenswaard dat het raamwerk elke wijziging bij het opnieuw genereren van configuratiebestanden bijhoudt en deze in een speciaal bestand naast het hoofdconfiguratiebestand plaatst. De vermelding in het logboek ziet er als volgt uit: “Opgeslagen 1-eigenschap verandert in order/diff-application.yaml" Hierdoor kunt u snel wijzigingen in grote configuratiebestanden detecteren.
Door gemeenschappelijke delen van de configuratie te verwijderen, kunt u veel onnodig kopiëren en plakken verwijderen, maar kunt u niet flexibel een configuratie voor verschillende omgevingen maken - de eindpunten van onze services zijn uniek en hard gecodeerd, dit is slecht. Laten we proberen dit te verwijderen.
Een goede oplossing zou zijn om alle eindpunten in één configuratie te houden waar anderen naar kunnen verwijzen. Voor dit doel is ondersteuning voor tijdelijke aanduidingen in het raamwerk geïntroduceerd. Dit is hoe het configuratiebestand zal veranderen eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Laten we nu eens kijken hoe deze tijdelijke aanduiding werkt. Het systeem vindt een component met de naam eindpunten en zoekt er betekenis in eurekaipen vervangt het vervolgens in onze configuratie. Maar hoe zit het met verschillende omgevingen? Om dit te doen, maakt u een instellingenbestand aan in eindpunten het volgende soort applicatie.dev.yaml. Het framework beslist onafhankelijk, op basis van de bestandsextensie, tot welke omgeving deze configuratie behoort en laadt deze:
Inhoud ontwikkelaarbestand:
eurekaip: 192.89.89.111
dbip: 192.168.0.100We kunnen dezelfde configuratie maken voor de poorten van onze services:
server.port: ${ports@order}.Alle belangrijke instellingen bevinden zich op één plek, waardoor de kans op fouten als gevolg van verspreide parameters in configuratiebestanden wordt verkleind.
Het raamwerk biedt veel kant-en-klare tijdelijke aanduidingen, u kunt bijvoorbeeld de naam opvragen van de map waarin het configuratiebestand zich bevindt en deze toewijzen:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Hierdoor is het niet nodig om de applicatienaam extra op te geven in de configuratie en kan deze ook in een gemeenschappelijke module worden geplaatst, bijvoorbeeld in dezelfde eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Het configuratiebestand bestellen wordt teruggebracht tot één regel:
#include eureka, oracle
server.port: ${ports@order}Als we geen instellingen uit de bovenliggende configuratie nodig hebben, kunnen we deze in onze configuratie opgeven en worden deze tijdens het genereren toegepast. Dat wil zeggen, als we om wat voor reden dan ook een unieke naam nodig hebben voor de bestelservice, laten we de parameter gewoon staan spring.applicatie.naam.
Stel dat u aangepaste logboekinstellingen aan de service moet toevoegen, die bijvoorbeeld in een afzonderlijk bestand worden opgeslagen: logback.xml. Laten we er een aparte groep instellingen voor maken:
In de basisconfiguratie vertellen we het raamwerk waar het bestand met loginstellingen moet worden geplaatst, met behulp van een tijdelijke aanduiding @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlIn bestand logback.xml we configureren standaard appenders, die op hun beurt ook tijdelijke aanduidingen kunnen bevatten die het raamwerk zal veranderen tijdens het genereren van configuraties, bijvoorbeeld:
<file>logs/${this@name}.log</file>Door import toe te voegen aan serviceconfiguraties terugloggen, krijgen we automatisch geconfigureerde logboekregistratie voor elke service:
#include eureka, oracle, logback
server.port: ${ports@order}Het is tijd om meer in detail kennis te maken met alle beschikbare tijdelijke aanduidingen van het raamwerk:
${dit@env} - retourneert de naam van de huidige omgeving.
${…@naam} — retourneert de naam van de component.
${…@configDir} — retourneert het volledige pad naar de configuratiemap van de component.
${…@resultDir} — retourneert het volledige pad naar de doelmap van de component (de resulterende bestanden worden in deze map geplaatst).
${dit@configRoot} — retourneert het volledige pad naar de hoofdmap van het configuratiearchief.
Met het systeem kunt u ook omgevingsvariabelen ophalen, bijvoorbeeld het pad naar Java:
${env@JAVA_HOME}
Ofwel, aangezien het raamwerk erin is geschreven JAVA, kunnen we systeemvariabelen krijgen die vergelijkbaar zijn met de aanroep Systeem::getProperty met behulp van een structuur als deze:
${[e-mail beveiligd]}
Het is de moeite waard om ondersteuning voor de extensietaal te vermelden Lente EL. De volgende expressies zijn van toepassing in de configuratie:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} en u kunt lokale variabelen in configuratiebestanden gebruiken met behulp van de expressie #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorHet raamwerk is dus een redelijk krachtig hulpmiddel voor het verfijnen en flexibel configureren van microservices. Het raamwerk vervult perfect zijn hoofdtaak: het elimineren van kopiëren en plakken in instellingen, het consolideren van instellingen en als gevolg daarvan het minimaliseren van mogelijke fouten, terwijl u eenvoudig configuraties kunt combineren en wijzigen voor verschillende omgevingen.
Als je geïnteresseerd bent in dit raamwerk, raad ik je aan de officiële pagina te bezoeken en kennis te maken met het volledige raamwerk , of duik in de bronnen .
Bron: www.habr.com