System Design

ביישומים מונוליטיים מסורתיים, שמירה על עקביות נתונים על פני ישויות מרובות היא פשוטה. מנועי מסד נתונים יחסיים מספקים ערבויות ACID (אטומיות, עקביות, בידוד, עמידות) עטופים בעסקאות SQL מקומיות. אם ביצוע הזמנה, ניכוי תשלום או עתודת מלאי נכשלים באמצע הדרך, הקריאה ROLLBACK תחזיר כל שינוי במסד הנתונים באופן מיידי. עם זאת, כאשר עוברים ל-Microservices Architecture מודרנית, ניהול הנתונים משתנה באופן מהותי. כדי להבטיח אוטונומיה של תחום ומדרגיות עצמאית, כל מיקרו-שירות הוא הבעלים של מסד הנתונים הפרטי שלו. פעולה עסקית אחת - כגון עיבוד קופה של מסחר אלקטרוני - משתרעת כעת על מספר גבולות שירות ומנועי מסד נתונים (למשל, PostgreSQL להזמנות, DynamoDB for Payments, Redis for Inventory).

בארכיטקטורת מיקרו-שירותים מבוססת אירועים (Event-Driven Architecture), שירותים מפיצים אירועים באופן קבוע (OrderCreated, PaymentProcessed) כדי לתקשר שינויי מצב באופן מנותק. עם זאת, הבטחת אמינות מלאה בפרסום אירועים מציבה אתגר קריטי: כיצד להבטיח שעדכון מסד הנתונים ופרסום האירוע יצליחו שניהם יחד או ייכשלו שניהם יחד? אם מיקרו-שירות מעדכן את מסד הנתונים המקומי שלו (PostgreSQL או MySQL) ולאחר מכן מנסה לשלוח הודעה ברשת לברוקר (כגון Apache Kafka או RabbitMQ), תקלת רשת עלולה לגרום לחוסר עקביות בנתונים.

בארכיטקטורת שירותי מיקרו, שירותים יוצרים רשת של שיחות רשת מבוזרות. אמנם זה מאפשר לצוותים לבנות ולהרחיב שירותים באופן עצמאי, אבל זה גם אומר שהאמינות הכוללת של המערכת שלך חזקה רק כמו החוליה החלשה שלה. אם שירות קריטי נופל או לא מגיב, זה יכול להפעיל כשל מדורג שישבש את האפליקציה כולה. החזרת “שגיאת שרת פנימית 500” כללית או דף ריק למשתמשים ברגע שבו תלות בודדת נכשלת היא חווית משתמש גרועה. במקום זאת, מערכות גמישות בנויות להתקלקל בחן כאשר דברים משתבשים.

בארכיטקטורת שירותי מיקרו, שירותים מתקשרים דרך רשת ולא שיחות בזיכרון. אמנם הניתוק הזה מאפשר קנה מידה אופקי מסיבי ופריסה עצמאית, אבל הוא גם מציג פגיעות גדולה: הרשת לא אמינה. בכל רגע, שירות במורד הזרם עלול לחוות תקלת רשת קצרה, זינוק זמני של מעבד, מחלוקת מהירה של נעילת מסד נתונים או הפעלה מחדש של עדכון מתגלגל. כשלים זמניים אלו ידועים כתקלות חולפות.

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

במערכות מודרניות מבוססות ענן, מיקרו-שירותים צפויים לעשות הרבה יותר מאשר להפעיל לוגיקה עסקית. עליהם לטפל ברישום, לנהל תעודות SSL/TLS, לאסוף מדדים, ליישם מנגנוני ניסיון חוזר ולתאם תקשורת מאובטחת עם שירותים אחרים. אם נטמיע את כל הפונקציונליות הצולבת הזו ישירות בתוך בסיס הקוד של כל יישום, בסופו של דבר נגמור עם נפיחות קוד, צימוד הדוק ונעילה בשפה.

בהנדסת תוכנה מודרנית, יישומים מונוליטיים מדור קודם הם אתגר נפוץ. עם הזמן, בסיס קוד מוצלח גדל כל כך גדול ומקושר זה לזה עד שביצוע שינויים פשוטים הופך למסוכן, פריסות נמשכות שעות, ושינוי קנה מידה של תכונות בודדות הוא כמעט בלתי אפשרי. כאשר צוותים מחליטים לחדש את המערכות שלהם על ידי מעבר לשירותי מיקרו, הם מתמודדים עם שאלה בעלת סיכון גבוה: כיצד נשכתב את המערכת מבלי לשבור את העסק הנוכחי שלנו?

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

המעבר מיישום יחיד ומונוליטי לארכיטקטורת מיקרו-שירותים פותר בעיות רבות. זה מאפשר לצוותים לעבוד באופן עצמאי, לפרוס שירותים בנפרד ולהרחיב חלקים מהמערכת לפי הצורך. עם זאת, הוא גם מציג אתגר חדש: איך לקוחות מקיימים אינטראקציה עם כל השירותים העצמאיים הללו? אם יש לך עשרה, חמישים או מאות שירותים זעירים, האם אפליקציה או דף אינטרנט לנייד צריכים להתחבר ישירות לכל אחד מהם?

כאשר ארגונים עוברים מארכיטקטורה מונוליטית לשירותי מיקרו, הם מתמודדים עם שאלה קריטית וחשובה: כיצד נשרטט את הגבולות של השירותים שלנו? בתיאוריה, שירותי מיקרו צריכים להיות יחידות רופפות, מנותקות, שניתן לפתח, לפרוס ולהגדיל באופן עצמאי. אולם בפועל, בסופו של דבר צוותים רבים בונים מונוליט מבוזר - מערכת שבה השירותים מחוברים בצורה הדוקה כל כך עד ששינוי עסקי בודד מצריך שינוי ופריסה של מספר שירותים בו-זמנית, מה שמוסיף את זמן השהיית הרשת והפריסה.