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

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

كيف وصلنا إلى الخدمات الصغيرة

Avito هي واحدة من أكبر الإعلانات المبوبة في العالم ، فهي تنشر أكثر من 15 مليون إعلان جديد يوميًا. الخلفية لدينا يقبل أكثر من 20 ألف طلب في الثانية الواحدة. الآن لدينا عدة مئات من خدمات micros.

لقد تم بناء العمارة microservice لعدة سنوات. كيف بالضبط - تحدث زملاؤنا بالتفصيل في قسمنا في RIT ++ 2017. في CodeFest 2017 (انظر الفيديو ) ، أوضح سيرجي أورلوف وميخائيل بروكوبتشوك بالتفصيل سبب حاجتنا إلى الانتقال إلى الخدمات المصغرة والدور الذي لعبته Kubernet هنا. حسنًا ، نحن نفعل الآن كل ما في وسعنا لتقليل تكاليف التوسع التي تكمن في مثل هذه البنية.

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

الآن في الأداة المساعدة PaaS CLI ، يقوم فريق واحد بإنشاء خدمة جديدة وإضافة اثنين آخرين إلى قاعدة بيانات جديدة ونشرها على المسرح.

كيفية التغلب على عصر "تجزئة الخدمات الصغيرة"

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

بالإضافة إلى ذلك ، لكي تكون بنية الخدمات المصغرة فعالة ، يجب إنشاء العديد من العمليات ، وهي:

• قطع الأشجار ؛
• تتبع الاستعلام (جايجر) ؛
• تجميع الأخطاء (ترقب) ؛
• الحالات والرسائل والأحداث من Kubernetes (الحدث ستريم المعالجة) ؛
• الحد من السباق / قاطع الدائرة (يمكنك استخدام Hystrix) ؛
• التحكم في اتصال الخدمة (نستخدم Netramesh) ؛
• الرصد (غرافانا) ؛
• التجمع (TeamCity) ؛
• الاتصالات والإخطار (سلاك ، البريد الإلكتروني) ؛
• تتبع المهمة ؛ (جيرة)
• تجميع الوثائق.

لذا ، نظرًا لأن النظام يتدرج ، فإنه لا يفقد سلامته ويظل فعالًا ، نعيد التفكير في تنظيم عمل الخدمات المصغرة في Avito.

كيف نتعامل مع خدمات microservices

يساعد تطبيق "سياسة حزبية" موحدة بين العديد من الخدمات الصغرى التي تقدمها Avito:

• تقسيم البنية التحتية إلى طبقات ؛
• النظام الأساسي كمفهوم خدمة (PaaS) ؛
• مراقبة كل ما يحدث مع خدمات microservices.

تتضمن طبقات تجريد البنية التحتية ثلاث طبقات. دعنا نذهب من الأعلى إلى الأسفل.

شبكة العلوي الخدمة. في البداية ، جربنا Istio ، لكن اتضح أنه يستخدم الكثير من الموارد ، وهو أمر مكلف للغاية على وحدات التخزين الخاصة بنا. لذلك ، قام المهندس الكبير في فريق الهندسة المعمارية ألكسندر لوكيانشنكو بتطوير حله الخاص به - Netramesh (متوفر في Open Source) ، والذي نستخدمه الآن في الإنتاج ويستهلك موارد أقل عدة مرات من Istio (لكن لا يفعل كل ما يفتخر به Istio).
B. متوسطة - Kubernetes. على ذلك نحن نشر وتشغيل الخدمات الصغيرة.
جيم السفلى المعدنية العارية. نحن لا نستخدم السحب وأشياء مثل OpenStack ، ولكن نجلس بالكامل على المعدن العاري.

يتم دمج كل الطبقات بواسطة PaaS. وهذه المنصة ، بدورها ، تتكون من ثلاثة أجزاء.

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

II. مجمع جامع مع التحكم في جميع الأدوات من خلال لوحة القيادة المشتركة.

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

