مرحبًا٪ username٪!
في الآونة الأخيرة ، انتهى مؤتمر Highload ++ (شكرًا مرة أخرى لفريق المنظمين و
olegbunin شخصيًا. لقد كان رائعًا جدًا!).
عشية المؤتمر ، اقترح أليكسي
فيشر إنشاء مجموعة مبادرة من "المطاردون" في المؤتمر. خلال التقارير ، كتبنا ملاحظات صغيرة تبادلناها. تبين أن بعض الملاحظات كانت مفصلة ومفصلة للغاية.
قام المجتمع في الشبكات الاجتماعية بتقييم إيجابي لهذا التنسيق ، لذلك قررت (بإذن) نشر ملخص للتقرير الأول. إذا كان هذا التنسيق مثيرًا للاهتمام ، فيمكنني تحضير العديد من المقالات الأخرى.
قاد
لدى Avito العديد من الخدمات والعديد من الروابط بينهما. هذا يسبب مشاكل:
- الكثير من المستودعات. من الصعب تغيير الرمز في كل مكان في وقت واحد
- الفرق محدودة حسب سياقها. التداخل الأقصى قليلاً وليس الكل
- تمت إضافة تجزئة البيانات.
عدد كبير من عناصر البنية التحتية:
- تسجيل الدخول
- طلب تتبع (جيجر)
- تجميع الخطأ (ترقب)
- الحالات / الرسائل / الأحداث من Kubernetes
- حد السباق / قواطع دوائر (Hystrix)
- توصيلية الخدمة (Istio)
- المراقبة (جرافانا)
- التجميع (Teamcity)
- التواصل
- تعقب المهام
- التوثيق
- ...
هناك عدد من الطبقات ، ويصف التقرير طبقة واحدة فقط (PaaS).
تتكون المنصة من 3 أجزاء رئيسية:
- مولدات تسيطر عليها cli
- العارض (المجمع) ، الذي يتم التحكم فيه من خلال لوحة العدادات
- تخزين مع محفزات لأعمال معينة.
خط الأنابيب القياسي لتنمية الخدمات الصغيرة
CLI-push -> CI -> Bake -> Deploy -> Test -> Canary -> Productionدفع CLI
لفترة طويلة علمت أن تفعل المطورين المناسبين. على الرغم من كل ذلك ، ظلت نقطة ضعف.
مؤتمتة من خلال أداة cli التي تساعد على إنشاء أساس للخدمات الصغيرة:
- ينشئ خدمة قالب (يتم دعم قوالب عدد من PLS).
- ينشر البنية التحتية تلقائيا للتنمية المحلية
- يربط قاعدة بيانات (لا يتطلب التكوين ، لا يفكر المطور في الوصول إلى أي قاعدة بيانات).
- بناء مباشر
- إنشاء القرص Autotest.
يتم وصف التكوين في ملف toml.
ملف مثال:
التحقق
فحوصات التحقق الأساسية:
- توفر Dockerfile
- app.toml
- توافر الوثائق
- التبعيات
- قواعد التنبيه للمراقبة (يحددها صاحب الخدمة)
التوثيق
يجب أن يكون لدى الجميع وثائق ، ولكن لا يوجد أحد تقريبًا لديه
يجب أن تتضمن الوثائق:
- وصف الخدمة (قصير)
- رابط لمخطط العمارة
- دليل التشغيل
- التعليمات
- وصف API لنقطة النهاية
- العلامات (ملزمة للمنتج والوظيفة والتقسيم الهيكلي)
- مالك (أصحاب) الخدمة (قد يكون هناك العديد ، في معظم الحالات يمكن تحديدها تلقائيًا).
يجب مراجعة الوثائق.
إعداد خط الأنابيب
- مستودعات الطبخ
- عمل خط أنابيب في TeamCity
- وضعنا الحقوق
- نحن نبحث عن المالك (اثنان ، واحد لا يعول عليه)
- تسجيل الخدمة في أطلس (منتج داخلي)
- تحقق من الهجرة.
اخبز
- بناء التطبيق في صورة عامل ميناء.
- إنشاء مخططات الدفة للخدمة نفسها والموارد ذات الصلة (DB ، ذاكرة التخزين المؤقت)
- يتم إنشاء التذاكر للمسؤولين لفتح المنافذ ، وتؤخذ قيود الذاكرة ووحدة المعالجة المركزية بعين الاعتبار.
- قم بإجراء اختبارات الوحدة. يتم الحفاظ على تغطية التعليمات البرمجية. إذا كان أقل من معين ، فسيتم الانتهاء من النشر. إذا لم تتقدم التغطية ، يتم دفع الإخطارات.
يتم تحديد بحث المالك من خلال الدفع (عدد الدفع ومقدار الشفرة فيها).
إذا كانت هناك عمليات ترحيل (خطر) محتملة محتملة ، فسيتم تسجيل الزناد في Atlas ويتم عزل الخدمة.
يتم حل الحجر الصحي من خلال الدفع للمالكين (في الوضع اليدوي؟)
التحقق من الاتفاقية
نتحقق من:
- نقطة نهاية الخدمة
- مراسلات الإجابات للمخطط
- تنسيق السجل
- تعيين الرؤوس (بما في ذلك X-Source-ID عند إرسال الرسائل إلى الناقل لتتبع الاتصال عبر الناقل)
الاختبارات
يتم إجراء الاختبار في حلقة مغلقة (على سبيل المثال ، hoverfly.io) - يتم تسجيل الحمل النموذجي. ثم يتم محاكاته في حلقة مغلقة.
يتم التحقق من مراسلات استهلاك الموارد (نحن ننظر بشكل منفصل في الحالات القصوى - موارد قليلة جدًا / كثيرة) ، يتم قطعها بواسطة rps.
يُظهر اختبار الحمل أيضًا دلتا الأداء بين الإصدارات.
اختبارات الكناري
نبدأ الإطلاق على عدد صغير جدًا من المستخدمين (<0.1٪).
تحميل الحد الأدنى 5 دقائق. ساعتين الرئيسي. ثم يزيد حجم المستخدمين إذا كان كل شيء على ما يرام.
نحن ننظر:
- مقاييس المنتج (أولاً وقبل كل شيء) - هناك الكثير منها (100500)
- أخطاء ترقب
- حالات الاستجابة ،
- وقت المستجيبين - وقت الاستجابة الدقيق والمتوسط
- الكمون
- الاستثناءات (المجهزة وغير المجهزة)
- أكثر تحديدًا للغة المقياس (مثل العاملين في php-fpm)
اختبار الضغط
اختبار البثق.
نقوم بتحميل المستخدمين الحقيقيين 1 مثيل إلى نقطة الفشل. نحن ننظر إلى سقفها. بعد ذلك ، قم بإضافة مثيل آخر وتحميله. نحن ننظر إلى السقف التالي. نحن ننظر إلى الانحدار. نقوم بإثراء أو استبدال البيانات من اختبار الحمل في Atlas.
تحجيم
وحدة المعالجة المركزية فقط هي سيئة ، تحتاج إلى إضافة مقاييس المنتج.
المخطط النهائي:
- CPU + RAM
- عدد الطلبات
- زمن الاستجابة
- التوقعات التاريخية
عند القياس ، لا تنس أن تنظر في تبعيات الخدمة. تذكر سلسلة التحجيم (مستوى +1). نحن ننظر إلى البيانات التاريخية لخدمة التهيئة.
اختياري
- معالجة المشغل - عمليات الترحيل إذا لم يكن هناك نسخة أقل من X متبقية
- لم يتم تحديث الخدمة لفترة طويلة
- الحجر الصحي
- تحديثات آمنة
لوحة القيادة
نحن ننظر إلى كل شيء من الأعلى في شكل مجمع ونستخلص النتائج.
- تصفية الخدمة والتسمية
- التكامل مع التتبع والتسجيل والمراقبة
- وثائق خدمة نقطة واحدة
- نقطة عرض واحدة لجميع أحداث الخدمة
مثال:
