System Design

في التطبيقات المتجانسة التقليدية، يعد الحفاظ على تناسق البيانات عبر كيانات متعددة أمرًا بسيطًا. توفر محركات قواعد البيانات العلائقية ضمانات ACID (الذرية والاتساق والعزل والمتانة) داخل معاملات SQL المحلية. إذا فشل تقديم الطلب أو خصم الدفع أو احتياطي المخزون في منتصف الطريق، فإن استدعاء ROLLBACK يعيد كل تعديل لقاعدة البيانات على الفور. ومع ذلك، عند الانتقال إلى بنية الخدمات الصغيرة الحديثة، تتغير إدارة البيانات بشكل أساسي. لضمان استقلالية المجال وقابلية التوسع المستقلة، تمتلك كل خدمة صغيرة قاعدة بياناتها الخاصة. تمتد الآن عملية تجارية واحدة - مثل معالجة عملية دفع التجارة الإلكترونية - عبر حدود الخدمة ومحركات قواعد البيانات المتعددة (على سبيل المثال، PostgreSQL for Orders، وDynamoDB for Payments، وRedis for Inventory).

في الهندسة البرمجية الموزعة الحديثة، أصبحت البنية القائمة على الأحداث (Event-Driven Architecture) العمود الفقري لأنظمة الخدمات المصغرة القابلة للتوسع. تقوم الخدمات بانتظام بإصدار أحداث المجال مثل OrderCreated أو PaymentProcessed للتواصل عبر حدود الخدمات دون اقتران وثيق. ومع ذلك، فإن تطبيق نشر الأحداث الموثوق به يطرح مشكلة هندسية دقيقة وحرجة: كيف تضمن أن تحديث قاعدة البيانات ونشر الحدث المقابل ينجحان معًا أو يفشلان معًا؟

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

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

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

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

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

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

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

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