מדוע הארכיטקטורה של super app נשברת בריליס השני
הגרסה הראשונה של super app נבנית מהר: מאגר יחיד, מודולים משותפים של אימות, תשלומים ופרופיל, שכבת נתונים אחת. כל עוד יש שתיים-שלוש צוותים, זה מאיץ את העבודה — אין צורך לשכפל לוגיקה ומסכים. הבעיה מופיעה בריליס השני, כשהמודולים מתרבים וכל אחד חי לפי לוח זמנים משלו.
עד לנקודה הזו הקוד והנתונים המשותפים תפחו, וכל שינוי במודול בסיסי פוגע במודולים שכנים. הצימוד בין מודולי האפליקציה גדל באופן סמוי — דרך מודלים משותפים, מטמון, ניווט, הגדרות סביבה. הבנייה מפסיקה להיות צפויה: שינוי במדור אחד שובר אחר, והבדיקה מחייבת להריץ תרחישים של כל המוצר.
מופיעה נקודת כשל יחידה. השכבה המשותפת — מצב סשן, קונפיגורציה, מסך משותף — מפילה לא תרחיש בודד, אלא את כל האפליקציה, כולל מדורים שהשינוי לא נגע בהם. שגיאה במודול משותף מתגלה אצל כל המשתמשים בבת אחת, וקשה לאתר אותה לפי הלוגים.
זמן שחרור הריליס גדל: במקום אספקה מבודדת של מודול אחד, הצוות מתאם תאריכים עם כל מי שנוגע בקוד המשותף. הריליס הופך למשא ומתן ולבדיקה סינכרונית, ותיקון דחוף מחייב בנייה מחדש מלאה ומעבר חוזר על כל הבדיקות — כולל אלה שלא קשורות לשינוי.
זו לא תוצאה של צוות חלש, אלא של האופן שבו הוגדרו הגבולות בין חלקי המוצר. בהמשך נפרט איך זה נסגר: חוזים בין מודולים, בנייה עצמאית, בידוד כשלים ונתונים משל עצמו לכל מדור.
מה נותנת ליבת מודולים: ריליסים, עמידות בפני כשלים, עומס
ליבת מודולים מפזרת מסך, לוגיקת דומיין ואינטגרציות למודולים עצמאיים עם חוזה מפורש. החוזה מתאר מה המודול חושף החוצה, ואוסר לפנות ישירות לפנים של המודול השכן. הליבה נשארת דקה: ניווט, גרף תלויות, שכבת עיצוב משותפת — כל השאר מתחבר בבנייה נפרדת.
הוצאות עצמאיות של מודולים משנות את מחזור הריליס עצמו. הצוות בונה ומשחרר את חלקו בלי לחכות לאחרים: הרצת בדיקות מלאה מצטמצמת לבדיקות של המודול שהשתנה והחוזים שלו, והבנייה המשותפת מפסיקה להיות נקודת חסימה.
מודולים על סטאקים שונים חיים זה לצד זה — חלק מהבלוקים חוצי-הפלטפורמות נוח לבנות ב-Flutter, וקטעים כבדים נשארים נייטיביים.
עמידות האפליקציה בפני כשלים נשענת על בידוד תקלות. קריסה של מודול התשלומים לא מפילה את הקטלוג והפיד: הליבה תופסת את השגיאה, מסמנת את המודול כלא זמין ומציגה תרחיש מוגבל במקום לסגור את האפליקציה.
אנליטיקת קריסות מנוהלת לפי מודולים, כך שרואים איזה חלק מהקריסות ממוקד בתוך בלוק אחד, ותיקון לא מחייב בנייה מחדש של כל המוצר.
סקיילינג תחת עומס — תוצאה של אותו גבול. תרחישים כבדים (פיד, חיפוש, המלצות) עוברים לשירותים נפרדים וגדלים לפי המדד שלהם, ללא תלות באחרים.
האפליקציה טוענת מודולים לפי דרישה, ולכן זמן ההתחלה הקרה לא גדל יחד עם מספר הפונקציות, ובשיא מפסיק לפעול שירות מסוים: שאר המדורים ממשיכים לעבוד על מטמון ונתונים מקומיים.
דרכי בנייה של האפליקציה: מונוליט, מונוליט מודולרי, שירותים
בחירת ההרכבה תלויה לא באופנה, אלא בכמה צוותים עובדים על המוצר ובמידת העצמאות שבה הם צריכים לשחרר שינויים. כל עוד יש חמישה מודולים וצוות אחד, פיצול לשירותים מביא יותר תקורה על תקשורת מאשר תועלת.
כשקיימים שלושה-ארבעה כיוונים ולכל אחד קצב ריליסים משלו, את מהירות השחרור מתחילים לקבוע דווקא גבולות המודולים.
בפועל פלטפורמות עוברות דרך מאפליקציה אחת למונוליט מודולרי, ואל שירותים נפרדים מוציאים צמתים בודדים — תשלומים, התראות, חיפוש. להלן התאמה ומגבלות של כל אפשרות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אפליקציה אחת | מוצר אחד, צוות אחד, רשימת תרחישים קצרה, שלב בדיקת ביקוש | בנייה משותפת: שינוי במסך אחד גורר ריליס שלם, זמן הבנייה גדל, גדלים החפיפים בין תחומים |
| מונוליט מודולרי | כמה צוותים וכיוונים במוצר אחד, נדרשים ריליסים עצמאיים בלי לתפעל מערכת מבוזרת | נדרשת משמעת: גבולות המודולים נקבעים בכללי בנייה, אחרת הקשרים משתרשים והמודול מאבד עצמאות |
| שירותים נפרדים | צמתים עם עומס נפרד, קצב שינויים משלהם ודרישות עמידות בכשלים: תשלומים, התראות, קטלוג | השהיות בהעברה, טרנזקציות מבוזרות, ניטור נפרד וניהול גרסאות של חוזים בין צמתים |
| היברידי | חלק מהצמתים הבשילו לעצמאות, והליבה עוד משתנה במשותף | נדרשים חוזים ברורים ותקנון, אחרת המצב מתפצל בין הליבה לשירותים |
מערך המודולים והמקומות שבהם עוברים הגבולות שלהם מקובעים לפני תחילת הפיתוח: מזה תלויים מבנה המאגרים, סכימת הבנייה וסדר שחרור הריליסים.
שלבי תכנון הפלטפורמה: מסכימה למסירה
תכנון הפלטפורמה מתחיל במיפוי מלאי: אילו שירותים כבר עובדים, מה נעשה בו שימוש חוזר, היכן משוכפלים אימות, תשלומים והתראות. בסוף השלב — סכימת מודולים מסוכמת וחוזים בין המודולים; בלעדיהם super app הופך לאוסף אפליקציות תחת אייקון אחד.
- ניתוח המצב הקיים. מפת מסכים, שירותים ונקודות אינטגרציה, צווארי בקבוק ותלויות שחוסמים ריליסים עצמאיים.
- סכימת מודולים. גבולות: ליבת המעטפת, שירותים משותפים, מודולי דומיין. הקריטריון — מודול נבנה, נבדק ומשוחרר בלי לגעת באחרים.
- חוזים בין מודולים. פורמטי החלפה, ניהול גרסאות, התנהגות כשכן לא זמין. מודול מעודכן לא אמור לשבור גרסה שכבר שוחררה של האפליקציה.
- סביבות ובנייה. מפרידים סביבות פיתוח, בדיקה לפני ריליס ושחרור, מוציאים הגדרות מהקוד, מגדירים בנייה אוטומטית עם סדר שחרור אחיד.
- בדיקת ארכיטקטורה. תרחישי כשל של מודול, עדכון בלי לעצור את האפליקציה, גידול בעומס; בודקים במכשירים אמיתיים וברשתות חלשות.
- מסירה לצוות. מוסרים סכימות, תיעוד, תקנון להוספת מודול חדש ומקיימים הדרכה — כדי שהצוות של הלקוח יפתח את הפלטפורמה.
סכימות מודולים, חוזי שירותים ותקנוני ריליסים
ארכיטקטורת Super App חיה יותר מהצוות שבנה אותה — אבל רק אם ההחלטות מקובעות בארטיפקטים, ולא בהתכתבות. מסירת הפלטפורמה נעשית לפי רשימת קבלה: הלקוח מקבל ערכה שלפיה מפתחים את המוצר בכוחות עצמו או מוסרים לצוות אחר בלי הנדסה הפוכה. מה נכלל בה — בהמשך.
- מפת מודולים — תחום האחריות של כל מודול, התלויות שלו ונקודות ההרחבה. ממנה רואים מה משתנה באופן מבודד ומה יגרור אחריו שכנים.
- תיאור חילופי נתונים — חוזים בין שירותים, פורמטי הודעות, כללי ניהול גרסאות והתנהגות כשכן לא זמין: ניסיונות חוזרים, תור, מצב מוגבל.
- כללי גישה — תפקידים ותחומי נראות, נקודות בדיקת הרשאות, סדר הנפקה, חידוש ושלילה של מפתחות בין מודולים למערכות חיצוניות.
- תקנון שחרור ריליס — הסתעפות, בדיקות אוטומטיות חובה, שלבי העלאה, קריטריונים לחזרה אחורה וסדר פעולות בתקלה.
- תיעוד הפלטפורמה — סכימת סביבות, בנייה וחתימה של האפליקציה, רשימת אינטגרציות חיצוניות וגבולות אחריות של הצדדים.
- יומן החלטות ארכיטקטוניות — אילו אפשרויות נשקלו, מה נבחר ולמה, עם סיבות לדחיית החלופות. לשחזר את זה מהזיכרון זה היקר ביותר.
- תרחיש חיבור מודול חדש — שלב אחר שלב: אילו חוזים לתאר, היכן להירשם, אילו בדיקות לעבור לפני העלאה.
הערכה חיה יחד עם המוצר: תיקון של חוזה או תקנון שחרור נעשה בשינוי אחד עם המסמך. בקבלה אנחנו בודקים זאת בפועל — פותחים את המפה של כל מודול ומשווים לאיך שהוא נבנה.
מקרה בוחן: איך האפליקציה עמדה בגידול והאיצה את שחרור הריליסים
בהתחלה היה מונוליט: בנייה אחת, מסוע ריליסים משותף לכל הצוותים וכפתור יחיד של «לשחרר». כשבסיס המשתמשים גדל פי כמה, זה הפך לצוואר בקבוק — תיקון במסך אחד חיכה לריליס משותף, ותקלה בדומיין נפרד (תשלומים, משלוחים, תמיכה) הובילה להחזרה אחורה של כל הלקוח. זמן ההתאוששות הגיע לשש שעות, כי היה צריך לבנות מחדש ולבדוק את כל הבנייה כולה.
מה שינו
דומיינים הוצאו למודולים עצמאיים עם חוזים מנוהלי גרסאות, ואילו ניווט, אימות ואנליטיקה נשארו בשכבה המשותפת. כל צוות קיבל מסוע משלו: בנייה של המודול, בדיקות לפי החוזה, פריסה מדורגת לחלק מהקהל והחזרה אחורה מהירה.
החלק השרתי פוצל לשירותים והורץ ב-Kubernetes — החזרה אחורה נוגעת בשירות אחד ובחוזה שלו, ולא בכל הפלטפורמה.
מה נהיה
שחרור ריליסים לפי צוותים הואץ: במקום לחכות לתאריך משותף — כמה ימים מהמוכנות של הקוד ועד לקהל, וחלק מהשינויים מגיעים בקונפיגורציה מרחוק בכלל בלי עדכון האפליקציה. זמן ההתאוששות אחרי תקלה הצטמצם משעות לדקות.
הצד השני של העצמאות — השכבה המשותפת: תיקונים בניווט ובאימות עוברים סקירה נפרדת, אחרת המודולים שוב מתחילים לגרור זה את זה.
במה שונה super app מודולרי מאוסף אפליקציות נפרדות
super app מודולרי הוא אפליקציית-מעטפת אחת, שבתוכה חיים מודולים עצמאיים: חלון ראווה, הזמנות, תשלומים, משלוחים, אזור אישי. המעטפת מחזיקה ניווט, כניסה אחידה, שכבת עיצוב משותפת ומכניקת עדכונים, וכל מודול נבנה, נבדק ומנוהל בגרסאות בנפרד. המשתמש מתקין אפליקציה אחת ומקבל את כל השירותים עם פרופיל אחד, סל אחד והיסטוריית פעולות אחת.
אוסף אפליקציות נפרדות בנוי אחרת: כל מוצר גורר אימות משלו, קו תשלומים משלו, התראות משלו, אנליטיקה ומסך תמיכה משלו. בנוף טיפוסי 60-70% מהקוד משוכפל בין בסיסי הקוד, ותיקון בכללי אבטחה או בסכימת תשלום חוזר על עצמו כמספר האפליקציות בתיק. בהמשך נפרדות הגרסאות של הספרייה המשותפת — והצוותים מתחילים לשבור תאימות זה לזה.
המחיר מתגלה בריליסים. המעטפת מאפשרת לשחרר שינויי שירות בתוכה בלי להפעיל מחדש מחזור בדיקות מלא ב-App Store, בעוד כל בנייה מתוך האוסף עוברת אישור משלה. פלטפורמה משותפת נותנת את מה שאי אפשר להרכיב מחלקים: אנליטיקה רוחבית על כל השירותים, סשן אחיד, חיפוש והמלצות משותפים. מדור חדש מוצג כמודול במחזור ריליס אחד, ולא כמוצר נפרד עם תיאור משלו בחנות ותמיכה משלו.
הצד השני של המודולריות — דרישות למשמעת. נדרשים חוזים נוקשים בין מודולים, ניהול גרסאות של ממשקים ובידוד כשלים: בלי זה קריסה של מדור אחד מפילה את כל המעטפת.
עוד בהתחלה מקבעים אילו חלקים חיים בפלטפורמה המשותפת ואילו נשארים אוטונומיים, — אחרת super app מודולרי מתנוון לאותן אפליקציות מפוצלות, רק בתוך חלון אחד.
ספקות טכניים לפני ההתחלה: אינטגרציות, נתונים, תמיכה
ספקות לפני ההתחלה נוגעים בדרך כלל לא ל-super app עצמו, אלא לתפרים סביבו: איך הוא מתחבר למערכות שכבר עובדות, מה קורה לנתונים שנצברו ומי אחראי לפלטפורמה אחרי ההשקה. להלן ארבע שאלות שנשאלות הכי часто, ואיך אנחנו עונים עליהן ברמת הארכיטקטורה.
איך super app ישתלב עם המערכות הקיימות?
אנחנו לא כותבים מחדש את המערכות שעובדות, אלא שמים בינן לבין הפלטפורמה שכבת מתאמים: כל אינטגרציה מקבלת קריאות אידמפוטנטיות, ניסיונות חוזרים עם השהיה גדלה ומצב מוגבל מפורש. אם שירות חיצוני לא זמין, המודול מחזיר את הנתונים התקפים האחרונים במקום שגיאה על המסך.
איך מעבירים נתונים בלי השבתה?
הסכימה — תמונת מצב פלוס השלמת שינויים לפי יומן, ואחר כך התאמה לכל ישות: מספר רשומות, סכומי ביקורת, שלמות הפניות. את המעבר עושים אחרי הרצת צל על תעבורה אמיתית, עם נקודת חזרה למערכת המקורית.
מה עם הרשאות גישה וחשבונות?
מודל אחיד של תפקידים ומאפיינים, כניסה אחידה עם קטלוג המשתמשים הקיים ובדיקת הרשאות ברמת השירות, לא הממשק. פעולות עם נתונים רגישים נכנסות ליומן ביקורת, והמודולים מקבלים את היקף הגישה המינימלי הנדרש.
מה כולל הליווי של הפלטפורמה אחרי ההשקה?
מודולים מתעדכנים באופן עצמאי, ולכן ריליס של מדור אחד לא גורר אחריו את האחרים. מגדירים מדדים והתראות לפי נתיבים קריטיים, תקנון לשחרור גרסאות ועדכון בהתאם לדרישות חנויות האפליקציות וגרסאות מערכות ההפעלה העדכניות.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
ככל שנתוני המוצא בהתחלה קונקרטיים יותר, כך יש פחות הנחות בהערכה. לכן לשיחה כדאי לאסוף לא משאלות לגבי עיצוב, אלא את המצב בפועל של המוצר: אילו שירותים כבר קיימים בפנים, איך הם מאמתים משתמש והיכן הם שומרים את הנתונים שלו. בהמשך אנחנו הופכים את זה למפת מודולים ולגבולות הליבה.
- רשימת שירותים-מודולים שאמורים לחיות באפליקציה אחת, ומה נשאר מוצרים נפרדים.
- סכימת האימות והפרופיל האחיד הנוכחיים: היכן מנפיקים טוקנים, איך מאורגנת היציאה מהחשבון, האם כבר יש סשן רוחבי בין השירותים.
- קו התשלומים והעבודה עם ספקים חיצוניים: מי יוזם תשלום, היכן נשמרת היסטוריית הפעולות, אילו בדיקות הן חובה.
- דרישות לעומס ולמצבים בלי רשת: אילו מסכים חייבים להיפתח מהמטמון המקומי, ואילו מותר לטעון לפי דרישה.
- גישות לחשבונות של חנויות אפליקציות, לשרתי בנייה ולמערכות אנליטיקה — הטיפול בהן לוקח לעתים יותר זמן משלב הפיתוח הראשון.
- מגבלות: כללי הפלטפורמה, דרישות חיצוניות לאחסון נתונים אישיים, גרסאות מערכות הפעלה שיש לתמוך בהן בהתחלה.
אחרי דיון במשימה אנחנו חוזרים עם הערכה ותוכנית עבודה: הרכב הצוות בהתאם להיקף הקונקרטי — ארכיטקט, מהנדסי מודולי פלטפורמה, מפתחי מובייל, מומחה לבנייה ושחרור, — חלוקה לשלבים, נקודות אינטגרציה וסדר ההכנה להתחלה.
תארו את המשימה באופן חופשי, צרפו את מה שכבר קיים לפי הרשימה למעלה, — זה מספיק כדי להתחיל שיחה עניינית.