مرحبا ، habrozhiteli! إذا بدا لك لفترة طويلة أن كل عمليات التطوير والنشر في شركتك قد تباطأت إلى أقصى درجة - فانتقل إلى بنية الخدمات الصغيرة. إنه يوفر التطوير المستمر ، تسليم ونشر التطبيقات بأي تعقيد.
يروي الكتاب ، المخصص للمطورين والمهندسين المعماريين من الشركات الكبرى ، كيفية تصميم التطبيقات وكتابتها بروح هندسة الخدمات المصغرة. يصف أيضًا كيفية إعادة تشكيل تطبيق كبير - ويتحول المتراصة إلى مجموعة من الخدمات المصغرة.
نحن نقدم لك أن تتعرف على المقطع "إدارة المعاملات في هندسة Microservice"
يتم تنفيذ أي طلب تقريبًا تتم معالجته بواسطة تطبيق صناعي كجزء من معاملة قاعدة البيانات. يستخدم مطورو هذه التطبيقات أطر عمل ومكتبات تعمل على تبسيط العمل مع المعاملات. توفر بعض الأدوات واجهة برمجة تطبيقات ضرورية لبدء المعاملات والالتزام بها واسترجاعها يدويًا. والأطر مثل الربيع لديها آلية التصريح. يدعم Spring التعليق التوضيحي علىTransactional ، والذي يستدعي تلقائيًا طريقة ضمن معاملة. بفضل هذا ، تصبح كتابة منطق أعمال المعاملات في غاية البساطة.
لتكون أكثر دقة ، إدارة المعاملات بسيطة في التطبيقات المتجانسة التي تصل إلى قاعدة بيانات واحدة. إذا كان التطبيق يستخدم العديد من قواعد البيانات وسماسرة الرسائل ، تصبح هذه العملية أكثر صعوبة. حسنًا ، في بنية الخدمات المصغرة ، تغطي المعاملات عدة خدمات ، لكل منها قاعدة بيانات خاصة بها. في مثل هذه الظروف ، يجب أن يستخدم التطبيق آلية معاملة أكثر تطوراً. كما سترى قريبًا ، فإن الطريقة التقليدية للمعاملات الموزعة ليست قابلة للتطبيق في التطبيقات الحديثة. يجب أن تستخدم الأنظمة المستندة إلى Microservice سرد القصص بدلاً من ذلك.
ولكن قبل الانتقال إلى السرد ، دعونا نرى لماذا تخلق إدارة المعاملات الكثير من التعقيدات في بنية الخدمات المصغرة.
4.1.1. Microservice الهندسة المعمارية والحاجة إلى المعاملات الموزعة
تخيل أنك مطور لدى FTGO وأنك مسؤول عن تنفيذ عملية نظام createOrder (). كما هو موضح في الفصل 2 ، يجب أن تضمن هذه العملية أنه يمكن للعميل تقديم الطلبات ، والتحقق من تفاصيل الطلب ، وتفويض البطاقة المصرفية للعميل ، وإنشاء سجل طلبات في قاعدة البيانات. سيكون تنفيذ هذه الإجراءات بسيطًا نسبيًا في تطبيق مترابط. جميع البيانات اللازمة للتحقق من الطلب جاهزة ومتاحة. بالإضافة إلى ذلك ، يمكن استخدام معاملات ACID لضمان اتساق البيانات. يمكنك ببساطة تحديد التعليق التوضيحيTransactional لطريقة خدمة createOrder ().
ومع ذلك ، فإن إجراء هذه العملية في بنية microservice أكثر صعوبة بكثير. كما يمكن أن يرى في التين. 4.1 ، تنتشر البيانات المطلوبة بواسطة عمليات createOrder () عبر العديد من الخدمات. يقوم createOrder () بقراءة المعلومات من خدمة المستهلك وتحديث محتويات خدمات الطلب والمطبخ والمحاسبة.
نظرًا لأن لكل خدمة قاعدة بيانات خاصة بها ، يجب عليك استخدام آلية لتنسيق البيانات بينها.
4.1.2. مسائل المعاملات الموزعة
النهج التقليدي لضمان اتساق البيانات بين العديد من الخدمات أو قواعد البيانات أو وسطاء الرسائل هو استخدام المعاملات الموزعة. المعيار الفعلي لإدارة المعاملات الموزعة هو X / Open XA (انظر
en.wikipedia.org/wiki/XA ). يستخدم طراز XA التزامًا على مرحلتين (2PC) لضمان حفظ جميع التغييرات في المعاملة أو التراجع عنها. يتطلب ذلك قواعد البيانات ووسطاء الرسائل وبرامج تشغيل قواعد البيانات وواجهة برمجة تطبيقات الرسائل للامتثال لمعيار XA ، كما يلزم وجود آلية اتصال بين العمليات التي توزع معرفات معاملات XA العالمية. معظم قواعد البيانات العلائقية متوافقة مع XA ، وكذلك بعض وسطاء الرسائل. على سبيل المثال ، يمكن للتطبيق المستند إلى Java EE إجراء المعاملات الموزعة باستخدام JTA.
على الرغم من بساطتها ، المعاملات الموزعة لديها عدد من المشاكل. العديد من التقنيات الحديثة ، بما في ذلك قواعد بيانات NoSQL مثل MongoDB و Cassandra ، لا تدعمها. المعاملات الموزعة غير مدعومة من قبل بعض وسطاء الرسائل الحديثة مثل RabbitMQ و Apache Kafka. لذلك ، إذا قررت استخدام المعاملات الموزعة ، فلن تتوفر لك العديد من الأدوات الحديثة.
مشكلة أخرى مع المعاملات الموزعة هي أنها شكل من أشكال IPC متزامن ، مما يضعف توافر. من أجل الالتزام بالمعاملة الموزعة ، يجب أن تكون جميع الخدمات المشاركة فيها متاحة. كما هو موضح في الفصل 3 ، فإن إمكانية الوصول إلى النظام هي نتاج إمكانية الوصول لجميع المشاركين في المعاملة. إذا شاركت خدمتان توفرتا نسبة 99.5٪ في معاملة موزعة ، فإن التوافر الإجمالي سيكون 99٪ ، وهو أقل بكثير. كل خدمة إضافية تقلل من درجة التوافر. صاغ Eric Brewer نظرية CAP ، التي تنص على أنه لا يمكن أن يحتوي النظام إلا على اثنين من الخصائص الثلاثة التالية: الاتساق وإمكانية الوصول ومقاومة القسم (en.wikipedia.org/wiki/CAP_ Theorem). اليوم ، المهندسين المعماريين يفضلون أنظمة بأسعار معقولة ، والتضحية بالاتساق.
للوهلة الأولى ، قد تبدو المعاملات الموزعة جذابة. من وجهة نظر المطور ، لديهم نفس نموذج البرنامج مثل المعاملات المحلية. ولكن نظرًا للمشاكل الموضحة مسبقًا ، فإن هذه التكنولوجيا غير قابلة للتطبيق في التطبيقات الحديثة. يوضح الفصل 3 كيفية إرسال الرسائل كجزء من معاملة قاعدة البيانات دون استخدام المعاملات الموزعة. لحل المشكلة الأكثر تعقيدًا المتمثلة في ضمان تناسق البيانات في بنية الخدمة المصغرة ، يجب أن يستخدم التطبيق آلية مختلفة استنادًا إلى مفهوم الخدمات غير المتزامنة المزدوجة الترابط. وهنا الروايات تأتي في متناول اليدين.
4.1.3. استخدم قالب سرد القصص للحفاظ على تناسق البيانات
رواية القصص هي آلية تضمن اتساق البيانات في بنية الخدمات المصغرة دون استخدام المعاملات الموزعة. يتم إنشاء السرد لكل فريق نظام يحتاج إلى تحديث البيانات في العديد من الخدمات. هذا عبارة عن سلسلة من المعاملات المحلية ، يقوم كل منها بتحديث البيانات في خدمة واحدة ، باستخدام الأطر والمكتبات المألوفة لمعاملات ACID المذكورة سابقًا.
قالب القص
يضمن اتساق البيانات بين الخدمات التي تستخدم سلسلة من المعاملات المحلية التي يتم تنسيقها باستخدام رسائل غير متزامنة. انظر microservices.io/patterns/data/saga.html .
تبدأ عملية النظام في المرحلة الأولى من السرد. الانتهاء من معاملة محلية واحدة يؤدي إلى ما يلي. في القسم 4.2 ، سترى كيف يتم تنسيق هذه الخطوات باستخدام رسائل غير متزامنة. تتمثل إحدى الميزات المهمة للرسائل غير المتزامنة في أنه يضمن إكمال جميع مراحل السرد ، حتى لو تعذر الوصول إلى مشارك واحد أو أكثر.
السرد لديها اختلافات مهمة عدة من المعاملات ACID. بادئ ذي بدء ، يفتقرون إلى العزلة (لمعرفة المزيد عن هذا ، انظر القسم 4.3). بالإضافة إلى ذلك ، نظرًا لأن كل معاملة محلية تجسد تغييراتها ، لاستعادة القصة ، يجب عليك استخدام معاملات التعويض ، والتي سنناقشها لاحقًا في هذا القسم. النظر في مثال القص.
مثال سردي: إنشاء أمر
في هذا الفصل ، نستخدم السرد "إنشاء أمر" كمثال (الشكل 4.2). يقوم بتنفيذ عملية createOrder (). يتم تشغيل المعاملة المحلية الأولى بواسطة طلب إنشاء طلب خارجي. يتم تشغيل المعاملات الخمسة المتبقية واحدة تلو الأخرى.
يتكون هذا السرد من المعاملات المحلية التالية.
1. طلب الخدمة. ينشئ طلبًا مع الحالة APPROVAL_PENDING.
2. خدمة المستهلك. يتحقق إذا كان العميل يستطيع تقديم الطلبات.
3. خدمة المطبخ. يتحقق من تفاصيل الطلب ويقوم بإنشاء طلب بالحالة CREATE_PENDING.
4. خدمة المحاسبة. يرخص بطاقة العميل المصرفية.
5. خدمة المطبخ. يغير حالة التطبيق إلى AWAITING_ACCEPTANCE.
6. ترتيب الخدمة. يغير حالة الطلب إلى APPROVED.
في القسم 4.2 ، سأوضح كيف تتفاعل الخدمات المشاركة في القصة مع بعضها البعض باستخدام رسائل غير متزامنة. تنشر الخدمة رسالة عند إتمام معاملة محلية. هذا يبدأ المرحلة التالية من السرد ويسمح ليس فقط لتحقيق تماسك ضعيف للمشاركين ، ولكن أيضًا لضمان التنفيذ الكامل للسرد. حتى إذا كان المستلم غير متاح مؤقتًا ، يقوم الوسيط بتخزين الرسالة حتى يمكن تسليمها.
تبدو السرد بسيطة ، لكن استخدامها يرتبط ببعض الصعوبات ، خاصة مع عدم وجود عزلة بينهما. تم توضيح حل المشكلة في القسم 4.3. جانب آخر غير تافه هو التراجع عن التغييرات عند حدوث خطأ. دعونا نرى كيف يتم ذلك.
تستخدم السرد المعاملات المقاصة لاستعادة التغييرات
تحتوي معاملات ACID التقليدية على ميزة واحدة رائعة: يمكن منطق الأعمال بسهولة استعادة معاملة إذا تم اكتشاف انتهاك قاعدة العمل. إنه ببساطة ينفذ أمر ROLLBACK ، وتلغي قاعدة البيانات جميع التغييرات التي تم إجراؤها حتى الآن. لسوء الحظ ، لا يمكن إرجاع القصة تلقائيًا ، لأنها في كل مرحلة تلتقط التغييرات في قاعدة البيانات المحلية. هذا ، على سبيل المثال ، يعني أنه في حالة فشل تفويض بطاقة مصرفية في المرحلة الرابعة من السرد "إنشاء أمر" ، يجب على تطبيق FTGO إلغاء التغييرات التي تم إجراؤها في المراحل الثلاث السابقة يدويًا. يجب عليك كتابة ما يسمى المعاملات الإزاحة.
افترض فشل المعاملة (n + 1) في القصة. من الضروري تحييد نتائج المعاملات السابقة n. على المستوى المفاهيمي ، كل مرحلة من مراحل Ti هذه لها معاملة Ci الخاصة بها ، والتي تلغي تأثير Ti. للتعويض عن تأثير المراحل الأولى n ، يجب على السرد تنفيذ كل معاملة Ci بترتيب عكسي. يبدو التسلسل كالتالي: T1 ... Tn، Cn ... C1 (الشكل 4.3). في هذا المثال ، تفشل الخطوة Tn + 1 ، الأمر الذي يتطلب إلغاء الخطوات T1 ... Tn.
ينفذ السرد المعاملات التعويضية بالترتيب العكسي للصفقات الأصلية: Cn ... C1. هنا ، تعمل نفس آلية التنفيذ المتسلسل كما في حالة Ti. إنهاء Ci يجب أن يبدأ Ci - 1.
خذ على سبيل المثال سرد إنشاء الطلب. قد تفشل لأسباب متنوعة.
1. معلومات غير صحيحة حول العميل ، أو غير مسموح للعميل بإنشاء أوامر.
2. معلومات غير صحيحة حول المطعم ، أو أن المطعم غير قادر على قبول الطلب.
3. عدم القدرة على تفويض البطاقة المصرفية للعميل.
في حالة حدوث فشل في المعاملة المحلية ، يجب أن تقوم آلية تنسيق سرد القصص بالخطوات التعويضية التي ترفض الطلب وربما يكون الترتيب. في الجدول. 4.1 يتم جمع المعاملات التعويضية لكل مرحلة من مراحل إنشاء الطلب. تجدر الإشارة إلى أنه ليس كل مرحلة تتطلب معاملة تعويضية. ينطبق هذا ، على سبيل المثال ، على قراءة العمليات ، مثل checkConsumerDetails () ، أو على عملية AuthorCreditCard () ، جميع الخطوات التي تنجح دائمًا بعدها.
في القسم 4.3 ، ستكتشف أن المراحل الثلاثة الأولى من السرد "إنشاء أمر" تسمى المعاملات المتاحة للتعويض ، لأن الخطوات التالية قد تفشل. تسمى الخطوة الرابعة معاملة تحول لأن الخطوات التالية لن تفشل أبدًا. تسمى الخطوتين الأخيرتين بالمعاملات القابلة للتكرار ، لأنها تنتهي دائمًا بنجاح.
لفهم كيفية استخدام المعاملات التعويضية ، تخيل موقفًا يفشل فيه تفويض البطاقة المصرفية للعميل. في هذه الحالة ، ينفذ السرد المعاملات المحلية التالية.
1. طلب الخدمة. ينشئ طلبًا مع الحالة APPROVAL_PENDING.
2. خدمة المستهلك. يتحقق إذا كان العميل يستطيع تقديم الطلبات.
3. خدمة المطبخ. يتحقق من تفاصيل الطلب ويقوم بإنشاء طلب بالحالة CREATE_PENDING.
4. خدمة المحاسبة. يجعل محاولة فاشلة لترخيص البطاقة المصرفية للعميل.
5. خدمة المطبخ. يغير حالة التطبيق إلى CREATE_REJECTED.
6. ترتيب الخدمة. يغير حالة الطلب إلى مرفوض.
تعوض المرحلتان الخامسة والسادسة المعاملات التي تلغي التحديثات التي تجريها خدمات المطبخ ، وبناءً على الطلب. منطق السرد التنسيقي هو المسؤول عن تسلسل المعاملات المباشرة والموازنة. دعونا نرى كيف يعمل.
عن المؤلف
كريس ريتشاردسون هو مطور ومهندس ومؤلف كتاب POJOs in Action (Manning ، 2006) ، الذي يصف كيفية إنشاء تطبيقات Java على مستوى المؤسسات باستخدام أطر Spring و Hibernate. يحمل الألقاب الفخرية لـ Java Champion و JavaOne Rock Star.
طور كريس النسخة الأصلية من CloudFoundry.com ، وهو تطبيق مبكر لمنصة Java PaaS لنظام Amazon EC2.
الآن يعتبر زعيمًا أيديولوجيًا معترفًا به في عالم الخدمات المصغرة ويتحدث بانتظام في المؤتمرات الدولية. أنشأ كريس microservices.io ، والذي يحتوي على أنماط تصميم microservice. كما أنه يجري مشاورات ودورات تدريبية في جميع أنحاء العالم للمنظمات التي تتحول إلى بنية microservice. يعمل كريس حاليًا على بدء تشغيله الثالث ، Eventuate.io. إنها منصة برمجية لتطوير خدمات المعاملات الصغيرة.
»يمكن الاطلاع على مزيد من المعلومات حول الكتاب على
موقع الناشر»
المحتويات»
مقتطفاتخصم 25 ٪ على كوبون الباعة المتجولين -
Microservice Patternsعند دفع النسخة الورقية من الكتاب ، يتم إرسال كتاب إلكتروني عبر البريد الإلكتروني.