لنبدأ بتحديد ما هي الخدمات المصغرة. إنها طريقة لتقسيم مشاريع البرامج الكبيرة إلى وحدات مترابطة بشكل غير محكم تتواصل مع بعضها البعض من خلال واجهات برمجة تطبيقات بسيطة (APIs).
أصبحت الخدمات المصغرة شائعة بشكل متزايد في السنوات الأخيرة. إنها مثال على أسلوب العمارة المعياري ، بناءً على فلسفة تقسيم مشاريع البرامج الكبيرة إلى أجزاء أصغر ، مستقلة ، غير مترابطة.
اكتسب هذا النمط المعماري مكانة بارزة بين المطورين لصفاته الديناميكية والمرنة في إدارة واجهة برمجة التطبيقات وتنفيذ التطبيقات المحددة للغاية والمهام المنفصلة.
بعبارات بسيطة ، لا تعد الخدمات المصغرة أكثر من حل معماري آخر لتصميم التطبيقات المعقدة - معظمها على شبكة الإنترنت.
في هذه المقالة ، سوف نفهم ما هي المزايا التي تقدمها بنيات الخدمات المصغرة.
متابعة!
النظرية وراء الخدمات المصغرة
تُعدّ قابلية التوسع إحدى أهمّ العوامل الدافعة وراء أيّ نوع من الحلول المعمارية. ويتجه العديد من المحترفين في عالم الهندسة المعمارية وتطوير البرمجيات إلى كتاب بعنوان " فنّ قابلية التوسع".
كان النموذج المحدد للكتاب هو مقياس المكعب، الذي يصف أبعاد الأبعاد الثلاثة:
كما ترى ، يمثل المحور X القياس الأفقي للتطبيق (والذي رأيناه ممكنًا حتى مع الهندسة المتجانسة) ، ويمثل المحور Z مقياس التطبيق عن طريق تقسيم الأشياء المتشابهة.
يمكن فهم فكرة المحور Z بشكل أفضل باستخدام مفهوم التجزئة ، حيث يتم تقسيم البيانات ويعيد التطبيق توجيه الطلبات إلى الأجزاء المقابلة بناءً على إدخال المستخدم (كما يحدث عادةً مع قواعد البيانات).
يمثل المحور Y التحلل الوظيفي. في هذا النهج ، يمكن اعتبار العديد من الوظائف كخدمات مستقلة.
بدلاً من نشر التطبيق بالكامل عند توفر جميع المكونات ، يمكن للمطورين نشر خدماتهم بشكل مستقل.
لا يؤدي هذا إلى تحسين إدارة وقت المطور فحسب ، بل يمنحك أيضًا مرونة أكبر لتغيير الوحدات النمطية وإعادة نشرها دون القلق بشأن بقية مكونات التطبيق.
مزايا معماريات الخدمات المصغرة
تبدو مزايا الخدمات المصغرة قوية بما يكفي لإقناع بعض الشركات الكبرى ، مثل Amazon و Netflix و eBay ، بتبني المنهجية.
بالمقارنة مع المزيد من أطر التصميم المتجانسة ، تقدم الخدمات المصغرة:
- عزل أفضل للخطأ: يمكن أن تظل التطبيقات الأكبر حجمًا غير متأثرة إلى حد كبير بفشل وحدة واحدة.
- يزيل الاعتماد على البائع أو التكنولوجيا: توفر الخدمات المصغرة المرونة لتجربة مجموعة تقنية جديدة على خدمة فردية حسب الحاجة. لن يكون هناك الكثير من مخاوف التبعية وسيصبح عكس التغييرات أسهل بكثير. مع وجود كود أقل في اللعب ، هناك المزيد من المرونة.
- سهولة الفهم: بشكل أكثر بساطة ، يمكن للمطورين فهم وظائف الخدمة بشكل أفضل.
- عمليات نشر أصغر وأسرع: قواعد بيانات ونطاق أصغر = عمليات نشر أسرع ، مما يتيح لك أيضًا البدء في استكشاف فوائد النشر المستمر.
- قابلية التوسع: نظرًا لأن خدماتك منفصلة ، يمكنك بسهولة توسيع نطاق الخدمات التي تحتاجها بشدة في الأوقات المناسبة ، بدلاً من التطبيق بأكمله. عند القيام بذلك بشكل صحيح ، يمكن أن يؤثر ذلك على توفير التكاليف.
نشر الخدمات المصغرة
الآن بعد أن فهمنا الخدمات المصغرة ، كيف يتم نشرها؟
أفضل طريقة لنشر التطبيقات القائمة على بنية الخدمات المصغرة هي استخدام الحاويات ، وهي بيئات أنظمة تشغيل افتراضية متكاملة توفر عمليات معزولة ووصولاً مخصصاً إلى موارد الأجهزة الأساسية. يُعدّ Docker أحد أبرز حلول الحاويات حالياً.
يمكن للأجهزة الافتراضية من موفري البنية التحتية مثل Amazon Web Services (AWS) أن تعمل بشكل جيد لعمليات نشر الخدمات الصغيرة.
مع استمرار تطور اتجاهات تطوير التطبيقات ، سيصبح الجدل بين استخدام الخدمات المصغرة أو الاستفادة من البنى التقليدية المتجانسة أكثر وضوحًا. في النهاية ، يجب على المطورين بذل العناية الواجبة وفهم ما يصلح لحالات الاستخدام المحددة الخاصة بهم.
بالنسبة للشركات الأصغر ، يمكن أن يكون البدء بتطبيق مترابط أبسط وأسرع وأرخص - وإذا لم ينضج المنتج كثيرًا ، فلا يزال من الممكن ترحيله إلى الخدمات المصغرة في الوقت المناسب.
تعد المؤسسات الكبيرة التي تضم ملايين المستخدمين أمثلة واضحة على أفضل حالة استخدام للخدمات المصغرة لأنها تحتاج إلى ضمان وقت التشغيل وقابلية التوسع التي يمكن أن توفرها الوحدات النمطية المضافة.
هل ترغب في التعمق أكثر في موضوع بنية الخدمات المصغرة؟ حمّل الآن كتاب "مقدمة في بنية الخدمات المصغرة على AWS" الإلكتروني!
