قبل أسبوع ، تحدثت في اجتماع Node.JS ، ووعدت الكثيرين بنشر تسجيل للأداء. أدركت لاحقًا أنني لم أتمكن من استيعاب بعض الحقائق المثيرة للاهتمام في نصف ساعة منظمة. نعم ، وأنا أفضل القراءة ، بدلاً من المشاهدة والاستماع ، لذلك قررت أن أرسل عرضي التقديمي في شكل مقال. ومع ذلك ، سيكون الفيديو أيضًا في نهاية المنشور في قسم الروابط.
قررت أن أخبركم عن نقطة حساسة - الحياة في متراصة. يوجد بالفعل مئات من المقالات حول هذا الموضوع على المحور ، يتم كسر الآلاف من النسخ في التعليقات ، والحقيقة توفي لفترة طويلة في الجدل ، ولكن ... الحقيقة هي أن لدينا تجربة محددة للغاية في OneTwoTrip ، على عكس العديد من الأشخاص الذين يكتبون عن أنماط معمارية معينة في الفراغ:
- أولاً ، متراصة لدينا بالفعل 9 سنوات.
- ثانياً ، لقد قضى حياته كلها تحت عبء كبير (أصبح الآن 23 مليون طلب في الساعة).
- وفي NaN ، نكتب متجانستنا على Node.JS ، والتي تغيرت إلى حد لا يمكن الاعتراف به على مدى السنوات التسع الماضية. نعم ، بدأنا الكتابة على العقدة في عام 2010 ، ونحن نغني أغنية لجنون الشجعان!
لذلك لدينا الكثير من أي خصوصية وتجربة حقيقية. المهتمة؟ دعنا نذهب!
إخلاء المسؤولية مرات
يعكس هذا العرض التقديمي فقط الرأي الخاص لمؤلفه. قد يتزامن مع موضع OneTwoTrip ، أو قد لا يتزامن. هذا هو كيف الحظ. أعمل كخبير فني في أحد فرق الشركة ولا أدعي أنه موضوعي أو يعبر عن رأي شخص آخر غير رأيي.
تنويه اثنين
توضح هذه المقالة الأحداث التاريخية ، وفي الوقت الحالي ، كل شيء خاطئ تمامًا ، لذلك لا تنزعج.
0. كيف حدث ذلك
اتجاه الاستعلام لكلمة "microservice" في google:
كل شيء بسيط للغاية - منذ تسع سنوات لم يكن أحد يعلم عن الخدمات الصغيرة. لذلك بدأنا الكتابة ، مثل أي شخص آخر - في متراصة.
1. ألم في متراصة
هنا سوف أصف حالات المشكلات التي واجهناها خلال هذه السنوات التسع. تم حل بعضها ، وتم التحايل على بعضها من قبل المتسللين ، والبعض الآخر فقد أهميته. لكن ذاكرتهم ، مثل ندوب المعارك ، لن تتركني أبداً.
1.1 تحديث المكونات المتصلة
هذا هو الحال عندما يكون التآزر شريرًا. نظرًا لأنه تم إعادة استخدام أي مكون لعدة مئات من المرات ، وإذا كان من الممكن استخدامه بطريقة ملتوية ، فلن يتم فقده. أي إجراء يمكن أن يسبب تأثيرات لا يمكن التنبؤ بها تمامًا ، ولا يتم تتبعها جميعًا بواسطة الوحدات واختبارات التكامل. تذكر قصة عن المماسح ، مروحة ، وبالون؟ إذا لم يكن كذلك ، جوجل ذلك. إنها أفضل توضيح للرمز في المتراصة.
1.2 الهجرة إلى التكنولوجيات الجديدة
هل تريد اكسبرس؟ اللنت؟ إطار آخر للاختبارات أو موكس؟ تحديث المدقق أو على الأقل lodash؟ تحديث Node.js؟ انا اسف للقيام بذلك ، يجب عليك تحرير آلاف أسطر التعليمات البرمجية.
يتحدث الكثيرون عن ميزة المتراصة ، وهي أن أي مراجعة هي التزام ذري . هؤلاء الناس صامتون بشأن شيء واحد - هذه المراجعة لن تتم أبداً .
هل تعرف النكتة القديمة عن الإصدارات الدلالية؟
الدلالات الحقيقية للإصدار الدلالي:
الرئيسية = تغيير كسر
قاصر = تغيير طفيف
التصحيح = تغيير كسر قليلا
الآن تخيل أن أي تغيير بسيط قليلاً سوف يظهر في شفرتك. لا ، من الممكن أن نتعايش معها ، وقد جمعنا قوتنا ونهاجر بشكل دوري ، لكن كان الأمر صعبًا للغاية. جدا.
1.3 الإصدارات
هنا يجب أن أقول عن بعض تفاصيل منتجاتنا. لدينا عدد كبير من عمليات الدمج الخارجية وفروع منطق الأعمال المختلفة التي نادرا ما تنبثق بشكل منفصل. أنا أحسد حقًا على المنتجات التي تنفذ فعليًا جميع فروع الشفرة الخاصة بها في 10 دقائق من الإنتاج ، ولكن هذا ليس هو الحال هنا. من خلال التجربة والخطأ ، وجدنا لأنفسنا دورة إطلاق مثالية تقلل من عدد الأخطاء التي تصل إلى المستخدمين النهائيين:
- الإصدار قيد التنفيذ وتنجح اختبارات الاندماج في نصف يوم
- ثم تحت إشراف دقيق على المسرح لمدة يوم (لمدة 10 ٪ من المستخدمين)
- ثم يكمن يوم آخر على الإنتاج تحت إشراف أكثر حذرا.
- وفقط بعد ذلك نعطيه الضوء الأخضر في السيد.
نظرًا لأننا نحب زملائنا ولا نصدر يوم الجمعة ، فهذا يعني في النهاية أن الإصدار يذهب إلى المعلم حوالي 1.5-2 مرات في الأسبوع. مما يؤدي إلى حقيقة أن الإصدار يمكن أن يكون 60 مهمة أو أكثر. يؤدي هذا المبلغ إلى تعارضات الدمج وتأثيرات التآزر المفاجئ وعبء العمل الكامل عن ضمان الجودة على تحليل السجل والأحزان الأخرى. بشكل عام ، كان من الصعب للغاية بالنسبة لنا إصدار متراصة.
1.4 فقط الكثير من التعليمات البرمجية
يبدو أن مقدار الكود لا ينبغي أن يكون ذا أهمية أساسية. لكن ... ليس حقا. في العالم الحقيقي هو:
- عتبة دخول أعلى
- التحف بناء ضخمة لكل مهمة
- عمليات CI الطويلة ، بما في ذلك اختبارات التكامل واختبارات الوحدات وحتى شفرة الفحص
- العمل البطيء IDE (في فجر تطوير Jetbrains ، صدمناهم بسجلاتنا أكثر من مرة)
- البحث السياقي المتطور (لا تنس ، ليس لدينا كتابة ثابتة)
- صعوبة في العثور على التعليمات البرمجية غير المستخدمة وإزالتها
1.5 أصحاب الرموز المفقودة
في كثير من الأحيان تنشأ المهام مع مجال غير مفهوم من المسؤولية - على سبيل المثال ، في المكتبات ذات الصلة. ويمكن للمطور الأصلي الانتقال بالفعل إلى فريق آخر ، أو حتى مغادرة الشركة. الطريقة الوحيدة للعثور على المسؤولية في هذه الحالة هي التعسف الإداري - لأخذ وتعيين شخص. وهو ليس ممتعًا دائمًا لكل من المطور والشخص الذي يقوم بذلك.
1.6 صعوبة التصحيح
هل الذاكرة تتدفق؟ زيادة استهلاك وحدة المعالجة المركزية؟ مطلوب لبناء الرسوم البيانية لهب؟ انا اسف في متراصة ، تحدث أشياء كثيرة في نفس الوقت ، بحيث يصبح من الصعب تمييز مشكلة ما بجنون. على سبيل المثال ، لفهم أيٍّ من المهام الستين عند بدء الإنتاج يؤدي إلى زيادة استهلاك الموارد (على الرغم من أن هذا لا يتم إعادة إنتاجه محليًا في بيئات الاختبار والتدريج) فهو غير واقعي تقريبًا.
1.7 كومة واحدة
من ناحية ، من الجيد أن "يتحدث" جميع المطورين بنفس اللغة. في حالة JS ، اتضح أنه حتى Backend مع مطوري Frontend يفهمون بعضهم البعض. لكن ...
- لا توجد رصاصة فضية ، وفي بعض المهام تريد أحيانًا استخدام شيء آخر. لكن لدينا مجموعة متراصة ، وليس لدينا أي مكان لإلصاق مطورين آخرين.
- لا يمكننا فقط أن نأخذ فريقًا جيدًا بناءً على التوصية ، التي جاءت إلينا بناءً على نصيحة الأصدقاء - ليس لدينا مكان لوضعها.
- بمرور الوقت ، نحن نعتمد على حقيقة أن السوق ببساطة لا يحتوي على عدد كاف من المطورين في المجموعة المناسبة.
1.8 العديد من الفرق ذات الأفكار المختلفة عن السعادة
إذا كان لديك مطوران ، فأنت لديك بالفعل فكرتان مختلفتان حول أيهما أفضل إطار ، والمعايير التي يجب احترامها ، واستخدام المكتبات ، وما إلى ذلك.
إذا كان لديك عشرة فرق ، لكل منها عدة مطورين ، فهذه مجرد كارثة.
وهناك طريقتان فقط لحلها - إما "ديمقراطية" (كل شخص يفعل ما يريد) ، أو شمولي (المعايير مفروضة من الأعلى). في الحالة الأولى ، تعاني الجودة والتوحيد ، في الحالة الثانية - الأشخاص الذين لا يُسمح لهم بإدراك فكرة السعادة لديهم.
2. مزايا متراصة
بالطبع ، هناك بعض المزايا في المتراصة التي يمكن أن تكون مختلفة لمجموعات مختلفة ، والمنتجات ، والفرق. بالطبع ، هناك أكثر من ثلاثة أشخاص ، لكنني لن أكون مسؤولاً عن كل ما هو ممكن ، فقط لأولئك الذين كانوا وثيقي الصلة بنا.
2.1 سهلة النشر
عندما يكون لديك خدمة واحدة ، فإن رفعها واختبارها أسهل بكثير من اثنتي عشرة خدمة. صحيح ، هذه الإضافة ذات صلة فقط في المرحلة الأولية - على سبيل المثال ، يمكنك رفع بيئة الاختبار ، واستخدام جميع الخدمات ، باستثناء ما تم تطويره منها. أو من الحاويات. أو أي شيء آخر.
2.2 لا نقل البيانات النفقات العامة
زائد مشكوك فيه جدا ، إذا لم يكن لديك حمولة كبيرة. لكن لدينا مثل هذه الحالة - وبالتالي ، فإن تكلفة النقل بين الخدمات الصغيرة ملحوظة بالنسبة لنا. بغض النظر عن كيفية القيام بذلك بسرعة ، يمكنك تخزين ونقل كل شيء في ذاكرة الوصول العشوائي بشكل أسرع من أي شيء آخر - وهذا أمر واضح.
2.2 تجميع واحد
إذا كنت بحاجة إلى التراجع في مرحلة ما من التاريخ ، فإن القيام بذلك باستخدام متراصة أمر بسيط حقًا - خذها وتراجعها. في حالة الخدمات المصغرة ، من الضروري تحديد إصدارات متوافقة من الخدمات التي تم استخدامها مع بعضها البعض في وقت معين ، والتي لا يمكن أن تكون بسيطة دائمًا. صحيح ، تم حل هذا أيضًا بمساعدة البنية التحتية.
3. مزايا خيالية من متراصة
هنا أخذت كل تلك الأشياء التي عادة ما تعتبر إيجابيات ، ولكن من وجهة نظري فهي ليست كذلك.
3.1 رمز - هذه هي الوثائق
كثيرا ما سمعت هذا الرأي. ولكن عادة ما يتبعه مطورو مبتدئون لم يروا الملفات بعشرات الآلاف من أسطر الشفرات التي كتبها أشخاص تركوا قبل سنوات. حسنًا ، لسبب ما ، غالبًا ما تتم إضافة هذا العنصر لصالح مؤيدي متراصة - يقولون إننا لا نحتاج إلى أي وثائق ، وليس لدينا أي وسيلة نقل أو واجهة برمجة تطبيقات - كل شيء موجود في الكود ، إنه سهل وواضح. أنا لن أجادل مع هذا البيان ، فقط أقول أنني لا أؤمن به.
3.2 لا توجد إصدارات مختلفة من المكتبات والخدمات وواجهات برمجة التطبيقات. لا توجد مستودعات مختلفة.
نعم. لكن لا. لأنه في النظرة الثانية ، تفهم أن الخدمة غير موجودة في فراغ. ومن بين عدد كبير من الشفرات والمنتجات الأخرى التي يتم دمجها بها - بدءًا من مكتبات الجهات الخارجية ، والاستمرار في إصدارات برامج الخادم ، ولا تنتهي بالتكاملات الخارجية ، وإصدار IDE ، وأدوات CI ، وما إلى ذلك. وبمجرد فهمك لعدد الأشياء المختلفة التي تتضمنها خدمتك بشكل غير مباشر ، يصبح من الواضح على الفور أن هذه الإضافة هي مجرد ديماغوجية.
3.3 أسهل الرصد
أسهل. نظرًا لأن لديك لوحة معلومات واحدة تقريبًا ، بدلاً من بضع عشرات. لكن الأمر أكثر تعقيدًا ، وأحيانًا مستحيل ، لأنه لا يمكنك تحليل الرسوم البيانية الخاصة بك إلى أجزاء مختلفة من الشفرة ، ولديك فقط متوسط درجة الحرارة في المستشفى. بشكل عام ، لقد سبق أن قلت كل شيء في الفقرة حول تعقيد تصحيح الأخطاء ، وسأوضح فقط أن نفس التعقيد ينطبق على المراقبة.
3.4 من الأسهل الالتزام بالمعايير المشتركة
نعم. لكن ، كما كتبت بالفعل في الفقرة حول الكثير من الفرق التي لديها فكرة السعادة - يتم فرض المعايير بشكل شمولي ، أو تضعف تقريبًا إلى غيابها.
3.5 فرصة أقل لتكرار الكود
الرأي الغريب هو أن الكود غير مكرر في المتراصة. لكن التقيت به في كثير من الأحيان. في ممارستي ، اتضح أن ازدواجية الكود تعتمد فقط على ثقافة التطوير في الشركة. إذا كان الأمر كذلك ، فسيتم تخصيص الكود العام لجميع أنواع المكتبات والوحدات النمطية والخدمات الميكروية. إذا لم يكن هناك ، فسيكون هناك عجينة نسخ عشرين مرة في المتراصة.
4. إيجابيات الخدمات الدقيقة
الآن سأكتب عن ما حصلنا عليه بعد الهجرة. مرة أخرى ، هذه استنتاجات حقيقية من موقف حقيقي.
4.1 يمكنك إنشاء بنية تحتية غير متجانسة
الآن يمكننا كتابة التعليمات البرمجية على مكدس هو الأمثل لحل مشكلة معينة. ومن المنطقي استخدام أي مطورين جيدين قدموا إلينا. على سبيل المثال ، فيما يلي قائمة نماذج من التقنيات المتوفرة لدينا حاليًا:
4.2 يمكنك عمل العديد من الإصدارات المتكررة
الآن يمكننا أن نجعل العديد من الإصدارات المستقلة الصغيرة ، وهي أبسط وأسرع وغير مؤلمة. بمجرد أن كان لدينا فريق واحد فقط ، لكن الآن هناك 18 فريقًا. سيكون هناك استراحة إذا ظلوا جميعًا في المتراصة. أو الأشخاص المسؤولين عن ذلك ...
4.3 أسهل للقيام اختبارات مستقلة
لقد قللنا من وقت اختبارات الاندماج ، التي تختبر الآن فقط ما الذي تغير بالفعل ، وفي الوقت نفسه لسنا خائفين من آثار التآزر المفاجئ. بالطبع ، كان عليّ أن أتجول في أشعل النار - على سبيل المثال ، تعلم كيفية جعل واجهات برمجة التطبيقات المتوافقة مع الإصدارات السابقة - ولكن بمرور الوقت ، استقر كل شيء.
4.4 أسهل لتنفيذ واختبار ميزات جديدة
الآن نحن منفتحون على التجريب. أي أطر عمل ، ومكدسات ، ومكتبات - يمكنك تجربة كل شيء ، وإذا نجحت ، يمكنك المتابعة.
4.5 يمكنك تحديث أي شيء
يمكنك تحديث إصدار المحرك ، المكتبات ، ولكن أي شيء! كجزء من خدمة صغيرة ، يكون العثور على جميع التغييرات العاجلة وإصلاحها مسألة دقائق. وليس أسابيع ، كما كان من قبل.
4.6 ولا يمكنك التحديث
ومن الغريب أن هذه واحدة من أروع ميزات الخدمات المجهرية. إذا كان لديك كود عمل ثابت ، فيمكنك فقط تجميده ونسيانه. ولن تضطر أبدًا إلى تحديثه ، على سبيل المثال ، من أجل تشغيل رمز المنتج على محرك جديد. المنتج نفسه يعمل على محرك جديد ، ولا تزال الخدمة الميكروية حية كما هي. الذباب مع شرحات يمكن أن تؤكل في النهاية بشكل منفصل.
5 سلبيات من Microservices
بالطبع ، لم تكن الذبابة في المرهم كاملة ، ولم ينجح الحل الأمثل للجلوس والاستلام. ماذا واجهنا:
5.1 بحاجة إلى حافلة لتبادل البيانات وتسجيل واضح.
يعد تفاعل الخدمات عبر HTTP نموذجًا تقليديًا ، وبشكل عام نموذجًا عامًا ، بشرط أن تكون هناك طبقات تسجيل وموازنة بينها. ولكن من الأفضل أن يكون لديك إطار أكثر تميزًا. بالإضافة إلى ذلك ، يجب أن تفكر في كيفية جمع السجلات ودمجها فيما بينها - وإلا سيكون لديك عصيدة على يديك.
5.2 تتبع ما يفعله المطورون.
بشكل عام ، يجب أن يتم ذلك دائمًا ، لكن من الواضح أن المطورين يتمتعون بمزيد من الحرية في الخدمات المجهرية ، مما قد يؤدي أحيانًا إلى ظهور أشياء يمكن أن يؤدي إليها ستيفن كينغ. حتى لو كان ظاهريًا ظاهريًا أن الخدمة تعمل - فلا تنس أن يكون هناك شخص يراقب ما بداخله.
5.3 أنت بحاجة إلى فريق DevOps جيد لإدارة كل شيء.
يمكن لأي مطور تقريبًا نشر متراصة بطريقة أو بأخرى وتحميل إصداراتها (على سبيل المثال ، عبر FTP أو SSH ، رأيت هذا). ولكن مع خدمات microservices ، هناك كل أنواع الخدمات المركزية لجمع السجلات والمقاييس ولوحات المعلومات والطهاة لإدارة التهيئة والجهد والجنك وغيرها من الأشياء الجيدة ، والتي بدونها يمكنك العيش بشكل عام - ولكن هذا أمر سيء وغير مفهوم. حتى تتمكن من إدارة خدمات microservices ، يجب أن يكون لديك فريق DevOps جيد.
5.4 يمكنك محاولة القبض على الضجيج واطلاق النار على نفسك في القدم.
ربما هذا هو الطرح الرئيسي للهندسة المعمارية وخطرها. في كثير من الأحيان يتبع الناس الاتجاهات بشكل عمياء ويبدأون في إدخال الهندسة والتكنولوجيا دون فهمها. بعد ذلك يسقط كل شيء ، يشعرون بالارتباك في الفوضى الناتجة ، ويكتبون مقالًا عن هبر "كيف انتقلنا من الخدمات الصغيرة إلى متراصة" على سبيل المثال. بشكل عام ، لا تتحرك إلا إذا كنت تعرف سبب قيامك بذلك وما هي المشاكل التي ستحلها. وتلك التي تحصل عليها.
6 كاكي في متراصة
بعض الاختراقات التي سمحت لنا بالعيش في متراصة أفضل قليلاً وأطول قليلاً.
6.1 لينت
إدخال linter في متراصة ليست مهمة بسيطة كما يبدو للوهلة الأولى. بالطبع ، يمكنك وضع قواعد صارمة ، إضافة تهيئة ، و ... لن يتغير أي شيء ، كل شخص يقوم بإيقاف تشغيل linter ، لأن نصف الكود يتحول إلى اللون الأحمر.
لتقديم الوبر تدريجياً ، كتبنا إضافة بسيطة لـ eslint - slowlint ، والتي تسمح لك بالقيام بشيء بسيط واحد - لاحتواء قائمة من الملفات التي تم تجاهلها مؤقتًا. نتيجة لذلك:
- يتم تمييز كل رمز غير صحيح في IDE
- يتم إنشاء ملفات جديدة وفقًا لقواعد الفحص ، وإلا فإن CI لن تفوتها
- القديمة تسود تدريجيا والابتعاد عن الاستثناءات
على مدار العام ، كان من الممكن إدخال حوالي نصف رمز المونليث في نمط واحد ، أي تقريبا كل الشفرات المضافة بنشاط.
6.2 تحسينات اختبار الوحدة
مرة واحدة أجريت اختبارات وحدة معنا لمدة ثلاث دقائق. لا يريد المطورون الانتظار كثيرًا من الوقت ، لذلك تم فحص كل شيء فقط في CI على الخادم. بعد مرور بعض الوقت ، اكتشف المطور أن الاختبارات سقطت ، ولعنت ، وفتحت فرعًا ، وعادت إلى الرمز ... بشكل عام ، عانى. ماذا فعلنا بهذا:
- بالنسبة للمبتدئين ، بدأنا في إجراء اختبارات ذات مؤشرات ترابط متعددة. Yandex لديها نوع مختلف من المخاوي المتعددة الخيوط ، لكن معنا لم تقلع ، لذلك قاموا هم أنفسهم بكتابة غلاف بسيط. بدأت الاختبارات التي يتم تنفيذها أسرع مرة ونصف.
- ثم انتقلنا من 0.12 إلى العقد الثامن (نعم ، العملية نفسها توجه إلى تقرير منفصل). غريبًا كما يبدو ، لم يحقق مكسبًا أساسيًا في الإنتاجية في الإنتاج ، ولكن بدأت الاختبارات أسرع بنسبة 20٪.
- ثم جلسنا لتصحيح الاختبارات وتحسينها بشكل فردي. مما أعطى أكبر زيادة في السرعة.
بشكل عام ، في الوقت الحالي ، تجري اختبارات الوحدة في خط الإعداد وتنجح في 10 ثوان ، وهي مريحة للغاية وتتيح لك تشغيلها دون مقاطعة الإنتاج.
6.3 تخفيف الوزن قطعة أثرية
في نهاية المطاف استغرق قطعة أثرية متراصة 400 ميغابايت. بالنظر إلى حقيقة أنه تم إنشاؤه لكل التزام ، فقد تبين أن الكميات الكلية كبيرة جدًا. ساعدتنا وحدة الإسهال ، وهي شوكة الوحدة النمطية ، في هذا الأمر. لقد أزلنا اختبارات الوحدة من قطعة أثرية وقمنا بتنظيفها من القمامة المختلفة مثل ملفات المستند التمهيدي والاختبارات داخل الحزم وما إلى ذلك. وكان المكسب حوالي 30 ٪ من الوزن!
6.4 التخزين المؤقت التبعية
في السابق ، استغرق تثبيت التبعيات باستخدام npm الكثير من الوقت بحيث لا يمكنك فقط شرب القهوة ، ولكن أيضًا ، على سبيل المثال ، خبز البيتزا. لذلك ، في البداية استخدمنا وحدة ذاكرة التخزين المؤقت npm ، والتي كانت متشعبة وانتهت قليلاً. لقد سمح لك بتخزين التبعيات على محرك أقراص شبكة مشترك ، والتي ستأخذ منها جميع البنيات الأخرى.
ثم فكرنا في استنساخ الجمعيات. عندما يكون لديك متراصة ، فإن تغيير التبعيات الانتقالية هو آفة الله. نظرًا لحقيقة أننا كنا متخلفين كثيرًا عن إصدار المحرك في ذلك الوقت ، فإن تغيير تبعية المستوى الخامس من شأنه أن يؤدي بسهولة إلى كسر التجميع بأكمله. لذلك بدأنا في استخدام npm-shrinkwrap. لقد كان الأمر أسهل معه بالفعل ، على الرغم من أن دمج تغييراته كان من دواعي سروري للقوي في الروح.
وبعد ذلك ، ظهر أخيرًا قفل الحزمة npm ci الممتاز - والذي كان يعمل بسرعة أقل قليلاً فقط من تثبيت التبعيات من ذاكرة التخزين المؤقت للملف. لذلك ، بدأنا استخدامه فقط ، وتوقفنا عن تخزين تجميعات التبعية. في هذا اليوم ، أحضرت للعمل عدة صناديق من الكعك.
6.5 توزيع ترتيب الإصدارات.
وهذا أكثر من مجرد اختراق إداري وليس تقنيًا. في البداية ، كنت أعارضه ، لكن الوقت أظهر أن الخبير الفني الثاني كان على صواب وكان جيدًا بشكل عام. عندما تم توزيع الإصدارات بدورها بين عدة فرق ، أصبح من الواضح أين ظهرت الأخطاء بالضبط ، والأهم من ذلك ، شعر كل فريق بمسؤوليته عن السرعة ، وحاول حل المشكلات وطرحها في أسرع وقت ممكن.
6.6 حذف الكود الميت
في متراصة ، من المخيف جدًا حذف الكود - فأنت لا تعرف أبدًا أين يمكن أن تتعثر فيه. لذلك ، في الغالب يبقى فقط الاستلقاء على الجانب. على مر السنين. وحتى الكود الميت يجب دعمه ، ناهيك عن الارتباك الذي يقدمه. لذلك ، مع مرور الوقت ، بدأنا في استخدام -طلب تحليل للبحث سطحي عن رمز ميت ، واختبارات التكامل بالإضافة إلى إطلاق في وضع التحقق من التغطية للبحث أعمق.
7 متراصة قطع
لسبب ما ، يعتقد الكثير من الناس أنه من أجل التبديل إلى الخدمات المصغرة ، تحتاج إلى التخلي عن متراصة ، وكتابة مجموعة من الخدمات المصغرة من نقطة الصفر ، وبدء تشغيلها مرة واحدة - وستكون هناك سعادة. لكن هذا النموذج ... حسنًا ... إنه محفوف بحقيقة أنك لن تفعل شيئًا ، وأن تقضي الكثير من الوقت والمال في كتابة الكود الذي يجب عليك التخلص منه.
أقترح خيارًا آخر يبدو لي أكثر فاعلية والذي تم تنفيذه معنا:
- نبدأ في كتابة خدمات جديدة في خدمات microservices. ندير التكنولوجيا ، والقفز على أشعل النار ، ونحن نفهم ما إذا كنا نريد أن نفعل ذلك على الإطلاق.
- نقوم باستخراج الشفرة إلى وحدات نمطية أو مكتبات أو أي شيء يستخدم هناك.
- نحن نميز الخدمات من متراصة.
- نحن نميز الخدمات الميكروية عن الخدمات. دون التسرع واحد في وقت واحد.
8 وأخيرا
في النهاية ، قررت أن أترك أهم شيء.
تذكر:
- أنت لست جوجل
- أنت لست مايكروسوفت
- أنت لست فيسبوك
- أنت لست ياندكس
- أنت لست netflix
- أنت لست OneTwoTrip
إذا كان هناك شيء ما يعمل في شركات أخرى ، فليس من المفيد لك على الإطلاق. إذا حاولت نسخ تجربة شركات أخرى بصورة عمياء بعبارة "إنها مفيدة لهم" ، فمن المحتمل أن ينتهي هذا الأمر بشكل سيء. كل شركة وكل منتج وكل فريق فريد من نوعه. ما يصلح للبعض لن ينفع للآخرين. لا أحب أن أقول أشياء واضحة ، لكن الكثير من الناس يبدؤون في بناء عبادة شحن حول شركات أخرى ، واتباع نُسخ عمياء ، ودفن أنفسهم تحت زخارف شجرة عيد الميلاد المزيفة. لا تفعل ذلك. تجربة ، حاول ، تطوير تلك الحلول المثلى لك. وعندها فقط كل شيء سوف ينجح في مسعاه.
روابط مفيدة: