المقدمة
في الآونة الأخيرة ، تمت مناقشة عيوب البنى الموجهة للخدمة ، وبشكل خاص ، معماريات الخدمات المصغرة (MA) بنشاط. قبل بضع سنوات فقط ، كان الكثير على استعداد للانتقال إلى MA بسبب فوائده العديدة: المرونة في شكل عمليات النشر المستقلة ، والملكية الشفافة ، وزيادة استقرار النظام ، وفصل الاهتمامات بشكل أفضل. ومع ذلك ، فقد تغير الوضع مؤخرًا: فقد بدأ انتقاد نهج الخدمات المصغرة بسبب ميله إلى زيادة التعقيد بشكل خطير ، مما يجعل من الصعب أحيانًا تنفيذ حتى الوظائف التافهة . (تحدثنا عن هذا في الحديث "الخدمات المصغرة: الحجم مهم ، حتى لو كان لديك Kubernetes " - تقريبًا. الترجمة.)
تمتلك أوبر حاليًا حوالي 2200 خدمة مصغرة مهمة ، وقد اختبرنا جميع إيجابيات وسلبيات هذا النهج بأنفسنا. على مدار العامين الماضيين ، حاولت أوبر تقليل تعقيد مشهد الخدمات المصغرة مع الحفاظ على مزايا الهندسة على طول الطريق. من خلال هذا المنشور ، نخطط لتقديم نهجنا العام لبنى الخدمات المصغرة يسمى هندسة الخدمات المصغرة ذات النطاق الموجه (DOMA).
في حين أنه كان من الشائع انتقاد بنى الخدمات المصغرة لأوجه القصور فيها في السنوات الأخيرة ، إلا أن القليل منهم تجرأ على إعلان أنه ينبغي التخلي عنها تمامًا. الفوائد التشغيلية كلها مهمة للغاية ؛ علاوة على ذلك ، يبدو أنه لا توجد بدائل (أو محدودة للغاية) لهذا النهج. الهدف من نهجنا المعمم هو مساعدة المؤسسات التي ترغب في تقليل التعقيد الكلي للنظام مع الحفاظ على المرونة الكامنة في MA.
ستستكشف هذه المقالة DOMA ، والتحديات التي أدت إلى هذا النهج في Uber ، وفوائدها لفرق النظام الأساسي والمنتجات ، وأخيرًا بعض النصائح لأولئك الذين يتطلعون إلى الانتقال إلى هذه البنية.
ما هي الخدمة المصغرة؟
الخدمات المصغرة هي امتداد للهياكل الموجهة نحو الخدمة. على عكس "الخدمات" الكبيرة نسبيًا في العقد الأول من القرن الحادي والعشرين ، تؤدي الخدمات المصغرة مهمة محددة. تتم استضافة هذه التطبيقات ويمكن الوصول إليها عبر الشبكة وتوفر واجهة محددة جيدًا. تصل التطبيقات الأخرى إلى هذه الواجهة باستخدام استدعاء الإجراء البعيد (RPC).
السمة الرئيسية للماجستير هي الطريقة التي يتم بها نشر التعليمات البرمجية واستدعاءها ونشرها. عادة ما يتم تقسيم التطبيقات الكبيرة المتجانسة إلى مكونات مغلفة بواجهات محددة جيدًا. ثم يتم استدعاء هذه الواجهات مباشرة من داخل العملية وليس عبر الشبكة. بهذا المعنى ، يمكن اعتبار الخدمة المصغرة نوعًا من المكتبات ذات الأداء المنخفض (بسبب تأثير تأخيرات الشبكة والوقت على التسلسل / إلغاء التسلسل) عند استدعاء أي من وظائفها.
بالتفكير في الخدمات المصغرة بهذه الطريقة ، قد نتساءل لماذا نحتاج إلى بنية الخدمات المصغرة على الإطلاق؟ تكمن الإجابة الكلاسيكية لهذا السؤال في القدرة على نشر المكونات الفردية بشكل مستقل وتوسيع نطاقها بسهولة.... في حالة وجود تطبيق كبير ومتآلف ، تضطر المنظمة إلى نشر أو إطلاق كل الكود في نفس الوقت. نتيجة لذلك ، يحمل كل إصدار جديد الكثير من التغييرات. تصبح عمليات النشر محفوفة بالمخاطر وتستغرق وقتًا طويلاً. يمكن أن يؤدي أي خطأ إلى انهيار النظام بأكمله.
وبالتالي ، تنتقل الشركات إلى الخدمات المصغرة لسهولة الاستخدام مع التضحية بالأداء . كما يتعين عليهم أيضًا تحمل التكاليف الإضافية لصيانة البنية التحتية المطلوبة للخدمات المصغرة. تظهر التجربة أنه في العديد من المواقف يكون مثل هذا الحل الوسط منطقيًا. في الوقت نفسه ، إنها حجة قوية ضد الانتقال المبكر إلى MA.
التحفيز
في وقت الانتقال إلى الخدمات المصغرة (حوالي 2012-2013) ، كان لدينا في أوبر خدمتان رئيسيتان متجانستان ، وواجهنا الكثير من المشكلات التشغيلية التي نجحت الخدمات المصغرة في حلها:
- مخاطر التوفر. يمكن لأي خطأ في قاعدة بيانات monolith أن يسقط النظام بأكمله (في هذه الحالة ، Uber بالكامل).
- عمليات النشر المحفوفة بالمخاطر والمكلفة. كان من الصعب جدًا تنفيذها ، وغالبًا ما كان يتعين عليهم الرجوع إلى الإصدار السابق.
- ضعف الفصل بين مناطق المسؤولية. كان من الصعب جدًا تتبع المسؤول عن ما في قاعدة البيانات الضخمة. مع النمو المتسارع ، فإن التسرع أحيانًا يطمس الخطوط الفاصلة بين المنطق والمكونات.
- عمل غير فعال. جعلت المشاكل المذكورة أعلاه معًا من الصعب على الفرق العمل بشكل مستقل أو مستقل عن بعضها البعض.
بعبارة أخرى ، على خلفية الزيادة في عدد المهندسين في أوبر من العشرات إلى المئات من الأشخاص وظهور عدد كبير من الفرق التي تمتلك أجزاء من مجموعة التكنولوجيا ، ربطت الهندسة المتجانسة بشكل متزايد مصير هذه الفرق ولم تسمح لهم بالعمل بشكل مستقل.
لذلك ، قررنا التبديل إلى MA. نتيجة لذلك ، أصبحت أنظمتنا أكثر مرونة وسمحت للفرق بأن تصبح أكثر استقلالية .
- موثوقية النظام. تزداد موثوقية النظام الإجمالية مع الانتقال إلى MA. يمكن أن تتعطل خدمة فردية (ويمكن التراجع إلى إصدار سابق) دون المخاطرة بتعطل النظام بأكمله.
- . - : « ?», — .
- . , . , , , , .
- . .
- . .
ليس من قبيل المبالغة القول إن أوبر لم تكن لتصل إلى نطاقها الحالي ومستوى الجودة بدون المتوسط المتحرك.
ومع ذلك ، مع استمرار نمو الشركة وزيادة عدد المهندسين من المئات إلى الآلاف ، بدأنا نلاحظ عددًا من المشكلات المرتبطة بزيادة تعقيد النظام بشكل كبير . في حالة MA ، فإننا نضحي بقاعدة كود واحدة متجانسة مقابل عدد من "الصناديق السوداء" التي يمكن أن تتغير وظائفها في أي وقت وتؤدي إلى سلوك غير متوقع.
على سبيل المثال ، كان على المهندسين تحليل حوالي 50 خدمة عبر 12 فريقًا مختلفًا للوصول إلى جذر المشكلة.
يمكن أن يصبح فهم التبعيات بين الخدمات أمرًا صعبًا للغاية حيث يمكن أن تتفاعل مع بعضها البعض على عدة مستويات. يمكن أن يتسبب ارتفاع حالات التأخير في التبعية في سلسلة من المشاكل في خدمات المنبع. علاوة على ذلك ، بدون الأدوات المناسبة ، سيكون من المستحيل فهم ما حدث. كل هذا يجعل تصحيح الأخطاء صعبًا للغاية.
هندسة الخدمات الصغيرة في أوبر اعتبارًا من منتصف عام 2018 بواسطة Jaeger
لتنفيذ أبسط وظيفة ، غالبًا ما يتعين على المهندس العمل مع العديد من الخدمات ، في حين أن الفرق والأشخاص المختلفين تمامًا هم المسؤولون عنها. نتيجة لذلك ، يتم قضاء الكثير من الوقت في تنظيم العمل الجماعي والاجتماعات واستشارات التصميم ومراجعة الكود (المراجعة الأساسية). تتلاشى الفائدة الأولية لشفافية الملكية تدريجيًا مع استمرار غزو الفرق لخدمات بعضها البعض ، وتغيير نماذج البيانات ، وحتى النشر نيابة عن مالكي الخدمات. يمكن أن يؤدي هذا إلى إنشاء وحدات متجانسة للشبكة حيث تبدو الخدمات مستقلة فقط ، ولكن في الواقع يجب نشرها معًا من أجل إجراء أي تغيير بأمان.
مثال على مثل هذا النظام المعقد في Uber (~ 2018) مع عشر نقاط اتصال لسهولة التكامل (حتى قبل DOMA).
نتيجة لذلك ، لدينا تباطؤ في عملية التطوير ، وعدم استقرار يضرب أصحاب الخدمة ، والمزيد من عمليات الترحيل التي تستغرق وقتًا طويلاً ، وما إلى ذلك. للأسف ، ليس هناك عودة للمنظمات التي تحولت بالفعل إلى MA. يتضح الموقف تمامًا من خلال العبارة المعروفة: "من المستحيل العيش معهم ولا يمكنك إطلاق النار عليهم ".
بنية الخدمات المصغرة الخاصة بالمجال
فكر في الخدمات المصغرة على أنها مكتبات مرتبطة بإدخال / إخراج ، وبنية الخدمات المصغرة كتطبيق ضخم وموزع. في هذه الحالة ، يمكننا استخدام الحلول المعمارية المعروفة للتفكير في أفضل السبل لتنظيم الكود الخاص بنا.
وهكذا، فإن Microservice العمارة الموجه المجال (DOMA) يمكن الاعتماد على الطرق الراسخة للتنظيم رمز مثل الموجه المجال، تصميم ، نظيفة العمارة ، خدمة المنحى العمارة ، وأنماط الشيئية والتنمية الموجه واجهة.نرى DOMA على أنه مبتكر بمعنى أنه طريقة جديدة نسبيًا للاستفادة من مبادئ التصميم الحالية في الأنظمة الموزعة عالميًا للمؤسسات الكبيرة .
فيما يلي بعض مفاهيم DOMA الأساسية والمصطلحات ذات الصلة:
- بدلاً من النظر إلى الخدمات المصغرة الفردية ، فإننا ننظر إلى مجموعات منها. ونحن نسميها المجالات (المجالات) .
- بعد ذلك ، نقوم بدمج مجالات ما يسمى بالطبقات (الطبقات) . تحدد الطبقة التي ينتمي إليها المجال التبعيات المتاحة للخدمات المصغرة في هذا المجال. نسمي العمارة الناتجة للطبقات المتعددة (تصميم الطبقات) .
- , . (gateways).
- , , , 'hardcode' , . (, - ), (extension architecture) .
بعبارة أخرى ، تعمل البنية الهيكلية وبوابات المجال ونقاط قابلية توسيع DOMA المبنية مسبقًا على تحويل بنيات الخدمات المصغرة من شيء معقد إلى شيء مفهوم وملموس: مجموعة منظمة من المكونات المرنة والقابلة لإعادة الاستخدام والمتعددة الطبقات.
ستركز بقية هذه المقالة على تطبيق Uber لـ DOMA وفوائده. كما سيتم تقديم المشورة العملية للشركات التي ترغب في اعتماد هذا النهج.
التنفيذ في أوبر
المجالات
نطاقات أوبر عبارة عن مجموعات لواحدة أو أكثر من الخدمات المصغرة المرتبطة بناءً على مجموعة منطقية من الوظائف. السؤال الذي يطرح نفسه بشكل طبيعي ، ما هو الحجم الذي يجب أن يكون عليه المجال. في هذه الحالة ، لا نعطي أي تعليمات. يمكن أن تتضمن بعض المجالات عشرات الخدمات ، والبعض الآخر واحد فقط. من المهم هنا التفكير مليًا في الدور المنطقي لكل جمعية. على سبيل المثال ، قمنا بتجميع خدمات البحث على الخريطة وخدمات الأجرة وخدمات الاختيار (مقارنة السائقين والركاب) في مجالات منفصلة. بالإضافة إلى ذلك ، لا يكررون دائمًا الهيكل التنظيمي للشركة. تنقسم خرائط أوبر إلى ثلاثة مجالات مع 80 خدمة مصغرة مخفية خلف ثلاث بوابات مختلفة.
العمارة القائمة على الطبقة
تجيب البنية متعددة الطبقات على السؤال حول الخدمة وأيها يمكن التواصل داخل حدود MA Uber. وهذا يعني أنه يمكن اعتباره توزيعًا عالميًا لمجالات المسؤولية أو كآلية لإدارة التبعية العالمية.
تساعد البنية متعددة الطبقات على فهم نصف قطر الضرر بعد الفشل وتعكس خصوصية المنتج من حيث عدد الخدمات التابعة لأوبر. أثناء انتقالك من الأسفل إلى الأعلى ، يتم تقليل عدد الخدمات المتأثرة في حالة الفشل ويضيق نطاق تطبيق المنتج . والعكس صحيح ، يعتمد عدد أكبر من الخدمات على الوظائف في المستويات الأدنى ، وبالتالي ، فإن نصف قطر الضرر الناتج عن الفشل ، كقاعدة عامة ، أكبر ، ونطاق مهام العمل التي يتم حلها أوسع. يوضح الشكل أدناه هذا المفهوم.
يمكنك أن تتخيل أن المستويات العليا تركز على الوظائف المسؤولة عن تجربة مستخدم محددة (ضيقة) (على سبيل المثال ، وظائف الهاتف المحمول) ، في حين أن المستويات الأدنى تسكنها وظائف أعمال عالمية أكثر (على سبيل المثال ، إدارة الحساب أو السفر عبر سوق النقل) ... تعتمد كل طبقة فقط على الطبقات الأساسية ، مما يضفي الوضوح على مفاهيم مثل نصف قطر الانفجار وتكامل المجال.
تجدر الإشارة إلى أن الوظيفة غالبًا ما تتحرك إلى أسفل في هذا المخطط ، من ضيق إلى أوسع. يمكنك تخيل بعض الوظائف البسيطة التي تصبح أكثر أهمية ("النظام الأساسي") بمرور الوقت مع تطور المتطلبات. في الواقع ، يُتوقع حدوث هذا النوع من الترحيل إلى أسفل ، وقد بدأت العديد من منصات الأعمال الأساسية لشركة Uber كميزة للسائقين أو الركاب ، ومع مرور الوقت نمت وأصبحت أكثر عمومية باعتبارها خطوط أعمال جديدة (مثل Uber Eats أو Uber Freight ) وربط المزيد من التبعيات بهم.
داخل أوبر ، نميز المستويات الخمسة التالية.
- . , . — Uber , .
- -. , Uber , , Rides (), Eats ( ) Freight ( ).
- . , , . , «request a ride» ( ) , Rides: Rider, Rider «Lite», m.uber.com, ..
- . , (/), .
- . Uber . .
كما ترى ، يمثل كل مستوى لاحق مجموعة أضيق بشكل متزايد من الوظائف ولها نصف قطر وصول أصغر (بمعنى آخر ، يعتمد عدد أقل من المكونات على الوظائف داخل هذه الطبقة).
بوابات
مصطلح بوابة API راسخ بالفعل في بنيات الخدمات المصغرة. لا يختلف تعريفنا كثيرًا عن التعريف الراسخ - باستثناء أننا نميل إلى التفكير في البوابات كنقطة دخول واحدة إلى مجموعة الخدمات المقابلة (التي نسميها مجالًا ). يعتمد نجاح البوابة على بنية API جيدة التصميم:
يوضح هذا الرسم التخطيطي التصميم عالي المستوى للبوابة. يستخلص من تفاصيل الهيكل الداخلي للمجالات: مجموعة من الخدمات ، والجداول مع البيانات ، وخطوط أنابيب ETL ، إلخ. المجالات الأخرى لها حق الوصول فقط إلى الواجهات: API لاستدعاءات الإجراءات عن بُعد والأحداث والطلبات في نظام المراسلة.
نظرًا لأن مستهلكي المنبع يعملون فقط على خدمة واحدة ، فإن البوابات توفر العديد من الفوائد من حيث عمليات الترحيل المستقبلية ، وقابلية الاكتشاف ، وتقليل شامل في تعقيد النظام عندما يكون لخدمات المنبع تبعية واحدة فقط (بدلاً من الاعتماد على العديد من الخدمات النهائية التي قد تكون موجودة في المجال). عند النظر إليها من منظور تصميم OO ، فإن البوابات هي تعريفات للواجهة وتسمح لنا بالقيام بكل ما نريد من خلال "تنفيذ" داخلي (أي مجموعة من الخدمات المصغرة).
ملحقات
الامتدادات (الامتدادات) ، كما يوحي الاسم ، هي آلية لتوسيع المجالات. التعريف الأساسي لهذه الوظيفة الإضافية هو أنها توفر آلية لتوسيع وظائف الخدمة دون تغيير الأجزاء الداخلية لتلك الخدمة أو التأثير على موثوقيتها الإجمالية. يوجد في Uber نموذجان للتوسع: المنطق (الامتدادات المنطقية) وعلى أساس البيانات (بيانات الامتدادات) . سمح لنا مفهوم الامتداد بتوسيع نطاق البنية بحيث يمكن للفرق المتعددة العمل بشكل مستقل عن بعضها البعض.
الامتدادات المنطقية
توفر الامتدادات المنطقية آلية لتوسيع المنطق الأساسي للخدمة. بالنسبة لهم ، نستخدم نوعًا من الموفر أو نمط البرنامج المساعد بواجهة يتم تحديدها بشكل منفصل لكل خدمة. يتيح ذلك للفرق تنفيذ منطقهم باستخدام الواجهة فقط ودون التدخل في رمز النظام الأساسي الرئيسي.
افترض ، على سبيل المثال ، أن السائق متصل بالإنترنت. عادةً ما نقوم بإجراء فحوصات مختلفة للتأكد من أنه يُسمح بالحصول على حالة عبر الإنترنت (للأمان والامتثال وما إلى ذلك). كل واحد منهم لديه فريقه الخاص. تتمثل إحدى الطرق الممكنة للقيام بذلك في إجبار كل أمر على كتابة منطق في نفس نقطة النهاية ، ولكن هذا يمكن أن يضيف تعقيدًا. سيتطلب كل فحص منطقًا مختلفًا - وغير ذي صلة تمامًا -.
في حالة امتدادات نقطة النهاية المنطقية تسمى go onlineستحدد الواجهة التي يُتوقع أن يتوافق معها كل امتداد مع طلب محدد مسبقًا ونوع استجابة. سيقوم كل فريق بتسجيل امتداد يكون مسؤولاً عن تنفيذ هذا المنطق. في هذه الحالة ، يمكنهم ببساطة أخذ بعض المعلومات حول برنامج التشغيل وإرجاع قيمة منطقية ( منطقية ) ، والتي ستحدد ما إذا كان السائق "يستحق" حالة الاتصال أم لا. وستعمل نقطة النهاية نفسها (الاتصال بالإنترنت ) ببساطة على تكرار هذه الإجابات وتحديد ما إذا كان أي منها خاطئًا .
يفصل هذا الأسلوب الكود الأساسي عن الامتدادات ويوفر عزلًا بينهما. في هذه الحالة ، لا تعرف الامتدادات المنطق الآخر الذي يتم تنفيذه. هذا يجعل من السهل إنشاء وظائف إضافية ، على سبيل المثال للملاحظة أو ميزة الإبلاغ .
ملحقات تعتمد على البيانات
يوفر هذا النوع من الامتدادات آلية لإرفاق بيانات عشوائية بالواجهة لتجنب تضخم نماذج بيانات النظام الأساسي بشكل غير ضروري. في امتدادات البيانات ، نستخدم بنشاط ميزات مثل Any from Protobuf ، والتي تسمح بإضافة بيانات عشوائية إلى الطلبات. غالبًا ما تخزن الخدمات هذه البيانات أو تمررها إلى امتداد منطقي ، بحيث لا تقوم المنصة الرئيسية مطلقًا بإلغاء التسلسل (وبالتالي لا تعرف أي شيء) عن هذا السياق التعسفي. يتطلب أي تنفيذ بعض النفقات العامة للبنية التحتية في مقابل كتابة أقوى. البديل الأبسط هو تنسيق JSON لتمثيل أي بيانات:
مكملات تعسفية
بالإضافة إلى الامتدادات المنطقية والبيانات ، طورت العديد من الفرق في Uber قوالب امتدادات مخصصة لمطابقة نطاقاتهم. على سبيل المثال ، تستخدم معظم عمليات الدمج المتعلقة بهندسة العرض التقديمي منطق تنفيذ المهام المستند إلى DAG.
فوائد
لقد أثرت DOMA على كل أعمال أوبر الرئيسية تقريبًا بدرجة أو بأخرى. خلال العام الماضي ، ركزنا بشكل أساسي على طبقة الأعمال. يوفر منطقًا معممًا لمختلف خطوط الأعمال في الشركة.
يعد DOMA جديدًا نسبيًا على Uber ، وفي المستقبل سنشارك بالتأكيد المزيد من المعلومات والأمثلة عن هندستنا. كانت النتائج الأولى مشجعة: لقد بسّطوا عمل المطورين بشكل كبير وقللوا التعقيد الكلي للنظام.
المنتجات والمنصات
DOMA هو جهد تعاوني بين مختلف فرق المنتجات والنظام الأساسي في Uber. في كثير من الحالات ، انخفضت تكاليف دعم النظام الأساسي بمقدار كبير. استفادت فرق المنتج من الخصوصية والتطوير المتسارع.
على سبيل المثال ، تمكن مستهلك النظام الأساسي المبكر لهندسة الإضافات الخاصة بنا من تقليل الوقت اللازم لتحديد الأولويات ودمج ميزة جديدة من ثلاثة أيام إلى ثلاث ساعات عن طريق تقليل أوقات مراجعة الكود والجدولة وتسريع تعليم المستهلك.
تقليل التعقيد
في السابق ، كان على فرق المنتج العمل مع العديد من خدمات المصب داخل مجال ، لكنهم الآن بحاجة فقط إلى الاتصال بواحد. من خلال تقليل عدد نقاط الاتصال عند تقديم ميزة جديدة ، تم تقليل وقت التنفيذ بنسبة 25-30٪. بالإضافة إلى ذلك ، تمكنا من توزيع 2200 خدمة عبر 70 مجالًا. تم تنفيذ حوالي نصفها ، وبالنسبة للغالبية هناك خطة للتنفيذ بشكل أو بآخر.
هجرات المستقبل
في أوبر ، حسبنا أن نصف عمر الخدمة المصغرة 1.5 سنة. بعبارة أخرى ، كل عام ونصف ، تفقد 50٪ من خدماتنا أهميتها. بدون بوابات ، يمكن أن تصبح بنية الخدمات المصغرة بمثابة جحيم ترحيل. تتطلب الخدمات الصغيرة المتغيرة باستمرار عمليات ترحيل مستمرة إلى المنبع. تسمح البوابات للفرق بتجنب التبعيات على خدمات المجال النهائية ، مما يعني أن هذه الخدمات يمكن أن تتغير دون الحاجة إلى الانتقال إلى المنبع.
حدثت اثنتان من أكبر ترقيات الأنظمة الأساسية لـ Uber في العام الماضي خلف البوابات. تحتوي هذه المنصات على مئات الخدمات التابعة ، وبدون بوابات ، يجب ترحيل جميع المستهلكين الحاليين. سيكون مكلفًا بشكل لا يصدق ، مما يجعل إعادة التصميم الكاملة للمنصة أمرًا غير واقعي.
خطوط أعمال ومنتجات جديدة
أثبتت الأطر المستندة إلى DOMA أنها أكثر قابلية للتوسعة وأسهل في الصيانة. قامت معظم الفرق في Uber التي تحولت إلى DOMA بذلك لأنه أصبح مكلفًا للغاية للحفاظ على خطوط أعمال جديدة.
نصائح عملية
في هذا القسم ، قمت بتجميع بعض النصائح العملية للشركات التي قد تكون مهتمة بـ DOMA. المبدأ التوجيهي هنا هو أنه ، من خلال تجربتنا ، فإن بنية الخدمات الدقيقة الناضجة والمدروسة تستند إلى تحولات تدريجية في الاتجاه الصحيح في الوقت المناسب. في الواقع ، يكاد يكون من المستحيل "إعادة كتابة" MA بالكامل.
لذلك ، فإننا ننظر إلى تطور المتوسط المتحرك كنوع من عملية "قطع التحوط" ، والذي بفضله ينمو في الاتجاه الصحيح ، وليس كجهد إرادي لمرة واحدة. إنها عملية ديناميكية وتدريجية.
الشركات الناشئة
الأسئلة الرئيسية هنا هي: "متى يجب أن ننتقل إلى MA؟" و "هل هذا منطقي لمنظمتنا؟" كما رأينا أعلاه ، بينما توفر الخدمات المصغرة ميزة تشغيلية في المؤسسات التي بها عدد كبير من المهندسين ، فإنها تضيف أيضًا إلى التعقيد الكلي الذي يمكن أن يجعل من الصعب تنفيذ ميزات جديدة.
في المؤسسات الصغيرة ، من غير المرجح أن تعوض الميزة التشغيلية عن التعقيد المعماري المتزايد. علاوة على ذلك ، عادةً ما تتطلب MAs موارد هندسية مخصصة لدعمها ، والتي قد تكون باهظة الثمن لشركة في مرحلة مبكرة أو ببساطة دون المستوى الأمثل من حيث تحديد الأولويات.
مع ذلك ، قد يكون من الحكمة تأجيل الانتقال إلى الخدمات المصغرة لبعض الوقت. إذا قررت المؤسسة التبديل إلى الخدمات المصغرة ، فإننا نوصي باستخدام تشبيه تطبيق موزع كبير والتفكير مسبقًا في تقسيم مناطق المشكلات بين الخدمات. ضع في اعتبارك أيضًا أن الخدمات المصغرة الأولى من المحتمل أن تكون الأكثر أهمية وأطول عمراً ، لأنها تصف جزءًا رئيسيًا من العمل.
الأعمال المتوسطة
تزداد فائدة MA في الشركات متوسطة الحجم مع العديد من الفرق ، حيث تتلاشى خطوط المسؤولية تدريجياً بين الوظائف والمنصات المختلفة.
هذا هو المكان الذي يمكنك فيه البدء في التفكير في التسلسل الهرمي للخدمات المصغرة. قد تظهر إدارة التبعية في المقدمة حيث يمكن أن تصبح بعض الخدمات أكثر أهمية لإدارة الأعمال وستعتمد عليها المزيد من الفرق.
يمكن أن تؤتي الاستثمارات المبكرة في مجال المنصات أرباحًا في وقت لاحق. يتيح إنشاء منصات أعمال لا تعتمد على منتجات أخرى تجنب تراكم الديون التقنية وتغلغل منطق المنتج التعسفي في الخدمات الرئيسية للمنصة. ربما يجب إدخال آلية تمديد في هذه المرحلة لتحقيق هذا الهدف.
نظرًا لأن عدد الخدمات المصغرة لا يزال صغيرًا ، فقد لا يكون من المنطقي تجميعها معًا حتى الآن. ومع ذلك ، تجدر الإشارة هنا إلى أن المجال في سياق تنفيذ DOMA في Uber قد يشتمل على خدمة واحدة ، لذلك لا يزال تدريب الفكر "الموجه نحو المجال" غير مؤلم.
عمل كبير
يمكن أن يكون لدى المؤسسات الهندسية الكبيرة المئات من المتخصصين والخدمات المصغرة والعديد من التبعيات. في ظل هذه الظروف ، تصل DOMA إلى إمكاناتها الكاملة. بالتأكيد سيكون لدى هذه الشركات مجموعات واضحة من الخدمات المصغرة التي يمكن دمجها بسهولة في مجالات مع بوابات أمامها. غالبًا ما تحتاج الخدمات القديمة إلى إعادة بناء / إعادة كتابة وترحيل لاحق. هذا يعني أن البوابات ستبدأ قريبًا في تحقيق فوائد حقيقية من حيث سهولة الترحيل (إذا تم نشرها بالفعل).
ستزداد أيضًا أهمية التسلسل الهرمي الشفاف والمفهوم: ستكون بعض الخدمات "منتجًا" لوظائف أو مجموعات وظائف معينة ، بينما يدعم البعض الآخر منتجات متعددة ويعمل "كمنصات". في هذه المرحلة ، من الضروري فصل منطق المنتج التعسفي عن الأنظمة الأساسية لتجنب الضغط التشغيلي الهائل على فرق النظام الأساسي ، وكذلك لتقليل مخاطر عدم استقرار النظام العالمي.
افكار اخيرة
في أوبر ، نواصل تطوير DOMA بنشاط مع انتقال المزيد من الفرق إليه. الفكرة الرئيسية وراء DOMA هي أن بنية الخدمات المصغرة هي مجرد برنامج كبير موزع. ويمكن تطبيق نفس المبادئ على تطوره مثل أي برنامج آخر. DOMA هو مجرد نهج للتفكير العملي حول هذه المبادئ. نأمل أن تجدها مفيدة ونتطلع إلى تعليقاتك!
DOMA نفسه هو نتيجة جهد متعدد الوظائف قام به ما يقرب من 60 مهندسًا من جميع أنحاء أوبر. أود أن أعرب عن امتناني الخاص للأشخاص التالية أسماؤهم على مساهماتهم في هذا العمل على مدار العامين الماضيين:
أليكس زيلمان ، ألكسندر ويلهيلم ، ألين لو ، أنكيت سريفاستافا ، أنتوني تران ، أنوبام ديكشيت ، أنوراغ بياني ، دانيال وولف ، ديبتي شيدا ، دميتري بريندن ، غوراف تونغاتكار ، جاكوب جرينليف ، جايكومار غانيش ، جيني نجيابواي ، جوشيير ، كوشا كابور ، ليندا فو ، مادان ثانجافيلو ، نيميش شيث ، بارث شاه ، شون بورك ، سيمون نيوتن ، ستيف شيروود ، عدي كيران ميديسيتي ووليد قادوس.
شكر وتقدير: لقد جمع هذا العمل العديد من أنماط التصميم الحالية في الصناعة لحل المشكلات في Uber ، كما اقترح بعض الأنماط الجديدة (مثل الامتدادات). نحن ممتنون للصناعة للعمل عليها. نحن ممتنون أيضًا لمهندسي Linkedin الذين عملوا في Superblocks لمشاركة تجاربهم معنا.
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «: , Kubernetes»;
- « 2018 ».