مرحبا يا هبر!
بدأنا في ترجمة كتاب
أنماط الخدمات المصغرة من كريس ريتشاردسون. لقد مضى نصف عام على العرض الأول باللغة الروسية ، ولكن نود أن نقدم لك نوعًا من المقطورات - مراجعة مختصرة قليلاً لهذا الكتاب من بن نادل ، الذي قرأ نسخة MEAP. يقتبس الاستعراض بنشاط نص نسخة كيندل من ريتشاردسون.
مرحبًا بك في القط!
تعرفت على كريس ريتشاردسون عندما تعرفت على مورد
Microservices.io على الإنترنت. حيث ، لأكون صريحًا ، هناك كمية هائلة من المعلومات - التي قررت تأجيلها لوقت لاحق ، لأنني في ذلك الوقت لم أكن أعرف كيفية التعامل معها ، خاصة بالنظر إلى أنني لم أتعامل عمليًا مع الخدمات الصغيرة حتى الآن. أحب قراءة المزيد. لذلك ، عندما علمت أن كريس كان ينشر كتاب
المؤلف أنماط الخدمات الصغيرة: مع أمثلة في جافا ، كان مصدر
إلهامي ببساطة. لدرجة أنه لم يستطع انتظار خروجها. لذا اكتسبت وقرأت "الإصدار المبكر" من شركة مانينغ (MEAP). في الأسبوع الماضي ، قمت للتو بما درست هذا الكتاب ، وأعتقد أن هذه دراسة رائعة وعملية وشاملة لنهج الخدمات الصغيرة في التنمية.
تم بناء الكتاب بالكامل على شكل قصة Mary - CTO (CTO) من Food To Go، Inc (FTGO). تسعى الشركة إلى تنمية الأعمال التجارية من خلال إطلاق إعادة هيكلة تطبيقها المتآلف القديم وتحويله إلى بنية خدمات صغيرة. تأخذ ماري هذا المشروع ، لأن سرعة التطوير انخفضت ، وأصبح الرؤساء أكثر انزعاجًا من أن المبرمجين تحت قيادة ماري غير قادرين على إنتاج ميزات جديدة في شكل عالي الجودة إلى حد ما.
بالطبع ، مشكلة ماري الرئيسية هي ما يسمى "الجحيم المتآلف" في مصطلحات ريتشاردسون. في حين أن المونوليث هو تطبيق كبير ومتزايد ، يركز ريتشاردسون على جانب دقيق إلى حد ما من هجرة FTGO ، بحيث يكون أكثر ملاءمة لفضح ونقل جميع المفاهيم. في هذه الحالة ، محتويات الكتاب قابلة للهضم بشكل لا يصدق. عادة ما تكون معظم اعتبارات العمارة إما مفرطة في التبسيط أو معقدة. ومع ذلك ، تمكن ريتشاردسون من إيجاد أرضية وسط من خلال بناء نموذج مجال يتناسب (تقريبًا) في الرأس ، ولكنه معقد في الوقت نفسه بما يكفي لتوضيح تدفقات المهام بين الخدمات المثيرة للاهتمام عليه.
منذ البداية ، كنت أتطلع إلى أن يكون ريتشاردسون عمليًا في كل التفاصيل. لا يتم تقديم أي جانب من جوانب الكتاب على أنه "رصاصة فضية" أو "الحل الوحيد". في كل مكان نرى خيارًا محسوبًا ، مجموعة من التنازلات المحددة بوضوح. على سبيل المثال ، يقدم المؤلف فكرة الخدمات الصغيرة في هذا السياق: يجب دائمًا تجنب هندسة الخدمات الدقيقة ، باستثناء الحالات التي تكون فيها ضرورية للغاية:
التحدي الآخر المرتبط باستخدام بنية الخدمات المصغرة هو أن تقرر عند أي نقطة في دورة حياة التطبيق لبدء استخدام هذه البنية. عند تطوير الإصدار الأول من التطبيق ، غالبًا ما لا تواجهك مشاكل تحلها هذه البنية. علاوة على ذلك ، فإن استخدام بنية موزعة متوازنة بشكل جيد سيبطئ فقط من التنمية. يمكن أن تنشأ مثل هذه المعضلة عند الشركات الناشئة ، حيث يكمن التحدي الأهم عادة في التطور السريع لنموذج الأعمال وتطبيقه الخاص. عند استخدام بنية الخدمات المصغرة ، يكون من الصعب تنظيم التكرارات السريعة. يجب أن يبدأ تطوير بدء التشغيل بالتأكيد بتطبيق متجانسة. (نسخة كيندل ، العنوان 416)
يعتبر ريتشاردسون أيضًا الخدمات المصغرة من منظور شامل ، حيث تناقش ديناميكيات الفريق كدائرة مستقلة تمامًا من المشكلات التي يتم بناؤها على الجانب التكنولوجي. وبالطبع ، فهو ينظر في موضوعات مثل
قانون كونواي و مناورة
كونواي العكسية ، لكنه في نفس الوقت ، يتطرق أيضًا إلى حقيقة أن المبرمجين هم شخصيات عاطفية يجب عليك "بيعها" فكرة الخدمات الصغيرة:
بالانتقال إلى نموذج الخدمات الصغيرة ، فإنك مجبر على تغيير بنيتك ، مؤسستك ، وعمليات التطوير. ومع ذلك ، في النهاية ، تتغير بيئة العمل ، والظروف التي يعمل فيها الناس ، والناس ، كما سبق ذكره ، عاطفية. إذا تم تجاهل العواطف البشرية ، فإن إدخال الخدمات الصغيرة في منظمة يمكن أن يتحول إلى طريق حاد. (نسخة كيندل ، العنوان 718)
تنطبق الاستراتيجيات التي وصفها المؤلف على النشاط التجاري بأكمله ، وتؤثر على المديرين والمديرين التنفيذيين الذين قد لا يجرؤون على بدء إعادة هيكلة كبيرة ، مع أخذ موارد قيمة منه ، والأشخاص الذين يمكنهم تطوير ميزات جديدة بنشاط:
من الفوائد الهامة لإعادة البناء التدريجي خطوة بخطوة نحو بنية الخدمات الصغيرة أن مثل هذه الاستراتيجية تبدأ على الفور في الدفع. ليس هذا هو الوضع على الإطلاق عند "إصلاح" رمز لا يجلب أي فائدة حتى يكتمل تمامًا ...
إضافة أخرى للحالة التي يتم فيها الحصول على القيمة من الانتقال في مرحلة مبكرة هي أنه يمكننا جذب دعم الأعمال لضمان الهجرة. يعد هذا الدعم المستمر أمرًا حاسمًا ، نظرًا لأنه كلما كانت إعادة الهيكلة أكثر نشاطًا ، قل الوقت الذي ستقضيه في تطوير الميزات. في بعض المنظمات ، من الصعب التخلص من الديون التقنية ، حيث يمكن أن تكون المحاولات السابقة طموحة بشكل مفرط ولا تحقق الفوائد المرجوة. ونتيجة لذلك ، فإن العمل متردد في مواصلة الاستثمار في "التنظيف". إن طبيعة إعادة الهيكلة خطوة بخطوة في حالة الخدمات الدقيقة تعني أن الفريق يمكنه إظهار نتائج قيمة في كثير من الأحيان. (عنوان إصدار كيندل 10769)
من وجهة نظر تكنولوجية ، في كتاب "Microservices. درست أنماط التطوير وإعادة الهيكلة مجموعة واسعة من المواضيع: من البنى السداسية والاختبار والتكامل المستمر إلى أنماط الرسائل وإنشاء أنظمة يمكن ملاحظتها. هذه التغطية تعني أن بعض الموضوعات في الكتاب تمت تغطيتها بمزيد من التفصيل من غيرها. ومع ذلك ، مرة أخرى ، تمكن ريتشاردسون تمامًا من تحقيق التوازن بين كل شيء وإعطاء تفاصيل كثيرة جدًا بحيث يمكن للمرء أن يناقش الموضوع بشكل معقول دون تثبيط القارئ.
في الواقع ، يتم تنظيم محتويات الكتاب بطريقة يمكنك من خلالها اختيار الموضوعات التي تتعمق فيها. في كل فصل ، قبل الانغماس المفصل في الموضوع ، يتم إعطاء قائمة TL ؛ DR ، والتي تسرد بإيجاز جميع الإيجابيات والسلبيات. وبالتالي ، يمكنك التقاط أهم نقاط الفصل دون قراءة كل كلمة.
بصراحة ، لقد قمت بقلب فصلين فقط حول اختبار الخدمات الصغيرة وفصل واحد حول نشر الخدمات الصغيرة. أنا متأكد من أن المؤلف عمل على معالجة هذه المواضيع بشكل مثالي ، ولكن يبدو لي أنه كان هناك ببساطة معلومات أكثر مما يمكنني استيعابها. النشر ليس مهمة يومية عاجلة بالنسبة لي. كتب العديد من الاختبارات في حياته.
وهكذا ، أردت ترك مساحة كافية في وعي الكهف غير الواضح الخاص بي لوضع مواد من جميع الفصول الأخرى: على التصميم الموجه للموضوع (DDD) ، والاتصالات بين العمليات ، ومزامنة البيانات.
يخبرنا أحد الأقسام التي جعلتني مندهشًا بشكل خاص عن الخدمة التي يجب أن تتعامل مع الطلبات من نوع واحد متخصص ، وهي: العثور على المطاعم المناسبة بالقرب من الموقع الحالي للمستخدم:
ومع ذلك ، قد يكون من الصعب تنفيذ حتى تلك الطلبات المحلية من حيث خدمة معينة. هذا ممكن لعدة أسباب. أولاً ، لأنه (كما هو موضح أدناه) ، يكون من غير المعقول في بعض الأحيان تنفيذ طلب في الخدمة التي تمتلك البيانات. سبب آخر هو أنه في بعض الأحيان لا يمكن لقاعدة بيانات الخدمة (أو نموذج البيانات) دعم الطلب بكفاءة (إصدار Kindle ، العنوان 5659)
... إذا تم تخزين معلومات المطاعم في قاعدة بيانات [ findAvailableRestaurant() ] ، فإن تنفيذ استعلام findAvailableRestaurant() يكون أكثر تعقيدًا. يجب تخزين نسخة طبق الأصل من بيانات المطاعم في شكل يدعم الاستعلامات الجغرافية المكانية. على سبيل المثال ، يمكن للتطبيق استخدام مكتبة الفهرسة الجغرافية المكانية لـ DynamoDB ، حيث يتم استخدام الجدول كمؤشر جغرافي مكاني. البديل: يمكن للتطبيق تخزين نسخة طبق الأصل من بيانات المطاعم في نوع مختلف تمامًا من قواعد البيانات. يحدث موقف مماثل عندما نستخدم الاستعلامات النصية مع قاعدة بيانات للبحث عن النص. (نسخة كيندل ، العنوان 5675)
... في هذه الحالة ، من المستحسن (للوهلة الأولى على الأقل) أن يتم تنفيذ عملية الطلب بواسطة الخدمة ذاتها التي تمتلك البيانات. ومع ذلك ، بالإضافة إلى ملكية البيانات ، يجب النظر في عوامل أخرى.
من الضروري أيضًا مراعاة الحاجة إلى الفصل بين الواجبات وتجنب التحميل الزائد للخدمات مع ميزات كثيرة جدًا. على سبيل المثال ، تتمثل المسؤولية الرئيسية لفريق تطوير خدمة المطعم في مساعدة مديري المطاعم على خدمة عمل المؤسسة. هذه المهمة ليست على الإطلاق من خطة تنفيذ طلب حاسم للعمل مع كميات كبيرة من البيانات. علاوة على ذلك ، إذا كان فريق التطوير مسؤولًا عن عملية findAvailableRestaurants() ، findAvailableRestaurants() دائمًا إدخال مثل هذه التغييرات التي يمكن أن تمنع المستهلكين من تقديم الطلبات. (نسخة كيندل ، العنوان 5675)
هنا ، انفجر عقلي قليلاً لأنني رأيت لأول مرة خدمة وظيفتها الوحيدة هي تحسين بيانات خدمة أخرى لأداء مهمة محددة. ومع ذلك ، كما يشير ريتشاردسون ، فإن هذا مجرد تجريد أكثر عمومية للفكرة التي تكمن وراء البحث عن نص كامل ، على سبيل المثال ، في Apache Lucene (توفر هذه الأداة فهرسة نص كامل فوق مستودع بيانات آخر).
أظن - أو بالأحرى ، أتمنى - أنه بعد رؤية هذا التقسيم للمسؤوليات ، سيبدأ القارئ في رسم خط جديد بين الخدمات. لن يفكر في "ملكية البيانات" فحسب ، بل سيبدأ أيضًا في مراعاة "فرص الأعمال" - أي أنه عامل ذو قيمة حقيقية بحيث لا يبدو أن قاعدة البيانات هي فقط المكان الذي يتم فيه تخزين الدولة.
جانب آخر تم تسليط الضوء عليه في هذه المناقشة هو الأهمية المطلقة لمزامنة البيانات والنسخ المتماثل ، وكذلك الرسائل غير المتزامنة في بنية الخدمات الدقيقة. يمر هذا الموضوع من خلال كتاب ريتشاردسون بالكامل بخيط أحمر ، بغض النظر عما يتحدثون عنه: إنشاء خدمة صغيرة من الصفر أو إعادة هيكلة تدريجية لموحد إلى خدمات صغيرة (يتم تخصيص فصل منفصل لهذا الموضوع). يوضح بوضوح أن المزامنة هي تلك القوة الأساسية التي تسمح حقًا بتحقيق أشياء كثيرة.
يمكنني أن أذكر الكثير من الأشياء المثيرة للاهتمام. ما الذي يستحق ، على سبيل المثال ، حقيقة أن ريتشاردسون يتحدث بشكل صحيح عن المصادقة والتفويض في نظام موزع؟ أعتقد أن هذا الموضوع لم يتم استكشافه بالكامل حتى الآن ، بعبارة ملطفة. يشرح المؤلف التصميم الموجه نحو الموضوع بأكثر الطرق وصولاً. ويوضح أيضًا أنه حتى الطبقات البسيطة جدًا يمكن أن يكون لها سلوك.
منذ أكثر من عام ، كنت أحاول فهم بنية الأنظمة الموزعة وأنماط الخدمات الدقيقة بشكل صحيح (وهو أمر صعب بشكل خاص ، لأن عملي اليومي مرتبط بخدمة المونوليث). العديد من النصوص التي قرأتها حول هذه المواضيع إما سطحية للغاية أو ضيقة للغاية وفي نفس الوقت متعمقة. كتاب "Microservices. إن أنماط التطوير وإعادة الهيكلة هي في الواقع الوسط بين هذين الطرفين.
أوصي بشدة بهذا الكتاب لكل شخص (جريئنا) الذي يحاول (بما في ذلك ، حتى الآن دون جدوى) التحول من بنية متجانسة إلى نظام موزع.