لما نقول نظام Monolith ( توحيدي او موحد) معناه أنه نظام تحتاج عند كل تعديل عليه و لو كان بسيط ان ترفع Deploy نسخه كاملة جديدة منه. قد يكون النظام Modular موزّع بداخله لكن الفيصل في الحُكم هو طريقة الDeployment. سنتعرف ايضاً عن الSOA و الMicrosevices و الفرق بينهما
(سلسلة)
(سلسلة)
ذكرت في تغريدة سابقة اننا عندما نبني انظمتنا فعادة نراعي تقسيمة فريق المطورين لدينا و ليس اقسام إدارات العمل كما في الصورتين. و حتى لو وزعنا النظام إلى عدة Modules فعلى الأغلب جميعها تستخدم قاعدة بيانات واحدة مشتركة. فمالمشكلة في ذلك ؟
المشكلة ان هناك Coupling أي ارتباط وثيق ينتج عنه أن أي تعديل في أي جزء يستلزم تغيير في جزء آخر و علينا الحذر حتى لا يؤثر التغيير على الأجزاء الاخرى بما فيها قواعد البيانات.
من مباديء الArchitecture ان تسعى لأن تكون انظمتك متماسكة لا مترابطة أي High cohesion, Low coupling
ستتضح هذه الفكرة ..
ستتضح هذه الفكرة ..
ذكرت ايضاً في تغريدة سابقة ان الObject أُُهين بأن اصبح مجرد ناقل للبيانات مع انه في الأصل يعتبر Software بحد ذاته.
بحيث يحمي بياناته و يغلفها Encapsulate و يتعامل مع بقية الObjects من خلال الMessages فقط.
نفس الشيء هنا بالنسبة للMicroservices
بحيث يحمي بياناته و يغلفها Encapsulate و يتعامل مع بقية الObjects من خلال الMessages فقط.
نفس الشيء هنا بالنسبة للMicroservices
الMicroservices هي أن تأخذ Module معين بالكود و بقاعدة بياناته الخاصه به و تقوم بتغليفه و يصبح التعامل معه من خلال Api هي عبارة عن عقد Contract مع الModule الأخرى. بأن تقول سأوفر لكم كذا إن اعطيتوني كذا او العكس ان ترسل لMicorservice الأخرى بيانات و تتوقع منها بيانات حسب عقدها.
لكن على أي أساس نقسم نظامنا الMonolith عدة Microservices ؟ هناك طرق كثيرة منها اعتماد مبدأ SRP الذي هو احد مباديء SOLID الخمسة في تصميم الكلاسات و الذي ينص على ان يكون هناك سبب واحد فقط للتغير في ذلك الكلاس
و كما شرحه روبرت مارتن بأن يكون كل كلاس موجه لإدارة او قطاع خاص في منشأتك بحيث لو طلبت إدارة تتبع للقطاع أي تغيير عليه فليس من الضروري استشارة ادارات اخرى في ذلك التغيير مادمنا محافظين على العقد من خلال الAPI و سيكون التغيير اسرع.
كيف نتحول إذاً من Monolith إلى Microservices ؟
كيف نتحول إذاً من Monolith إلى Microservices ؟
للبدأ في التحول إلى الMicroservices حاول فصل جزء بسيط واحد كالفواتير الذي يخص القطاع المالي من مجمل الMonolith ثم قم بعمل Integration له مع الMonolith و تعلم من ذلك التحول البسيط و حاول تحسينه ثم ابدأ بجزء آخر و هكذا. هذه العملية قد تستغرق اشهر لكنك في الطريق الصحيح.
تعلم من تجربتك و اخطائك فلن يأتي شخص من الخارج ليملي عليك الأنسب لك و لنظامك الذي تعرفه اكثر منه. الأنظمة الMonolith ليست في حد ذاتها مشكلة بل التوابع التي تلحقها عندما يتضخم النظام كصعوبة التعديل و التطوير.
تقنيات تقسيم الMonolith إلى Microservices استفادت من مفهوم الBounded Context في الDomain Driven Design
ففي البداية إن تم تقسيم النظام إلى اجزاء طبقاً لتقسيم الBusiness فسيكون الانتقال للMicroservices سلساً.
ففي البداية إن تم تقسيم النظام إلى اجزاء طبقاً لتقسيم الBusiness فسيكون الانتقال للMicroservices سلساً.
هناك ايضاً مقولة أن Microservices are SOA done right قد نتفق او نختلف معها. لكن حتماً بدون ESB فاستخدامنا ESB مع الMicroservices قد يكون Done Wrong. الESB هي اساس الSOA من حيث انك تحتاج إلى اوركستر يدير و ينسق العمل بين الServices لكن الMicroservices يفترض أن تدير نفسها بنفسها.
قد تحتاج إلى Mediator في الوسط مثل Kafka إن كنت تعتمد الأحداث Events أو كانت الMicroservices تنتج Notifications
. قد تحتاج الى API Management tool لكن لا تحتاج ESB إلا إن كانت لديك مصادر بيانات خارجية اخرى ببروتوكلات مختلفة و تحتاج إلى تعديل تلك البيانات للتناسب معك.
. قد تحتاج الى API Management tool لكن لا تحتاج ESB إلا إن كانت لديك مصادر بيانات خارجية اخرى ببروتوكلات مختلفة و تحتاج إلى تعديل تلك البيانات للتناسب معك.
مهما كانت اللغة او الstack الذي تبني به سواء java او net. او pyhton او nodejs او php او Go فانت قادر على التحول إلى الMicroservcies توجد كتب كثيرة لكل stack مخصصة للMicroservcies. لكن الأهم ان تفهم الفكرة و المباديء و الأنماط قبل الانتقال للتنفيذ.
الMicroservices اصبحت جزء مهم و ممكّن للDevOps مثلها مثل استخدام الContainers بدل الطرق التقليدية. يسرع عملية التطوير و الإطلاق و المراقبة و التحسين لمن اراد الاستفادة الحقيقية من جوهر الDevOps. ذكرت مصطلحات قد تكون جديدة على البعض يمكن وضع تعليق او البحث عنها.
ودمتم.
ودمتم.
جاري تحميل الاقتراحات...