مرحبًا! اسمي فاديم ماديسون ، أقود تطوير Avito System Platform. لقد قيل أكثر من مرة كيف ننتقل في الشركة من بنية متجانسة إلى خدمة مصغرة. حان الوقت لمشاركة كيفية تحويل بنيتنا التحتية لتحقيق أقصى استفادة من الخدمات المصغرة وعدم الضياع فيها. كيف تساعدنا PaaS هنا ، وكيف قمنا بتبسيط النشر وتقليل إنشاء خدمة مصغرة بنقرة واحدة - واصل القراءة. ليس كل ما أكتب عنه أدناه مطبق بالكامل في Avito ، جزء منه هو كيفية تطويرنا لمنصتنا.
(وفي نهاية هذا المقال ، سأتحدث عن فرصة الحصول على ندوة لمدة ثلاثة أيام من كريس ريتشاردسون ، خبير في هندسة الخدمات المصغرة).
كيف وصلنا إلى الخدمات المصغرة
Avito هي واحدة من أكبر الإعلانات المبوبة في العالم ، فهي تنشر أكثر من 15 مليون إعلان جديد يوميًا. تقبل الواجهة الخلفية لدينا أكثر من 20 ألف طلب في الثانية. الآن لدينا عدة مئات من الخدمات المصغرة.
لقد عملنا على بناء بنية الخدمات المصغرة لأكثر من عام. كيف بالضبط - زملائنا بالتفصيل في قسمنا في RIT ++ 2017. في CodeFest 2017 (انظر ) ، أوضح سيرجي أورلوف وميخائيل بروكوبتشوك بالتفصيل سبب حاجتنا إلى الانتقال إلى الخدمات المصغرة على الإطلاق والدور الذي لعبه Kubernetes هنا. حسنًا ، نحن الآن نفعل كل شيء لتقليل تكاليف القياس المتأصلة في مثل هذه البنية.
في البداية ، لم نخلق نظامًا بيئيًا من شأنه أن يساعدنا بشكل شامل في تطوير وإطلاق الخدمات المصغرة. لقد جمعوا للتو حلولًا ذكية مفتوحة المصدر وأطلقوها في المنزل وعرضوا على المطور التعامل معها. نتيجة لذلك ، ذهب إلى عشرات الأماكن (لوحات المعلومات ، الخدمات الداخلية) ، وبعد ذلك عزز رغبته في قطع الكود بالطريقة القديمة ، بشكل مترابط. يشير اللون الأخضر في المخططات أدناه إلى ما يفعله المطور بطريقة أو بأخرى بيديه ، ويشير اللون الأصفر إلى التشغيل الآلي.
الآن ، في الأداة المساعدة PaaS CLI ، يقوم فريق واحد بإنشاء خدمة جديدة ، ويقوم فريقان آخران بإضافة قاعدة بيانات جديدة ونشرها في Stage.
كيفية التغلب على عصر "تجزئة الخدمات المصغرة"
مع بنية متجانسة ، من أجل تناسق التغييرات في المنتج ، اضطر المطورون إلى معرفة ما كان يحدث مع جيرانهم. عند العمل على البنية الجديدة ، لم تعد سياقات الخدمة تعتمد على بعضها البعض.
بالإضافة إلى ذلك ، لكي تكون بنية الخدمات المصغرة فعالة ، من الضروري إنشاء العديد من العمليات ، وهي:
• تسجيل؛
• طلب البحث عن المفقودين (جايجر) ؛
• تجميع الأخطاء (Sentry).
• الحالات والرسائل والأحداث من Kubernetes (معالجة تدفق الأحداث) ؛
• حد السباق / قاطع الدائرة (يمكنك استخدام Hystrix) ؛
• التحكم في اتصال الخدمة (نستخدم Netramesh) ؛
• المراقبة (جرافانا)؛
• التجمع (TeamCity) ؛
• الاتصال والإخطار (سلاك ، البريد الإلكتروني).
• تتبع المهام. (جيرا)
• إعداد الوثائق.
للتأكد من أن النظام لا يفقد النزاهة ويظل فعالاً مع زيادة حجمه ، قمنا بإعادة التفكير في تنظيم الخدمات المصغرة في Avito.
كيف ندير الخدمات المصغرة
يساعد Avito في تنفيذ "سياسة حزبية" واحدة من بين العديد من الخدمات المصغرة:
- تقسيم البنية التحتية إلى طبقات ؛
- مفهوم النظام الأساسي كخدمة (PaaS) ؛
- مراقبة كل ما يحدث مع الخدمات المصغرة.
تتضمن مستويات تجريد البنية التحتية ثلاث طبقات. دعنا ننتقل من أعلى إلى أسفل.
ألف أعلى - شبكة الخدمة. في البداية جربنا Istio ، لكن اتضح أنه يستخدم الكثير من الموارد ، وهو مكلف للغاية بالنسبة لأحجامنا. لذلك ، طور المهندس الأول في فريق الهندسة ألكسندر لوكيانتشينكو حله الخاص - (متوفر في المصدر المفتوح) ، والذي نستخدمه حاليًا في الإنتاج والذي يستهلك عدة مرات موارد أقل من Istio (لكنه لا يفعل كل ما يمكن أن يتباهى به Istio).
ب. متوسطة - Kubernetes. على ذلك ، نقوم بنشر وتشغيل الخدمات المصغرة.
C. القاع - المعدن العاري. نحن لا نستخدم السحب وأشياء مثل OpenStack ، لكننا نجلس بالكامل على المعدن.
يتم دمج كل الطبقات PaaS. وهذه المنصة بدورها تتكون من ثلاثة أجزاء.
المولدات، تدار من خلال الأداة المساعدة CLI. إنها هي التي تساعد المطور على إنشاء خدمة مصغرة بالطريقة الصحيحة وبأقل جهد ممكن.
ثانيًا. المجمع الموحد مع التحكم في جميع الأدوات من خلال لوحة عدادات مشتركة.
ثالثا. تخزين. يتصل بالمجدولين الذين يقومون تلقائيًا بتعيين المشغلات للإجراءات ذات المعنى. بفضل هذا النظام ، لم يتم تفويت أي مهمة لمجرد أن شخصًا ما نسي وضع مهمة في Jira. نستخدم أداة داخلية تسمى أطلس لهذا الغرض.
يتم تنفيذ الخدمات المصغرة في Avito أيضًا وفقًا لمخطط واحد ، مما يبسط التحكم فيها في كل مرحلة من مراحل التطوير والإصدار.
كيف يعمل خط أنابيب تطوير الخدمات المصغرة القياسية
بشكل عام ، تبدو سلسلة إنشاء الخدمات المصغرة كما يلي:
CLI-push ← التكامل المستمر ← الخبز ← النشر ← الاختبارات الاصطناعية ← اختبارات الكناري ← اختبار الضغط ← الإنتاج ← الصيانة.
دعنا نمر بها بالضبط بهذا الترتيب.
دفع CLI
• إنشاء خدمة مصغرة.
لقد كافحنا لفترة طويلة لتعليم كل مطور كيفية إنشاء الخدمات المصغرة. بما في ذلك كتب تعليمات مفصلة في التقاء. لكن المخططات تغيرت واستكملت. والنتيجة - تشكل عنق الزجاجة في بداية الرحلة: استغرق تشغيل الخدمات المصغرة وقتًا أطول بكثير مما هو مسموح به ، ولا تزال هناك مشكلات في كثير من الأحيان عند إنشائها.
في النهاية ، أنشأنا أداة مساعدة CLI بسيطة تعمل على أتمتة الخطوات الأساسية لإنشاء خدمة مصغرة. في الواقع ، إنه يحل محل أول دفع git. هذا هو بالضبط ما تفعله.
- يُنشئ خدمة وفقًا لقالب - خطوة بخطوة ، في وضع "المعالج". لدينا قوالب للغات البرمجة الرئيسية في خلفية Avito: PHP و Golang و Python.
- أمر واحد في كل مرة ينشر بيئة للتطوير المحلي على جهاز معين - يرتفع Minikube ، ويتم إنشاء مخططات Helm تلقائيًا وتشغيلها في kubernetes المحلية.
- يربط قاعدة البيانات المطلوبة. لا يحتاج المطور إلى معرفة عنوان IP وتسجيل الدخول وكلمة المرور للوصول إلى قاعدة البيانات التي يحتاجها - على الأقل محليًا ، على الأقل في Stage ، على الأقل في الإنتاج. علاوة على ذلك ، يتم نشر قاعدة البيانات على الفور في تكوين متسامح مع الأخطاء ومع موازنة.
- يقوم بالتجميع الحي بنفسه. لنفترض أن المطور قام بتصحيح شيء ما في الخدمة المصغرة من خلال IDE الخاص به. ترى الأداة المساعدة التغييرات في نظام الملفات ، وبناءً عليها ، تعيد بناء التطبيق (لـ Golang) وإعادة التشغيل. بالنسبة لـ PHP ، نقوم ببساطة بإعادة توجيه الدليل داخل المكعب وهناك يتم الحصول على إعادة التحميل المباشر "تلقائيًا".
- يولد اختبارات تلقائية. في شكل فراغات ، لكنها قابلة للاستخدام تمامًا.
• نشر الخدمات المصغرة.
كان الأمر كئيبًا بعض الشيء لنشر خدمة مصغرة معنا. إلزامي مطلوب:
I. ملف الإرساء.
ثانيًا. التكوين.
ثالثا. مخطط هيلم ، وهو مرهق في حد ذاته ويتضمن:
- الرسوم البيانية نفسها ؛
- قوالب
- قيم محددة مع مراعاة البيئات المختلفة.
لقد تخلصنا من آلام إعادة صياغة قوائم Kubernetes والآن يتم إنشاؤها تلقائيًا. ولكن الأهم من ذلك أننا قمنا بتبسيط النشر إلى أقصى حد. من الآن فصاعدًا ، لدينا Dockerfile ، والمطور يكتب التكوين بالكامل في ملف app.toml قصير واحد.
نعم ، وفي app.toml نفسه ، هناك الآن مسألة لمدة دقيقة. نحدد أين عدد نسخ الخدمة التي سيتم رفعها (على خادم dev ، عند التدريج ، عند الإنتاج) ، مع الإشارة إلى تبعياتها. لاحظ حجم الخط = "صغير" في كتلة [المحرك]. هذا هو الحد الذي سيتم تخصيصه للخدمة عبر Kubernetes.
علاوة على ذلك ، على أساس التكوين ، يتم إنشاء جميع مخططات Helm الضرورية تلقائيًا ويتم إنشاء اتصالات بقواعد البيانات.
• التحقق الأساسي. هذه الفحوصات آلية أيضًا.
تحتاج إلى تتبع:
- هل يوجد ملف Dockerfile ؛
- هل يوجد app.toml ؛
- هل هناك وثائق؟
- سواء في ترتيب التبعية ؛
- ما إذا كان قد تم تعيين قواعد التنبيه.
إلى النقطة الأخيرة: يحدد مالك الخدمة بنفسه مقاييس المنتج المراد مراقبتها.
• إعداد الوثائق.
لا تزال منطقة مشكلة. يبدو أنه الأكثر وضوحًا ، ولكن في نفس الوقت السجل "غالبًا ما يُنسى" ، وبالتالي الحلقة الضعيفة في السلسلة.
من الضروري أن تكون الوثائق لكل خدمة مصغرة. يتضمن الكتل التالية.
XNUMX. وصف موجز للخدمة. مجرد بضع جمل حول ما يفعله وما الغرض منه.
ثانيًا. ارتباط بمخطط العمارة. من المهم أن تفهم بشكل سريع ، على سبيل المثال ، ما إذا كنت تستخدم Redis للتخزين المؤقت أو كمخزن بيانات رئيسي في الوضع الثابت. في Avito ، في الوقت الحالي ، هذا رابط إلى Confluence.
ثالثا. كتاب الجري. دليل موجز لبدء الخدمة وتفاصيل التعامل معها.
IV. التعليمات، حيث سيكون من الجيد توقع المشكلات التي قد يواجهها زملاؤك عند العمل مع الخدمة.
V. وصف نقاط نهاية API. إذا لم تحدد الوجهات فجأة ، فمن المؤكد تقريبًا أن الزملاء الذين ترتبط خدماتهم الصغيرة بخدماتك سيدفعون مقابل ذلك. الآن نستخدم Swagger لهذا وحلنا المسمى باختصار.
السادس. تسميات. أو علامات توضح المنتج والوظيفة والتقسيم الهيكلي للشركة التي تنتمي إليها الخدمة. فهي تساعد على فهم سريع ، على سبيل المثال ، ما إذا كنت تنشر الوظيفة التي طرحها زملاؤك لوحدة العمل نفسها قبل أسبوع.
سابعا. صاحب الخدمة أو أصحابها. في معظم الحالات ، يمكن تحديدها - أو هم - تلقائيًا باستخدام PaaS ، ولكن بالنسبة للتأمين ، نطلب من المطور تحديدها يدويًا أيضًا.
أخيرًا ، من الممارسات الجيدة إجراء مراجعات التوثيق ، على غرار مراجعات الكود.
التكامل المستمر
- تجهيز المستودعات.
- إنشاء خط أنابيب في TeamCity.
- منح الحقوق.
- ابحث عن أصحاب الخدمة. يوجد هنا مخطط مختلط - وضع العلامات اليدوية والحد الأدنى من التشغيل الآلي من PaaS. يفشل المخطط التلقائي بالكامل عند نقل الخدمات للدعم في فريق تطوير آخر أو ، على سبيل المثال ، إذا استقال مطور الخدمة.
- التسجيل في الخدمة بنظام أطلس (أنظر فوق). بكل أصحابها وتوابعها.
- التحقق من عمليات الترحيل. نتحقق مما إذا كان هناك أي خطر محتمل بينهم. على سبيل المثال ، في أحدها ، ينبثق جدول بديل أو أي شيء آخر يمكن أن يكسر توافق مخطط البيانات بين الإصدارات المختلفة من الخدمة. ثم لا يتم تنفيذ الترحيل ، ولكن يتم إدخاله في اشتراك - يجب أن تشير PaaS إلى مالك الخدمة عندما يصبح تطبيقها آمنًا.
خبز
المرحلة التالية هي خدمات التعبئة والتغليف قبل النشر.
- تجميع التطبيق. وفقًا للكلاسيكيات - في صورة Docker.
- إنشاء مخططات Helm للخدمة نفسها والموارد ذات الصلة. بما في ذلك لقواعد البيانات وذاكرة التخزين المؤقت. يتم إنشاؤها تلقائيًا وفقًا لتكوين app.toml الذي تم إنشاؤه في مرحلة دفع CLI.
- عمل تذاكر للمسؤولين لفتح المنافذ (عند الحاجة).
- إجراء اختبارات الوحدة وحساب تغطية الكود. إذا كانت تغطية الكود أقل من قيمة العتبة المحددة ، فعلى الأرجح ، لن تذهب الخدمة إلى أبعد من ذلك - إلى النشر. إذا كان على وشك القبول ، فسيتم تخصيص معامل "تشاؤم" للخدمة: بعد ذلك ، إذا لم يكن هناك تحسن في المؤشر بمرور الوقت ، فسيتلقى المطور إشعارًا بعدم وجود تقدم فيما يتعلق بالاختبارات ( ويجب فعل شيء حيال ذلك).
- يمثل الذاكرة وقيود وحدة المعالجة المركزية. في الأساس ، نكتب خدمات مصغرة في Golang ونديرها في Kubernetes. وبالتالي ، هناك دقة واحدة مرتبطة بميزة لغة Golang: بشكل افتراضي ، يتم استخدام جميع النوى الموجودة على الجهاز عند بدء التشغيل ، إذا لم تقم بتعيين متغير GOMAXPROCS صراحة ، وعندما يتم تشغيل العديد من هذه الخدمات على نفس الجهاز ، فإنها تبدأ للتنافس على الموارد ، والتدخل مع بعضها البعض. توضح الرسوم البيانية أدناه كيف يتغير وقت التنفيذ إذا تم تشغيل التطبيق بدون تنازع وفي وضع سباق الموارد. (مصادر المخططات هي ).
وقت التنفيذ ، القليل أفضل. الحد الأقصى: 643 مللي ثانية ، الحد الأدنى: 42 مللي ثانية. الصورة قابلة للنقر.
وقت الجراحة ، الأقل هو الأفضل. الحد الأقصى: 14091 نانوثانية ، الحد الأدنى: 151 نانوثانية. الصورة قابلة للنقر.
في مرحلة إعداد التجميع ، يمكنك ضبط هذا المتغير بشكل صريح أو يمكنك استخدام المكتبة من الرجال في أوبر.
نشر
• التحقق من الاصطلاحات. قبل أن تبدأ في تقديم تصميمات الخدمة إلى بيئاتك المقصودة ، تحتاج إلى التحقق مما يلي:
- نقاط نهاية API.
- مراسلات استجابات نقاط نهاية API للمخطط.
- تنسيق السجل.
- ضبط رؤوس الطلبات للخدمة (الآن يتم ذلك عن طريق netramesh)
- ضبط علامة المالك عند إرسال الرسائل إلى الحافلة (ناقل الحدث). يعد ذلك ضروريًا لتتبع اتصال الخدمات عبر الحافلة. يمكنك إرسال كل من البيانات غير الفعالة إلى الحافلة التي لا تزيد من اتصال الخدمات (وهو أمر جيد) ، وبيانات الأعمال التي تعزز اتصال الخدمات (وهو أمر سيء للغاية!). وفي الوقت الذي يصبح فيه هذا الاتصال مشكلة ، فإن فهم من يكتب ويقرأ الحافلة يساعد على فصل الخدمات بشكل صحيح.
حتى الآن ، لا توجد الكثير من الاتفاقيات في Avito ، لكن مجموعتهم تتوسع. كلما زادت هذه الاتفاقيات في شكل مفهوم وملائم للفريق ، كان من الأسهل الحفاظ على الاتساق بين الخدمات المصغرة.
الاختبارات الاصطناعية
• اختبار الحلقة المغلقة. لذلك ، نستخدم الآن المصدر المفتوح . أولاً ، يسجل الحمل الحقيقي على الخدمة ، ثم - فقط في حلقة مغلقة - يحاكي.
• اختبار الإجهاد. نحاول تقديم جميع الخدمات إلى الأداء الأمثل. ويجب أن تخضع جميع إصدارات كل خدمة لاختبار التحميل - حتى نتمكن من فهم الأداء الحالي للخدمة والاختلاف مع الإصدارات السابقة من نفس الخدمة. إذا انخفض أداء الخدمة ، بعد تحديث الخدمة ، مرة ونصف ، فهذه إشارة واضحة لأصحابها: تحتاج إلى البحث في الكود وتصحيح الموقف.
نبدأ من البيانات التي تم جمعها ، على سبيل المثال ، من أجل تنفيذ القياس التلقائي بشكل صحيح ، وفي النهاية ، لفهم مدى قابلية الخدمة بشكل عام.
أثناء اختبار الحمل ، نتحقق مما إذا كان استهلاك الموارد يفي بالحدود المحددة. ونحن نركز في المقام الأول على المتطرفين.
أ) ننظر إلى الحمولة الإجمالية.
- صغير جدًا - على الأرجح لا يعمل شيء ما على الإطلاق إذا انخفض الحمل فجأة عدة مرات.
- كبير جدًا - التحسين مطلوب.
ب) انظر إلى قطع RPS.
هنا نلقي نظرة على الفرق بين الإصدار الحالي والإصدار السابق والعدد الإجمالي. على سبيل المثال ، إذا أعطت الخدمة 100 rps ، فإما أن تكون مكتوبة بشكل سيئ ، أو أن هذه هي تفاصيلها ، ولكن على أي حال ، هذا سبب للنظر إلى الخدمة عن كثب.
على العكس من ذلك ، إذا كان هناك عدد كبير جدًا من RPS ، فربما يكون هناك نوع من الأخطاء وبعض نقاط النهاية قد توقفت عن تنفيذ الحمولة ، ولكن فقط بعض return true;
اختبارات الكناري
بعد اجتياز الاختبارات التركيبية ، نقوم بتشغيل الخدمة المصغرة على عدد صغير من المستخدمين. نبدأ بحذر بحصة ضئيلة من الجمهور المستهدف للخدمة - أقل من 0,1٪. في هذه المرحلة ، من المهم جدًا إدخال المقاييس الفنية والمقاييس الخاصة بالمنتج في المراقبة بحيث تظهر المشكلة في الخدمة في أسرع وقت ممكن. الحد الأدنى لوقت اختبار الكناري هو 5 دقائق ، والوقت الرئيسي هو ساعتان. بالنسبة للخدمات المعقدة ، نضبط الوقت في الوضع اليدوي.
نحن نحلل:
- المقاييس الخاصة باللغة ، على وجه الخصوص ، عمال php-fpm ؛
- أخطاء في الحراسة ؛
- حالات الاستجابة.
- زمن الاستجابة (زمن الاستجابة) الدقيق والمتوسط ؛
- وقت الإستجابة؛
- الاستثناءات ، المعالجة وغير المعالجة ؛
- مقاييس المنتج.
اختبار الضغط
يسمى اختبار الضغط أيضًا باختبار "الضغط". تم تقديم اسم التقنية في Netflix. جوهرها هو أننا نملأ أولاً حالة واحدة بحركة مرور حقيقية إلى حالة الفشل وبالتالي نضع حدودها. ثم نضيف مثيلًا آخر ونحمل هذا الزوجين - مرة أخرى إلى الحد الأقصى ؛ نرى سقفها ودلتا مع الضغط الأول. ومن ثم نقوم بتوصيل مثيل واحد في كل خطوة ونحسب النمط في التغييرات.
تتدفق بيانات الاختبارات من خلال "الضغط" أيضًا إلى قاعدة بيانات مشتركة للمقاييس ، حيث إما نثري نتائج الحمل الاصطناعي بها ، أو حتى نستبدل "التركيبات" بها.
إنتاج
• التحجيم. عند طرح الخدمة للإنتاج ، نراقب كيف تتوسع. في الوقت نفسه ، فإن مراقبة مؤشرات وحدة المعالجة المركزية فقط ، في تجربتنا ، غير فعالة. يعمل القياس التلقائي باستخدام معايير RPS في أنقى صوره ، ولكن فقط لخدمات معينة ، مثل البث عبر الإنترنت. لذلك فإننا ننظر بشكل أساسي إلى مقاييس المنتج الخاصة بالتطبيقات.
نتيجة لذلك ، عند القياس ، نقوم بتحليل:
- مؤشرات وحدة المعالجة المركزية وذاكرة الوصول العشوائي ،
- عدد الطلبات في قائمة الانتظار ،
- وقت الاستجابة،
- التنبؤ على أساس البيانات التاريخية المتراكمة.
عند توسيع نطاق خدمة ما ، من المهم أيضًا تتبع تبعياتها حتى لا يحدث أن نقوم بتوسيع نطاق الخدمة الأولى في السلسلة ، وتلك التي تصل إليها تقع تحت العبء. من أجل إنشاء حمل مقبول لمجموعة الخدمات بالكامل ، فإننا ننظر إلى البيانات التاريخية للخدمة التابعة "الأقرب" (من حيث وحدة المعالجة المركزية وذاكرة الوصول العشوائي ، إلى جانب المقاييس الخاصة بالتطبيق) ومقارنتها بالبيانات التاريخية لـ تهيئة الخدمة ، وما إلى ذلك على طول "سلسلة التبعية" بأكملها ، من أعلى إلى أسفل.
خدمة
بعد تشغيل الخدمة المصغرة ، يمكننا تعليق المشغلات عليها.
فيما يلي المواقف النموذجية التي تعمل فيها المحفزات.
- تم الكشف عن هجرات يحتمل أن تكون خطرة.
- تم إصدار تحديثات الأمان.
- الخدمة نفسها لم يتم تحديثها لفترة طويلة.
- انخفض العبء على الخدمة بشكل ملحوظ أو أن بعض مقاييس منتجاتها خارجة عن القاعدة.
- لم تعد الخدمة تلبي المتطلبات الجديدة للمنصة.
بعض المشغلات مسؤولة عن استقرار العمل ، وبعضها - كوظيفة صيانة للنظام - على سبيل المثال ، لم يتم نشر بعض الخدمات لفترة طويلة وتوقفت صورتها الأساسية عن اجتياز فحوصات الأمان.
لوحة القيادة
باختصار ، لوحة القيادة هي لوحة التحكم في PaaS بالكامل.
- نقطة واحدة للمعلومات حول الخدمة ، مع بيانات حول تغطية الاختبار ، وعدد صورها ، وعدد نسخ الإنتاج ، والإصدارات ، وما إلى ذلك.
- أداة لتصفية البيانات حسب الخدمات والتسميات (الرموز المميزة للانتماء إلى وحدات الأعمال ، ووظائف المنتج ، وما إلى ذلك)
- أداة تكامل مع أدوات البنية التحتية للتعقب والتسجيل والرصد.
- نقطة واحدة لتوثيق الخدمات.
- وجهة نظر واحدة لجميع الأحداث حسب الخدمة.
في المجموع
قبل تقديم PaaS ، يمكن للمطور الجديد قضاء عدة أسابيع في فهم جميع الأدوات اللازمة لإطلاق خدمة مصغرة في الإنتاج: Kubernetes و Helm وميزات TeamCity الداخلية لدينا وإعداد اتصال بقواعد البيانات وذاكرة التخزين المؤقت بطريقة آمنة من الفشل ، إلخ. . الآن يستغرق الأمر بضع ساعات لقراءة بدء التشغيل السريع وجعل الخدمة نفسها.
لقد قدمت تقريرًا حول هذا الموضوع لـ HighLoad ++ 2018 ، يمكنك أن ترى и .
مسار مكافأة لأولئك الذين قرأوا حتى النهاية
نحن في Avito ننظم تدريبًا داخليًا لمدة ثلاثة أيام للمطورين من ، خبير في هندسة الخدمات المصغرة. نريد أن نمنح الفرصة للمشاركة فيه لأحد قراء هذا المنشور. تم نشر البرنامج التدريبي.
سيعقد التدريب في الفترة من 5 إلى 7 أغسطس في موسكو. هذه أيام عمل ستكون مشغولة بالكامل. سيكون الغداء والتدريب في مكتبنا ، ويدفع المشارك المختار تكاليف السفر والإقامة بنفسه.
يمكنك التقدم للمشاركة . منك - إجابة السؤال لماذا تحتاج إلى حضور التدريب ومعلومات حول كيفية الاتصال بك. الإجابة باللغة الإنجليزية ، لأن المشارك الذي يحصل على التدريب سيختاره كريس نفسه.
سنعلن عن اسم المشارك في التدريب مع تحديث لهذا المنشور وعلى الشبكات الاجتماعية Avito للمطورين (AvitoTech in , , ) في موعد أقصاه 19 يوليو.
المصدر: www.habr.com