متى يتم الترحيل من وحدة متراصة إلى الخدمات الصغيرة (ومتى لا يتم ذلك)

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

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

ما هو متراصة، ولماذا يعمل

المونوليث هي وحدة واحدة قابلة للنشر. قاعدة بيانات واحدة، وقاعدة بيانات واحدة، وخط أنابيب بناء واحد، ونشر واحد. وحدة المصادقة الخاصة بك، ونظام الفوترة الخاص بك، وخدمة الإشعارات، وطبقة واجهة برمجة التطبيقات (API) الخاصة بك؛ إنهم جميعًا يعيشون في نفس المستودع ويتم نشرهم معًا.

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

بدأت كل شركة تقنية ناجحة كوحدة متراصة. يدير Shopify تطبيق Rails متجانس يخدم معاملات بمليارات الدولارات. يخدم Stack Overflow 100 مليون زائر شهريًا من منصة واحدة. هذه ليست شركات لا تستطيع اكتشاف الخدمات الصغيرة. لقد فهمت الشركات أن الحجر المتراص هو الأداة المناسبة لمشكلتهم.

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

ما هي الخدمات المصغرة وما هي تكلفتك؟

تعمل بنية الخدمات الصغيرة على تقسيم تطبيقك إلى خدمات مستقلة. تمتلك كل خدمة قاعدة بيانات خاصة بها، وتنشر بشكل مستقل، وتتواصل مع الخدمات الأخرى من خلال واجهات برمجة التطبيقات (عادةً REST أو gRPC) أو قوائم انتظار الرسائل.

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

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

• فشل الشبكة بين الخدمات.في الوحدة المتراصة، إما أن يعمل استدعاء الدالة أو يطرح استثناءً. في الخدمات الصغيرة، يمكن أن تنتهي مهلة الطلب، أو يُرجع استجابة جزئية، أو يفشل بصمت. أنت بحاجة إلى منطق إعادة المحاولة، وقواطع الدائرة، والاستراتيجيات الاحتياطية لكل مكالمة بين الخدمات.
• المعاملات الموزعةعندما تشمل عملية واحدة خدمتين (شحن العميل، ثم تحديث المخزون)، فإنك تحتاج إلى قصص ملحمية أو أنماط اتساق نهائية. هذه معقدة في البناء ومؤلمة لتصحيح الأخطاء.
• إمكانية الملاحظة في الأعلى.طلب واحد قد يمس 6 خدمات. بدون التتبع الموزع (Jaeger أو Zipkin أو Datadog APM)، فإن تصحيح أخطاء الطلب الفاشل يعني البحث من خلال 6 تدفقات سجل منفصلة على أمل ربط الطوابع الزمنية.
• تعقيد النشر.أنت بحاجة إلى تنسيق الحاوية (Kubernetes أو ECS)، واكتشاف الخدمة، وبوابات API، وخطوط أنابيب CI/CD لكل خدمة. خط أنابيب واحد يصبح 15.
• تحديات اتساق البيانات.تمتلك كل خدمة قاعدة البيانات الخاصة بها. ربط البيانات عبر الخدمات يعني استدعاءات API، وليس انضمام SQL. يصبح إعداد التقارير مشروعًا هندسيًا، وليس استعلامًا.

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

المتراصة على ما يرام حتى لا تكون كذلك

أربع إشارات محددة تخبرك بأن حجرك المتراص قد تجاوز نفسه:

1. نشر تعارضات التردد

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

2. الفرق تدوس على بعضها البعض

دمج الصراعات في الوحدات المشتركة. يقوم فريقان بتغيير مخطط قاعدة البيانات نفسه في نفس السباق. Code reviews that require context from three different feature areas. هذه علامات على أن قاعدة التعليمات البرمجية الخاصة بك قد نمت إلى ما هو أبعد مما يمكن أن يمتلكه فريق واحد. عندما يقضي المهندسون وقتًا أطول في التنسيق بدلاً من البرمجة، فإن الوحدة المتراصة تعمل على إبطائك.

3. خلل في إحدى الوحدات يؤدي إلى تدمير كل شيء

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

4. إن توسيع نطاق ميزة واحدة يعني توسيع نطاق التطبيق بأكمله

تحتاج وحدة تحويل ترميز الفيديو إلى 8 أضعاف وحدة المعالجة المركزية لطبقة API الخاصة بك. ولكنها يتم نشرها كوحدة واحدة، لذا فأنت تقوم بتشغيل وحدة معالجة مركزية 8x لتطبيقك بالكامل لتلبية احتياجات مكون واحد. فاتورة البنية التحتية الخاصة بك أعلى بمقدار 5 إلى 10 مرات مما يجب أن تكون عليه لأنه لا يمكنك توسيع نطاق المكونات بشكل مستقل.

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

علامات تدل على عدم استعدادك للخدمات الصغيرة

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

