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

מערכת קצה עורפית (backend) יחידה כבר לא עמדה בקצב הגידול של עסק בתחום הבריאות והתזונה. תעבורת AI chatbot, קליטה רבה של נתוני מכשירים לבישים, ובקשות API יומיומיות, כולן התחרו על אותם משאבים – מה שהפך את המערכת לקשה להאצה ומסוכנת לפריסה. ארגנו אותה מחדש לשירותים ממוקדים וניתנים לפריסה באופן עצמאי, המתואמים מאחורי API gateway יחיד, ורצים ב-AWS.

האתגר

בסיס קוד אחד המטפל בכל המשימות. זרימת עבודה אחת כללה ניהול משתמשים, הסקת AI chatbot, מתכונים, וניתוח נתוני בריאות. קפיצה בכל תחום אחד פגעה בכל הפלטפורמה, וכל שינוי דרש פריסה מחדש של כל המערכת.
פרופילי משאבים שונים באופן קיצוני. בקשות chatbot מבוססות LLM דורשות הרבה CPU וזיכרון ונוטות להיות 'התפרצויות'; קליטת נתוני מכשירים לבישים היא כבדת כתיבה ורציפה; ממשקי CRUD API הליבתיים הם קלים וקבועים. הגדרת שרת יחיד לכל השלושה משמעותה תשלום יתר עבור עומסי עבודה מסוימים ו'הרעבה' של אחרים.
האצה ופריסה עצמאיות. הצוות נדרש להאיץ את עומס העבודה של ה-AI מבלי לגעת ב-API הליבתי, ולשלוח שינויים לתחום אחד מבלי לסכן את האחרים.
נקודת כניסה יחידה ובטוחה. למרות שירותי backend מרובים, הלקוחות (מובייל, ווב, אדמין) נזקקו לממשק עקבי ומאומת יחיד לתקשורת – ללא חשיפת טופולוגיית השירות הפנימית לעולם החיצון.

הפתרון שלנו

חילקנו את הפלטפורמה לשלושה שירותי NestJS ממוקדים מאחורי AWS Application Load Balancer, כאשר השרת הראשי משמש כ-API gateway ו-orchestrator. הוא אחראי על אימות ותחומים ליבתיים, ומאציל עבודה מיוחדת לשירותי ה-chatbot וה-health microservices באמצעות REST מאומת. שכבת נתונים והודעות משותפת שומרת על השירותים מקושרים באופן רופף אך עקבי.

ארכיטקטורה

שרת ראשי (NestJS) — API gateway ו-orchestrator: אימות, משתמשים, יעדים, מתכונים, תזמון והתראות. לכל הלקוחות נקודת כניסה ציבורית יחידה.
Microservice של Chatbot (NestJS) — שירות שיחה מבוסס AI המופעל על ידי Azure OpenAI (GPT-4o) באמצעות LangChain/LangGraph, עם RAG מגובה ב-Elasticsearch לאחזור מתכונים וידע.
Microservice של בריאות (NestJS) — קולט ומאגד נתוני בריאות ממכשירים לבישים ומזינה ידנית (Apple Health, Health Connect) ומספק אנליטיקה.
AWS ECS Fargate מריץ את שלושת השירותים המקונטיינרים, כל אחד עם הגדרות CPU/memory ומדיניות האצה משלו.
Application Load Balancer מסיים HTTPS ומנתב תעבורה באמצעות נתיב לשירות הנכון.
שכבת נתונים משותפת — MongoDB Atlas (אחסון ראשי), Redis (מטמון/סשנים), Elasticsearch (חיפוש), ActiveMQ (מסירת התראות אסינכרונית).
CI/CD — בניית Docker multi-stage נדחקת ל-Amazon ECR, ונפרסת ל-ECS כעדכונים מתגלגלים.

תכונות עיקריות

1. תבנית Orchestrator. השרת הראשי הוא השירות היחיד החשוף ללקוחות. הוא מאמת כל בקשה, ולאחר מכן מבצע קריאות פנימיות בין שירותים – כך שטופולוגיית ה-backend נשארת פרטית והאינטגרציה של הלקוח נשארת פשוטה.

2. קריאות מאומתות בין שירותים. תקשורת בין שירותים היא REST על גבי HTTP client משותף, מאובטחת עם מפתחות bearer API לכל שירות:

// השרת הראשי מפנה בקשת AI לשירות המיקרו של הצ'אטבוט

const reply = await this.microserviceClient.post(

this.chatbotApiKey, // מפתח bearer עבור שירות

`${this.chatbotUrl}/chat`,

{ user, question, sessionId, attachment },

);

3. האצה עצמאית לפי עומס עבודה. כל שירות הוא הגדרת משימת Fargate נפרדת עם מימדים משלה – שירות ה-chatbot עתיר הזיכרון מתרחב באופן עצמאי מה-API הליבתי הקל, כך שזינוקי תעבורת AI לעולם לא 'מרעיבים' בקשות יומיומיות.

4. שירות AI בגודל מתאים עם עמידות מובנית. שירות ה-chatbot מחליף בין מספר מפתחות Azure OpenAI, עובר אוטומטית למפתח חלופי במקרה של מגבלות קצב או שגיאות – ושומר על תכונות ה-AI מגיבות תחת עומס.

5. התראות באמצעות העברת הודעות אסינכרונית. מכיוון שתורי השהיה של ActiveMQ מפרידים התרעות ותזכורות מבוססות זמן מזרם הבקשות, מסירת התראות לעולם אינה מפריעה או מאטה את תעבורת ה-API הליבתית.

6. פריסות ניתנות לשחזור ומבודדות. מ-ECR ל-ECS, כל שירות נשלח כתמונת Docker משלו. שינוי בשירות הבריאות פשוט פורס מחדש את שירות הבריאות – מהדורות מהירות ובעלות סיכון נמוך עם עדכונים מתגלגלים הנבדקים לבריאותם.

7. חוזה לקוח עקבי אחד. יישום המובייל (React Native) ולוח המחוונים של האדמין, כולם מתקשרים לנקודת כניסה אחת מאוזנת עומסים ומאובטחת ב-HTTPS – הפיצול הפנימי ל-microservices בלתי נראה להם.

תוצאות

בימים אלה, עומסי העבודה עבור AI chatbots, נתוני בריאות ו-APIs ליבתיים ניתנים להאצה בנפרד; שום משימה אינה יכולה לפגוע באחרות.
כל שירות נפרס באופן עצמאי, והופך מהדורות מסוכנות ברמת הפלטפורמה כולה לעדכונים מהירים ומבודדים.
החישוב מותאם לגודל השירות, מה שמבטל את הקצאת היתר של שרת יחיד המתאים לכל.
נקודת כניסה מאובטחת ומאוזנת עומסים אחת שומרת על אינטגרציית הלקוח פשוטה, בעוד ה-backend נשאר פרטי ומודולרי.

מערך טכנולוגי

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