استخدام المراسلة غير المتزامنة لتحسين التوفر

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

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

فيما يلي مقتطف من الكتاب الذي يستخدم المراسلة غير المتزامنة

استخدام المراسلة غير المتزامنة لتحسين التوفر

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

أولاً ، دعنا نرى ما هي المشاكل التي يخلقها التفاعل المتزامن وكيف يؤثر على إمكانية الوصول.

3.4.1. التفاعل المتزامن يقلل من التوافر

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

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


يتكون تكوين الطلب من تسلسل الخطوات هذا.

1. يقدم العميل طلب HTTP POST / orders إلى خدمة الطلب.
2. تقوم خدمة الطلب باسترداد معلومات العميل عن طريق تقديم طلب HTTP GET / للمستهلكين / الهوية إلى خدمة المستهلك.
3. تقوم خدمة الطلب باسترداد معلومات المطعم عن طريق تنفيذ طلب HTTP GET / restaurant / id إلى خدمة المطعم.
4. طلب أخذ الشيكات الطلب باستخدام معلومات حول العميل والمطعم.
5. ترتيب أخذ يخلق النظام.
6. طلب أخذ يرسل استجابة HTTP إلى العميل.

نظرًا لأن هذه الخدمات تستخدم HTTP ، يجب أن تكون FTGO متاحة للجميع لمعالجة طلب CreateOrder. لن تتمكن من إنشاء طلب في حالة عدم توفر إحدى الخدمات على الأقل. من وجهة نظر رياضية ، يعد توفر عملية تشغيل النظام نتاجًا لتوفر الخدمات المشاركة فيه. إذا توفرت خدمة الطلب والخدمات التي تتصل بها بنسبة 99.5٪ ، فسيكون توفرها الإجمالي 99.5٪ 3 = 98.5٪ ، وهو أقل بكثير. كل خدمة لاحقة تشارك في الطلب تجعل العملية أقل سهولة.

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

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

3.4.2. تخلص من التفاعل المتزامن

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

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

باستخدام أنماط التفاعل غير المتزامن

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


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

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

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

تكرار البيانات

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


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

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

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

إنهاء المعالجة بعد إرجاع استجابة

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

1. تقوم الخدمة بفحص الطلب فقط بمساعدة البيانات المتوفرة محليًا.
2. يقوم بتحديث قاعدة البيانات الخاصة به ، بما في ذلك إضافة رسائل إلى جدول OUTBOX.
3. إرجاع الاستجابة إلى عميله.

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

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

1. تنشئ خدمة الطلب طلبًا بالحالة معلقة.
2. تقوم خدمة الطلب بإرجاع استجابة بمعرف الطلب إلى عميلها.
3. ترسل خدمة الطلب رسالة ValidateConsumerInfo إلى خدمة المستهلك.
4. ترسل خدمة الطلب رسالة ValidateOrderDetails إلى خدمة المطعم.
5. تتلقى خدمة المستهلك رسالة ValidateConsumerInfo ، وتتحقق لمعرفة ما إذا كان يمكن للعميل تقديم طلب ، ويرسل رسالة ConsumerValidated إلى خدمة الطلب.
6. تتلقى خدمة المطعم رسالة ValidateOrderDetails ، وتتحقق من صحة عناصر القائمة وقدرة المطعم على توصيل طلب إلى عنوان معين ، وترسل رسالة OrderDetailsValidated إلى خدمة Order.
7. تتلقى خدمة الطلب رسائل ConsumerValidated و OrderDetailsValidated وتغيير حالة الطلب إلى VALIDATED.

وهلم جرا ...

يمكن أن تتلقى خدمة الطلب رسائل ConsumerValidated و OrderDetailsValidated بأي ترتيب. لمعرفة أي واحد حصل عليه أولاً ، قام بتغيير حالة الطلب. إذا تم التحقق من صحة الرسالة الأولى ، فسيتم تغيير حالة الطلب إلى CONSUMER_VALIDATED ، وإذا تغيرت OrderDetailsValidated إلى ORDER_DETAILS_VALIDATED. بعد تلقي الرسالة الثانية ، تقوم خدمة الطلب بتعيين حالة الطلب على VALIDATED.

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


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

