Mudah mengelola konfigurasi layanan-mikro dengan microconfig.io

Salah satu masalah utama dalam pengembangan dan pengoperasian selanjutnya dari layanan-layanan microsoft adalah penyetelan instans yang kompeten dan akurat. Menurut pendapat saya, kerangka kerja microconfig.io baru dapat membantu. Ini memungkinkan Anda untuk menyelesaikan tugas-tugas rutin pengaturan aplikasi dengan cukup elegan.

Jika Anda memiliki banyak layanan microser, dan masing-masing dilengkapi dengan file sendiri / pengaturan file, maka kemungkinan akan membuat kesalahan di salah satu dari mereka, yang tanpa ketangkasan yang tepat dan sistem logging bisa sangat sulit untuk ditangkap. Tugas utama yang ditetapkan kerangka itu sendiri adalah untuk meminimalkan pengaturan instance duplikat, sehingga mengurangi kemungkinan menambahkan kesalahan.

Mari kita lihat sebuah contoh. Misalkan ada aplikasi sederhana dengan file konfigurasi yaml . Ini bisa berupa layanan microser apa pun dalam bahasa apa pun. Mari kita lihat bagaimana kerangka kerja dapat diterapkan pada layanan ini.

Tetapi pertama-tama, untuk kenyamanan yang lebih besar, kami akan membuat proyek kosong di IDE Idea dengan terlebih dahulu memasang plugin microconfig.io di dalamnya:



Kami mengkonfigurasi konfigurasi peluncuran plugin, Anda dapat menggunakan konfigurasi default, seperti pada tangkapan layar di atas.

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



Dalam folder dengan nama layanan kami meletakkan file konfigurasi - application.yaml . Semua layanan Microsoft diluncurkan dalam beberapa jenis lingkungan, jadi, selain membuat konfigurasi layanan itu sendiri, perlu untuk menggambarkan lingkungan itu sendiri: untuk ini, buat folder envs dan tambahkan file dengan nama lingkungan kerja kami ke dalamnya. Dengan demikian, kerangka kerja akan membuat file konfigurasi untuk layanan di lingkungan dev , karena parameter ini diatur dalam pengaturan di plugin.

Struktur file dev.yaml akan sangat sederhana:

mainorder: components: - order 

Kerangka kerja ini bekerja dengan konfigurasi yang dikelompokkan bersama. Untuk layanan kami, pilih nama untuk grup pesanan utama. Kerangka kerja ini menemukan setiap kelompok aplikasi dalam file lingkungan dan membuat konfigurasi untuk semua yang ditemukan dalam folder yang sesuai.

Dalam file pengaturan layanan pesanan itu sendiri, kami akan mengindikasikan sejauh ini hanya satu parameter:

 spring.application.name: order 

Sekarang jalankan plugin dan itu akan menghasilkan konfigurasi layanan yang diinginkan untuk kita sesuai dengan jalur yang ditentukan dalam properti:



Anda dapat melakukannya tanpa menginstal plugin hanya dengan mengunduh kit distribusi kerangka kerja dan menjalankannya dari baris perintah.
Solusi ini cocok untuk digunakan pada build server.

Perlu dicatat bahwa framework tersebut benar-benar memahami sintaksis properti , yaitu file properti biasa yang dapat digunakan bersama dalam konfigurasi yaml .

Tambahkan satu layanan pembayaran lagi dan tambah rumit layanan yang ada pada saat bersamaan.
Dalam rangka :

 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 

Dalam 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 copy paste dalam pengaturan layanan. Mari kita lihat bagaimana kerangka itu membantu menyingkirkannya. Mari kita mulai dengan yang paling jelas - kehadiran konfigurasi eureka dalam deskripsi setiap layanan Microsoft. Buat direktori baru dengan file pengaturan dan tambahkan konfigurasi baru ke dalamnya:



Dan di setiap proyek kami, kami sekarang akan menambahkan baris #include eureka .

Kerangka kerja akan secara otomatis menemukan konfigurasi eureka dan menyalinnya ke file konfigurasi layanan, sementara konfigurasi eureka terpisah tidak akan dibuat, karena kami tidak akan menentukannya dalam file lingkungan dev.yaml . Pesanan layanan:

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

Kami juga dapat membuat pengaturan basis data dalam konfigurasi terpisah dengan mengubah baris impor ke #include eureka, oracle .

Perlu dicatat bahwa setiap perubahan selama regenerasi file konfigurasi dimonitor kerangka dan menempatkan dalam file khusus di sebelah file konfigurasi utama. Entri di log-nya terlihat seperti ini: "Properti yang disimpan 1 berubah menjadi order / diff-application.yaml ". Ini memungkinkan Anda mendeteksi perubahan dalam file konfigurasi besar dengan cepat.

