המסע של שופרוקט למיקרו-שירותים: חלק 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שופרוקט תמשיך במסעה אל מיקרו-שירותים. אנו מצפים לספר לכם יותר בחלק 2!