ملخص

• يتم توزيع بنية Microservice ، لذلك يلعب التواصل بين العمليات دورًا رئيسيًا في ذلك.
• يجب تناول تطوير خدمة واجهة برمجة التطبيقات (API) بعناية وبعناية. من الأسهل إجراء تغييرات متوافقة مع الإصدارات السابقة لأنها لا تؤثر على طريقة عمل العملاء. عند إجراء تغييرات عاجلة على واجهة برمجة التطبيقات للخدمة ، عادة ما يتعين عليك الحفاظ على الإصدار القديم والجديد حتى يتم تحديث العملاء.
• هناك العديد من تقنيات IPC ، ولكل منها نقاط القوة والضعف الخاصة بها. القرار الرئيسي في مرحلة التصميم هو الاختيار بين استدعاء الإجراء البعيد المتزامن والرسائل غير المتزامنة. أسهل استخدام هي بروتوكولات متزامنة مثل REST ، استنادًا إلى استدعاء الإجراءات عن بُعد. ولكن من الناحية المثالية ، لزيادة إمكانية الوصول ، يجب أن تتواصل الخدمات باستخدام المراسلة غير المتزامنة.
• لمنع حدوث تراكم يشبه الانهيار الجليدي في حالات الفشل في النظام ، يجب أن يكون العميل الذي يستخدم بروتوكولًا متزامنًا قادرًا على التعامل مع حالات الفشل الجزئي - حقيقة أن الخدمة المدعومة إما غير متوفرة أو تعرض زمن انتقال عالٍ. على وجه الخصوص ، عند تنفيذ الطلبات ، من الضروري حساب وقت الانتظار وتقييد عدد الطلبات المتأخرة وتطبيق قالب "Fuse" لتجنب المكالمات إلى الخدمة المعيبة.
• يجب أن تتضمن البنية التي تستخدم بروتوكولات متزامنة آلية اكتشاف حتى يتمكن العملاء من تحديد موقع شبكة مثيلات الخدمة. أسهل طريقة هي التركيز على آلية الاكتشاف التي توفرها منصة النشر: على القوالب "اكتشاف جانب الخادم" و "تسجيل الجهة الخارجية". تتمثل الطريقة البديلة في تنفيذ اكتشاف الخدمة على مستوى التطبيق: قوالب اكتشاف العميل والتسجيل الذاتي. تتطلب هذه الطريقة مزيدًا من الجهد ، ولكنها مناسبة للحالات التي تعمل فيها الخدمات على منصات نشر متعددة.
• يحتوي نموذج الرسالة والقناة على تفاصيل عن تطبيق نظام المراسلة ويصبح خيارًا جيدًا عند تصميم هذا النوع من الهندسة المعمارية. في وقت لاحق ، يمكنك ربط الهيكل الخاص بك ببنية تحتية خاصة بالرسائل ، والتي تستخدم عادةً الوسيط.
• الصعوبة الرئيسية في المراسلة هي نشر وتحديث قاعدة البيانات. الحل الجيد هو استخدام قالب نشر الأحداث: تتم كتابة الرسالة في قاعدة البيانات في البداية كجزء من المعاملة. تقوم عملية منفصلة بعد ذلك باسترداد الرسالة من قاعدة البيانات باستخدام قالب Interrogating Publisher أو سجل تتبع المعاملات ، وتمريرها إلى الوسيط.

»يمكن الاطلاع على مزيد من المعلومات حول الكتاب على موقع الناشر
» المحتويات
» مقتطفات

ل Khabrozhiteley خصم 30 ٪ على الكتب قبل النظام على قسيمة - Microservices