كيف نكتب خدمات micros ولماذا لا نفعل ذلك بسرعة

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

في RBK.money ، لدينا أيضًا خدمات ميكروية. لكننا أتينا إليهم بطريقة مختلفة قليلاً عن معظمهم. كان كل شيء أسوأ بالنسبة لنا من المتراصة - في البداية ، كان كل شيء سيئًا.

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

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

سريع مقابل جيد

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

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

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

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

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

1. ابدأ الخدمة

كيف كان:

1. انتقل إلى سجل ويندوز.
2. العثور على مفتاح معين هناك.
3. تغييره إلى 1.
4. ابدأ الخدمة
5. إعادة تعيين قيمة المفتاح إلى 0.

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

كود من البروتوكول

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

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

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

يوجد 50 خدمة مصرفية في RBK Money ، وهي مكتوبة بواسطة حوالي 20 شخصًا. التوفير موجود في كل مكان بالداخل ، للمطورين بروتوكول معقد إلى حد ما ، وصعوبة الحذف صعبة ، كما يصعب كتابة الوثائق. وإذا تركت التصفيف في أنقى صوره ، فسوف يطلقون عليّ كلمات سيئة. لذلك ، لم نتوصل إلى أي شيء - راحة JSON ، بسيطة وبديهية ، بالإضافة إلى OpenAPI ، تتمسك بشغف. لتكون قادرًا على قبول هذه الطلبات من الخارج ، يجب أن يتم التحقق من صحتها وترخيصها ، ثم إطلاقها في النظام الأساسي بواسطة خدمات ميكروية أخرى. وكتبنا أيضًا هذا الأمر برمته كخدمة ميكروية مستقلة ، وهي:

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

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

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