يتم تنفيذ الخدمات المصغرة في Avito أيضًا وفقًا لمخطط واحد ، مما يسهل التحكم فيها في كل مرحلة من مراحل التطوير والإصدار.

كيف يعمل خط أنابيب تطوير خدمات microservice القياسية

بشكل عام ، سلسلة إنشاء خدمات microservice هي كما يلي:

CLI-push ← تكامل مستمر ← خبز ← نشر ← اختبارات اصطناعية ← اختبارات الكناري ← اختبار الضغط ← الإنتاج ← خدمة.

نسير عبرها بالضبط في هذا التسلسل.

CLI-دفع

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

في النهاية ، قمنا ببناء أداة CLI بسيطة تعمل على أتمتة الخطوات الأساسية عند إنشاء خدمة microservice. في الواقع ، فإنه يحل محل الدفعة الأولى. هذا ما تفعله.

- ينشئ خدمة وفقًا للقالب - خطوة بخطوة ، في وضع "المعالج". لدينا قوالب للغات البرمجة الرئيسية في خلفية Avito: PHP و Golang و Python.

- في أحد الأوامر ، يقوم بنشر البيئة الخاصة بالتطوير المحلي على جهاز معين - ارتفاع Minikube ، يتم إنشاء مخططات Helm تلقائيًا وتشغيلها في kubernetes المحلية.

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

- هو نفسه يؤدي تجميع حي. دعنا نقول المطور ثابت شيء في microservice من خلال IDE له. ترى الأداة التغييرات في نظام الملفات ، وبناءً عليها ، تقوم بإعادة تجميع التطبيق (لـ Golang) وإعادة التشغيل. بالنسبة لـ PHP ، نعيد توجيه الدليل داخل المكعب ويتم إعادة التحميل المباشر "تلقائيًا".

- يولد autotests. في شكل أقراص ، ولكن مناسبة تماما للاستخدام.

• نشر microservice .

كان كئيبا بعض الشيء نشر خدمة microservice من قبل. إلزامي مطلوب:

I. دوكرفيل.

II. التكوين.
III. مخطط Helm ، وهو بحد ذاته ضخم ويشمل:

- المخططات نفسها ؛
- القوالب ؛
- قيم محددة مع مراعاة البيئات المختلفة.

لقد تخلصنا من آلام إعادة إظهار عروض Kubernetes ، والآن يتم إنشاؤها تلقائيًا. ولكن الأهم من ذلك ، أنها تبسيط النشر إلى الحد الأقصى. من الآن فصاعدًا ، لدينا Dockerfile ، والمطور يكتب التكوين بالكامل في ملف app.toml قصير واحد.

نعم ، وفي app.toml نفسه الآن الشؤون لمدة دقيقة. نكتب إلى أين تشير إلى عدد نسخ الخدمة التي تريد رفعها (على خادم dev ، على مراحل ، على الإنتاج) ، تشير إلى تبعياتها. لاحظ حجم الخط = "صغير" في كتلة [المحرك]. هذا هو الحد الذي سيتم تخصيصه للخدمة عبر Kubernetes.

كذلك على أساس التكوين ، يتم إنشاء جميع مخططات Helm اللازمة تلقائيًا وإنشاء اتصالات بقواعد البيانات.

• التحقق من صحة الأساسية. هذه الشيكات هي أيضا الآلي.
تحتاج إلى تتبع:
- هل هناك Dockerfile ؛
- هل هناك app.toml ؛
- ما إذا كانت هناك وثائق ؛
- ما إذا كانت التبعية سليمة ؛
- هي مجموعة قواعد التنبيهات.
إلى النقطة الأخيرة: يشير مالك الخدمة نفسه إلى مقاييس المنتج المراد مراقبتها.

• إعداد الوثائق.
لا يزال مكان المشكلة. يبدو أنه الأكثر وضوحًا ، ولكن في الوقت نفسه ، "غالبًا ما ينسى" كسر الأرقام القياسية ، وبالتالي فهو حلقة ضعيفة في السلسلة.
من الضروري أن تكون الوثائق تحت كل خدمة microservice. يتم تضمين الكتل التالية في ذلك.

أولا وصف موجز للخدمة . فقط بضع جمل حول ما يفعله وما هو مطلوب.

II. رابط لمخطط العمارة . من المهم أن تسهل نظرة سريعة عليها ، على سبيل المثال ، ما إذا كنت تستخدم Redis للتخزين المؤقت أو كمخزن بيانات رئيسي في الوضع المستمر. في Avito ، هذا رابط إلى Confluence.

III. Runbook . دليل قصير لإطلاق الخدمة وتعقيدات التعامل معها.

IV. الأسئلة الشائعة ، حيث سيكون من الجيد توقع المشكلات التي قد يواجهها زملاؤك عند العمل مع الخدمة.

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

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

VII. مالك أو أصحاب الخدمة . في معظم الحالات ، يمكن تحديدها - أو هم - تلقائيًا باستخدام PaaS ، ولكن للتأمين ، نطلب من المطور تحديدها يدويًا.

أخيرًا ، من الممارسات الجيدة مراجعة الوثائق ، على غرار مراجعة التعليمات البرمجية.

التكامل المستمر

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

خبز

المرحلة التالية هي تغليف الخدمات قبل النشر.

• بناء التطبيق. وفقا لكلاسيكيات - في صورة عامل الميناء.
• إنشاء مخططات Helm للخدمة نفسها والموارد ذات الصلة. بما في ذلك قواعد البيانات وذاكرة التخزين المؤقت. يتم إنشاؤها تلقائيًا وفقًا للتكوين app.toml الذي تم إنشاؤه في مرحلة الضغط CLI.
• إنشاء تذاكر للمسؤولين لفتح المنافذ (عند الاقتضاء).
• تشغيل وحدة الاختبار وحساب تغطية الشفرة . إذا كانت تغطية الشفرة أقل من قيمة الحد المعطاة ، فستفشل الخدمة على الأرجح في الانتشار. إذا كانت على وشك السماح ، فسيتم تعيين معامل "متشائم" للخدمة: بعد ذلك ، في حالة عدم وجود تحسينات في المؤشر بمرور الوقت ، سيتلقى المطور إشعارًا بعدم حدوث تقدم من جانب الاختبارات (ويلزم القيام بشيء بهذا).
• النظر في الذاكرة والقيود وحدة المعالجة المركزية . نكتب بشكل أساسي خدمات microservices في Golang ونديرها في Kubernetes. من هنا ، هناك دقة واحدة مرتبطة بخصوصية لغة Golang: افتراضيًا ، يتم استخدام جميع النواة الموجودة على الجهاز عند بدء التشغيل ، وإذا لم تقم بتعيين متغير GOMAXPROCS بشكل صريح وعند بدء تشغيل العديد من هذه الخدمات على نفس الجهاز ، فإنها تبدأ في التنافس على الموارد ، والتدخل مع بعضها البعض. توضح الرسوم البيانية أدناه كيف يتغير وقت التشغيل إذا قمت بتشغيل التطبيق دون منافسة وفي السباق على الموارد. (مصدر الرسوم البيانية هنا ).

مهلة ، أقل هو أفضل. الحد الأقصى: 643 مللي ثانية ؛ الحد الأدنى: 42 مللي ثانية. الصورة قابلة للنقر.

الوقت لإجراء عملية جراحية ، أقل هو أفضل. الحد الأقصى: 14091 نانو ثانية ، الحد الأدنى: 151 نانو ثانية. الصورة قابلة للنقر.

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

نشر

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

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

الاختبارات الاصطناعية

• اختبار حلقة مغلقة. بالنسبة له ، نحن نستخدم الآن Hoverfly.io مفتوح المصدر. أولاً ، تسجل الحمل الحقيقي على الخدمة ، ثم - في حلقة مغلقة - تحاكي.

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

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

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

ب) نحن ننظر إلى وقف إنتاج المواد الانشطارية.
نحن هنا ننظر إلى الفرق بين الإصدار الحالي والإصدار السابق والرقم الإجمالي. على سبيل المثال ، إذا كانت إحدى الخدمات تنتج 100 دورة في الدقيقة ، فهي إما مكتوبة بشكل سيء أو أنها محددة ، ولكن في أي حال ، هذه مناسبة للنظر عن كثب في الخدمة.
على العكس من ذلك ، إذا كان هناك عدد كبير جدًا من RPS ، فربما توقفت بعض الأخطاء وتوقف بعض نقاط النهاية عن أداء الحمولة النافعة ، ولكن return true; تشغيل نوع من return true;

اختبارات الكناري

بعد اجتياز الاختبارات الاصطناعية ، نقوم بتشغيل خدمة microservice على عدد صغير من المستخدمين. نبدأ بعناية ، مع جزء صغير جدًا من الجمهور المقدّر للخدمة - أقل من 0.1٪. في هذه المرحلة ، من المهم جدًا وضع المقاييس التقنية ومنتج المنتجات الصحيح في المراقبة بحيث تظهر المشكلة في الخدمة في أسرع وقت ممكن. الحد الأدنى لوقت اختبار الكناري هو 5 دقائق ، أهمها ساعتان. للخدمات المعقدة ، وضعنا الوقت في الوضع اليدوي.
نحن نحلل:
- مقاييس خاصة باللغة ، ولا سيما عمال php-fpm ؛
- الأخطاء في ترقب ؛
- حالات الردود ؛
- زمن الاستجابة (زمن الاستجابة) ، دقيق ومتوسط ​​؛
- الكمون
- الاستثناءات ، المعالجة وغير المعالجة ؛
- مقاييس الغذاء.

اختبار الضغط

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

الإنتاج

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

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

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

خدمة

بعد تشغيل الخدمة الصغيرة ، يمكننا تعليق المشغلات عليها.

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

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

لوحات

باختصار ، لوحة القيادة هي لوحة التحكم في PaaS بالكامل.

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

في المجموع

قبل إدخال PaaS ، يمكن لمطور جديد قضاء عدة أسابيع في فرز جميع الأدوات اللازمة لإطلاق خدمة microservice في الإنتاج: Kubernetes ، و Helm ، وميزات TeamCity الداخلية الخاصة بنا ، وإعداد اتصال بقواعد البيانات وذاكرة التخزين المؤقت في شكل يتحمل الأخطاء ، إلخ. الآن يستغرق الأمر بضع ساعات لقراءة التشغيل السريع وجعل الخدمة نفسها.

لقد قدمت تقريراً حول هذا الموضوع لـ HighLoad ++ 2018 ، يمكنك مشاهدة الفيديو والعرض التقديمي .

مسار مكافأة لأولئك الذين قرأوا حتى النهاية

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

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

يمكنك التقدم بطلب للمشاركة في نموذج Google هذا . منك - الإجابة على السؤال لماذا بالضبط تحتاج إلى حضور التدريب والمعلومات حول كيفية الاتصال بك. أجب باللغة الإنجليزية ، لأن كريس سيختار المشارك الذي سيذهب إلى التدريب.
سنعلن اسم المشارك في التدريب كتحديث لهذا المنشور على شبكات Avito الاجتماعية للمطورين (AvitoTech على Facebook و Vkontakte و Twitter ) في موعد لا يتجاوز 19 يوليو.

محدث ، 07/19: تلقينا العشرات من الطلبات. قام كريس بفحصهم واختار مشاركًا: مع زملائنا ، سيذهب Andrei Igumnov للدراسة. تهانينا!