تطبيق الخدمات المصغرة في بيئات الإنتاج

إنفورماتيك ديجيتال » موارد » تطبيق الخدمات المصغرة في بيئات الإنتاج

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

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

لماذا يتم نشر الخدمات المصغرة في بيئة الإنتاج (ومتى لا يكون ذلك مجديًا)

تتيح لك بنية الخدمات المصغرة المصممة جيدًا العمل مع فرق صغيرة ومستقلة ومتعددة الوظائف تتولى هذه الفرق مسؤولية خدمة متكاملة. يعمل كل فريق ضمن سياق محدد بوضوح، ويمكنه النشر بشكل متكرر، ويتحمل المسؤولية الكاملة عن خدمته، مما يقلل من وقت دورة التطوير ويسرع من تقديم الميزات الجديدة.

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

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

من وجهة نظر تكنولوجية، تعزز الخدمات المصغرة حرية اختيار اللغات والأطر وقواعد البيانات لكل خدمة. لا تتناسب جميع الاحتياجات مع نفس مجموعة التقنيات: فقد تكون لديك خدمات أعمال مكتوبة بلغة .NET أو Java، ومعالجة بيانات مكتوبة بلغة Scala/Spark، وخدمات متخصصة مكتوبة بلغة Python أو F#، أو خدمات مصغرة للذكاء الاصطناعي مكتوبة بلغة R. يتيح لك هذا التنوع المُتحكم فيه استخدام الأداة المناسبة لكل حالة، دون جر التطبيق بأكمله إلى تغيير تقني شامل.

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

التصميم المعماري وتصميم الخدمات

لكي تعمل الخدمات المصغرة بشكل جيد في بيئة الإنتاج، يجب أن تبدأ بـ التصميم الدقيق لحدود الخدمة والمسؤولياتمن الناحية العملية، يبدأ الأمر عادةً بتحديد الخدمات ذات الحبيبات الخشنة داخل النظام المتجانس الحالي: المجالات الوظيفية الكبيرة أو مجالات الأعمال (مثل الطلبات، والكتالوج، والمستخدمين، والفواتير) التي تتمتع بالفعل ببعض الفصل المنطقي.

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

يجب أن تحتوي واجهات برمجة التطبيقات التي تعرض هذه الخدمات على عقود محددة بوضوح ومستقرةيتضمن ذلك توثيقًا دقيقًا (REST مع OpenAPI، و gRPC مع ملفات .proto، وما إلى ذلك)، وإصدارًا صريحًا، والحفاظ على التوافق مع الإصدارات السابقة حيثما أمكن، وأتمتة التحقق من صحة العقد لاكتشاف التغييرات الجذرية قبل وصولها إلى مرحلة الإنتاج.

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

في العديد من الأنظمة المعقدة، تتعايش خدمات CRUD البسيطة نسبيًا مع خدمات أكثر تطورًا تركز على تغيير قواعد العمل. لا تحتاج جميع الخدمات المصغرة إلى بنية داخلية معقدةقد يكون بعضها وحدات تحكم HTTP بسيطة مع وصول أساسي للبيانات، بينما قد تستفيد وحدات أخرى، مثل خدمة الطلبات أو الفوترة، من أنماط أكثر تقدماً (DDD، CQRS، أحداث المجال، إلخ).

البنية التحتية للإنتاج: الحوسبة السحابية، والحاويات، وKubernetes/OpenShift

تُظهر التجارب العملية أن الخدمات المصغرة تتناسب بشكل أفضل عند نشرها على بنية تحتية سحابية مع حاويات وتنسيق مقارنةً بالأجهزة الافتراضية المعزولة. توفر منصات مثل Kubernetes وOpenShift الأدوات الأساسية اللازمة لتغليف الخدمات في حاويات، وتوسيع نطاقها، وترقيتها، وموازنة الأحمال، وإدارة التوافر العالي.

عادةً، كل خدمة مصغرة هي صورة عبوة داخل حاوية، مستندة إلى صورة أساسية للشركة. (على سبيل المثال، OpenJDK 21 لخدمات Java) تحت إشراف فريق البنية التحتية. يتم تحديث هذه الصورة الأساسية باستمرار بأحدث التصحيحات الأمنية، وعند إصدار نسخة جديدة، تتولى فرق التطوير مسؤولية إعادة بناء خدماتها ونشرها في البيئات المناسبة.

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

يتم تطبيق التوسع التلقائي باستخدام المقياس التلقائي للكبسولة الأفقية (HPA)يُعدّل هذا عدد النسخ المتماثلة بناءً على مقاييس مثل وحدة المعالجة المركزية والذاكرة أو غيرها من المقاييس المخصصة. كما يجب على المنصة تهيئة قواعد منع التقارب بين وحدات التشغيل (pods) بحيث يتم توزيع نسخ الخدمة نفسها على عُقد مختلفة، مما يمنع تعطل أي عُقدة من إيقاف جميع النسخ.

