بسهولة إدارة تكوينات microservice مع microconfig.io

واحدة من المشاكل الرئيسية في تطوير وتشغيل ما يلي من خدمات microsing هو ضبط دقيقة ودقيقة من الحالات الخاصة بهم. في رأيي ، يمكن أن يساعد إطار microconfig.io الجديد. إنها تتيح لك حل بعض المهام الروتينية لإعداد التطبيقات بأناقة.

إذا كان لديك الكثير من الخدمات المصغرة ، ويأتي كل منها بملفات الملفات / الإعدادات الخاصة به ، فمن المحتمل أن يرتكب خطأ في أحدها ، وهو ما قد يصعب للغاية التقاطه بدون مهارة مناسبة ونظام تسجيل. تتمثل المهمة الرئيسية التي يحددها إطار العمل في تقليل إعدادات النسخ المكررة إلى الحد الأدنى ، وبالتالي تقليل احتمالية إضافة خطأ.

لنلقِ نظرة على مثال. افترض أن هناك تطبيقًا بسيطًا به ملف تكوين yaml . يمكن أن يكون أي microservice بأي لغة. دعونا نرى كيف يمكن تطبيق الإطار على هذه الخدمة.

ولكن أولاً ، لمزيد من الراحة ، سننشئ مشروعًا فارغًا في Idea IDE عن طريق تثبيت البرنامج المساعد microconfig.io أولاً فيه:



نحن تكوين تكوين إطلاق البرنامج المساعد ، يمكنك استخدام التكوين الافتراضي ، كما هو الحال في الصورة أعلاه.

تسمى خدمتنا النظام ، ثم في مشروع جديد سننشئ بنية مماثلة:



في المجلد الذي يحمل اسم الخدمة ، نضع ملف التكوين - application.yaml . يتم تشغيل جميع الخدمات المصغرة في نوع من البيئة ، لذلك ، بالإضافة إلى إنشاء تهيئة الخدمة نفسها ، تحتاج إلى وصف البيئة نفسها: لهذا ، قم بإنشاء مجلد envs وإضافة ملف باسم بيئة العمل الخاصة بنا إليه. وبالتالي ، سيقوم الإطار بإنشاء ملفات التكوين للخدمات في بيئة التطوير ، حيث يتم تعيين هذه المعلمة في الإعدادات في البرنامج المساعد.

ستكون بنية ملف dev.yaml بسيطة جدًا:

mainorder: components: - order 

يعمل الإطار مع التكوينات التي تم تجميعها معًا. لخدمتنا ، حدد اسمًا لمجموعة mainorder . يبحث الإطار عن كل مجموعة من هذه التطبيقات في ملف البيئة وينشئ تكوينات لكل منهم يجدها في المجلدات المقابلة.

في ملف إعدادات خدمة الطلب نفسه ، سنشير إلى معلمة واحدة فقط حتى الآن:

 spring.application.name: order 

الآن قم بتشغيل المكون الإضافي وسوف يولد التكوين المطلوب لخدمتنا بالنسبة لنا وفقًا للمسار المحدد في الخصائص:



يمكنك الاستغناء عن تثبيت المكون الإضافي عن طريق تنزيل مجموعة التوزيع الخاصة بالإطار وتشغيله من سطر الأوامر.
هذا الحل مناسب للاستخدام على خادم الإنشاء.

تجدر الإشارة إلى أن الإطار يفهم تمامًا بناء جملة الخاصية ، أي ملفات الخصائص العادية التي يمكن استخدامها معًا في تكوينات yaml .

أضف خدمة دفع أخرى وقم بتعقيد الخدمة الحالية في نفس الوقت.
بالترتيب :

 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 

في الدفع :

 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 

المشكلة الرئيسية في هذه التكوينات هي وجود كمية كبيرة من لصق النسخ في إعدادات الخدمة. دعونا نرى كيف يساعد إطار العمل على التخلص منه. لنبدأ بالأكثر وضوحًا - وجود تكوين eureka في وصف كل خدمة microservice. قم بإنشاء دليل جديد باستخدام ملف الإعدادات وإضافة تكوين جديد إليه:



وفي كل مشروع من مشاريعنا ، سنضيف الآن السطر # تضمين eureka .

سيعثر الإطار تلقائيًا على تكوين eureka ونسخه إلى ملفات تكوين الخدمة ، في حين لن يتم إنشاء تكوين منفصل لـ eureka ، حيث أننا لن نحدده في ملف بيئة dev.yaml . طلب الخدمة:

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

يمكننا أيضًا إعداد إعدادات قاعدة البيانات في تكوين منفصل عن طريق تغيير خط الاستيراد إلى #include eureka ، oracle .

تجدر الإشارة إلى أن كل تغيير أثناء تجديد ملفات التكوين يراقب إطار العمل ويضعه في ملف خاص بجوار ملف التكوين الرئيسي. يبدو الإدخال في سجله كما يلي: "تتغير خاصية 1 المخزنة إلى order / diff-application.yaml ". يسمح لك هذا باكتشاف التغييرات في ملفات التكوين الكبيرة بسرعة.

