بناء المستقبل: هندسة الخدمات المصغرة

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

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

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

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

الفكرة هنا هي أن يكون لديك نظام يتكون من عدة خدمات قائمة بذاتها وقابلة للتطوير والاستبدال.

لبنة لبنة: تحريك النظام تدريجيًا

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

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

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

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

• • خدمة التواصل عبر البريد الإلكتروني للعملاء
  • الخروج كخدمة
  • خدمة توفر العنصر
  • محرك البحث التجاري
  • خدمات التخصيص المتنوعة أو الاستشارية أو التوصيات
  • مراجعات المنتج / خدمة التقييم

توسيع نطاق مشروعك بالطريقة الصحيحة: تحديد عمليات وخطط هندسة الخدمات المصغرة

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

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

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

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

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

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

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

خارطة طريق الهندسة هي الأداة التي تساعد على تحديد اتجاه تطور النظام لمدة عامين إلى ثلاثة أعوام في المستقبل.

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