فيما يتعلق بالأبعاد الرأسية، فإنها تلعب بـ الموارد.الطلبات والموارد.الحدود لتحديد نطاق موارد وحدة المعالجة المركزية والذاكرة التي يمكن أن يستهلكها التطبيق. على سبيل المثال، حجز حد أدنى قدره 100 ميجابايت من وحدة المعالجة المركزية و256 ميجابايت من الذاكرة، والسماح بما يصل إلى 500 ميجابايت و2 جيجابايت على التوالي في خدمة جافا، مع ضبط إعدادات JVM (Xms، Xmx، Xss) لتحقيق الاستخدام الأمثل لموارد الحاوية.

إدارة الحالة: الخدمات المصغرة عديمة الحالة والخدمات المصغرة ذات الحالة

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

ومع ذلك، هناك سيناريوهات لا يوجد فيها خيار آخر سوى الـ الخدمات المصغرة ذات الحالة المدعومة بوحدات تخزين دائمةينطبق هذا على بعض قواعد البيانات، وأنظمة الملفات الموزعة، أو المكونات التي تتطلب الاحتفاظ بالبيانات المحلية. عادةً ما يتم نشر هذه الوحدات باستخدام StatefulSets، وربطها بوحدات التخزين الدائمة باستخدام PersistentVolumeClaims، وتتوسع رأسيًا بدلاً من أفقيًا.

عندما تحتاج خدمة مصغرة إلى تخزين دائم، فإن مطالبة وحدة التخزين الدائمة (PVC) مع الحجم، وطريقة الوصول، والاستخدام المقصوديتولى فريق العمليات مسؤولية توفير هذه الوحدة وفقًا لسياسات المنصة. ويُشار إلى هذه الوحدة الدائمة (PVC) في بيان النشر، ويتم تثبيتها على الحاوية (pod) لتمكين الخدمة من قراءة البيانات وكتابتها بشكل مستمر.

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

لامركزية البيانات وسيادة الخدمات

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

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

هذا لا يعني عدم وجود تكامل بين البيانات: بل يعني أن تتم إدارة التناسق بين الخدمات باستخدام الأحداث والرسائل غير المتزامنةقبول الاتساق النهائي عند المعقول. من الشائع استخدام ناقلات الأحداث (مثل RabbitMQ وAzure Service Bus وKafka وغيرها) لنشر تغييرات الحالة بين الخدمات المصغرة، مما يقلل الاعتماد الشديد على قاعدة بيانات واحدة.

تسهل منصة الحوسبة السحابية على الفرق اختيار نوع قاعدة البيانات الأمثل لكل خدمة (علاقاتية، قائمة على المستندات، مفتاح-قيمة، سلاسل زمنية، إلخ)، دون فرض تقنية واحدة. المهم هو أن يراعي التصميم إمكانية نقل المخططات والهياكل دون الإخلال بالعقود مع الخدمات الأخرى، وأن تُتخذ قرارات البيانات بما يتوافق مع حدود نطاق كل خدمة مصغرة.

الحوكمة والفرق والتنظيم الموزع

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

يتحمل كل فريق مسؤولية خدمة مصغرة واحدة أو أكثر ضمن نفس المجال الوظيفي، ويتولى مسؤولية كل من التطوير كعملية (أنت تبنيه، أنت تديره)هذا يعني أن الفريق يدير خطوط أنابيب التكامل المستمر/التسليم المستمر (CI/CD)، ويتعاون مع قسم البنية التحتية لتلبية الاحتياجات الخاصة، ويشارك في رصد الحوادث والاستجابة لها. ويركز قسم البنية التحتية ومنصة الحوسبة السحابية على توفير خدمات مشتركة وموحدة.

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

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

التكامل المستمر/التسليم المستمر، والأتمتة، ونموذج GitOps

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

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

يتضمن كل مستودع للخدمات المصغرة عادةً ملف Dockerfile موحد، وهو ملف تكوين لخط الأنابيب (على سبيل المثال، ci.json)خصائص لتحليل الجودة ودليل نشر يحتوي على تعريفات Kubernetes (Kustomize أو Helm) مفصولة حسب البيئة. تعمل خطافات الويب الخاصة بالمستودع على تشغيل خط الأنابيب عند حدوث أحداث مثل دفع العلامات أو طلبات الدمج.

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

الإعدادات والأسرار والأمان

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

تُدار الأسرار (بيانات الاعتماد، والمفاتيح، والرموز المميزة، والشهادات) باستخدام سياسات أمنية صارمةفي البيئات الأقل أهمية، قد يكون من المقبول الاحتفاظ بها كنص عادي يديره فريق التطوير، ولكن في مرحلة ما قبل الإنتاج والإنتاج، يوصى بتشفيرها باستخدام أدوات مثل Sealed Secrets أو مديري السحابة الخارجية المحددة.