• لديك أقل من 5 مهندسين.تعمل الخدمات المصغرة على حل مشاكل تنسيق الفريق. فريق مكون من 3 أفراد ليس لديه مشاكل في التنسيق؛ يحتوي على قناة Slack وسبورة بيضاء. سوف تستهلك النفقات العامة لتشغيل البنية التحتية الموزعة ما بين 30 إلى 40% من قدرة فريقك الصغير.
• أنت تخدم أقل من 10000 مستخدم.في حالة حركة المرور المنخفضة، يتعامل خادم واحد مع كل شيء بشكل مريح. تضيف الخدمات الصغيرة زمن الوصول (تنقلات الشبكة بين الخدمات) والتعقيد دون توفير فوائد توسيع ذات معنى بهذا الحجم.
• ليس لديك خبرة في DevOps في الفريق.تتطلب الخدمات الصغيرة تنسيق الحاوية وتكوين شبكة الخدمة والتسجيل الموزع وخطوط أنابيب النشر الآلية. بدون وجود شخص قام بتشغيل هذه الأنظمة في الإنتاج، ستقضي أشهرًا في بناء البنية التحتية بدلاً من الميزات.
• ليس لديك أي مراقبة أو إمكانية الملاحظة في المكان.إذا لم تتمكن من تتبع الطلب من خلال متراصتك اليوم، فمن المؤكد أنك لن تتمكن من تتبعه عبر 10 خدمات غدًا. قم بإعداد التسجيل المنظم وتتبع الأخطاء (Sentry) ومراقبة أداء التطبيق (Datadog وNew Relic) قبل تقسيم أي شيء.
• لم تقم بتحديد حدود واضحة للوحدة النمطية في متراصتك.إذا كان الكود الخاص بك عبارة عن شبكة متشابكة حيث تقرأ وحدة الفوترة مباشرة من جدول جلسة المستخدم ويقوم نظام الإشعارات بالكتابة إلى قاعدة بيانات الطلب، فسيكون استخراج الخدمة بمثابة كابوس. تنظيف الحدود أولا.

مسار الهجرة: نمط التين الخانق

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

يتجنب نمط التين الخانق هذا تمامًا. سُميت على اسم شجرة التين الخانقة التي تنمو حول شجرة مضيفة وتحل محلها تدريجيًا، ويعمل هذا النهج في ثلاث خطوات:

• الخطوة 1:تحديد مكون واحد لاستخراجه. قم بتوجيه حركة المرور الخاصة به من خلال بوابة API أو الوكيل.
• الخطوة 2:قم ببناء الخدمة الجديدة جنبًا إلى جنب مع المنصة المتراصة. كلاهما يعمل في الإنتاج في وقت واحد. يقوم الوكيل بتوجيه حركة المرور إلى الخدمة الجديدة للمكون المستخرج وإلى الوحدة المتراصة لكل شيء آخر.
• الخطوة 3:بمجرد أن تتعامل الخدمة الجديدة مع 100% من حركة المرور الخاصة بها بشكل موثوق، قم بإزالة الكود القديم من الوحدة المتراصة. كرر مع المكون التالي.

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

ما يجب استخراجه أولا

لديك خياران جيدان لاستخراجك الأول:

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

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

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

الأخطاء الشائعة التي تقتل عمليات ترحيل الخدمات الصغيرة

استخراج عدد كبير جدًا من الخدمات بسرعة كبيرة جدًا

تشعر الفرق بالحماس بعد أول استخراج ناجح لها وتحاول تقسيم كل شيء مرة واحدة. وفجأة، قاموا بتشغيل 12 خدمة مع 12 مسار نشر، و12 مجموعة من السجلات، و12 نقطة فشل محتملة. العبء التشغيلي يثقل كاهل الفريق. استخرج خدمة واحدة، وقم بتشغيلها في مرحلة الإنتاج لمدة 4-6 أسابيع، وتعلم من التحديات التشغيلية، ثم استخرج الخدمة التالية.

متراصة الموزعة

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

لا توجد شبكة خدمة أو إمكانية الملاحظة

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

مقارنة التكلفة: متراصة مقابل الخدمات الصغيرة

يعد الفرق في تكلفة البنية التحتية بين هذه البنى كبيرًا، وتقلل الفرق من قيمته باستمرار.

تعكس هذه النطاقات الشركات الناشئة في منتصف المرحلة والشركات في مرحلة النمو. يمكن أن يتم تشغيل عمليات النشر على مستوى المؤسسة بشكل أعلى على كلا الطرفين.

تكلفة البنية التحتية هي الجزء المرئي. التكلفة الخفية هي الوقت الهندسي. ينفق الفريق الذي يقوم بتشغيل الخدمات الصغيرة ما بين 20 إلى 30% من طاقته على المهام التشغيلية: تحديث تكوينات Kubernetes، وتصحيح أخطاء الاتصالات بين الخدمات، وإدارة عمليات ترحيل قاعدة البيانات عبر خدمات متعددة، وصيانة خطوط أنابيب CI/CD. هذا هو الوقت الهندسي الذي لا يتجه نحو الميزات التي يهتم بها المستخدمون.

الأرضية الوسطى "المتراصة المعيارية".

هناك خيار ثالث تتخطاه معظم مقالات الهندسة المعمارية: المتراصة المعيارية. يمكنك الاحتفاظ بوحدة واحدة قابلة للنشر ولكنك تفرض حدودًا صارمة للوحدة داخلها.

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

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

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

بالنسبة للفرق المكونة من 5 إلى 30 مهندسًا، غالبًا ما تكون الوحدات المتراصة هي الإجابة الصحيحة. يمكنك الحصول على هيكل وانضباط التفكير في الخدمات الصغيرة دون دفع ضريبة البنية التحتية والتشغيل.

ما يوصي سافي

لقد قمنا ببناء وحدات متراصة ووحدات متراصة معيارية وهياكل خدمات صغيرة للعملاء عبر التكنولوجيا المالية والتجارة الإلكترونية وSaaS. إليك كتاب اللعب الذي نتبعه:

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

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

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

الأسئلة المتداولة