لا تخف من الخدمات الصغيرة: أليكسي بايتوف حول استخدام بنية الخدمات الصغيرة في الممارسة العملية

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

لقد طلبنا مشاركة دراسة الحالة الخاصة بنا لتطوير وتقديم الخدمات الدقيقة Alexei Baitov ، مهندس رئيسي 2GIS. دعنا نتحدث عن الحلول المعمارية ونشرها وقابليتها للتوسع. دعنا نسأل عن الأدوات الشائعة والعمل فقط.



- أليكسي ، من فضلك أخبرنا قليلاً عن نفسك وعن فريقك في 2GIS . ما الذي تعمل عليه الآن؟

عدت إلى تكنولوجيا المعلومات في عام 2003 كمسؤول نظام ، وانغمست في التطوير في عام 2011. خلال هذا الوقت ، عمل في PHP وجافا سكريبت ونفذ سلسلة من خدمات RESTful وسائق Python لـ Git. أعمل في 2GIS منذ عام 2015.

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

تم كتابة الخدمة في Go. سمح لي التجميع السريع بعدم الانتظار ، وتمكنت من التركيز على النشر المستمر. ثم بدأنا للتو في استخدام GitLab CI و Prometheus و Grafana و Deis ( نظير مفتوح المصدر من Heroku ). لدينا فريق من البنية التحتية والعمليات ، والذي أدى في وقت تطوري إلى جلب جميع حلول البنية التحتية هذه إلى مستوى جاهز للإنتاج. قررت أن أجرب كل هذا ونفذت بنجاح خدمة مايكرو مستقلة.

قبل عامين ، انتقلت إلى فريق آخر في مشروع جديد ، حيث بدأت الانخراط في البرمجة الوظيفية في سكالا. لقد طور فريق عملنا من الصفر بنية خدمات صغيرة لتخزين مواد الإعلان 2GIS في Scala و C # و JavaScript. لقد وضعت الأساس لجميع الخدمات بالأدوات والخبرة المكتسبة لبناء ممارسات DevOps (النشر المستمر والصيانة). لقد انتقلت العمارة من النموذج الأولي إلى العمليات الصناعية. لقد استوعبت متجانسين ، وتتكون الآن من 15 خدمة وتتوسع باستمرار.

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

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

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

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

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

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

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

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

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

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



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

قل لي ، هل أنت مؤيد للتطور من الصفر أو هل يمكن أن تكون هناك مواقف تستحق فيها الاستنتاج التدريجي من المونوليث؟ كيفية تحديد استراتيجية الخروج؟

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

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

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

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

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

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

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

للعمل مع نموذج الأعمال الجديد للغاية ، تم اختيار Scala وقاعدة بيانات PostgreSQL هذه المرة. سكالا استوفى متطلباتنا التقنية. بالإضافة إلى ذلك ، كان مطورو Scala موجودين في نفس الطابق مثل مطوري C #. هذا قلل من الوقت لاتصال الفريق. عمل قانون كونواي - تملي هيكل الشركة هيكل التطبيق. قام مطور PHP بإعادة تطويره ليصبح مطور Scala. لقد انتهيت للتو من العمل على خدمة صغيرة مستقلة في Golang بدورة CI / CD كاملة ، وبعد ذلك انضممت إلى الفريق وأصبحت أيضًا مطور Scala.

من المثير للاهتمام ما اقترحته بالضبط للعمل مع منطق الأعمال Scala ، وليس C #. والحقيقة هي أنه لم يكن لدينا ما يكفي من مطوري C #. أردت أنا و PHP-shnik إعادة التدريب على Scala. بالإضافة إلى ذلك ، أتيحت لنا الفرصة لجذب مطور Scala ذو خبرة. نقطة أخرى: إذا قمنا بتطبيق كل شيء في C # ، فيمكننا الحصول على بنية خدمة صغيرة أو متآلف آخر عند الإخراج. التقسيم إلى Scala و C # ، واحتياجات التخزين المختلفة وتوافر المطورين ذوي الخبرة في كل مجال من المجالات المطلوبة - كل هذا يشير مباشرة إلى بنية الخدمات الصغيرة. واستفدنا فقط من هذا. قبل عام ، دخلت بنية الخدمات المصغرة للعمل مع المواد الرسومية والنصية في التشغيل التجاري وقد تم تشغيلها بنجاح حتى يومنا هذا.

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

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

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

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

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

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

