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

תפאורה: מכימיה בסיסית ועד מכניקת קוונטים

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

המערכת לא קלה להבנה

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

אם לא ניתן לאתר באגים, אולי נבדוק אותם

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

לכל הפשרות יש סיבה טובה. ימין?

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

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

מקור: www.habr.com