مرحبا يا هبر!
لا تلامس ترجمة اليوم وليس فقط الكثير من الخدمات المجهرية - وهو موضوع لدى الجميع على شفاههم اليوم - ولكن أيضًا تذكر مدى أهمية تسمية الأشياء بأسمائها. من الضروري في بعض الأحيان الانتقال إلى بنية الخدمة الصغيرة ، ولكن كما يؤكد المؤلف مرة أخرى ، فإنه يتطلب دراسة متأنية للعواقب. استمتع وقراءة مثمرة!
من وقت لآخر أطرح نفس السؤال.
هل هناك مثل هذه الحقيقة المهمة التي يتفق معها قليل فقط؟ - بيتر تيل
قبل الجلوس لهذا المنصب ، حاولت في هذه المسألة لفترة طويلة لموضوع واحد ، وهو في اتجاه خطير اليوم - يتعلق بالخدمات الدقيقة. أعتقد الآن أن لدي شيئًا أقوله ؛ وتستند بعض النتائج على التفكير ، والبعض الآخر على الخبرة العملية. أنا أخبرك.
لنبدأ بحقيقة واحدة مهمة ستكون بمثابة نقطة مرجعية لنا على طول الطريق مثل النجم القطبي.
معظم تطبيقات microservice ليست أكثر من متراصة موزعة.
عصر متراصة
بدأ أي نظام كتطبيق متجانسة. لن أخوض في تفاصيل هذا الموضوع هنا - لقد كتب الكثيرون بالفعل عن الكثير. ومع ذلك ، فإن حصة الأسد من المعلومات حول متراصة مكرسة لقضايا مثل إنتاجية المطور وقابلية التوسع ، مع ترك وراء الأقواس الأصول الأكثر قيمة لأي شركة الإنترنت: البيانات.
بنية تطبيق متجانسة نموذجيةإذا كانت البيانات مهمة جدًا ، فلماذا يتم الاهتمام بجميع الموضوعات الأخرى ، ولكن ليس لها؟ الإجابة بشكل عام بسيطة: لأنها ليست مؤلمة مثل سؤال البيانات.
ربما تكون المتراصة هي المرحلة الوحيدة في دورة حياة النظام حيث:
- نفهم تماما نموذج البيانات الخاصة بك.
- يمكنك التعاون مع البيانات (من المفترض أن يتم تحديد قاعدة البيانات الخاصة بك بشكل صحيح للتطبيق الخاص بك).
من حيث البيانات ، المتراصة مثالية. ونظرًا لأن البيانات هي أهم أصول أي شركة ، فمن الأفضل عدم كسر المتراصة ، ما لم يكن لديك سبب وجيه للغاية ، أو مزيج من هذه الأسباب. في معظم الحالات ، يكون السبب الحاسم من هذا النوع هو الحاجة إلى التوسع (حيث أننا نعيش في العالم الحقيقي مع القيود المادية الكامنة فيه).
عندما تصل هذه اللحظة ، من المرجح أن ينتقل نظامك إلى أقنوم جديد: إنه
يتحول إلى متراصة موزعة .
عصر متراصة الموزعة
دعنا نقول أن الأمور تسير على ما يرام في شركتك ، ويجب أن ينمو التطبيق. لديك المزيد والمزيد من العملاء الكبار ، وقد تغيرت متطلباتك الخاصة بالفوترة وإعداد التقارير من حيث مجموعة من الفرص وحجمها.
بجدية تناول هدم المتراصة ، على وجه الخصوص ، ستحاول تنفيذ خدمتين صغيرتين ، إحداهما ستوفر التقارير ، والثانية - الفوترة. على الأرجح ، ستوفر هذه الخدمات الجديدة واجهة HTTP HTTP ولديها قاعدة بيانات مخصصة لتخزين الحالة على المدى الطويل. بعد العديد من الالتزامات ، قد تحصل ،
مثلنا في
Unbabel ، على شيء يشبه الرسم التوضيحي التالي.
طريقة عرض عامة لبنية النظام بعد فصل خدمات الفوترة وإعداد التقارير من التطبيق المترابط الرئيسيكل شيء يسير حسب الخطة.
- يواصل الفريق تقسيم المتراصة إلى أنظمة أصغر ؛
- التكامل المستمر / تسليم الناقلات تعمل كالساعة.
- مجموعة Kubernetes صحية ، والمهندسون منتجون وسعداء بكل شيء.
الحياة جميلة
لكن ماذا لو قلت إن المؤامرات البشعة الآن تنسج ضدك؟
الآن ، وبالنظر إلى النظام الخاص بك ، ستجد أن البيانات قد تم توزيعها عبر العديد من الأنظمة المختلفة. لقد بدأت مع المرحلة عندما كان لديك قاعدة بيانات فريدة حيث تم تخزين جميع كائنات البيانات ، والآن انتشرت كائنات البيانات الخاصة بك إلى أماكن مختلفة. قد تظن أن هذه ليست مشكلة ، لأن هناك حاجة إلى خدمات ميكروية لإنشاء تجريدات وختم البيانات ، وإخفاء التعقيد الداخلي للنظام.
أنت على حق تماما. ولكن مع زيادة الحجم ، تنشأ مشاكل أكثر تعقيدًا: في أي وقت من الأوقات تضطر إلى الوفاء بمتطلبات العمل (على سبيل المثال ، لتتبع بعض المقاييس) التي تتطلب الوصول إلى البيانات الموجودة في أكثر من نظام واحد.
ماذا تفعل؟ في الواقع ، هناك العديد من الخيارات. ولكن على عجل ، تحتاج أيضًا إلى خدمة مجموعة كبيرة من العملاء الذين سجلوا معك مؤخرًا ، لذلك عليك إيجاد توازن بين "الصيام" و "الجيد". بعد مناقشة التفاصيل ، قررت إنشاء نظام إضافي من شأنه أداء عمل ETL معيّن ، مما يساهم في حل المهام النهائية. سيتعين على هذا النظام الوصول إلى جميع النسخ المتماثلة للقراءة التي تحتوي على المعلومات التي تحتاجها. يوضح الشكل التالي كيف يمكن لهذا النظام العمل.
مثال معمم لنظام ETL تحليلي (في Unbabel أطلقنا عليه تحليلات الترجمة التلقائية)في Unbabel ، استخدمنا هذا النهج ، حيث:
- لا يؤثر على أداء كل خدمة microservice أكثر من اللازم ؛
- لا يتطلب تغييرات أساسية في البنية الأساسية (فقط أضف خدمة microservice جديدة) ؛
- تمكنا من تلبية متطلبات أعمالنا بسرعة كافية.
تشير التجربة إلى أن هذا النهج سيعمل لبعض الوقت - حتى يصل إلى نطاق معين. في Unbabel ، خدمنا جيدًا حتى وقت قريب ، عندما بدأنا في مواجهة تحديات أكثر وأكثر خطورة. فيما يلي بعض الأشياء التي تحولت إلى صداع بالنسبة لنا:
1. تغييرات البياناتواحدة من المزايا الرئيسية لل microservices هو التغليف. يمكن أن يتغير التمثيل الداخلي للبيانات ، لكن هذا لا يؤثر على عملاء النظام ، لأنهم يتواصلون عبر واجهة برمجة تطبيقات خارجية. ومع ذلك ، تتطلب استراتيجيتنا الوصول المباشر إلى التمثيل الداخلي للبيانات ، وبالتالي ، بمجرد أن يقوم الفريق ببعض التغييرات فقط على عرض البيانات (على سبيل المثال ، إعادة تسمية حقل أو تغيير النوع من
text إلى المستخدم) ، كان علينا أيضًا تغيير وإعادة استخدام ETL- الخدمة.
2. الحاجة إلى معالجة العديد من مخططات البيانات المختلفةنظرًا لزيادة عدد الأنظمة التي نحتاج للاتصال بها ، فقد تعين علينا التعامل مع المزيد والمزيد من الطرق غير المتجانسة لتقديم البيانات. كان من الواضح أننا لم نتمكن من توسيع نطاق كل هذه المخططات والعلاقات بينها وبين تمثيلاتها.
جذر كل شرللحصول على صورة كاملة لما يحدث في النظام ، كان علينا التوقف عند اتباع نهج يشبه المتراصة. كان الاختلاف كله أنه لم يكن لدينا نظام واحد وقاعدة بيانات واحدة ، ولكن عشرات من هذه الأزواج ، ولكل منها تمثيل البيانات الخاص بها ؛ علاوة على ذلك ، في بعض الحالات ، تم نسخ نفس البيانات عبر عدة أنظمة.
أنا أفضل أن أسمي هذا النظام متراصة موزعة. لماذا؟ نظرًا لأنه غير مناسب تمامًا لتتبع التغييرات في النظام ، والطريقة الوحيدة لعرض حالة النظام هي جمع خدمة تتصل مباشرة بمستودعات البيانات لجميع الخدمات الصغيرة. من المثير للاهتمام معرفة عدد التحديات الكبيرة التي واجهتها الإنترنت أيضًا في مرحلة ما من تطورها. ومن الأمثلة الجيدة في هذه الحالة التي أحب أن أقدمها دائمًا هي شبكة LinkedIn.
هذا هو نوع البيانات التي تمثل تدفق معلومات Linkedin حوالي عام 2011 - المصدرفي الوقت الحالي ، قد تتساءل: "ماذا ستفعل يا رفاق مع كل هذا؟" الإجابة بسيطة: تحتاج إلى بدء تعقب التغييرات وتتبع الإجراءات المهمة عند حدوثها.
كسر متراصة موزعة باستخدام مصدر الحدثمثل بقية العالم تقريبًا ، تستجيب الأنظمة على الإنترنت. لذلك ، يمكن أن يؤدي طلب واجهة برمجة التطبيقات إلى إدراج سجل جديد في قاعدة البيانات. حاليًا ، في معظم الحالات ، لا تزعجنا هذه التفاصيل ، حيث أننا مهتمون في المقام الأول بتحديث حالة قاعدة البيانات. يعد تحديث حالة قاعدة البيانات نتيجة مشروطة لبعض الأحداث (في هذه الحالة ، طلب API). ظاهرة الحدث بسيطة ، ومع ذلك ، فإن إمكانات الأحداث كبيرة للغاية - بل يمكن استخدامها لتدمير متراصة موزعة.
الحدث ليس أكثر من حقيقة ثابتة لبعض التعديلات التي حدثت في نظامك . في هندسة الخدمات المصغرة ، تصبح الأحداث مهمة وتساعد على فهم تدفقات البيانات ، وعلى أساسها لاستنتاج الحالة الإجمالية للعديد من الأنظمة. يجب أن تنشئ كل خدمة ميكروية تنفذ إجراء مثيرًا للاهتمام من وجهة نظر النظام بأكمله حدثًا جنبًا إلى جنب مع جميع المعلومات الأساسية المتعلقة بحقيقة أن هذا الحدث يمثل.
ربما لديك سؤال:
"كيف يمكن أن تساعدني الخدمات الميكروية التي تولد الأحداث في حل مشكلة المتراصة الموزعة؟"
إذا كان لديك أنظمة تنشئ أحداثًا ، فقد يكون هناك سجل حقائق يحتوي على الخصائص التالية:
- عدم الربط بأي مستودع بيانات: عادة ما يتم إجراء تسلسل للأحداث باستخدام تنسيقات ثنائية مثل JSON أو Avro أو Protobufs ؛
- الثبات: بمجرد إنشاء الحدث ، يكون من المستحيل تغييره ؛
- استنساخ: يمكن استعادة حالة النظام في أي وقت من الأوقات ؛ لهذا ، يكفي إعادة تشغيل سجل الأحداث.
باستخدام هذا السجل ، يمكنك عرض الحالة باستخدام أي نوع من المنطق على مستوى التطبيق. لم تعد مرتبطًا بأي مجموعة من خدمات microservices وطرق
N التي تعرض بها البيانات. المصدر الحقيقي للحقيقة ومستودع البيانات الوحيد الخاص بك هو الآن مستودع تخزين الأحداث.
فيما يلي بعض الأسباب التي تجعل سجل الأحداث يبدو لي طريقة للمساعدة في كسر متراصة الموزعة:
1. المصدر الوحيد للحقيقةبدلاً من الاحتفاظ بمصادر البيانات N التي قد تكون ضرورية للاتصال بقواعد بيانات غير متجانسة (متعددة) ، في هذا السيناريو الجديد ، يتم تخزين الحقيقة النهائية في مستودع واحد بالضبط: سجل الأحداث.
2. تنسيق البيانات العالميفي الإصدار السابق من النظام ، كان علينا التعامل مع العديد من تنسيقات البيانات ، لأننا كنا متصلين مباشرة بقاعدة البيانات. في التصميم الجديد ، يمكننا العمل بشكل أكثر مرونة.
لنفترض أنك أحببت صورة Instagram نشرها أحد أصدقائك. يمكن وصف مثل هذا الإجراء: "
المستخدم X أعجبت الصورة P ". وهنا حدث يمثل هذه الحقيقة:
حدث يتوافق مع نهج AVO (ممثل ، فعل ، كائن) ، يحاكي حقيقة أن المستخدم يختار الصورة التي يحبونها.3. ضعف التواصل بين المنتجين والمستهلكينأخيرًا وليس آخرًا ، تتمثل إحدى أكبر مزايا عمليات الأحداث في الضعف الفعال في التواصل بين منتجي البيانات والمستهلكين. هذا الموقف ليس فقط يبسط التحجيم ، ولكن أيضا يقلل من عدد التبعيات بينهما. العقد الوحيد المتبقي بين الأنظمة في هذه الحالة هو مخطط الحدث.
في بداية هذه المقالة ، تم طرح السؤال التالي: هل هناك حقيقة مهمة يتفق معها قليلون فقط؟
دعني أعود إليه في ختام هذه الرحلة. أعتقد أن معظم الشركات لا تفكر في البيانات "كيانات من الدرجة الأولى" عندما تبدأ الترحيل إلى بنية الخدمات المصغرة. يقال أنه لا يزال من الممكن إجراء جميع تغييرات البيانات من خلال واجهة برمجة التطبيقات ، ولكن هذا النهج يؤدي في النهاية إلى تعقيد مستمر للخدمة نفسها.
أعتقد أن النهج الحقيقي الوحيد لالتقاط تغييرات البيانات في بنية الخدمات المصغرة هو جعل أنظمة تنبعث منها الأحداث وفقًا لعقد محدد بدقة. يتيح لك وجود سجل أحداث مترجم بشكل صحيح عرض الكثير من البيانات بناءً على أي مجموعة من متطلبات العمل. في هذه الحالة ، عليك فقط تطبيق قواعد مختلفة على نفس الحقائق. في بعض الحالات ، يمكن تجنب تجزئة البيانات هذه إذا تعاملت شركتك (خاصة مديري المنتجات) مع البيانات كمنتج. ومع ذلك ، هذا هو موضوع لمقال آخر.