Why was a microservices architecture used for the health platform?

Microservices separated the platform into independently scalable services for core APIs, AI chatbot workloads, and health-data processing, preventing one workload from affecting the performance of others.

How does AWS ECS Fargate support microservices scaling?

AWS ECS Fargate runs each microservice as an independently managed container, allowing CPU, memory, and scaling policies to be configured based on each service's workload.

Why use an API gateway with a microservices architecture?

An API gateway provides a single secure entry point for clients while handling authentication and routing requests to the appropriate backend microservice without exposing internal service architecture.

How do microservices improve deployment reliability?

Each service can be built, tested, and deployed independently, allowing changes to one microservice without redeploying or risking the entire application.

How does independent scaling improve health platform performance?

Independent scaling allows resource-intensive workloads such as AI chatbot requests and wearable-data processing to scale separately from lightweight API traffic, preventing resource contention and improving overall reliability.

Scaling a Health Platform with Microservices

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

التحدي

قاعدة كود واحدة تتعامل مع جميع المهام. تضمنت سير العمل إدارة المستخدم، الدردشة الذكية بالذكاء الاصطناعي، الوصفات، وتحليل بيانات الصحة. أي زيادة في أي مجال تؤدي إلى تدهور النظام بأكمله، وكل تغيير يعني إعادة نشر النظام بالكامل.
ملفات موارد متباينة للغاية. طلبات الدردشة الذكية المدعومة من LLM تتطلب الكثير من وحدة المعالجة المركزية والذاكرة وتكون متقطعة؛ ابتلاع البيانات من الأجهزة القابلة للارتداء يكون كثيف الكتابة ومستمر؛ APIs الأساسية CRUD تكون خفيفة وثابتة. تحديد حجم خادم واحد لجميع الثلاثة يعني دفع مبالغ زائدة لبعض الأحمال وتجويع الآخرين.
التوسع والنشر المستقل. كان الفريق بحاجة إلى توسيع عبء العمل الخاص بالذكاء الاصطناعي دون المساس بـ API الأساسي، وشحن التغييرات إلى مجال واحد دون المخاطرة بالآخرين.
نقطة دخول واحدة وآمنة. على الرغم من وجود خدمات خلفية متعددة، كان العملاء (المحمول، الويب، الإدارة) بحاجة إلى سطح موحد ومصادق عليه للتواصل — دون تسريب الطوبولوجيا الداخلية للخدمات إلى العالم الخارجي.

حلنا

قمنا بتقسيم المنصة إلى ثلاث خدمات NestJS مركزة خلف AWS Application Load Balancer، مع عمل الخادم الرئيسي كـ بوابة API ومنسق. يتولى المصادقة والمجالات الأساسية، ويفوض العمل المتخصص إلى خدمات الدردشة الذكية والصحة المصغرة عبر REST المصادق عليه. طبقة بيانات ورسائل مشتركة تحافظ على الخدمات مفككة ولكن متسقة.

الهندسة المعمارية

الخادم الرئيسي (NestJS) — بوابة API ومنسق: المصادقة، المستخدمين، الأهداف، الوصفات، الجدولة، والإشعارات. جميع العملاء لديهم نقطة دخول عامة واحدة.
خدمة الدردشة الذكية المصغرة (NestJS) — خدمة محادثة بالذكاء الاصطناعي مدعومة من Azure OpenAI (GPT-4o) عبر LangChain/LangGraph، مع RAG مدعوم من Elasticsearch لاسترجاع الوصفات والمعرفة.
خدمة الصحة المصغرة (NestJS) — تبتلع وتجمع البيانات الصحية من الأجهزة القابلة للارتداء واليدوية (Apple Health, Health Connect) وتقدم التحليلات.
AWS ECS Fargate تشغل الخدمات الثلاثة المعبأة في حاويات، كل منها بحجم وحدة المعالجة المركزية/الذاكرة الخاصة بها وسياسة التوسع.
Application Load Balancer ينهي HTTPS ويوجه حركة المرور إلى الخدمة الصحيحة.
طبقة البيانات المشتركة — MongoDB Atlas (المخزن الأساسي)، Redis (الذاكرة المؤقتة/الجلسات)، Elasticsearch (البحث)، ActiveMQ (تسليم الإشعارات غير المتزامن).
CI/CD — بناءات Docker متعددة المراحل تُدفع إلى Amazon ECR، تُنشر إلى ECS كتحديثات متدحرجة.

الميزات الرئيسية

1. نمط المنسق. الخادم الرئيسي هو الخدمة الوحيدة المكشوفة للعملاء. يقوم بمصادقة كل طلب، ثم يقوم بإجراء مكالمات خدمة إلى خدمة داخلية — بحيث تبقى الطوبولوجيا الخلفية خاصة وتبقى تكامل العميل بسيطًا.

2. مكالمات خدمة إلى خدمة مصادق عليها. التواصل بين الخدمات هو REST عبر عميل HTTP مشترك، مؤمن بمفاتيح API لكل خدمة:

// الخادم الرئيسي يفوض طلب الذكاء الاصطناعي إلى خدمة الدردشة الذكية المصغرة

const reply = await this.microserviceClient.post(

this.chatbotApiKey, // مفتاح الحامل لكل خدمة

`${this.chatbotUrl}/chat`,

{ user, question, sessionId, attachment },

);

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

4. خدمة الذكاء الاصطناعي بالحجم المناسب مع المرونة المدمجة. تدور خدمة الدردشة الذكية عبر مفاتيح Azure OpenAI متعددة، وتفشل تلقائيًا عند حدود المعدل أو الأخطاء — مما يحافظ على استجابة ميزات الذكاء الاصطناعي تحت الضغط.

5. الإشعارات عبر الرسائل غير المتزامنة. لأن ActiveMQ يفصل قوائم الانتظار المؤجلة النكزات والتذكيرات المستندة إلى الوقت عن تيار الطلبات، فإن تسليم الإشعارات لا يعيق أو يبطئ حركة مرور API الأساسية.

6. عمليات النشر المتكررة والمعزولة. من ECR إلى ECS، يتم شحن كل خدمة كصورة Docker خاصة بها. تعديل خدمة الصحة يعيد نشر خدمة الصحة فقط — إصدارات سريعة ومنخفضة المخاطر مع تحديثات متدحرجة يتم التحقق من صحتها.

7. عقد عميل متسق واحد. يتحدث كل من (React Native) ولوحة التحكم الإدارية إلى نقطة دخول واحدة متوازنة التحميل، HTTPS — الانقسام الداخلي إلى الخدمات المصغرة غير مرئي لهم.

النتائج

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

التقنية المستخدمة

NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker