لقد قطع تطوير البرمجيات شوطا طويلا مما كان عليه قبل بضع سنوات. توجد اليوم مقتطفات أكواد جاهزة وأطر عمل متاحة تجعل حياة المطورين أسهل. يتفاقم هذا من خلال الأنظمة الأساسية التي لا تحتوي على تعليمات برمجية والتي تجعل تطوير تطبيقات البرامج أبسط وأسرع. وعلى طول هذا الطريق ، رأينا بعض نماذج البناء والبنى التي جعلت هذا التحسين ممكنًا.
شهدت العديد من المشاريع التي تستخدم الخدمات المصغرة فوائدها. لا يوجد تعريف دقيق لبنية الخدمات المصغرة ، ولكن هناك بعض الجوانب المشتركة لجميع المشاريع التي تستخدمها. نظرًا للابتكارات المتزايدة في التسليم القابل للتطوير والتصميم المستند إلى المجال وأتمتة البنية التحتية ، أصبحت الخدمات الصغيرة أكثر شيوعًا يومًا بعد يوم. دعنا نلقي نظرة على بنية الخدمات المصغرة وما جاء قبلها.
ما هي الخدمات المصغرة؟
يعد النمط المعماري للخدمات المصغرة أسلوبًا فريدًا لإنشاء منتجات برمجية. يهدف إلى التركيز على إنشاء وحدات أحادية الوظيفة ذات اتصالات وإجراءات واضحة. كل واحدة من هذه الوحدات مسؤولة عن وظيفة معينة ويمكنها التفاعل مع أنظمة البرامج الأخرى عبر بوابات API مباشرة لحل مشاكل وإمكانيات العمل الأكثر تعقيدًا.
نظرًا لأن المزيد والمزيد من الشركات بدأت في اعتماد منهجيات مثل النموذج الرشيق ، فقد أصبحت الخدمات المصغرة مستخدمة على نطاق واسع. يتمتع هذا النمط المعماري بالعديد من الفوائد وتستخدمه العلامات التجارية الشهيرة مثل Netflix و Amazon و PayPal وغيرها الكثير. يمكن توسيع أنظمة البرامج بشكل أسرع بفضل بنى الخدمات المصغرة. هذا بشكل أساسي لأنه يقلل من الوقت لإضافة إمكانيات جديدة إلى تطبيقك.
مصدر الصورة: learn.microsoft.com
تم إنشاء هذا النمط المعماري مع وضع إمكانات العمل في الاعتبار ويمكن نشره بشكل منفصل باستخدام معدات نشر مؤتمتة بالكامل. تتم إدارة هذه الخدمات ، التي يمكن برمجتها بلغات برمجة مختلفة واستخدام طرق تخزين البيانات المختلفة ، بشكل مركزي إلى الحد الأدنى. يمكن أن يؤدي استخدام بوابات API إلى جعل العديد من العمليات أبسط أيضًا.
غالبًا ما يخلط الناس بين الأسلوب المعماري للخدمات المصغرة والبنية الموجهة نحو الخدمة. بنية الخدمات المصغرة قريبة جدًا مما يفضله بعض مؤيدي SOA. على الرغم من أن بعض المتحمسين للخدمات المصغرة يرفضون لقب SOA ، يرى آخرون الخدمات المصغرة على أنها بنية واحدة موجهة نحو الخدمة.
العمارة المتجانسة
ترتبط جميع الأنشطة في الهندسة المعمارية المتجانسة ارتباطًا وثيقًا وتعمل كمنصة موحدة. هذا يعني أنه يجب توسيع البنية المتجانسة الكاملة إذا كان أحد مكونات البرنامج يعاني من زيادة في الطلب. مع توسع قاعدة التعليمات البرمجية للتطبيق الأحادي ، تصبح إضافة وظائف جديدة أو تحديث الوظائف الحالية أكثر صعوبة. هذا التعقيد يقيد الابتكار ويجعل من الصعب تنفيذ مفاهيم جديدة. نظرًا لأنها تتضمن العديد من العمليات المترابطة والمترابطة بإحكام ، فإن التصميمات المتجانسة تشكل خطرًا أكبر في حالة ارتكاب مكون واحد لأي أخطاء.
يتم تنفيذ كل عملية تطبيق كخدمة بواسطة مكونات منفصلة في بنية الخدمات المصغرة. كل خدمة لها وظيفة معينة وتم تصميمها مع وضع القدرات التجارية في الاعتبار. يمكن ترقية كل مكون وإطلاقه وتوسيعه لمطابقة الطلب على وظائف برنامج معينة لأنها تعمل بشكل منفصل.
السمات الرئيسية للخدمات المصغرة
فيما يلي بعض الخصائص الرئيسية لبنية الخدمات المصغرة:
عناصر متعددة
يمكن تقسيم بنية الخدمات المصغرة إلى عدة عمليات مكونة منفصلة. يسمح ذلك بنشر الخدمة وتعديلها وإعادة نشرها بشكل منفصل دون تعريض بنية النظام للخطر. بدلاً من إعادة نشر التطبيقات الكاملة ، سيكون عليك فقط تعديل خدمة واحدة محددة بهذه الطريقة. ومع ذلك ، هناك عيوب في هذه الإستراتيجية ، مثل المكالمات البعيدة المكلفة بدلاً من المكالمات قيد المعالجة وزيادة التعقيدات عند توزيع الواجبات بين العناصر.
مصممة للشركات
عادةً ما يتم تنظيم بنية الخدمات المصغرة وفقًا لأهداف وقدرات الشركة. تستخدم بنية الخدمات المصغرة مجموعات متعددة الوظائف ، حيث تركز فرق التطوير المختلفة بشكل خاص ، على عكس استراتيجية النمو التقليدية المتجانسة. تنتج كل مجموعة منتجات معينة بناءً على خدمات فريدة تتواصل عبر ناقل رسائل.
توجيه سهل
على غرار نظام UNIX التقليدي ، تأخذ الخدمات المصغرة الاستعلامات وتحللها ثم تقدم ردًا. تعمل العديد من مجموعات التكنولوجيا الأخرى ، بما في ذلك حافلات خدمة المؤسسات ، بشكل عكسي. تُستخدم الحلول عالية التقنية لتسلسل الرسائل والتوجيه وتنفيذ قيود الأعمال. تحتوي الخدمات المصغرة على أنابيب تحمل تدفقات تخزين البيانات ونقاط النهاية الذكية التي تقيم إدارة البيانات وتستخدم المنطق.
لامركزية
يمكن أن تكون التقنيات التقليدية للحكم المركزي أفضل لأن الخدمات الصغيرة تشمل مجموعة متنوعة من الأنظمة. يفضل نظام الخدمات المصغرة الحوكمة اللامركزية بحيث يمكن لمنشئيها توفير الأدوات التي يمكن للآخرين استخدامها لمعالجة نفس المشكلات. تشجع بنية الخدمات المصغرة أنظمة المعلومات اللامركزية. في الأنظمة المتجانسة ، تشترك تطبيقات المؤسسات المختلفة في تخزين بيانات منطقي واحد. في الوقت نفسه ، تحافظ كل خدمة عادةً على إدارة البيانات الخاصة بها في نظام الخدمات المصغرة.
مقاومة الفشل
تم تصميم بنية الخدمات المصغرة للتعامل مع حالات الفشل. من الممكن إلى حد ما أن تنقطع الخدمة لأن العديد من الخدمات المختلفة تتفاعل مع بعضها البعض. في هذه الحالات ، يجب على المستخدم الخروج من النظام بلطف مع السماح لخدماته المجاورة بمواصلة العمل. ومع ذلك ، فإن إدارة الخدمات المصغرة تساعد في تقليل فرصة حدوث خلل. يجعل هذا المطلب الخدمات المصغرة أكثر صعوبة من التصميمات المتجانسة.
تطوري
بنية الخدمات المصغرة هي بنية تطورية ومناسبة للشبكات التطورية. في مثل هذه الأنظمة ، من المستحيل التنبؤ بشكل كامل بالأجهزة التي ستتصل ببرنامجك في المستقبل. تبدأ العديد من البرامج بتصميم متجانسة يحركها المجال ولكن يمكن تغييرها تدريجيًا إلى خدمات صغيرة تتواصل عبر بنية متجانسة سابقة باستخدام بوابات API عند ظهور احتياجات جديدة.
فوائد الخدمات المصغرة
يتمتع هيكل المكون المنفصل لبنية الخدمات المصغرة بالعديد من الفوائد. تساهم كل من الميزات التي ذكرناها أعلاه في ذلك. تعتمد العديد من منتجات البرامج التي تم إنشاؤها اليوم على أتمتة البنية التحتية ، ويمكن أن تساعد الخدمات المصغرة في ذلك. بعض مزايا بنية الخدمات المصغرة التي يجب أن تكون على دراية بها هي:
رشاقة
يمكن تنظيم المجموعات الصغيرة المستقلة التي تتحمل مسؤولية عملياتها من خلال استخدام الخدمات المصغرة للرشاقة. يتم تمكين الموظفين للعمل بشكل أكثر استقلالية وكفاءة ضمن بيئة محددة ومقيدة. لا داعي للقلق بشأن كفاءة وعمل فرق ومكونات التطوير الأخرى. يتم تقصير أوقات الدورات للتطوير. يمكن أن يؤدي ذلك إلى زيادة الإنتاجية الإجمالية للأعمال.
تحجيم قابل للتكيف
قد تتوسع كل عملية بشكل مستقل لتلبية متطلبات البرنامج الذي تدعمه ، وذلك بفضل الخدمات المصغرة. يتيح ذلك لفرق التطوير توسيع نطاق متطلبات أتمتة البنية التحتية بشكل مناسب ، وحساب تكلفة الوظيفة ، وضمان توفر الخدمة في حالة زيادة الطلب. من المرجح أن تحتاج الشركات إلى توسيع وحدة معينة من المنتج بدلاً من المنتج بأكمله. تم جعل هذه العملية أبسط بشكل ملحوظ مع بنية الخدمات المصغرة.
نشر بسيط
أصبح تكامل الأعمال والنشر ممكنًا من خلال الخدمات المصغرة ، مما يجعل من السهل اختبار المفاهيم الجديدة وتقليصها إذا كان هناك شيء غير مناسب. يشجع السعر المنخفض للفشل على الابتكار ويسهل تحديثات الكود. يمكنك البقاء في صدارة منافسيك فقط بالأفكار الجديدة ، وبنية الخدمات المصغرة تجعل ذلك أسهل.
الاستقلال الفني
لا تلتزم بنية الخدمات المصغرة بواحدة لجميع الفلسفة. يمكن للفرق اختيار الحل المثالي لمعالجة مشكلاتهم الخاصة. قد يعمل نفس النموذج أو الأداة مع بعض المكونات فقط ، ووفقًا لاحتياجاتهم ، يمكنهم اختيار المكونات التي يريدونها. وهذا يعطي كل وحدة ، وبالتالي ، كل فريق يعمل معها ، استقلالية فنية.
كود قابل لإعادة الاستخدام
تسمح التعليمات البرمجية التي تم تقسيمها إلى مكونات يمكن إدارتها ومحددة جيدًا للفرق باستخدام وظائفها بطرق متنوعة. يمكن أن تكون الخدمة التي تم إنشاؤها لغرض معين هي الأساس لوظيفة أخرى. نتيجة لذلك ، يمكن للمبرمجين إضافة ميزات جديدة إلى التطبيق دون البدء من نقطة الصفر برموزهم. سيكون البديل هو كتابة رمز مشابه بشكل متكرر ، وهو أمر زائد ومحبط للمطورين.
تكيف
لا بد أن تحدث أخطاء وأخطاء معينة في برنامج معقد. من غير المجدي أن يتم إغلاق النظام بأكمله بسبب خطأ في وحدة واحدة. تزداد مرونة البرنامج في مواجهة الإخفاقات من خلال استقلالية الخدمة. تتيح البنية المتجانسة إمكانية فشل عنصر واحد في إسقاط البرنامج بأكمله. تستجيب البرامج التي تستخدم الخدمات المصغرة للانهيار الكلي للخدمة عن طريق تقليل القدرة بدلاً من الانهيار. يجب إصلاح عنصر الانهيار فقط ، ويمكن للوحدات النمطية الأخرى الاستمرار في العمل كالمعتاد.
كيف أبدأ بهندسة الخدمات المصغرة؟
كما رأينا أعلاه ، تتمتع بنية الخدمات المصغرة بالعديد من المزايا. إنه اختيار جيد للنظر فيه لمشروعك القادم. ولكن من أين تبدأ؟ الهيكل الأساسي الذي يمكنك اتباعه هو البدء بنظام مترابط والانتقال إلى بنية الخدمات المصغرة لاحقًا. يمكنك تقسيم موظفيك وتنظيمهم إلى فرق وتكليفهم بالعمل.
من المفيد أن تتذكر أن يكون لديك هيكل تصميم وظيفي أثناء البدء بالخدمات المصغرة. من المهم أيضًا نشر واستضافة المكونات المنفصلة بشكل مستقل. حاول البحث عن خيارات إدارة البيانات الخاصة بالخدمة. كما أنه يساعد على تبني أفضل تقنية يمكنك العثور عليها ومركزة العمليات.
أمثلة على الخدمات المصغرة
تستخدم العديد من شركات التكنولوجيا البارزة خدمات مصغرة لأغراض مختلفة ، بما في ذلك تبسيط بنيتها ، وتسريع تطوير البرامج ، وتحسين استجابة أنظمتها وقدرتها على التحديث. ساهم تطوير تقنيات أتمتة البنية التحتية أيضًا في التبني الواسع للهندسة المعمارية. فيما يلي بعض رواد السوق الذين يستخدمون هندسة الخدمات المصغرة في أنظمتهم:
أمازون
كان موقع الويب التجاري لشركة Amazon عبارة عن كتلة متراصة لها روابط معقدة بين عملياتها متعددة المستويات وفيما بينها عندما بدأت. يتطلب هذا تطويرًا دقيقًا للبرامج عند الحاجة إلى تنفيذ مهمة تحديث أو قابلية للتوسع لضمان عدم فشل أي شيء. كانت هذه الاستراتيجية شائعة في ذلك الوقت. تم استخدام الهندسة المعمارية المتجانسة لتطوير مبادرات تقنية واسعة النطاق نفذتها الشركات الكبرى.
ولكن مع نمو قاعدة مستخدمي Amazon ، قاموا بتوظيف أشخاص إضافيين للعمل عليها ، مما أدى إلى وجود قاعدة بيانات أكبر. نتيجة لذلك ، أصبح تغيير الهيكل أكثر صعوبة ، مما أدى إلى زيادة تكاليف المعالجة وإطالة دورة حياة التطوير.
لحل هذه المشكلات ، قسمت أمازون أنظمتها الكبيرة المتجانسة إلى تطبيقات مؤسساتية أصغر مستقلة. قام المطورون بفحص الكود المصدري في المراحل الأولى وأجزاء معزولة من الكود تؤدي غرضًا واحدًا. ثم تم وضع الوحدات داخل طبقة خدمة ويب بعد الانتهاء من ذلك. على سبيل المثال ، تم إنشاء وحدات نمطية مختلفة لأزرار وآلات حاسبة مختلفة. تقوم Amazon حاليًا بتطوير وتوزيع منتجات مثل AWS و Apollo ، مما يسهل على المؤسسات الأخرى تبني الخدمات المصغرة.
نيتفليكس
Netflix هي شركة رائدة في صناعة هندسة الخدمات المصغرة ، مثل Amazon. عندما واجه عملاق البث العديد من تحديات قابلية التوسع وانقطاع الخدمة ، بدأ نقله في عام 2008.
عندما تعطل نظام إدارة بيانات Netflix ، مما أدى إلى حظر شحنات أقراص DVD للمشتركين لمدة ثلاثة أيام ، أدركت الشركة أن الوقت قد حان للانتقال إلى الخدمات المصغرة. اختارت Netflix خدمات Amazon Web Services ( AWS) كمورد سحابي لتحقيق أهداف الترحيل إلى السحابة.
في عام 2009 ، بدأت Netflix في تحويل بنيتها المتجانسة ، وظيفة واحدة في كل مرة ، إلى بنية خدمات مصغرة. بدأت بتحويل منصة البرمجة النصية للأفلام التي لا تواجه المستخدم لتعمل على سحابة AWS باستخدام بنية خدمات مصغرة فردية. بدأت في ترحيل أنظمتها الاستهلاكية إلى الخدمات المصغرة بعد فترة وجيزة وانتهت العملية في عام 2012.
اوبر
بسبب حواجز التوسع ، قررت أوبر أيضًا كسر هيكلها المتجانس ، على غرار Amazon و Netflix. واجهت شبكة مشاركة الرحلات صعوبات في الجمع بين عملياتها الدولية سريعة التوسع ، فضلاً عن عدم الكفاءة في إنشاء وتقديم خدمات جديدة. لقد وصل إلى النقطة التي تتطلب فيها حتى ترقيات وتعديلات النظام الأساسية مبرمجين ذوي مهارات عالية بسبب هيكل التطبيق المعقد.
قسمت أوبر تطبيقها الأحادي إلى بنية خدمات صغيرة مدعومة بالسحابة لمعالجة المشكلات التي جلبتها. وسرعان ما تبع ذلك خدمات مصغرة محددة لعمليات الشركة ، مثل إدارة بيانات السفر وإدارة العملاء.
هل الخدمات المصغرة هي المستقبل
تعد بنية الخدمات المصغرة مفهومًا قويًا يتمتع بمزايا كبيرة لتطوير ونشر أنظمة الشركات. يستخدم العديد من المبرمجين والشركات استراتيجيات لاستغلال بوابات واجهة برمجة التطبيقات التي يمكن تصنيفها على أنها خدمات مصغرة دون اعتماد اللقب أو حتى تحديد سلوكهم على أنه SOA.
يحاول عدد قليل من مجموعات التكنولوجيا حل المشكلات التي تحاول بنية الخدمات المصغرة إصلاحها ، مثل UDDI. ومع ذلك ، فهي معقدة في التنفيذ ولا تُستخدم عمومًا في الأنظمة الأحدث. بالنظر إلى التعقيد المتزايد واحتياجات الاتصالات لبرامج SaaS ، والتكنولوجيا القابلة للارتداء ، وإنترنت الأشياء ، فمن الواضح أن بنية الخدمات المصغرة لها مستقبل ميمون.
إحدى المشكلات التي تواجهها الخدمات المصغرة هي أن كل وحدة أصبحت أكثر اعتمادًا على الآخرين بمرور الوقت. تعد بوابات API ، وكذلك اكتشاف الخدمة ، مفيدة جدًا في هذه الحالة. يتيح بناء بوابة API لجميع المستخدمين الدخول من خلال نقطة واحدة بحيث يمكن لبوابات API أن تقدم العديد من واجهات برمجة التطبيقات للعملاء. قد تستخدم بوابة API أيضًا إجراءات أمنية ، مثل تأكيد تفويض العميل بتقديم الطلب.
كيف يساعد AppMaster؟
كما ذكرنا من قبل ، فإن التطوير بدون كود يعيد حقًا تعريف الطريقة التي يتعامل بها المطورون مع الترميز. لقد أتاح للأشخاص العاديين بناء أفكارهم في منتجات برمجية حتى بدون لغات برمجة مختلفة أو خبرة. كما أن تطور العديد من الأنظمة الأساسية والأدوات المفيدة بدون تعليمات برمجية قد جعل هذه العملية أسهل.
AppMaster هو أحد هذه المنصات حيث يمكنك بناء منتجاتك من scratc h ، حتى بدون تشفير! يمكنك إنشاء كود لجميع أنواع التطبيقات ولا تقلق بشأن تعيين فريق كامل من المطورين. هذه عملية أبسط وأقل تكلفة بكثير. لا داعي للقلق بشأن ملكية الكود الذي تنشئه ، لأنه سيكون ملكًا لك وحدك.
كنمط معماري حديث ، تعد هندسة الخدمات المصغرة أسلوبًا معماريًا جيدًا ومستقرًا لتطوير التطبيقات والمشاريع المعقدة. منصة AppMaster مبنية على مبدأ الواجهة الخلفية للخدمات المصغرة وواجهات الخدمات المصغرة. كل شيء يتوسع ديناميكيًا ، بفضل الأسلوب المعماري. هذا يعني أن القياس التلقائي ممكن إذا كان لدينا حمل متزايد على بعض المكونات. هذا بفضل فصل جميع المكونات في بنية الخدمات المصغرة.
بدلاً من الاضطرار إلى توسيع نطاق المنتج بالكامل ، والذي يمكن أن يستهلك موارد غير ضرورية ، يمكننا الآن توسيع نطاق مكون واحد فقط سيؤدي على وجه التحديد مهمة مطلوبة معينة. علاوة على ذلك ، نقدم لعملائنا خدمات مصغرة خلفية بمساعدة مصمم من خلال منصتنا. يمكنهم إنشاء العديد من الخدمات المصغرة الخلفية باستخدام منصتنا فقط.
استنتاج
إذا كنت جديدًا تمامًا على نظام هندسة الخدمات المصغرة ، فمن الأفضل أن تبدأ صغيرًا. ابدأ مشروعك بمكون أو مكونين أو وحدات. مع الوقت والخبرة ، يمكنك التوسع ببطء. ستكون هذه العملية أسهل قليلاً إذا كان لديك بالفعل نظام أساسي مترابط.
لقد رأينا ما هي بنية الخدمات المصغرة وما هي فوائدها العديدة. لا يمكن للتطبيقات الحديثة العمل بأسلوب معماري مترابط دون مواجهة المشكلات في النهاية. على الرغم من أن بنية الخدمات المصغرة بها بعض التعقيدات ، إلا أنها خيار أفضل بكثير من نظيرتها. تسمح بنية الخدمات المصغرة بتوسيع نطاق تطبيقات البرامج وتصبح أكثر ابتكارًا.