Menghapus bagian-bagian umum dari konfigurasi memungkinkan Anda untuk menyingkirkan banyak copy-paste yang tidak perlu, tetapi tidak memungkinkan Anda untuk secara fleksibel membuat konfigurasi untuk berbagai lingkungan - titik akhir dari layanan kami adalah unik dan hardcoded, ini buruk. Mari kita coba hapus.

Solusi yang baik adalah menyimpan semua titik akhir dalam satu konfigurasi yang dapat dirujuk oleh yang lain. Untuk melakukan ini, dukungan untuk placeholder telah dimasukkan ke dalam kerangka kerja. Inilah cara perubahan file konfigurasi eureka :

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

Sekarang mari kita lihat bagaimana placeholder ini bekerja. Sistem menemukan komponen bernama endpoint dan mencari eurekaip di dalamnya, dan kemudian menggantinya di konfigurasi kami. Tetapi bagaimana dengan lingkungan yang berbeda? Untuk melakukan ini, buat file pengaturan di titik akhir dari tipe application.dev.yaml berikut. Kerangka kerja secara mandiri, dengan ekstensi file, memutuskan lingkungan mana yang dimiliki oleh konfigurasi ini dan memuatnya:



Isi file dev:

 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 di mana file konfigurasi berada dan menetapkannya:

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

Karena itu, tidak perlu menentukan nama aplikasi tambahan dalam konfigurasi dan juga dapat dipindahkan ke modul umum, misalnya, ke eureka yang sama:

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

File konfigurasi pesanan 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 dalam konfigurasi kita dan itu akan diterapkan selama pembuatan. Artinya, jika karena alasan tertentu kita memerlukan nama unik untuk layanan pesanan, tinggalkan saja parameter spring.application.name .

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



Dalam konfigurasi dasar, kami akan menunjukkan kerangka kerja tempat menempatkan file pengaturan logging yang kami perlukan menggunakan placeholder @ConfigDir:

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

Dalam file logback.xml , kami mengonfigurasi appenders standar, yang pada gilirannya juga dapat berisi placeholder, yang kerangka kerjanya akan berubah selama pembuatan konfigurasi, misalnya:

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

Menambahkan impor logback dalam konfigurasi layanan, kami secara otomatis mendapatkan pendataan yang dikonfigurasi untuk setiap layanan:

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

Saatnya membiasakan diri dengan semua placeholder kerangka yang tersedia secara lebih rinci:

$ {this @ env} - mengembalikan nama lingkungan saat ini.
$ {... @ name} - mengembalikan nama komponen.
$ {... @ configDir} - mengembalikan path lengkap ke direktori config komponen.
$ {... @ resultDir} - mengembalikan path lengkap ke direktori tujuan komponen (file yang diterima akan ditempatkan di direktori ini).
$ {this @ configRoot} - Mengembalikan path lengkap ke direktori root dari toko konfigurasi.

Sistem ini juga memungkinkan Anda untuk mendapatkan variabel lingkungan, misalnya, jalur ke java:
$ {env @ JAVA_HOME}
Atau, karena framework ditulis dalam JAVA , kita bisa mendapatkan variabel sistem yang mirip dengan memanggil System :: getProperty menggunakan konstruk seperti ini:
${system@os.name}
Perlu disebutkan dukungan untuk bahasa ekstensi Spring EL . Dalam konfigurasi, ekspresi serupa berlaku:

 connection.timeoutInMs: #{5 * 60 * 1000} datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} 

dan Anda bisa menggunakan variabel lokal di file konfigurasi menggunakan ekspresi #var :

 #var feedRoot: ${system@user.home}/feed folder: root: ${this@feedRoot} success: ${this@feedRoot}/archive error: ${this@feedRoot}/error 

Dengan demikian, kerangka kerja ini adalah alat yang agak kuat untuk konfigurasi layanan mikro yang halus dan fleksibel. Kerangka kerja dengan sempurna melakukan tugas utamanya - menghilangkan penyalinan pada pengaturan, mengkonsolidasikan pengaturan dan, sebagai hasilnya, meminimalkan kemungkinan kesalahan, sambil membuatnya mudah untuk menggabungkan konfigurasi dan perubahan untuk lingkungan yang berbeda.

Jika Anda tertarik dengan kerangka kerja ini, saya sarankan Anda mengunjungi halaman resminya dan membaca dokumentasi lengkapnya, atau mempelajari sumbernya di sini .