عندما يلزم مشاركة سر بين عدة خدمات (على سبيل المثال، بيانات اعتماد جامع بيانات OTEL أو مخزن مفاتيح مشتركيمكن مركزة هذا في مستودع تكوين لكل مساحة اسم. وتنسق المشاريع التي تشترك في مساحة الاسم هذه لتحديثها عند الضرورة، مع الحفاظ على التحكم في من يمكنه قراءة هذه الموارد أو تعديلها.

في مجال أمن الاتصالات، النمط السائد هو صفر الثقةلا يُفترض أي شيء لمجرد أن حركة البيانات "داخلية". يجب توثيق جميع المكالمات بين الخدمات، سواء الداخلية أو الخارجية، وتفويضها، ويُفضل استخدام بروتوكول mTLS أو رموز JWT أو آليات مماثلة. لا تُفوّض الخدمات المصغّرة مسؤولية الأمان إلى مدير واجهة برمجة التطبيقات أو الشبكة بشكل أعمى، بل تُجري عمليات التحقق الخاصة بها.

التواصل بين الخدمات المصغرة وواجهات برمجة التطبيقات والرسائل

في بنية الخدمات المصغرة المتطورة، تُقسّم طبقة الاتصال إلى عدة حالات. بالنسبة لحركة البيانات من العملاء (المتصفحات، تطبيقات الجوال، الجهات الخارجية) إلى الواجهة الخلفية، تُستخدم الحالات التالية: يتم نشر واجهات برمجة التطبيقات وإدارتها من خلال مدير واجهات برمجة التطبيقاتعادة ما تكون واجهات برمجة التطبيقات هذه من نوع REST (غالبًا باستخدام OpenAPI) أو، في بعض الحالات، gRPC يتم عرضها من خلال بوابة.

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

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

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

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

إمكانية المراقبة، جامع بيانات OTEL وتشغيله

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

يُعدّ العنصر الأساسي في هذا المخطط هو جامع بيانات القياس عن بعد المفتوح (جامع بيانات القياس عن بعد المفتوح)يتم نشر هذا النظام في نطاق الاسم أو مركزيًا لجمع المقاييس والسجلات والبيانات من جميع المكونات. كل ما تحتاجه الخدمات المصغرة هو معرفة أنها يجب أن ترسل بيانات القياس عن بُعد إلى المُجمِّع؛ ثم يقوم المُجمِّع بإعادة توجيهها إلى أنظمة المراقبة (بروميثيوس، جرافانا، جايجر، إيلاستيك، إلخ) دون أن تحتاج الخدمة إلى معرفة التفاصيل.

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

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

استراتيجية الاختبار، والعقود، والخبرة في التطوير المحلي

يتطلب اختبار بنية الخدمات المصغرة الموزعة ما يلي: استراتيجية اختبار أكثر تفصيلا مقارنةً بالبنية المتجانسة. تظل اختبارات الوحدة أساسية، لكن اختبارات العقود (لواجهات برمجة التطبيقات والأحداث)، واختبارات التكامل بين الخدمات، والاختبارات الشاملة التي تغطي التدفقات الكاملة تكتسب أهمية متزايدة.

لتجنب التغييرات التي تُخلّ بالتوافق، تُستخدم تقنيات مثل اختبار العقود الموجهة للمستهلكحيث يحدد العملاء توقعاتهم من واجهة برمجة التطبيقات (API) ويلبيها مزودو الخدمات. يخضع كل تغيير في العقد لاختبارات آلية تُجرى ضمن مسارات التكامل المستمر (CI)، مما يمنع عمليات النشر التي قد تُعطل أيًا من المستخدمين المعروفين.

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

يعتمد الاختبار الشامل بشكل متزايد على بيئات مؤقتة أو "معاينات" تم إنشاؤها من فرع الميزةتُنشئ هذه الأدوات بيئة معزولة تضم الخدمات ذات الصلة بتلك الوظيفة. وهذا يقلل من الاحتكاك بين الفرق، ويحد من تأثير "يعمل على جهازي فقط"، ويكشف مشاكل التكامل قبل أن تصل إلى بيئات أكثر تكلفة مثل بيئة ما قبل الإنتاج.

أنماط نشر الخدمات المصغرة في بيئة الإنتاج

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

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

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

وأخيراً، اكتسبت هذه الأساليب شعبية بدون خوادم، مثل AWS Lambdaيتضمن هذا النمط تغليف وظائف تستجيب لطلبات HTTP أو أحداث من خدمات أخرى (مثل S3 وDynamoDB وقوائم الانتظار، إلخ)، حيث يدفع المستخدمون فقط مقابل ما يستخدمونه. وهو مناسب بشكل خاص للخدمات المصغرة الصغيرة جدًا أو المهام قصيرة الأجل التي تعتمد على الأحداث، على الرغم من أنه يُضيف اعتبارات إضافية تتعلق بإمكانية المراقبة، وبدء التشغيل البارد، وحدود التنفيذ.

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

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