Kelola konfigurasi layanan mikro dengan mudah menggunakan microconfig.io

Salah satu masalah utama dalam pengembangan dan pengoperasian layanan mikro selanjutnya adalah konfigurasi instance yang kompeten dan akurat. Menurut pendapat saya, kerangka kerja baru dapat membantu dalam hal ini mikroconfig.io. Ini memungkinkan Anda menyelesaikan beberapa tugas konfigurasi aplikasi rutin dengan cukup elegan.

Jika Anda memiliki banyak layanan mikro, dan masing-masing layanan tersebut dilengkapi dengan file/file konfigurasinya sendiri, maka kemungkinan besar terjadi kesalahan pada salah satu layanan tersebut, yang bisa sangat sulit ditangkap tanpa keahlian dan sistem logging yang tepat. Tugas utama yang ditetapkan kerangka kerja itu sendiri adalah meminimalkan duplikat parameter konfigurasi instance, sehingga mengurangi kemungkinan penambahan kesalahan.

Mari kita lihat sebuah contoh. Katakanlah kita memiliki aplikasi sederhana dengan file konfigurasi yaml. Ini bisa berupa layanan mikro apa pun dalam bahasa apa pun. Mari kita lihat bagaimana kerangka kerja tersebut dapat diterapkan pada layanan ini.

Tapi pertama-tama, untuk kenyamanan lebih, mari kita buat proyek kosong di Idea IDE, setelah menginstal plugin microconfig.io di dalamnya:

Kami mengatur konfigurasi peluncuran plugin, Anda dapat menggunakan konfigurasi default, seperti pada gambar di atas.

Layanan kami disebut pesanan, maka dalam proyek baru kami akan membuat struktur serupa:

Tempatkan file konfigurasi di folder dengan nama layanan - aplikasi.yaml. Semua layanan mikro diluncurkan di beberapa jenis lingkungan, jadi, selain membuat konfigurasi untuk layanan itu sendiri, perlu dijelaskan lingkungan itu sendiri: untuk ini kita akan membuat folder envs dan tambahkan file ke dalamnya dengan nama lingkungan kerja kita. Dengan demikian, kerangka kerja akan membuat file konfigurasi untuk layanan di lingkungan dev, karena parameter ini diatur dalam pengaturan plugin.

Struktur file dev.yaml itu akan sangat sederhana:

mainorder:
    components:
         - order

Kerangka kerja ini bekerja dengan konfigurasi yang dikelompokkan bersama. Untuk layanan kami, pilih nama grup pesanan utama. Kerangka kerja ini menemukan setiap grup aplikasi tersebut di file lingkungan dan membuat konfigurasi untuk semuanya, yang ditemukan di folder terkait.

Dalam file pengaturan layanan itu sendiri urutan Mari tentukan hanya satu parameter untuk saat ini:

spring.application.name: order

Sekarang mari kita jalankan pluginnya, dan itu akan menghasilkan konfigurasi yang diperlukan untuk layanan kita sesuai dengan jalur yang ditentukan di properti:

Satu dapat lewati dan tanpa menginstal plugin, cukup unduh distribusi kerangka kerja dan jalankan dari baris perintah.
Solusi ini cocok untuk digunakan pada server build.

Perlu dicatat bahwa ia memahami kerangka kerja dengan sempurna milik sintaksis, yaitu file properti biasa yang dapat digunakan bersama-sama yaml konfigurasi.

Mari tambahkan layanan lain pembayaran dan mempersulit yang sudah ada.
В urutan:

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

В pembayaran:

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.100

Masalah utama dengan konfigurasi ini adalah adanya sejumlah besar salin-tempel di pengaturan layanan. Mari kita lihat bagaimana kerangka kerja ini akan membantu menghilangkannya. Mari kita mulai dengan hal yang paling jelas - ketersediaan konfigurasi telah kudapat dalam deskripsi setiap layanan mikro. Mari buat direktori baru dengan file pengaturan dan tambahkan konfigurasi baru ke dalamnya:

Dan sekarang mari tambahkan baris ke setiap proyek kita #sertakan eureka.

Kerangka kerja akan secara otomatis menemukan konfigurasi eureka dan menyalinnya ke file konfigurasi layanan, sedangkan konfigurasi eureka terpisah tidak akan dibuat, karena kami tidak akan menentukannya di file lingkungan dev.yaml. Melayani urutan:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

Kita juga dapat memindahkan pengaturan database ke dalam konfigurasi terpisah dengan mengubah baris impor menjadi #termasuk eureka, oracle.

Perlu dicatat bahwa kerangka kerja melacak setiap perubahan saat membuat ulang file konfigurasi dan menempatkannya dalam file khusus di sebelah file konfigurasi utama. Entri di lognya terlihat seperti ini: “1 properti tersimpan berubah menjadi pesanan/diff-application.yaml" Ini memungkinkan Anda mendeteksi perubahan pada file konfigurasi besar dengan cepat.