تتيح لك إزالة الأجزاء الشائعة من التكوين التخلص من العديد من نسخ النسخ غير الضرورية ، ولكن لا تسمح لك بإنشاء تهيئة مرنة لمختلف البيئات - نقاط النهاية في خدماتنا فريدة ومفردة ، وهذا أمر سيء. دعنا نحاول إزالته.

الحل الجيد هو الاحتفاظ بجميع نقاط النهاية في تكوين واحد يمكن أن يشير إليها الآخرون. للقيام بذلك ، تم تقديم دعم العناصر النائبة في الإطار. إليك كيفية تغيير ملف تكوين eureka :

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

الآن دعونا نرى كيف يعمل هذا العنصر النائب. يعثر النظام على مكون يسمى نقاط النهاية ويبحث عن eurekaip فيه ، ثم يستبدله في التكوين الخاص بنا. ولكن ماذا عن البيئات المختلفة؟ للقيام بذلك ، قم بإنشاء ملف الإعدادات في نقاط النهاية من النوع التالي application.dev.yaml . يحدد إطار العمل بشكل مستقل ، بواسطة امتداد الملف ، البيئة التي ينتمي إليها هذا التكوين ويقوم بتحميلها:



محتويات ملف ديف:

 eurekaip: 192.89.89.111 dbip: 192.168.0.100 

يمكننا إنشاء نفس التكوين لمنافذ خدماتنا:

 server.port: ${ports@order}. 

جميع الإعدادات المهمة في مكان واحد ، مما يقلل من احتمال حدوث خطأ بسبب المعلمات المنتشرة في ملفات التكوين.

يوفر إطار العمل العديد من العناصر النائبة الجاهزة ، على سبيل المثال ، يمكنك الحصول على اسم الدليل الذي يوجد به ملف التكوين وتعيينه:

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

بسبب هذا ، ليست هناك حاجة لتحديد اسم التطبيق بشكل إضافي في التكوين ويمكن أيضًا نقله إلى وحدة نمطية مشتركة ، على سبيل المثال ، إلى eureka نفسه:

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

سيتم تقليل ملف تكوين الطلب إلى سطر واحد:

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

في حالة عدم حاجتنا إلى أي إعداد من التكوين الأصل ، يمكننا تحديده في التكوين الخاص بنا وسيتم تطبيقه أثناء الإنشاء. وهذا هو ، إذا كنا نحتاج إلى اسم فريد لخدمة الطلب لسبب ما ، فما عليك سوى ترك المعلمة spring.application.name .

لنفترض أنك بحاجة إلى إضافة إعدادات تسجيل مخصصة إلى الخدمة ، والتي يتم تخزينها في ملف منفصل ، على سبيل المثال ، logback.xml . قم بإنشاء مجموعة منفصلة من الإعدادات لها:



في التكوين الأساسي ، سنشير إلى إطار عمل وضع ملف إعدادات التسجيل الذي نحتاج إليه باستخدام العنصر النائب ConfigDir:

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

في ملف logback.xml ، نقوم بتكوين أجهزة إلحاق قياسية ، والتي بدورها يمكن أن تحتوي أيضًا على عناصر نائب ، والتي سيتغير إطار العمل أثناء إنشاء التكوينات ، على سبيل المثال:

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

إضافة استيراد logback في تكوين الخدمة ، نحصل تلقائيًا على التسجيل المكون لكل خدمة:

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

لقد حان الوقت للتعرف على جميع العناصر النائبة المتاحة في الإطار بمزيد من التفاصيل:

$ {this @ env} - يُرجع اسم البيئة الحالية.
$ {... @ name} - بإرجاع اسم المكون.
$ {... @ configDir} - بإرجاع المسار الكامل إلى دليل التكوين للمكون.
$ {... @ resultDir} - يُرجع المسار الكامل إلى الدليل الوجهة للمكون (سيتم وضع الملفات المستلمة في هذا الدليل).
$ {this @ configRoot} - إرجاع المسار الكامل إلى الدليل الجذر لمخزن التكوين.

يسمح لك النظام أيضًا بالحصول على متغيرات البيئة ، على سبيل المثال ، المسار إلى java:
$ {env @ JAVA_HOME}
أو نظرًا لأن الإطار مكتوب في JAVA ، يمكننا الحصول على متغيرات النظام المشابهة لاستدعاء System :: getProperty باستخدام بنية مثل هذا:
${system@os.name}
تجدر الإشارة إلى دعم لغة تمديد Spring EL . في التكوين ، تكون التعبيرات المماثلة قابلة للتطبيق:

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

ويمكنك استخدام المتغيرات المحلية في ملفات التكوين باستخدام تعبير #var :

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

وبالتالي ، فإن الإطار هو أداة قوية إلى حد ما لتكوين غرامة ومرنة من الخدمات المجهرية. يفي إطار العمل بمهمته الرئيسية تمامًا - التخلص من لصق النسخ في الإعدادات ، ودمج الإعدادات ، ونتيجة لذلك ، تقليل الأخطاء المحتملة ، مع تسهيل الجمع بين التكوينات والتغيير لبيئات مختلفة.

إذا كنت مهتمًا بهذا الإطار ، فإنني أوصيك بزيارة صفحته الرسمية وقراءة الوثائق كاملة ، أو الاطلاع على المصدر هنا .