توضيح : هذا المقال لا يحتج ولا يعتمد فكرة ما بناءَا على الضجة أو ما يراه المجتمع التقني صحيحَا...
بدايًة لفهم مفهوم الأنظمة المبنية على الخدمات الصغيرة (Microservices)، دعونا نعود بالقصة من البداية وكيف كانت تتم عملية بناء الأنظمة المتكاملة (Monolith Systems) وما يواجهها من عيوب ومنها نستطيع فهم جدوى إستخدام الأنظمة الصغيرة.
ما هي مشكلة الأنظمة المتكاملة (Monoliths)؟
لنحل مشكلة ونبني نظام إدارة مستشفى (Hospital Management System)
تخيل أن هناك نظاماً متكاملاً لإدارة مستشفى، وهو عبارة عن مشروع برمجي ضخم مبني داخل مستودع Git واحد، ويتكون من مجموعة من الأنواع أو لنقل فئات (classes) مثل:
• Patient (المرضى)
• Doctor (الأطباء)
• Appointment (المواعيد)
• Billing (الفواتير)
• Inventory (المخزون الطبي)
• Pharmacy (الصيدلية)
• LabTests (تحاليل المختبر)
• Surgery (الجراحات)
• RoomManagement (إدارة الغرف)
• Emergency (الطوارئ)
• Staff (الموظفين)
• Insurance (التأمين)
والقائمة تطول...
أين المشكلة؟
تخيل أنك تحاول إجراء تعديل على نظام "إدارة الغرف" (RoomManagement) ليضيف خاصية جديدة تتعلق بتخصيص غرف بناءًا على عدد الأسرة المتاحة.
الآن، ستجد نفسك مضطراً إلى تعديل أجزاء أخرى من النظام لأن الشفرة البرمحية (code) مرتبط بشكل وثيق (Tightly Coupled) مع الأنواع الأخرى مثل Billing (لحساب تكلفة الإقامة) أو Patient (لتحديث حالة الغرف للمرضى).
مثال آخر: ما العلاقة بين الصيدلية (Pharmacy) والجراحات (Surgery)؟ الصيدلية تهتم بالأدوية المتوفرة والكميات المتاحة في المخزون، بينما الجراحات تهتم بتخصيص الأدوات الطبية اللازمة للعمليات. ورغم أن الوظيفتين مختلفتان تماماً، إلا أنهما يعيشان داخل نفس النظام ويعتمدان على نفس الموارد البرمجية.
ما هي عيوب هذه البنية؟
1. ترابط وثيق (Tightly Coupled): الوحدات تعتمد على بعضها البعض بشكل كبير، مما يعني أن أي تعديل أو خطأ في وحدة واحدة قد يؤثر على النظام بأكمله.
2. ضعف الترابط الداخلي (Low Cohesion): لا تفتصر الوظائف المختلفة على التركيزعلى مهامها، بل تعتمد على وحدات أخرى لتكمل عملها.
3. صعوبة التوسعة والصيانة: مع نمو النظام، يصبح من الصعب إضافة ميزات جديدة أو تحديث النظام دون التسبب في مشاكل في أجزاء أخرى.
ما الذي نطمح إليه؟
في الأنظمة الجيدة، نسعى لتحقيق:
• ترابط ضعيف (Loose Coupling): بحيث تكون الوحدات البرمجية مستقلة ولا تعتمد على بعضها بشكل كبير.
• ترابط داخلي عالي (High Cohesion): بحيث تركز كل وحدة على مهمة واحدة فقط وتحتوي على كل ما يلزمها لإتمامها.
ماذا يمكننا أن نتعلم؟
الأنظمة المتكاملة قد تكون مناسبة للمشاريع الصغيرة، ولكن مع توسع المشروع، تظهر عيوبها بوضوح. لهذا السبب يتم التفكير في الانتقال إلى الخدمات الصغيرة (Microservices) التي تقدم مرونة أكبر، وسهولة في التطوير والصيانة.
لكن هنالك أسباب تجعلك دائما تفكر في استخدام الأنظمة المتكاملة (Monoliths) التي قد تكون مناسبة ومفيدة في بعض الحالات، خاصة عندما يكون:
1. المشروع صغير حيث أن المشاريع ذات الحجم الصغير أو المتطلبات البسيطة يمكن أن تعمل بكفاءة باستخدام الأنظمة المتكاملة، حيث تكون البنية أكثر سهولة في الفهم والتنفيذ.
2. البداية سريعة أو الوصول السريع للسوق هنا تمكن الأنظمة المتكاملة فرق التطوير من بناء النظام بسرعة في المراحل الأولية دون الحاجة إلى القلق بشأن تقسيم المهام أو إدارة الخدمات الصغيرة.
3. عادة ما يكون فريق التطوير الصغير أكثر كفاءة عند العمل على قاعدة برمجية واحدة متكاملة.
ما هي الخدمات الصغيرة (Microservices)؟
تخيل نفس نظام إدارة المستشفى أعلاه مبني على مفهوم الخدمات الصغيرة.
عند وصول مريض إلى قسم الطوارئ، يتم تسجيل بياناته الأساسية من خلال خدمة صغيرة مخصصة لتسجيل المرضى (Patient Registration Service).
ثم يتم تحويل المريض إلى الطبيب المناسب بناءً على حالته الصحية عبر خدمة تحديد المواعيد (Appointment Scheduling Service).
في حالة طلب الطبيب تحليلاً، يتم إرسال الطلب إلى خدمة تحاليل المختبر (Lab Tests Service)، التي بدورها تسجل العينة وتبدأ معالجة التحليل.
بمجرد ظهور النتائج، يتم إرسالها إلى الطبيب من خلال خدمة التقارير (Report Service)، والتي تعرض النتائج بشكل واضح ومنظم.
إذا احتاج المريض إلى أدوية، يتم توجيه الطلب إلى خدمة الصيدلية (Pharmacy Service)، والتي تتأكد من توفر الأدوية المناسبة في المخزون وتصدر فاتورة للمريض عبر خدمة الفواتير (Billing Service).
وفي حال كان المريض مشمولًا بالتأمين، تتواصل خدمة الفواتير مع خدمة التأمين (Insurance Service) للتحقق من التغطية وتحديث المدفوعات.
في نهاية اليوم، يمكن لمدير المستشفى فتح لوحة تحكم مركزية تعرض معلومات من مختلف الخدمات، عدد المرضى الذين تم علاجهم، وتكاليف الأدوية والموارد.
في نهاية كل شهر، يتم توليد تقرير مالي شامل باستخدام خدمة التقارير المالية (Financial Reporting Service).
ما هي الخدمات الصغيرة (Microservices) التي تصلح لنظام المستشفى؟
في هذا النظام، لدينا نماذج مثل:
• Patient: يمثل بيانات المرضى.
• Doctor: يمثل بيانات الأطباء.
• Appointment: لحجز المواعيد بين المرضى والأطباء.
• Prescription: لإدارة وصفات الأدوية.
• LabTest: لتحاليل المختبر.
• Invoice: للفواتير.
• Insurance: لتغطية التأمين.
• Room: لإدارة الغرف.
• Inventory: لإدارة المخزون الطبي.
• RevenueReport: لتقارير الإيرادات.
• CostReport: لتقارير التكاليف.
أولاً، نحاول إنشاء مجموعات لهذه الأنواع. في كل مجموعة، نضع الأنواع المرتبطة ببعضها البعض:
المجموعات:
• Patient Management: لإدارة المرضى.
• Doctor Management: لإدارة الأطباء والمواعيد.
• Lab Tests: لتحاليل المختبر.
• Pharmacy Management: لإدارة الأدوية والوصفات الطبية.
• Finance Management: للتقارير المالية والفواتير.
• Room Management: لإدارة الغرف والمخزون.
الآن لنقم بتوزيع الأنواع على المجموعات:
• إدارة المرضى (Patient Management):
◦ المريض (Patient)
• إدارة الأطباء والمواعيد (Doctor Management):
◦ الطبيب (Doctor)
◦ المواعيد (Appointment)
• تحاليل المختبر (Lab Tests):
◦ تحليل المختبر (LabTest)
• إدارة الصيدلية (Pharmacy Management):
◦ الوصفة الطبية (Prescription)
◦ المخزون (Inventory)
• الإدارة المالية (Finance Management):
◦ الفاتورة (Invoice)
◦ تقرير الإيرادات (RevenueReport)
◦ تقرير التكاليف (CostReport)
• إدارة الغرف (Room Management):
◦ الغرفة (Room)
◦ المخزون (Inventory)
ماذا الذي قمنا بفعله؟
• قمنا بتقسيم النظام إلى مجموعات بناءً على المسؤوليات (Responsibilities).
• في الأنظمة المتكاملة (Monoliths)، كنا سنضع كل هذه الانواع في مستودع (Repository) واحد، مما يجعلها مترابطة بشكل كبير.
• لكن في عالم الخدمات الصغيرة (Microservices)، نقوم بإنشاء مشروع منفصل لكل مجموعة.
كيف نقون بتنظيم الخدمات الصغيرة لنظام إدارة المستشفى؟
1. إدارة المرضى (Patient Management Service): مشروع مستقل يحتوي على الفئات المتعلقة بالمرضى ويهتم فقط بتسجيل المرضى وإدارة بياناتهم.
2. إدارة الأطباء والمواعيد (Doctor Management Service): مشروع مستقل يهتم بإدارة بيانات الأطباء وجدولة المواعيد.
3. إدارة تحاليل المختبر (Lab Test Service): مشروع مستقل يتعامل مع طلبات التحاليل وتسجيل النتائج.
4. إدارة الصيدلية (Pharmacy Service): مشروع يهتم بالمخزون الطبي وإدارة وصفات الأدوية.
5. الإدارة المالية (Finance Service): مشروع مستقل يقوم بتوليد الفواتير والتقارير المالية.
6. إدارة الغرف والمخزون (Room and Inventory Management Service): مشروع مستقل لإدارة الغرف والمخزون البطبي.
ما الفرق بين الأنظمة المتكاملة والخدمات الصغيرة لبناء نظام إدارة مستشفى:
• في الأنظمة المتكاملة (Monoliths): كل هذه الفئات والمجموعات تعمل معاً داخل نفس المستودع، أي تغيير في جزء من النظام قد يؤثر على النظام بالكامل.
• في الخدمات الصغيرة (Microservices): كل مجموعة مسؤولة عن جزء معين من النظام، ويتم تطويرها وصيانتها بشكل مستقل، يمكن لكل خدمة استخدام قاعدة بيانات وتقنيات مختلفة إذا لزم الأمر.
مزايا الخدمات الصغيرة في نظام المستشفى:
1. الاستقلالية حيث تعمل كل خدمة بشكل مستقل، مما يجعل النظام مرناً وسهل التوسع.
2. التخصص، كل خدمة تركز على وظيفة واحدة محددة، مما يسهل فهمها وصيانتها.
3. التوسع، يمكن توسيع كل خدمة بناءً على الضغط عليها دون التأثير على باقي النظام.
4. تقليل الترابط: أي خطأ في خدمة معينة لن يؤدي إلى تعطيل النظام بأكمله.
خلاصة:
باستخدام الخدمات الصغيرة، يمكن لنظام المستشفى أن يكون أكثر مرونة وفعالية، مما يتيح للمستشفى التوسع بسهولة وتقديم خدمات أفضل للمرضى.
في المقالة القادمة سأتحدث عن ما هي الخدمة وما يجعلها خدمة صغيرة وكيف تتواصل الخدمات الصغيرة مع بعضها...
التعليقات