لا يزال من الجدير التذكير بكلمات سام نيومان: كلما قلت الخدمة ، كلما ظهرت جميع مزايا وعيوب بنية الخدمات الصغيرة.

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

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

- ما مدى سلاسة النشر والنقل المتواصلين للخدمات الصغيرة لتحفيز؟

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

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

يعني النشر المستمر أنه يمكننا تقديم التطبيق في أي وقت إلى أي بيئة.

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

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

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

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

- ما يمكن أن يكون مجموعة الأدوات الأولية للنشر المستمر للخدمات الصغيرة؟ ما هي الخيارات التي تنصح باستخدامها للعمل مع الخدمات الصغيرة؟

النشر المستمر هو سلسلة من خطوط الأنابيب ، بما في ذلك التكامل المستمر واختبارات التكامل وتقديم الخدمات إلى بيئة التهيئة. أكثر أدوات تسلسل الخطوات شيوعًا هي Jenkins 2 Pipelines و TeamCity Build Chains و Bitbucket Pipelines و GitLab CI Pipelines . تحتاج أولاً إلى أتمتة التكامل المستمر (CI). نحن بحاجة إلى خادم CI بعيد لبناء وتشغيل الاختبارات على هذا التجميع.

تقدم الأدوات المدرجة حلولها. نحن نستخدم GitLab CI ، ويعمل GitLab Runners كخوادم. قطعة البناء هي صورة Docker . كجزء من اختبارات التكامل ، يمكنك إجراء اختبارات الحمل والسعة باستخدام Gatling ، على وجه الخصوص ، لتحديد الموارد التي تحتاجها (المعالج والذاكرة) للعمل في بيئة التزامن (على سبيل المثال ، Kubernetes ). يستخدم Helm على نطاق واسع للنشر ، ويسمح لك بوصف بنية الخدمات الدقيقة للبيئات المختلفة. في شركتنا لا نستخدم هيلم. لدينا أداة النشر الخاصة بنا ، والتي تم إنشاؤها عندما كان Helm في الإصدار الكلاسيكي ولم يدعم بيئات مختلفة. كل من هذه الأدوات لها صفات مفيدة مماثلة ، ولكن التنفيذ والتوزيع مختلفان. وأداتنا الخاصة تسمح لنا بإجراء تحسينات وتكييف كل شيء مع بنيتنا التحتية.

- ما هي التقنيات المثلى للشركات الصغيرة والمتوسطة التي ترغب في تنفيذ الخدمات الصغيرة؟ هل هذا مكلف للغاية بالنسبة لهم؟

على نحو متزايد ، صادفت تأكيدات بأن الشركات الصغيرة والمتوسطة غير مناسبة لرفع بيئة التنسيق الخاصة بها (على سبيل المثال ، Kubernetes أو Docker Swarm أو Apache Mesos ). . ( Google Cloud Platform , Amazon Web Services , Microsoft Azure Oracle Cloud ) .

GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .

, , , open source, .

Spinnaker Heroku — , , .

— , , , . . ?

, . , , .

( ) . .

. . , (package). .

( ) Docker-, Git. , . , . , .

, . : API. . : . , API. , API , — . , API, .

. , ; API, ; , , .

, , . , ?

— - . , API, , . . .

, , . , , . , , .

— , . 2. , ? ?

. . Mesosphere , OpenShift PaaS IaaS . Deis , Deis . open source Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .

Deis2 . Deis, Kubernetes. Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.

— , , , ? ?

Helm. , . Helm .

Helm , — : , .

Helm chart' chart, , .

2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.

API API Gateway . , — .

, : . , , .

DevOps , . DevOpsConf Russia .

DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .

DevOps , , – . 15 .