Microservices: מה הם, למה הם ומתי ליישם אותם

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

חוק קונווי והקשר בין עסקים, ארגון ומערכת מידע

שוב ארשה לעצמי לצטט:

"כל ארגון שיתכנן מערכת (במובן הרחב) יקבל עיצוב שהמבנה שלו משכפל את מבנה הצוותים באותו ארגון".
- מלווין קונווי, 1967

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

אוריינטציה עסקית של מערכות מידע

תן לי להסביר עם דוגמה. נניח שיש הזדמנות עסקית לארגן עסק למכירת פיצה. בגרסת V1 (בואו נקרא לזה מידע מראש) החברה הייתה פיצריה, קופה ושירות משלוחים. גרסה זו ארכה חיים בתנאים של שונות סביבתית נמוכה. ואז באה גרסה 2 להחליף אותה - מתקדמת יותר ומסוגלת להשתמש במערכת מידע בליבתה לעסקים עם ארכיטקטורה מונוליטית. וכאן, לדעתי, יש פשוט עוול נוראי ביחס למונוליטים - ארכיטקטורה מונוליטית לכאורה אינה תואמת את המודל העסקי של התחום. כן, אם זה היה כך, המערכת לא הייתה מסוגלת לעבוד כלל - בניגוד לחוק והשכל הישר של אותו קונווי. לא, ארכיטקטורה מונוליטית תואמת לחלוטין את המודל העסקי בשלב זה של הפיתוח העסקי - אני כמובן מתכוון לשלב שבו המערכת כבר נוצרה והוכנסה לפעולה. זוהי עובדה נפלאה לחלוטין שללא קשר לגישה הארכיטקטונית, גם גרסה 3 של ארכיטקטורה מוכוונת שירות וגם גרסת N של ארכיטקטורת microservices יעבדו באותה מידה. מה המלכוד?

הכל זורם, הכל משתנה, או ששירותי מיקרו הם אמצעי להילחם במורכבות?

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

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

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

מחזור חיי המוצר ומחזור חיי השירות

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

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

שירותי מיקרו כאמצעי להילחם במורכבות... ניהול תצורה

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

ממצאים

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

מקור: www.habr.com