Salah satu masalah utama dalam pembangunan dan operasi seterusnya bagi perkhidmatan mikro ialah konfigurasi yang cekap dan tepat bagi keadaan mereka. Pada pendapat saya, rangka kerja baharu boleh membantu dalam hal ini . Ia membolehkan anda menyelesaikan beberapa tugas konfigurasi aplikasi rutin dengan agak elegan.
Jika anda mempunyai banyak perkhidmatan mikro, dan setiap daripada mereka dilengkapi dengan fail/fail konfigurasi sendiri, maka terdapat kebarangkalian tinggi untuk membuat ralat dalam salah satu daripada mereka, yang boleh menjadi sangat sukar untuk ditangkap tanpa kemahiran yang betul dan sistem pembalakan. Tugas utama yang ditetapkan oleh rangka kerja untuk dirinya sendiri adalah untuk meminimumkan parameter konfigurasi contoh pendua, dengan itu mengurangkan kemungkinan menambah ralat.
Mari kita lihat satu contoh. Katakan kita mempunyai aplikasi mudah dengan fail konfigurasi keladi. Ini boleh menjadi sebarang perkhidmatan mikro dalam mana-mana bahasa. Mari lihat bagaimana rangka kerja itu boleh digunakan pada perkhidmatan ini.
Tetapi pertama, untuk kemudahan yang lebih baik, mari buat projek kosong dalam Idea IDE, selepas memasang pemalam microconfig.io di dalamnya:
Kami menyediakan konfigurasi pelancaran pemalam, anda boleh menggunakan konfigurasi lalai, seperti dalam tangkapan skrin di atas.
Perkhidmatan kami dipanggil pesanan, maka dalam projek baru kami akan membuat struktur yang serupa:
Letakkan fail konfigurasi dalam folder dengan nama perkhidmatan - permohonan.yaml. Semua perkhidmatan mikro dilancarkan dalam beberapa jenis persekitaran, jadi, sebagai tambahan kepada membuat konfigurasi untuk perkhidmatan itu sendiri, adalah perlu untuk menerangkan persekitaran itu sendiri: untuk ini kami akan membuat folder envs dan tambahkan fail padanya dengan nama persekitaran kerja kami. Oleh itu, rangka kerja akan mencipta fail konfigurasi untuk perkhidmatan dalam persekitaran dev, kerana parameter ini ditetapkan dalam tetapan pemalam.
Struktur fail dev.yaml ia akan menjadi agak mudah:
mainorder:
components:
- orderRangka kerja berfungsi dengan konfigurasi yang dikumpulkan bersama. Untuk perkhidmatan kami, pilih nama untuk kumpulan pesanan utama. Rangka kerja mencari setiap kumpulan aplikasi tersebut dalam fail persekitaran dan mencipta konfigurasi untuk kesemuanya, yang ditemui dalam folder yang sepadan.
Dalam fail tetapan perkhidmatan itu sendiri bagi Mari tentukan hanya satu parameter buat masa ini:
spring.application.name: orderSekarang mari jalankan pemalam, dan ia akan menjana konfigurasi yang diperlukan untuk perkhidmatan kami mengikut laluan yang ditentukan dalam sifat:
boleh dan tanpa memasang pemalam, cuma muat turun pengedaran rangka kerja dan jalankannya daripada baris arahan.
Penyelesaian ini sesuai untuk digunakan pada pelayan binaan.
Perlu diingat bahawa rangka kerja itu difahami dengan sempurna harta sintaks, iaitu, fail harta biasa yang boleh digunakan bersama dalam keladi konfigurasi.
Mari tambah perkhidmatan lain pembayaran dan merumitkan yang sedia ada.
Π bagi:
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.100Masalah utama dengan konfigurasi ini ialah kehadiran sejumlah besar salinan-tampal dalam tetapan perkhidmatan. Mari lihat bagaimana rangka kerja itu akan membantu menyingkirkannya. Mari kita mulakan dengan yang paling jelas - kehadiran konfigurasi eureka dalam penerangan setiap perkhidmatan mikro. Mari buat direktori baharu dengan fail tetapan dan tambahkan konfigurasi baharu padanya:
Dan sekarang mari tambahkan baris pada setiap projek kami #termasuk eureka.
Rangka kerja akan mencari konfigurasi eureka secara automatik dan menyalinnya ke fail konfigurasi perkhidmatan, manakala konfigurasi eureka yang berasingan tidak akan dibuat, kerana kami tidak akan menentukannya dalam fail persekitaran dev.yaml. Perkhidmatan bagi:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Kami juga boleh mengalihkan tetapan pangkalan data ke dalam konfigurasi berasingan dengan menukar baris import kepada #termasuk eureka, oracle.
Perlu diingat bahawa rangka kerja menjejaki setiap perubahan apabila menjana semula fail konfigurasi dan meletakkannya dalam fail khas di sebelah fail konfigurasi utama. Entri dalam lognya kelihatan seperti ini: "1 harta yang disimpan berubah kepada order/diff-application.yaml" Ini membolehkan anda mengesan perubahan pada fail konfigurasi besar dengan cepat.
Mengalih keluar bahagian umum konfigurasi membolehkan anda menyingkirkan banyak salin-tampal yang tidak perlu, tetapi tidak membenarkan anda membuat konfigurasi secara fleksibel untuk persekitaran yang berbeza - titik akhir perkhidmatan kami adalah unik dan berkod keras, ini buruk. Mari cuba keluarkan ini.
Penyelesaian yang baik ialah menyimpan semua titik akhir dalam satu konfigurasi yang boleh dirujuk oleh orang lain. Untuk tujuan ini, sokongan untuk pemegang tempat telah diperkenalkan ke dalam rangka kerja. Beginilah cara fail konfigurasi akan berubah eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Sekarang mari kita lihat cara pemegang tempat ini berfungsi. Sistem mencari komponen bernama titik hujung dan mencari makna di dalamnya eurekaip, dan kemudian menggantikannya ke dalam konfigurasi kami. Tetapi bagaimana dengan persekitaran yang berbeza? Untuk melakukan ini, buat fail tetapan dalam titik hujung jenis berikut application.dev.yaml. Rangka kerja secara bebas, berdasarkan sambungan fail, memutuskan persekitaran yang mana konfigurasi ini dimiliki dan memuatkannya:
Kandungan fail Dev:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Kami boleh membuat konfigurasi yang sama untuk port perkhidmatan kami:
server.port: ${ports@order}.Semua tetapan penting berada di satu tempat, dengan itu mengurangkan kemungkinan ralat disebabkan oleh parameter bertaburan dalam fail konfigurasi.
Rangka kerja menyediakan banyak ruang letak siap sedia, sebagai contoh, anda boleh mendapatkan nama direktori di mana fail konfigurasi terletak dan menetapkannya:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Terima kasih kepada ini, tidak perlu lagi menentukan nama aplikasi dalam konfigurasi dan ia juga boleh diletakkan dalam modul biasa, sebagai contoh, dalam eureka yang sama:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Fail konfigurasi bagi akan dikurangkan kepada satu baris:
#include eureka, oracle
server.port: ${ports@order}Jika kami tidak memerlukan sebarang tetapan daripada konfigurasi induk, kami boleh menentukannya dalam konfigurasi kami dan ia akan digunakan semasa penjanaan. Iaitu, jika atas sebab tertentu kami memerlukan nama unik untuk perkhidmatan pesanan, kami hanya akan meninggalkan parameter tersebut spring.application.name.
Katakan anda perlu menambah tetapan pengelogan tersuai pada perkhidmatan, yang disimpan dalam fail berasingan, contohnya, log masuk.xml. Mari buat kumpulan tetapan yang berasingan untuknya:
Dalam konfigurasi asas, kami akan memberitahu rangka kerja tempat untuk meletakkan fail tetapan pengelogan yang kami perlukan menggunakan ruang letak @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlDalam fail log masuk.xml kami mengkonfigurasi pelengkap standard, yang seterusnya juga boleh mengandungi ruang letak yang rangka kerja akan berubah semasa penjanaan konfigurasi, contohnya:
<file>logs/${this@name}.log</file>Dengan menambahkan import pada konfigurasi perkhidmatan log masuk, kami secara automatik mendapat pengelogan yang dikonfigurasikan untuk setiap perkhidmatan:
#include eureka, oracle, logback
server.port: ${ports@order}Tiba masanya untuk berkenalan dengan lebih terperinci dengan semua ruang letak rangka kerja yang tersedia:
${this@env} - mengembalikan nama persekitaran semasa.
${β¦@name} β mengembalikan nama komponen.
${β¦@configDir} β mengembalikan laluan penuh ke direktori konfigurasi komponen.
${β¦@resultDir} β mengembalikan laluan penuh ke direktori destinasi komponen (fail yang terhasil akan diletakkan dalam direktori ini).
${this@configRoot} β mengembalikan laluan penuh ke direktori akar stor konfigurasi.
Sistem ini juga membolehkan anda mendapatkan pembolehubah persekitaran, contohnya laluan ke java:
${env@JAVA_HOME}
Sama ada, kerana rangka kerja ditulis dalam Jawa, kita boleh mendapatkan pembolehubah sistem yang serupa dengan panggilan Sistem::getProperty menggunakan struktur seperti ini:
${[e-mel dilindungi]}
Perlu disebut sokongan untuk bahasa sambungan EL musim bunga. Ungkapan berikut boleh digunakan dalam konfigurasi:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} dan anda boleh menggunakan pembolehubah tempatan dalam fail konfigurasi menggunakan ungkapan #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorOleh itu, rangka kerja adalah alat yang cukup berkuasa untuk menala halus dan konfigurasi perkhidmatan mikro yang fleksibel. Rangka kerja memenuhi tugas utamanya dengan sempurna - menghapuskan salin-tampal dalam tetapan, menyatukan tetapan dan, sebagai hasilnya, meminimumkan kemungkinan ralat, sambil membolehkan anda menggabungkan konfigurasi dengan mudah dan mengubahnya untuk persekitaran yang berbeza.
Jika anda berminat dengan rangka kerja ini, saya cadangkan melawati halaman rasminya dan berkenalan dengan sepenuhnya , atau gali sumbernya .
Sumber: www.habr.com