Menghapus bagian umum dari konfigurasi memungkinkan Anda menghilangkan banyak salin-tempel yang tidak perlu, tetapi tidak memungkinkan Anda membuat konfigurasi secara fleksibel untuk lingkungan yang berbeda - titik akhir layanan kami unik dan berkode keras, ini buruk. Mari kita coba untuk menghapus ini.

Solusi yang baik adalah menjaga semua titik akhir dalam satu konfigurasi yang dapat dirujuk oleh orang lain. Untuk tujuan ini, dukungan untuk placeholder telah diperkenalkan ke dalam kerangka kerja. Ini adalah bagaimana file konfigurasi akan berubah telah kudapat:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

Sekarang mari kita lihat cara kerja placeholder ini. Sistem menemukan komponen bernama endpoint dan mencari makna di dalamnya eurekaip, dan kemudian menggantinya ke dalam konfigurasi kita. Tapi bagaimana dengan lingkungan yang berbeda? Untuk melakukan ini, buat file pengaturan di endpoint tipe berikut aplikasi.dev.yaml. Kerangka kerja secara mandiri, berdasarkan ekstensi file, memutuskan lingkungan mana yang termasuk dalam konfigurasi ini dan memuatnya:

Isi file pengembang:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Kami dapat membuat konfigurasi yang sama untuk port layanan kami:

server.port: ${ports@order}.

Semua pengaturan penting ada di satu tempat, sehingga mengurangi kemungkinan kesalahan karena parameter yang tersebar di file konfigurasi.

Kerangka kerja ini menyediakan banyak placeholder yang sudah jadi, misalnya, Anda bisa mendapatkan nama direktori tempat file konfigurasi berada dan menetapkannya:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

Berkat ini, tidak perlu lagi menentukan nama aplikasi dalam konfigurasi dan itu juga dapat ditempatkan di modul umum, misalnya, di eureka yang sama:

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

File konfigurasi urutan akan dikurangi menjadi satu baris:

#include eureka, oracle
server.port: ${ports@order}

Jika kita tidak memerlukan pengaturan apa pun dari konfigurasi induk, kita dapat menentukannya di konfigurasi kita dan itu akan diterapkan selama pembuatan. Artinya, jika karena alasan tertentu kita memerlukan nama unik untuk layanan pemesanan, kita tinggalkan saja parameternya spring.aplikasi.nama.

Katakanlah Anda perlu menambahkan pengaturan logging khusus ke layanan, yang disimpan dalam file terpisah, misalnya, logback.xml. Mari buat grup pengaturan terpisah untuknya:

Dalam konfigurasi dasar, kami akan memberi tahu kerangka kerja di mana menempatkan file pengaturan logging yang kami perlukan menggunakan placeholder @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

Dalam file logback.xml kami mengonfigurasi penambahan standar, yang pada gilirannya juga dapat berisi placeholder yang akan diubah oleh kerangka kerja selama pembuatan konfigurasi, misalnya:

<file>logs/${this@name}.log</file>

Dengan menambahkan impor ke konfigurasi layanan masuk kembali, kami secara otomatis mengonfigurasi logging untuk setiap layanan:

#include eureka, oracle, logback
server.port: ${ports@order}

Saatnya untuk mengenal lebih detail semua placeholder kerangka kerja yang tersedia:

${ini@env} - mengembalikan nama lingkungan saat ini.
${…@nama} — mengembalikan nama komponen.
${…@configDir} — mengembalikan path lengkap ke direktori konfigurasi komponen.
${…@resultDir} — mengembalikan path lengkap ke direktori tujuan komponen (file yang dihasilkan akan ditempatkan di direktori ini).
${ini@configRoot} — mengembalikan path lengkap ke direktori root penyimpanan konfigurasi.

Sistem ini juga memungkinkan Anda mendapatkan variabel lingkungan, misalnya jalur ke java:
${env@JAVA_HOME}
Baik, karena kerangkanya sudah tertulis JAWA, kita bisa mendapatkan variabel sistem yang mirip dengan panggilan Sistem::getProperty menggunakan struktur seperti ini:
${[email dilindungi]}
Perlu disebutkan dukungan untuk bahasa ekstensi musim semi EL. Ekspresi berikut berlaku dalam konfigurasi:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

dan Anda dapat menggunakan variabel lokal dalam file konfigurasi menggunakan ekspresi #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Dengan demikian, kerangka kerja ini merupakan alat yang cukup ampuh untuk menyempurnakan dan mengkonfigurasi layanan mikro secara fleksibel. Kerangka kerja ini dengan sempurna memenuhi tugas utamanya - menghilangkan salin-tempel dalam pengaturan, mengkonsolidasikan pengaturan dan, sebagai hasilnya, meminimalkan kemungkinan kesalahan, sekaligus memungkinkan Anda menggabungkan konfigurasi dengan mudah dan mengubahnya untuk lingkungan yang berbeda.

Jika Anda tertarik dengan framework ini, saya sarankan untuk mengunjungi halaman resminya dan membaca selengkapnya dokumentasi, atau gali sumbernya di sini.

Sumber: www.habr.com