لماذا نهج الخدمات المصغرة لبناء التطبيقات
بالنسبة لمطوري البرامج، فإن تحليل التطبيق إلى أجزاء مكونة ليس بالأمر الجديد. عادة، يتم استخدام نهج بمستويات متعددة، مع مخزن خلفي، ومنطق أعمال من المستوى المتوسط، وواجهة مستخدم أمامية (UI). ما تغير على مدى السنوات القليلة الماضية هو أن المطورين يقومون ببناء تطبيقات موزعة للسحابة.
فيما يلي بعض احتياجات العمل المتغيرة:
- خدمة جرى إنشاؤها وتشغيلها على نطاقٍ واسعٍ للوصول إلى العملاء في مناطق جغرافية جديدة.
- تسليم أسرع للميزات والإمكانيات للاستجابة لمتطلبات العملاء بطريقة مرنة.
- تحسين استخدام الموارد لخفض التكاليف.
تؤثر احتياجات العمل هذه على كيفية بناء التطبيقات.
لمزيد من المعلومات حول نهج Azure للخدمات المصغرة، راجع الخدمات المصغرة: ثورة تطبيقات مدعومة من السحابة.
نهج تصميم متجانس مقابل الخدمات المصغرة
تتطور التطبيقات بمرور الوقت. تتطور التطبيقات الناجحة من خلال كونها مفيدة للناس. لا تتطور التطبيقات غير الناجحة ويتم إهمالها في النهاية. إليك السؤال: ما مدى معرفتك بمتطلباتك اليوم وماذا ستكون في المستقبل؟ على سبيل المثال، لنفترض أنك تنشئ تطبيقًا لإعداد التقارير لقسم في شركتك. أنت متأكد من أن التطبيق يطبق فقط ضمن نطاق شركتك وأن التقارير لن يتم الاحتفاظ بها لفترة طويلة. سيكون نهجك مختلفًا عن نهج، على سبيل المثال، بناء خدمة تقدم محتوى فيديو لعشرات الملايين من العملاء.
في بعض الأحيان، يكون إطلاق شئ ما كإثبات للمبدأ هو العامل الدافع. أنت تعلم أنه يمكن إعادة تصميم التطبيق لاحقًا. لا جدوى من المبالغة في تصميم شيء لا يتم استخدامه أبدًا. من ناحية أخرى، عندما تقوم الشركات ببناء تطبيقات السحابة، فإن التوقع هو النمو والاستخدام. ولا يمكن التنبؤ بالنمو والحجم. نريد عمل نموذج أولي سريعًا مع العلم أيضًا أننا نسير على طريق يمكنه التعامل مع النجاح في المستقبل. هذا هو نهج بدء التشغيل البسيط: البناء والقياس والتعلم والتكرار.
خلال عصر العميل/الخادم، كنا نميل إلى التركيز على بناء تطبيقات بمستويات متعددة باستخدام تقنيات محددة في كل مستوى. وقد ظهر مصطلح التطبيق المتجانس لوصف هذه النهج. تميل الواجهات إلى أن تكون بين المستويات، وتم استخدام تصميم مقترن بشكل أكثر إحكامًا بين المكونات داخل كل مستوى. قام المطورون بتصميم وتحليل الفئات التي تم تجميعها في مكتبات وربطها معًا في عدد قليل من الملفات القابلة للتنفيذ وDLLs.
هناك مزايا لنهج التصميم المتجانس. غالبًا ما تكون التطبيقات المتجانسة أبسط في التصميم، ويكون الاستدعاءات بين المكونات أسرع لأن هذه الاستدعاءات غالبًا ما تكون عبر الاتصال بين العمليات (IPC). أيضًا، يختبر الجميع منتجًا واحدًا، والذي يميل إلى أن يكون استخدامٍا أكثر كفاءة للموارد البشرية. الجانب السلبي هو أن هناك اقترانًا وثيقًا بين المستويات المتعددة، ولا يمكنك تغيير حجم المكونات الفردية. إذا كنت بحاجة إلى إجراء إصلاحات أو ترقيات، فيجب عليك الانتظار حتى ينهي الآخرون اختباراتهم. من الصعب أن تكون خفيف الحركة.
تعالج الخدمات المصغرة هذه الجوانب السلبية وتتماشى بشكل أوثق مع متطلبات العمل السابقة. ولكن لديهم أيضًا مزايا والتزامات. تتمثل مزايا الخدمات المصغرة في أن كل واحدة منها تغلّف عادةً وظائف أبسط لوظائف الأعمال، والتي يمكنك توسيع حجم أو تقليصه واختبارها وتوزيعها وإدارتها بصورة مستقلة. تتمثل إحدى الميزات المهمة لنهج الخدمات المصغرة في أن الفرق مدفوعة بسيناريوهات الأعمال أكثر من التكنولوجيا. تطور الفرق الأصغر خدمة مصغرة استنادًا إلى سيناريو العميل واستخدام أي تقنيات يريدون استخدامها.
وبعبارة أخرى، لا تحتاج المؤسسة إلى توحيد التكنولوجيا للحفاظ على تطبيقات الخدمات المصغرة. يمكن للفرق الفردية التي تمتلك خدمات أن تفعل ما هو منطقي بالنسبة لهم بناء على خبرة الفريق أو الحل الأنسب للمشكلة. في الممارسة العملية، يفضل وجود مجموعة من التقنيات الموصى بها، مثل مخزن NoSQL معين أو إطار عمل لتطبيق ويب.
الجانب السلبي للخدمات المصغرة هو أنه يتعين عليك إدارة كيانات أكثر انفصالاً والتعامل مع عمليات التوزيع والإصدار الأكثر تعقيدًا. وتزداد نسبة استخدام الشبكة بين الخدمات المصغرة، وكذلك زمن انتقال الشبكة المقابل. الكثير من الخدمات الدقيقة القائمة على الدردشة يمكن أن تسبب كابوسًا في الأداء. بدون أدوات لمساعدتك في عرض هذه التبعيات، من الصعب رؤية النظام بأكمله.
تجعل المعايير نهج الخدمات المصغرة يعمل من خلال تحديد كيفية التواصل والتسامح فقط مع الأشياء التي تحتاجها من الخدمة، بدلاً من العقود الصارمة. من المهم تحديد هذه العقود مقدمًا في التصميم نظرًا لتحديث الخدمات بشكل مستقل عن بعضها البعض. هناك وصف آخر تم صياغته للتصميم باستخدام نهج الخدمات المصغرة وهو "التصميم الدقيق الموجه نحو الخدمة (SOA)".
في أبسط صوره، يتعلق نهج تصميم الخدمات المصغرة باتحاد منفصل للخدمات، مع تغييرات مستقلة لكل منها ومعايير متفق عليها للاتصال.
مع إنتاج المزيد من التطبيقات السحابية، اكتشف الناس أن هذا التحلل للتطبيق الكلي إلى خدمات مستقلة تركز على السيناريو هو نهج أفضل على المدى الطويل.
مقارنة بين نُهج تطوير التطبيقات
يحتوي التطبيق المتجانس على وظائف خاصة بالمجال وينقسم عادة إلى طبقات وظيفية مثل الويب والأعمال والبيانات.
يمكنك تغيير حجم تطبيق متجانس عن طريق استنساخه على خوادم متعددة/أجهزة ظاهرية/حاويات.
يفصل تطبيق الخدمة المصغرة الوظائف إلى خدمات أصغر منفصلة.
يتم تغيير حجم نهج الخدمات المصغرة من خلال توزيع كل خدمة بشكل مستقل، وإنشاء مثيلات لهذه الخدمات عبر الخوادم/الأجهزة الظاهرية/الحاويات.
التصميم باستخدام نهج الخدمات المصغرة ليس مناسبًا لجميع المشاريع، ولكنه يتماشى بشكل أوثق مع أهداف العمل الموضحة سابقًا. قد يكون البدء بنهج متجانس منطقيًا إذا كنت تعرف أنه ستتاح لك الفرصة لإعادة صياغة التعليمات البرمجية لاحقًا في تصميم الخدمات المصغرة. بشكل أكثر شيوعًا، تبدأ بتطبيق متجانس وتقسمه ببطء على مراحل، بدءًا من المجالات الوظيفية التي تحتاج إلى أن تكون أكثر قابلية التحجيم أو المرونة.
عند استخدام نهج الخدمات المصغرة، فإنك تقوم بإنشاء تطبيقك للعديد من الخدمات الصغيرة. يتم تشغيل هذه الخدمات في حاويات يتم توزيعها عبر مجموعة من الأجهزة. تقوم الفرق الأصغر بتطوير خدمة تركز على سيناريو واختبار كل خدمة وإصدارها وتوزيعها وتغيير حجمها بشكل مستقل حتى يتمكن التطبيق بأكمله من التطور.
ما هي الخدمة الصغيرة؟
هناك تعريفات مختلفة للخدمات المصغرة. لكن معظم هذه الخصائص للخدمات المصغرة مقبولة على نطاق واسع:
- تغليف عميل أو سيناريو عمل. ما هي المشكلة التي تحلها؟
- التطوير من قبل فريق هندسي صغير.
- الكتابة بأي لغة برمجة، باستخدام أي إطار عمل.
- التكون من التعليمات البرمجية، والحالة اختياريًا، وكلاهما تم إصدارهما وتوزيعهما وتغيير حجمهما بشكل مستقل.
- التفاعل مع الخدمات المصغرة الأخرى عبر واجهات وبروتوكولات محددة جيدًا.
- الحصول على أسماء فريدة (عناوين URL) تستخدم لحل الموقع.
- الاتساق والتوفر في وجود حالات فشل.
لتلخيص ذلك:
تتكون تطبيقات الخدمات المصغرة من خدمات صغيرة ذات إصدار مستقل وقابلة للتطوير تركز على العملاء والتي تتواصل مع بعضها البعض عبر البروتوكولات القياسية مع واجهات محددة جيدا.
الكتابة بأي لغة برمجة، باستخدام أي إطار عمل
بصفتنا مطورين، نريد الحصول على حرية اختيار لغة أو إطار عمل، اعتمادًا على مهاراتنا واحتياجات الخدمة التي نقوم بإنشائها. بالنسبة لبعض الخدمات، قد تقدر مزايا أداء C++ فوق أي شيء آخر. بالنسبة للآخرين، قد تكون سهولة التطوير المُدار التي تحصل عليها من C# أو Java أكثر أهمية. في بعض الحالات، قد تحتاج إلى استخدام مكتبة شركاء معينة أو تقنية تخزين بيانات أو أسلوب لعرض الخدمة للعملاء.
بعد اختيار تقنية، تحتاج إلى التفكير في إدارة التشغيل أو دورة الحياة وتغيير حجم الخدمة.
يسمح بإصدار التعليمات البرمجية والحالة بشكل مستقل وتوزيعها وتغيير حجمها
بغض النظر عن كيفية كتابة الخدمات المصغرة الخاصة بك، يجب أن يتم التوزيع والترقية وتغيير الحجم بشكل مستقل عن طريق التعليمات البرمجية والحالة بشكل اختياري. من الصعب حل هذه المشكلة لأنها تتعلق باختيارك للتقنيات. بالنسبة لتغيير الحجم، فإن فهم كيفية تقسيم (أو قطع) كل من التعليمات البرمجية والحالة يمثل تحديًا. عندما تستخدم التعليمة البرمجية والحالة تقنيات مختلفة، وهو أمر شائع اليوم، يجب أن تكون البرامج النصية للتوزيع الخاصة بالخدمة المصغرة قادرة على تغيير حجمها معًا. يتعلق هذا الفصل أيضًا بخفة الحركة والمرونة، بحيث يمكنك ترقية بعض الخدمات المصغرة دون الحاجة إلى ترقيتها جميعًا في وقت واحد.
دعونا نعود إلى مقارنتنا بين نهج الخدمات المتجانسة والمصغرة للحظة. يوضح هذا الرسم التخطيطي الاختلافات في طرق تخزين الحالة:
تخزين الحالة للنهجين
النهج المتجانس، على اليسار، لديه قاعدة بيانات واحدة ومستويات من التقنيات المحددة.
يحتوي نهج الخدمات المصغرة، على اليمين، على رسم بياني للخدمات المصغرة المترابطة حيث يتم عادة تحجيم الحالة إلى الخدمة المصغرة ويتم استخدام تقنيات مختلفة.
في نهج متجانس، يستخدم التطبيق عادة قاعدة بيانات واحدة. ميزة استخدام قاعدة بيانات واحدة هي أنها في موقع واحد، مما يجعل من السهل توزيعها. يمكن أن يحتوي كل مكون على جدول واحد لتخزين حالته. تحتاج الفرق إلى فصل الحالة بشكل صارم، وهو تحد. حتمًا، سيميل شخص ما إلى إضافة عمود إلى جدول عميل موجود، والربط بين الجداول، وإنشاء تبعيات في طبقة التخزين. بعد حدوث ذلك، لا يمكنك تغيير حجم المكونات الفردية.
في نهج الخدمات المصغرة، تدير كل خدمة وتخزن حالتها الخاصة. كل خدمة مسؤولة عن تغيير حجم كل من التعليمات البرمجية والحالة معًا لتلبية متطلبات الخدمة. الجانب السلبي هو أنه عندما تحتاج إلى إنشاء طرق عرض أو استعلامات لبيانات تطبيقك، فأنت بحاجة إلى الاستعلام عبر مخازن متعددة في الحالة. عادة ما يتم حل هذه المشكلة بواسطة خدمة مصغرة منفصلة تقوم ببناء طريقة عرض عبر مجموعة من الخدمات المصغرة. إذا كنت بحاجة إلى تشغيل العديد من الاستعلامات المرتجلة على البيانات، فيجب أن تفكر في كتابة بيانات كل خدمة مصغرة إلى خدمة تخزين البيانات للتحليلات غير المتصلة بالإنترنت.
تم إصدار الخدمات المصغرة. من الممكن أن تعمل إصدارات مختلفة من الخدمة المصغرة جنبًا إلى جنب. قد يفشل إصدار أحدث من خدمة مصغرة أثناء الترقية ويحتاج إلى الرجوع إلى إصدار سابق. يعد تعيين الإصدار مفيدًا أيضًا لاختبار A/B، حيث يواجه المستخدمون المختلفون إصدارات مختلفة من الخدمة. على سبيل المثال، من الشائع ترقية خدمة مصغرة لمجموعة محددة من العملاء لاختبار وظائف جديدة قبل طرحها على نطاق أوسع.
التفاعل مع الخدمات المصغرة الأخرى عبر واجهات وبروتوكولات محددة جيدًا
على مدى السنوات ال 10 الماضية، تم نشر معلومات واسعة النطاق تصف أنماط الاتصال في التصميمات الموجهة نحو الخدمات. بشكل عام، يستخدم اتصال الخدمة نهج REST مع بروتوكولات HTTP وTCP وXML أو JSON كتنسيق إنشاء تسلسل. من منظور الواجهة، يتعلق الأمر باتباع نهج تصميم الويب. ولكن لا شيء يجب أن يمنعك من استخدام البروتوكولات الثنائية أو تنسيقات البيانات الخاصة بك. فقط كن على علم بأن الأشخاص سيواجهون صعوبة في استخدام خدماتك المصغرة إذا لم تكن هذه البروتوكولات والتنسيقات متوفرة علنًا.
لديها اسم فريد (URL) يستخدم لحل موقعها
يجب أن تكون خدمتك المصغرة قابلة للعنونة أينما كانت قيد التشغيل. إذا كنت تفكر في الأجهزة وأيها يقوم بتشغيل خدمة مصغرة معينة، فقد تسوء الأمور بسرعة.
بنفس الطريقة التي يحل بها DNS عنوان URL معينًا لجهاز معين، تحتاج الخدمة المصغرة إلى اسم فريد بحيث يكون موقعها الحالي قابلاً للاكتشاف. تحتاج الخدمات المصغرة إلى أسماء قابلة للعنونة ومستقلة عن البنية الأساسية التي تعمل عليها. هذا يعني أن هناك تفاعلاً بين كيفية توزيع خدمتك وكيفية اكتشافها، لأنه يجب أن يكون هناك سجل خدمة. عند فشل أحد الأجهزة، يحتاج سجل الخدمة إلى إخبارك بالمكان الذي تم نقل الخدمة إليه.
يظل ثابتًا ومتوفرًا في وجود حالات فشل
يعد التعامل مع حالات الفشل غير المتوقعة واحدة من أصعب المشكلات التي يجب حلها، خاصة في النظام الموزع. الكثير من التعليمات البرمجية التي نكتبها كمطورين بهدف التعامل مع الاستثناءات. أثناء الاختبار، نقضي أيضًا معظم الوقت في التعامل مع الاستثناءات. هذه العملية أكثر تعقيدًا من كتابة التعليمات البرمجية للتعامل مع حالات الفشل. ماذا يحدث عند فشل الجهاز الذي تعمل عليه الخدمة المصغرة؟ تحتاج إلى اكتشاف الفشل، وهي مشكلة صعبة من تلقاء نفسها. ولكنك تحتاج أيضًا إلى إعادة تشغيل الخدمة المصغرة.
من أجل التوفر، يجب أن تكون الخدمة المصغرة مرنة في مواجهة حالات الفشل وقادرة على إعادة التشغيل على جهاز آخر. بالإضافة إلى متطلبات المرونة هذه، لا ينبغي فقدان البيانات، ويجب أن تظل البيانات متسقة.
من الصعب تحقيق المرونة عند حدوث حالات فشل أثناء ترقية التطبيق. لا تحتاج الخدمة المصغرة، التي تعمل مع نظام التوزيع، إلى الاسترداد. تحتاج إلى تحديد ما إذا كان بإمكانها الاستمرار في المضي قدمًا إلى الإصدار الأحدث أو التراجع إلى إصدار سابق للحفاظ على حالة متسقة. تحتاج إلى النظر في بعض الأسئلة، مثل ما إذا كان هناك عدد كاف من الأجهزة المتوفرة لمواصلة المضي قدمًا وكيفية استرداد الإصدارات السابقة من الخدمة المصغرة. لاتخاذ هذه القرارات، تحتاج إلى الخدمة المصغرة لإصدار المعلومات الصحية.
الإبلاغ عن الصحة والتشخيصات
قد يبدو الأمر واضحًا، وغالبًا ما يتم تجاهله، لكن الخدمة المصغرة تحتاج إلى الإبلاغ عن صحتها وتشخيصاتها. خلاف ذلك، لديك القليل من التفاصيل حول صحتها من منظور العمليات. يعد ربط الأحداث التشخيصية عبر مجموعة من الخدمات المستقلة، والتعامل مع انحرافات ساعة الجهاز لفهم ترتيب الحدث، أمرًا صعبًا. بنفس الطريقة التي تتفاعل بها مع خدمة مصغرة عبر بروتوكولات وتنسيقات بيانات متفق عليها، تحتاج إلى توحيد كيفية تسجيل الأحداث الصحية والتشخيصية التي ستنتهي في النهاية في مخزن أحداث للاستعلام والعرض. مع نهج الخدمات المصغرة، تحتاج الفرق المختلفة إلى الاتفاق على تنسيق تسجيل واحد. يجب أن يكون هناك نهج متسق لعرض الأحداث التشخيصية في التطبيق ككل.
الصحة تختلف عن التشخيصات. تتعلق الصحة بالخدمة المصغرة التي تبلغ عن حالتها الحالية لاتخاذ الإجراءات المناسبة. ومن الأمثلة الجيدة على ذلك العمل مع آليات الترقية والتوزيع للحفاظ على التوافر. على الرغم من أن الخدمة قد تكون غير صحية حاليًا بسبب تعطل العملية أو إعادة تشغيل الجهاز، فقد تظل الخدمة قيد التشغيل. آخر شيء تحتاجه هو جعل الوضع أسوأ من خلال بدء الترقية. أفضل طريقة هي التحقيق أولاً أو إتاحة الوقت للخدمة المصغرة للاسترداد. تساعدنا الأحداث الصحية من الخدمة المصغرة على اتخاذ قرارات مستنيرة، وفي الواقع، تساعد في إنشاء خدمات الإصلاح الذاتي.
إرشادات لتصميم الخدمات المصغرة على Azure
تفضل بزيارة Azure Architecture Center للحصول على إرشادات حول تصميم وبناء خدمات مصغرة على Azure.
Service Fabric كنظام أساسي للخدمات المصغرة
ظهر Azure Service Fabric عندما انتقلت Microsoft من تقديم المنتجات، والتي كانت عادةً متجانسة، إلى تقديم الخدمات. تمكنت تجربة بناء وتشغيل الخدمات الكبيرة، مثل Azure SQL Database وAzure Cosmos DB، من تشكيل Service Fabric. تطور النظام الأساسي بمرور الوقت مع اعتماد المزيد من الخدمات له. كان لا بد من تشغيل Service Fabric ليس فقط في Azure ولكن أيضًا في عمليات توزيع Windows Server المستقلة.
الهدف من Service Fabric هو حل المشكلات الصعبة لبناء وتشغيل خدمة واستخدام موارد البنية الأساسية بكفاءة، بحيث يمكن للفرق حل مشاكل العمل باستخدام نهج الخدمات المصغرة.
يساعدك Service Fabric على بناء تطبيقات تستخدم نهج الخدمات المصغرة من خلال توفير:
- نظام أساسي يوفر خدمات النظام لتوزيع الخدمات الفاشلة وترقيتها والكشف عنها وإعادة تشغيلها واكتشاف الخدمات وتوجيه الرسائل وإدارة الحالة ومراقبة الصحة.
- القدرة على توزيع التطبيقات إما قيد التشغيل في حاويات أو كعمليات. Service Fabric هي مُنسق للحاويات والعمليات.
- واجهات برمجة تطبيقات برمجة إنتاجية لمساعدتك في بناء التطبيقات كخدمات مصغرة: ASP.NET Core وReliable Actors وReliable Services. على سبيل المثال، يمكنك الحصول على معلومات عن الصحة والتشخيصات، أو يمكنك الاستفادة من التوافر العالي المضمن.
تعتبر Service Fabric حيادية بشأن كيفية بناء خدمتك، ويمكنك استخدام أي تقنية. لكنها توفر واجهات برمجة تطبيقات برمجة مضمنة تسهل بناء الخدمات المصغرة.
ترحيل التطبيقات الموجودة إلى Service Fabric
يسمح لك Service Fabric بإعادة استخدام التعليمات البرمجية الموجودة وتحديثها بخدمات مصغرة جديدة. هناك خمس مراحل لتحديث التطبيق، ويمكنك البدء والتوقف في أي مرحلة. المراحل هي:
- ابدأ بتطبيق متجانس تقليدي.
- رحّل. استخدم الحاويات أو الملفات التنفيذية للضيف لاستضافة التعليمات البرمجية الموجودة في Service Fabric.
- حدّث. أضف خدمات مصغرة جديدة إلى جانب التعليمات البرمجية الموجودة في حاويات.
- ابدع. قسم التطبيق المتجانس إلى خدمات مصغرة بناء على الحاجة.
- حوّل التطبيقات إلى خدمات مصغرة. حوّل التطبيقات المتجانسة الموجودة أو أنشئ تطبيقات جديدة.
تذكر أنه يمكنك البدء والتوقف في أي من هذه المراحل. ليس عليك التقدم إلى المرحلة التالية.
دعونا نلقي نظرة على أمثلة لكل مرحلة من هذه المراحل.
ترحيل
لسببين، تقوم العديد من الشركات بترحيل التطبيقات المتجانسة الموجودة إلى حاويات:
- خفض التكاليف، إما بسبب دمج الأجهزة الموجودة وإزالتها أو بسبب تشغيل التطبيقات بكثافة أعلى.
- عقد توزيع متسق بين التطوير والعمليات.
تخفيضات التكلفة واضحة ومباشرة. في Microsoft، يتم وضع العديد من التطبيقات الموجودة في حاويات، مما يؤدي إلى توفير ملايين الدولارات. يصعب تقييم التوزيع المتسق ولكنه لا يقل أهمية. وهذا يعني أنه يمكن للمطورين اختيار التقنيات التي تناسبهم، لكن العمليات لن تقبل سوى طريقة واحدة لتوزيع التطبيقات وإدارتها. هذا الأمر يخفف العمليات من الاضطرار إلى التعامل مع تعقيد دعم التقنيات المختلفة دون إجبار المطورين على اختيار تقنيات معينة فقط. بشكل أساسي، يتم وضع كل تطبيق في حاويات في صور توزيع قائمة بذاتها.
تتوقف العديد من المؤسسات عند هذه الخطوة. لديهم بالفعل مزايا الحاويات، وتوفر Service Fabric تجربة الإدارة الكاملة، بما في ذلك التوزيع والترقيات والإصدارات والعودة إلى الحالة السابقة ومراقبة الصحة.
عصر
التحديث هو إضافة خدمات جديدة إلى جانب التعليمات البرمجية الموجودة في حاويات. إذا كنت ستكتب تعليمات برمجية جديدة، فمن الأفضل اتخاذ خطوات صغيرة على مسار الخدمات المصغرة. قد يعني هذا إضافة نقطة نهاية REST API جديدة أو منطق تسلسل عمل جديد. وبهذه الطريقة، تبدأ عملية بناء خدمات مصغرة جديدة وتمارس تطويرها وتوزيعها.
الابتكار
يستوعب نهج الخدمات المصغرة احتياجات العمل المتغيرة. في هذه المرحلة، تحتاج إلى أن تقرر ما إذا كنت ستبدأ في تقسيم التطبيق المتجانس إلى خدمات، أو الابتكار. مثال كلاسيكي هنا هو عندما تصبح قاعدة البيانات التي تستخدمها كقائمة انتظار سير عمل بمثابة ازدحام المعالجة. مع زيادة عدد طلبات سير العمل، يجب توزيع العمل على نطاق واسع. خذ هذا الجزء المحدد من التطبيق الذي لا يتم تغيير حجمه، أو الذي يحتاج إلى التحديث بشكل متكرر، وقم بتقسيمه كخدمة مصغرة وابتكر.
تحويل التطبيقات إلى خدمات مصغرة
في هذه المرحلة، يتكون تطبيقك بالكامل من (أو ينقسم إلى) خدمات مصغرة. للوصول إلى هذه النقطة، قمت برحلة الخدمات المصغرة. يمكنك البدء من هنا، ولكن للقيام بذلك بدون النظام الأساسي للخدمات المصغرة لمساعدتك يتطلب استثمارًا كبيرًا.
هل الخدمات المصغرة مناسبة لتطبيقي؟
ربما. في Microsoft، مع بدء المزيد من الفرق في البناء للسحابة لأسباب تجارية، أدرك العديد منهم مزايا اتباع نهج يشبه الخدمة المصغرة. Bing، على سبيل المثال، تستخدم الخدمات المصغرة منذ سنوات. وبالنسبة للفرق الأخرى، كان نهج الخدمات المصغرة جديدًا. وجدت الفرق أن هناك مشاكل صعبة يجب حلها خارج مجالات قوتهم الأساسية. هذا هو السبب في أن Service Fabric اكتسبت قوة جذب كتقنية لبناء الخدمات.
الهدف من Service Fabric هو تقليل تعقيدات بناء تطبيقات الخدمات المصغرة بحيث لا تضطر إلى المرور بالعديد من عمليات إعادة التصميم المكلفة. ابدأ بحجم صغير، واعمل على حجم كبير عند الحاجة، وقم بإيقاف الخدمات، وأضف خدمات جديدة، وتطور مع استخدام العميل. نحن نعلم أيضًا أن هناك العديد من المشاكل الأخرى التي لم يتم حلها بعد لجعل الخدمات المصغرة أكثر سهولة بالنسبة لمعظم المطورين. الحاويات ونموذج برمجة المستخدم هي أمثلة على خطوات صغيرة في هذا الاتجاه. نحن على يقين من ظهور المزيد من الابتكارات لجعل نهج الخدمات المصغرة أسهل.