Jednym z głównych problemów w rozwoju i późniejszym działaniu mikroserwisów jest kompetentna i dokładna konfiguracja ich instancji. Moim zdaniem nowe ramy mogą w tym pomóc . Pozwala dość elegancko rozwiązać niektóre rutynowe zadania związane z konfiguracją aplikacji.
Jeśli masz wiele mikroserwisów, a każdy z nich ma swój własny plik/pliki konfiguracyjne, to istnieje duże prawdopodobieństwo popełnienia błędu w którymś z nich, który może być bardzo trudny do wyłapania bez odpowiednich umiejętności i systemu logowania. Głównym zadaniem, jakie stawia przed sobą framework, jest minimalizacja zduplikowanych parametrów konfiguracyjnych instancji, a tym samym zmniejszenie prawdopodobieństwa dodania błędu.
Spójrzmy na przykład. Załóżmy, że mamy prostą aplikację z plikiem konfiguracyjnym jamla. Może to być dowolny mikroserwis w dowolnym języku. Zobaczmy, jak można zastosować framework do tej usługi.
Najpierw jednak dla większej wygody utwórzmy w Idea IDE pusty projekt, po zainstalowaniu w nim wtyczki microconfig.io:
Skonfigurowaliśmy konfigurację uruchamiania wtyczki, możesz skorzystać z konfiguracji domyślnej, jak na zrzucie ekranu powyżej.
Nasza usługa nazywa się porządek, wówczas w nowym projekcie stworzymy podobną strukturę:
Umieść plik konfiguracyjny w folderze o nazwie usługi - aplikacja.yaml. Wszystkie mikrousługi uruchamiane są w jakimś środowisku, dlatego oprócz stworzenia konfiguracji samej usługi konieczne jest opisanie samego środowiska: w tym celu utworzymy folder koperty i dodaj do niego plik z nazwą naszego środowiska pracy. W ten sposób framework utworzy pliki konfiguracyjne dla usług w środowisku dev, ponieważ ten parametr jest ustawiony w ustawieniach wtyczki.
Struktura pliku dev.yaml to będzie całkiem proste:
mainorder:
components:
- orderStruktura współpracuje z konfiguracjami, które są zgrupowane. W przypadku naszej usługi wybierz nazwę grupy główne zamówienie. Framework wyszukuje każdą taką grupę aplikacji w pliku środowiska i tworzy dla nich konfiguracje, które znajduje w odpowiednich folderach.
W samym pliku ustawień usługi zamówienie Określmy na razie tylko jeden parametr:
spring.application.name: orderTeraz uruchommy wtyczkę, która wygeneruje wymaganą konfigurację dla naszej usługi zgodnie ze ścieżką podaną we właściwościach:
Można i bez instalowania wtyczki, wystarczy pobrać dystrybucję frameworka i uruchomić ją z wiersza poleceń.
To rozwiązanie nadaje się do użycia na serwerze kompilacji.
Warto zaznaczyć, że framework doskonale rozumie własność składnia, czyli zwykłe pliki właściwości, których można używać razem w jamla konfiguracje.
Dodajmy kolejną usługę płatność i komplikuje już istniejącą.
В zamówienie:
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В płatność:
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.100Głównym problemem tych konfiguracji jest obecność dużej ilości kopiuj-wklej w ustawieniach usługi. Zobaczmy, jak framework pomoże się go pozbyć. Zacznijmy od najbardziej oczywistego - obecności konfiguracji eureka w opisie każdego mikrousługi. Utwórzmy nowy katalog z plikiem ustawień i dodajmy do niego nową konfigurację:
A teraz dodajmy linię do każdego z naszych projektów #uwzględnij eurekę.
Framework automatycznie znajdzie konfigurację eureka i skopiuje ją do plików konfiguracyjnych usługi, natomiast osobna konfiguracja eureka nie zostanie utworzona, ponieważ nie określimy jej w pliku środowiska dev.yaml. Praca zamówienie:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Możemy również przenieść ustawienia bazy danych do osobnej konfiguracji, zmieniając linię importu na #include eureka, wyrocznia.
Warto zauważyć, że framework śledzi każdą zmianę podczas ponownego generowania plików konfiguracyjnych i umieszcza ją w specjalnym pliku obok głównego pliku konfiguracyjnego. Wpis w dzienniku wygląda następująco: „Zapisano 1 właściwość zmienia się na Order/diff-aplikacja.yaml" Pozwala to szybko wykryć zmiany w dużych plikach konfiguracyjnych.
Usunięcie wspólnych części konfiguracji pozwala pozbyć się dużej ilości niepotrzebnego kopiowania i wklejania, ale nie pozwala na elastyczne tworzenie konfiguracji dla różnych środowisk - punkty końcowe naszych usług są unikalne i zakodowane na stałe, to jest złe. Spróbujmy to usunąć.
Dobrym rozwiązaniem byłoby utrzymanie wszystkich punktów końcowych w jednej konfiguracji, do której inni mogliby się odwoływać. W tym celu wprowadzono do frameworka obsługę symboli zastępczych. W ten sposób zmieni się plik konfiguracyjny eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Zobaczmy teraz, jak działa ten symbol zastępczy. System znajdzie komponent o nazwie Punkty końcowe i szuka w tym sensu eurekaip, a następnie podstawia go do naszej konfiguracji. Ale co z różnymi środowiskami? Aby to zrobić, utwórz plik ustawień w Punkty końcowe następujący typ aplikacja.dev.yaml. Framework samodzielnie na podstawie rozszerzenia pliku decyduje do jakiego środowiska należy dana konfiguracja i wczytuje ją:
Zawartość pliku deweloperskiego:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Tę samą konfigurację możemy stworzyć dla portów naszych usług:
server.port: ${ports@order}.Wszystkie ważne ustawienia znajdują się w jednym miejscu, co zmniejsza prawdopodobieństwo wystąpienia błędów wynikających z rozproszenia parametrów w plikach konfiguracyjnych.
Framework udostępnia wiele gotowych symboli zastępczych, można np. pobrać nazwę katalogu, w którym znajduje się plik konfiguracyjny i przypisać ją:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Dzięki temu nie ma potrzeby dodatkowego podawania nazwy aplikacji w konfiguracji i można ją także umieścić we wspólnym module, np. w tej samej eurece:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Plik konfiguracyjny zamówienie zostanie zredukowany do jednej linii:
#include eureka, oracle
server.port: ${ports@order}Jeśli nie potrzebujemy żadnego ustawienia z konfiguracji nadrzędnej, możemy je określić w naszej konfiguracji i zostanie ono zastosowane podczas generowania. Oznacza to, że jeśli z jakiegoś powodu potrzebujemy unikalnej nazwy dla usługi zamówienia, po prostu zostawimy ten parametr nazwa.wiosny.aplikacji.
Załóżmy, że chcesz dodać do usługi niestandardowe ustawienia rejestrowania, które są przechowywane w osobnym pliku, na przykład logback.xml. Stwórzmy dla niego osobną grupę ustawień:
W podstawowej konfiguracji powiemy frameworkowi, gdzie umieścić potrzebny plik ustawień rejestrowania, używając symbolu zastępczego @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlW pliku logback.xml konfigurujemy standardowe appendery, które z kolei mogą zawierać również symbole zastępcze, które framework zmieni podczas generowania konfiguracji, na przykład:
<file>logs/${this@name}.log</file>Poprzez dodanie importu do konfiguracji usług logback, automatycznie konfigurujemy logowanie dla każdej usługi:
#include eureka, oracle, logback
server.port: ${ports@order}Czas zapoznać się bardziej szczegółowo ze wszystkimi dostępnymi symbolami zastępczymi frameworka:
${this@env} - zwraca nazwę bieżącego środowiska.
${…@imię} — zwraca nazwę komponentu.
${…@configDir} — zwraca pełną ścieżkę do katalogu konfiguracyjnego komponentu.
${…@resultDir} — zwraca pełną ścieżkę do katalogu docelowego komponentu (pliki wynikowe zostaną umieszczone w tym katalogu).
${this@configRoot} — zwraca pełną ścieżkę do katalogu głównego magazynu konfiguracji.
System umożliwia także pobranie zmiennych środowiskowych, np. ścieżki do Java:
${env@JAVA_HOME}
Albo, ponieważ framework jest napisany JAVA, możemy uzyskać zmienne systemowe podobne do wywołania System::getProperty używając takiej struktury:
${[email chroniony]}
Warto wspomnieć o wsparciu dla języka rozszerzenia Wiosna EL. W konfiguracji mają zastosowanie następujące wyrażenia:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} i możesz używać zmiennych lokalnych w plikach konfiguracyjnych za pomocą wyrażenia #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorZatem framework jest dość potężnym narzędziem do dostrajania i elastycznej konfiguracji mikrousług. Framework doskonale spełnia swoje główne zadanie - eliminując kopiowanie-wklejanie w ustawieniach, konsolidując ustawienia i w efekcie minimalizując ewentualne błędy, jednocześnie umożliwiając łatwe łączenie konfiguracji i zmianę ich dla różnych środowisk.
Jeżeli interesuje Cię ten framework to polecam odwiedzić jego oficjalną stronę i zapoznać się z całością albo poszukaj w źródłach .
Źródło: www.habr.com