ארכיטקטורת Microservices צוברת תאוצה, ועם עליית הפופולריות תמיד גם מגיע השלב שבו הרבה אנשים מתחילים להאמין שארכיטקטורה זו היא היא המפתח לפתרון כל צרות העולם, בלי להבין את המורכבות שמגיעה עם הארכיטקטורה הזו.
בהרצאה קצרה זו Satyajit Ranjeev מציג מהניסיון שלו חלק מהמורכבויות שמגיעות עם ארכיטקטורה זו. ההרצאה המלאה.
איך מפרקים מערכת לשירותים?
התשובה הנכונה: ע"פ Bounded Context. התשובה הלא נכונה (שהם ניסו): על פי ישויות. חלוקה כזו מובילה למשל למערכת בלוגים שבה יש שירות של פוסטים, שירות הודעות, שירות תגובות וכו', כאשר לאו דווקא החלוקה הזו היא חלוקה שמונעת תלויות.
הדבר השני שהם לא הבינו בהתחלה היה "מה זה מיקרו". הם הגיעו די מהר ל-73 שירותים לצוות של 5 אנשים, וזה יצר תלויות, מורכבויות וצורך לשינויים רבים. למצוא את הגבולות הטבעיים של ה-context זה לא קל.
Event Sourcing
החברה שהמרצה עובד בה עוסקת בהעברת כספים. הם בחרו להשתמש ב-Kafaka כי הוא מבטיח שכל שדר מגיע לפחות פעם אחת. עדיין בערך 1% מהשדרים מגיע פעמיים, וכדי להבטיח Idempotency צריך לשמור את השדרים. הם בחרו בשביל זה להשתמש ב-event sourcing, וזה היה להם מאד נחמד כי אפשר לראות בדיוק מה קרה וגם לשחזר מידע במקרה של בעייה. איפה שומרים את כל ה-event-ים? הם בחרו להשתמש ב-Kafka עצמו כי הוא מבטיח סדר (per partition - זה הכריח אותם לעבוד רק עם partition אחד), וכל פעם ששירות עולה הוא בונה מחדש את המצב. באופן צפוי, היה topic אחד שהגיע ל-9 מליון הודעות ולקח לשירות המון זמן לעלות. חשוב גם לזכור שב-Kafka אי אפשר למחוק מידע מ-topic (רק מההתחלה אבל לא מהאמצע), ולא בטוח שהוא המוצר הכי מתאים ל-Event Sourcing.
כדי להתמודד עם עלייה ארוכה במקרה של topic-ים מאד גדולים, הם החליטו ליצור snapshots. הם שקלו שיטות שונות והחליטו ללכת על DB לכל שירות, וזה אכן פתר את בעיית האיטיות בעלייה. הם שמרו ב-PostgreS את ה-snapshots שרלוונטיים לשירות, ומה הנקודה האחרונה שנצפתה ב-Kafka.
איך עושים אוטומציה לכל השירותים האלה?
הם עבדו עם docker ו-Fleet.
אחד הדברים החשובים להבין כשנכנסים ל-Microservices זה שיש לזה עלות גבוהה ב-operations. נדרש להשקיע הרבה מאמץ רק כדי להשאיר את המערכת רצה. הם ידעו את זה מראש, אבל לצוות קטן זו עלות מאוד גבוהה - לטפל בסביבה, לטפל בניטור...
יש מאמר של Martin Fowler שאומר You must be this tall to use microservices. מומלץ לקרוא לפני שמתחילים.
עוד משהו מעניין שהם עשו זה להוציא מה-JIRA ספירה של Task-ים שעוסקים
בתשתיות הריצה. זה נראה ככה:
עוד נקודות מעניינות מה-Q&A
- הם החליטו לאחד בחזרה חלק מהשירותים, כי עכשיו הם מבינים יותר טוב מהם ה-Boundries. מהניסיון, זה קשה להבין אותם בהתחלה, ולכן גם המרצה הזה מציע להתחיל מ-monolith ואז לפרק אותו.
- "מה עושים עם שינוי בסכמה של event (ב-event sourcing)?" - הם רק הוסיפו שדות לאירועים. עוד משהו חשוב, זה שהם ניסו לשמור על האירועים כמה שיותר קטנים - אם מגיע עדכון גדול מהמשתמש מפרקים אותו להרבה אירועים קטנים לכל שדה בנפרד.
- "אילו בעיות חוויתם עם Zoo Keeper?" (בעקבות הערה שהמרצה אמר במהלך ההרצאה) - הוא עובד די טוב ב-Production אבל היה קשה להריץ אותו בסביבת הפיתוח והוא נפל כל הזמן בסביבה זו.
- "האם לדעתך 'שווה' ללכת ל-Event Sourcing?" - לא תמיד. הם למדו המון, אבל זה היה כואב.
- "איך עושים אנליזה על המידע כאשר הוא מחולק בין ה-DB השונים?" - הם עשו שירות אחד שעושה אגריגציה למידע.
אין תגובות :
הוסף רשומת תגובה