نشر الخدمات المصغرة: كل شيء بدءًا من أفضل الممارسات والاستراتيجيات وحتى المراقبة والأمن

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

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

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

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

ما هي الخدمات المصغرة؟ كيف يعملون؟

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

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

منذ ذلك الحين، أصبحت الخدمات المصغرة خيارًا معماريًا سائدًا، مدعومة بالتطورات في تقنيات النقل بالحاويات مثل Dockerوأدوات التنسيق مثل Kubernetes ومنصات الحوسبة بدون خادم. ولكن كيف تعمل الخدمات المصغرة؟

كيف تعمل الخدمات المصغرة؟

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

وفقًا لتعريف مارتن فاولر وجيمس لويس، تتمتع جميع الخدمات الصغيرة بأربع خصائص رئيسية هي كما يلي:

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

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

المراحل الرئيسية لنشر الخدمات المصغرة

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

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

التخطيط والإعداد لنشر الخدمات المصغرة

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

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

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

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

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

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

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

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

استراتيجيات نشر الخدمات المصغرة

عند نشر الخدمات الصغيرة، يعتمد اختيار استراتيجية النشر على وظيفة الخدمة وحركة المرور وإعداد البنية التحتية وخبرة الفريق واعتبارات التكلفة. ومع ذلك، بشكل عام، تكون استراتيجيات نشر الخدمات الصغيرة كما يلي:

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

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

تنسيق الخدمات المصغرة

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

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

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

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

علاوة على ذلك، يعمل Kubernetes أيضًا على تحسين أمان الخدمات الصغيرة مثل التكوينات والأسرار، مثل بيانات اعتماد قاعدة البيانات أو مفاتيح API، باستخدام ConfigMaps وSecrets. وهذا مهم بشكل خاص للشركات والخدمات، مثل Uber، التي تتعامل مع معلومات العملاء والمستخدمين الحساسة.

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

بمجرد إعداد أداة تنسيق الخدمات الصغيرة الخاصة بك، ستحتاج إلى الإنشاء والتشغيل الآلي خطوط أنابيب CI/CD لنشر الخدمات المصغرة.

خطوط أنابيب CI/CD لنشر الخدمات الصغيرة

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

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

علاوة على ذلك، يتم إجراء جميع مراحل الاختبار والتكامل تلقائيًا بواسطة خطوط أنابيب CI/CD حيث يتم دمج اختبارات الوحدة واختبارات التكامل والاختبارات الشاملة في خط الأنابيب.

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

وأخيرًا، يساعد تنفيذ مسارات CI/CD للخدمات الصغيرة وفقًا لأفضل ممارسات الخدمات الصغيرة المؤسسات على تحقيق تطوير أسرع وتقليل الأخطاء اليدوية والحفاظ على معايير الجودة العالية.

تستخدم العديد من الشركات، مثل Spotify وExpedia وiRobot وLufthansa وPandora وغيرها، مسارات CI/CD للخدمات الصغيرة من خلال أدوات CI/CD مثل CircleCI وAWS CodePipeline وGitLab لأتمتة عمليات النشر، وضمان جودة التعليمات البرمجية المتسقة، وتقديم ميزات جديدة بسرعة مع الحفاظ على استقرار النظام.

أنماط اتصالات الخدمات المصغرة

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

في أنماط اتصالات الخدمات الصغيرة المتزامنة، تتفاعل الخدمات في الوقت الفعلي، مما يعني أن الخدمة سترسل طلبًا وتنتظر الرد قبل المتابعة. أنماط اتصالات الخدمات الصغيرة المتزامنة الأكثر استخدامًا هي واجهات برمجة تطبيقات REST (نقل الحالة التمثيلية)., gRPC (استدعاء الإجراء عن بعد من Google)، و GraphQL.

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

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

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

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

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

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

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

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

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

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

عادةً ما يتم استخدام وسطاء الرسائل المستندة إلى الأحداث، مثل Apache Kafka وAWS EventBridge، لمعالجة تدفقات الأحداث واسعة النطاق في الوقت الفعلي وتوجيه الأحداث بين الخدمات الصغيرة في مجالات مثل الخدمات المالية وبيئات AWS.

أما بالنسبة لوسطاء رسائل النشر والاشتراك (Pub/Sub) مثل Google Cloud Pub/Sub وRedis Streams، فعادةً ما يتم استخدام وسطاء الرسائل هؤلاء للمراسلة القابلة للتطوير عبر الأنظمة الموزعة للتحليلات في الوقت الفعلي واستيعاب الأحداث والإشعارات في الوقت الفعلي وتطبيقات الدردشة.

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

اكتشاف خدمة الخدمات المصغرة

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

ويتم ذلك من خلال اكتشاف الخدمة المضمنة الذي يوفره Kubernetes DNS، والذي يقوم بتحديث عناوين IP وسجلات DNS ديناميكيًا أثناء توسع الخدمات أو تغيير الموقع داخل المجموعة.

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

من ناحية أخرى، لدينا أيضًا طريقة الاكتشاف من جانب العميل لاكتشاف خدمة الخدمات الصغيرة، حيث تستعلم الخدمة أو بوابة واجهة برمجة التطبيقات (API) عن سجل خدمة مثل Consul أو Eureka للعثور على المثيلات المتاحة.

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

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

على سبيل المثال، يستخدم نشر الخدمات الصغيرة من Netflix اكتشاف الخدمة الصغيرة من جانب العميل باستخدام Eureka وRibbon لموازنة التحميل، مما يسمح للعميل باختيار أفضل مثيل بناءً على معايير مثل زمن الوصول وتحميل الخادم.

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

تساعد حلول اكتشاف الخدمات الصغيرة من جانب الخادم مثل Kubernetes وAWS Elastic Load Balancing وAPI Gateways (Kong وNGINX وما إلى ذلك) على توجيه حركة المرور بكفاءة والحفاظ على التوفر العالي وتستخدمها شركات مثل Airbnb وPinterest وExpedia وLyft وما إلى ذلك.

أمن الخدمات المصغرة

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

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

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

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

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

تحجيم الخدمات المصغرة

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

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

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

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

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

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

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

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

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

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

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

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

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

مراقبة الخدمات المصغرة

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

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

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

الأفكار النهائية

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

التعليمات

ما هي استراتيجيات النشر شائعة الاستخدام للخدمات الصغيرة؟

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

ما الدور الذي يلعبه Kubernetes في تنسيق الخدمات الصغيرة؟

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

كيف يمكنني ضمان الأمان في بيئة الخدمات المصغرة؟

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