בילית חודשים בעיצוב מחדש של המונוליט שלך לשירותי מיקרו, ולבסוף כולם התאספו כדי להפוך את המתג. אתה עובר לדף האינטרנט הראשון... ושום דבר לא קורה. אתה טוען אותו מחדש - ושוב שום דבר טוב, האתר כל כך איטי שהוא לא מגיב במשך כמה דקות. מה קרה?
בהרצאתו, ג'ימי בוגארד יערוך "נתיחה שלאחר המוות" על אסון מיקרו-שירותי בחיים האמיתיים. הוא יראה את בעיות הדוגמנות, הפיתוח והייצור שגילה, וכיצד הצוות שלו הפך לאט לאט את המונוליט המבוזר החדש לתמונה הסופית של שפיות. למרות שאי אפשר למנוע לחלוטין שגיאות עיצוב, אתה יכול לפחות לזהות בעיות בשלב מוקדם בתהליך התכנון כדי להבטיח שהמוצר הסופי יהפוך למערכת מבוזרת אמינה.
שלום לכולם, אני ג'ימי והיום אתם הולכים לשמוע איך אפשר להימנע ממגה אסונות בבניית מיקרו-שירותים. זהו סיפורה של חברה שעבדתי בה במשך כשנה וחצי כדי לסייע במניעת התנגשות הספינה שלה בקרחון. כדי לספר את הסיפור הזה כמו שצריך, נצטרך לחזור אחורה בזמן ולדבר על איפה החברה הזו התחילה ואיך תשתית ה-IT שלה גדלה עם הזמן. כדי להגן על שמות החפים מפשע באסון הזה, שיניתי את שמה של החברה הזו לבל מחשבים. השקף הבא מציג כיצד נראתה תשתית ה-IT של חברות כאלה באמצע שנות ה-90. זוהי ארכיטקטורה טיפוסית של שרת HP Tandem Mainframe אוניברסלי גדול סובלני לתקלות להפעלת חנות לחומרי מחשב.
הם היו צריכים לבנות מערכת לניהול כל ההזמנות, המכירות, ההחזרות, קטלוגי המוצרים ובסיס הלקוחות, אז הם בחרו בפתרון המיינפריים הנפוץ ביותר באותה תקופה. המערכת הענקית הזו הכילה כל פיסת מידע על החברה, כל מה שאפשר, וכל עסקה בוצעה דרך המיינפריים הזה. הם שמרו את כל הביצים שלהם בסל אחד וחשבו שזה נורמלי. הדבר היחיד שלא נכלל כאן הוא קטלוגים של הזמנה בדואר וביצוע הזמנות בטלפון.
עם הזמן, המערכת הפכה לגדולה יותר ויותר, והצטברה בה כמות עצומה של אשפה. כמו כן, COBOL היא לא השפה הכי אקספרסיבית בעולם, כך שהמערכת בסופו של דבר הייתה חתיכת זבל גדול ומונוליטי. עד שנת 2000, הם ראו שלחברות רבות יש אתרים שדרכם הם ניהלו את כל עסקיהם, והחליטו לבנות את אתר הדוט-קום המסחרי הראשון שלהם.
העיצוב הראשוני נראה די נחמד והורכב מאתר ברמה עליונה bell.com ומספר תת-דומיינים ליישומים בודדים: catalog.bell.com, accounts.bell.com, orders.bell.com, חיפוש מוצרים search.bell. com. כל תת-דומיין השתמש במסגרת ASP.Net 1.0 ובבסיסי נתונים משלו, וכולם דיברו עם ה-backend של המערכת. עם זאת, כל ההזמנות המשיכו להיות מעובדות ומבוצעות בתוך מיינפריים ענק אחד, שבו כל הזבל נשאר, אבל הקצה הקדמי היה אתרים נפרדים עם אפליקציות בודדות ומסדי נתונים נפרדים.
אז העיצוב של המערכת נראה מסודר והגיוני, אבל המערכת בפועל הייתה כפי שמוצג בשקף הבא.
כל הרכיבים פנו לקריאות זה לזה, ניגשו לממשקי API, קבצי dll משובצים של צד שלישי וכדומה. לעתים קרובות קרה שמערכות בקרת גרסאות היו תופסות קוד של מישהו אחר, דוחפות אותו לתוך הפרויקט, ואז הכל נשבר. MS SQL Server 2005 השתמש בקונספט של שרתי קישור, ולמרות שלא הצגתי את החצים בשקופית, כל אחד מבסיסי הנתונים דיבר ביניהם, כי אין שום דבר רע בבניית טבלאות המבוססות על נתונים שהתקבלו ממספר מסדי נתונים.
מכיוון שכעת הייתה להם הפרדה מסוימת בין אזורים לוגיים שונים של המערכת, זה הפך לכתמי לכלוך מבוזרים, כאשר פיסת האשפה הגדולה ביותר עדיין נותרה בקצה האחורי של המיינפריים.
הדבר המצחיק היה שהמיינפריים הזה נבנה על ידי מתחרים של בל מחשבים ועדיין מתוחזק על ידי היועצים הטכניים שלהם. משוכנעת בביצועים הלא מספקים של האפליקציות שלה, החברה החליטה להיפטר מהם ולעצב מחדש את המערכת.
האפליקציה הקיימת הייתה בייצור במשך 15 שנה, וזה שיא עבור יישומים מבוססי ASP.Net. השירות קיבל הזמנות מכל העולם, וההכנסות השנתיות מאפליקציה בודדת זו הגיעו למיליארד דולר. חלק ניכר מהרווח נוצר על ידי אתר bell.com. בימי הבלאק פריידי הגיע מספר ההזמנות שבוצעו דרך האתר לכמה מיליונים. עם זאת, הארכיטקטורה הקיימת לא אפשרה כל פיתוח, שכן החיבורים הנוקשים של רכיבי מערכת לא אפשרו למעשה לבצע שינויים בשירות.
הבעיה החמורה ביותר הייתה חוסר היכולת לבצע הזמנה ממדינה אחת, לשלם עליה במדינה אחרת ולשלוח אותה למדינה שלישית, למרות שתוכנית מסחר כזו נפוצה מאוד בחברות גלובליות. האתר הקיים לא איפשר דבר כזה, אז הם נאלצו לקבל ולבצע הזמנות אלו בטלפון. זה הוביל לכך שהחברה חושבת יותר ויותר על שינוי הארכיטקטורה, בפרט על מעבר לשירותי מיקרו.
הם עשו את הדבר החכם בכך שבדקו חברות אחרות כדי לראות איך הם פתרו בעיה דומה. אחד הפתרונות הללו היה ארכיטקטורת השירות של נטפליקס, המורכבת משירותי מיקרו המחוברים באמצעות API ומסד נתונים חיצוני.
הנהלת בל מחשבים החליטה לבנות בדיוק ארכיטקטורה כזו, תוך הקפדה על עקרונות בסיסיים מסוימים. ראשית, הם ביטלו כפילות נתונים על ידי שימוש בגישת מסד נתונים משותף. לא נשלחו נתונים, להיפך, כל מי שהיה צריך אותם היה צריך ללכת למקור מרכזי. לאחר מכן באו בידוד ואוטונומיה - כל שירות היה בלתי תלוי באחרים. הם החליטו להשתמש ב-Web API לכל דבר - אם רציתם לקבל נתונים או לבצע שינויים במערכת אחרת, הכל נעשה דרך ה-Web API. הדבר הגדול האחרון היה מיינפריים חדש בשם "Bell on Bell" בניגוד למיינפריים "Bell" המבוסס על החומרה של המתחרים.
אז, במהלך 18 חודשים, הם בנו את המערכת סביב עקרונות הליבה האלה והביאו אותה לייצור טרום-ייצור. כשחזרו לעבודה לאחר סוף השבוע, התכנסו המפתחים והפעילו את כל השרתים אליהם הייתה מחוברת המערכת החדשה. 18 חודשי עבודה, מאות מפתחים, חומרת Bell המודרנית ביותר - וללא תוצאה חיובית! זה איכזב הרבה אנשים כי הם הפעילו את המערכת הזו על המחשבים הניידים שלהם פעמים רבות והכל היה בסדר.
הם היו חכמים להשליך את כל כספם בפתרון הבעיה הזו. הם התקינו את מדפי השרתים הכי מודרניים עם מתגים, השתמשו בסיבים אופטיים של גיגה-ביט, בחומרת השרת הכי חזקה עם כמות מטורפת של זיכרון RAM, חיברו הכל, הגדירו את זה - ושוב, כלום! ואז הם התחילו לחשוד שהסיבה עשויה להיות פסקי זמן, אז הם נכנסו לכל הגדרות האינטרנט, לכל הגדרות ה-API ועדכנו את כל תצורת הזמן הקצוב לערכים המקסימליים, כך שכל מה שהם יכולים לעשות זה לשבת ולחכות שמשהו יקרה לאתר. הם חיכו וחיכו וחיכו 9 וחצי דקות עד שהאתר סוף סוף נטען.
לאחר מכן התחוור להם שהמצב הנוכחי מצריך ניתוח מעמיק והם הזמינו אותנו. הדבר הראשון שגילינו הוא שבמהלך כל 18 חודשי הפיתוח, לא נוצר אפילו "מיקרו" אמיתי אחד - הכל רק גדל. לאחר מכן, התחלנו לכתוב נתיחה שלאחר המוות, המכונה גם "רטרוספקטיבה", או "רטרוספקטיבה עצובה", המכונה גם "סערת האשמה", בדומה ל"סערת מוח", כדי להבין את סיבת האסון.
היו לנו כמה רמזים, אחד מהם היה רוויה מלאה של תעבורה בזמן קריאת ה-API. כאשר אתה משתמש בארכיטקטורת שירות מונוליטית, אתה יכול מיד להבין מה בדיוק השתבש כי יש לך עקבות מחסנית בודדת שמדווחת על כל מה שיכול היה לגרום לכשל. במקרה שבו חבורה של שירותים ניגשים בו-זמנית לאותו API, אין דרך לעקוב אחר המעקב למעט שימוש בכלי ניטור רשת נוספים כמו WireShark, שבזכותם ניתן לבחון בקשה בודדת ולגלות מה קרה במהלך היישום שלה. אז לקחנו דף אינטרנט אחד ובילינו כמעט שבועיים בחיבור חלקי הפאזל, עשינו אליו מגוון שיחות וניתוח למה כל אחד מהם הוביל.
תסתכל על התמונה הזאת. זה מראה שבקשה חיצונית אחת מנחה את השירות לבצע שיחות פנימיות רבות שחוזרות בחזרה. מסתבר שכל קריאה פנימית מבצעת דילוגים נוספים על מנת שתוכל לתת שירות עצמאי לבקשה זו, כי היא לא יכולה לפנות לשום מקום אחר כדי לקבל את המידע הדרוש. התמונה הזו נראית כמו מפל חסר משמעות של שיחות, שכן הבקשה החיצונית קוראת לשירותים נוספים, שמתקשרים לשירותים נוספים אחרים, וכן הלאה, כמעט עד אינסוף.
הצבע הירוק בתרשים זה מציג חצי עיגול שבו השירותים קוראים זה לזה - שירות A קורא לשירות B, שירות B קורא לשירות C, והוא קורא שוב לשירות A. כתוצאה מכך, אנו מקבלים "מבוי סתום". בקשה בודדת יצרה אלף קריאות API לרשת, ומכיוון שלמערכת לא הייתה סובלנות תקלות והגנה מובנית, הבקשה תיכשל אם אפילו אחת מקריאות ה-API הללו תיכשל.
עשינו קצת מתמטיקה. לכל קריאת API היה SLA של לא יותר מ-150 אלפיות השנייה ו-99,9% זמן פעולה. בקשה אחת גרמה ל-200 שיחות שונות, ובמקרה הטוב, ניתן היה להציג את הדף ב-200 x 150 אלפיות השנייה = 30 שניות. כמובן שזה לא היה טוב. מכפלת זמן פעולה של 99,9% ב-200, קיבלנו זמינות של 0%. מסתבר שהארכיטקטורה הזו נדונה לכישלון כבר מההתחלה.
שאלנו את המפתחים כיצד הם לא הצליחו לזהות את הבעיה הזו לאחר 18 חודשי עבודה? התברר שהם ספרו רק את ה-SLA עבור הקוד שהריצו, אבל אם השירות שלהם התקשר לשירות אחר, הם לא ספרו את הזמן הזה ב-SLA שלהם. כל מה שהושק בתוך תהליך אחד עמד על ערך של 150 אלפיות השנייה, אך גישה לתהליכי שירות אחרים הגדילה את העיכוב הכולל פי כמה. הלקח הראשון שנלמד היה: "האם אתה שולט ב-SLA שלך, או ש-SLA שולט בך?" במקרה שלנו, זה היה האחרון.
הדבר הבא שגילינו הוא שהם ידעו על הרעיון של תפיסות מוטעות מחשוב מבוזר, שנוסחו על ידי פיטר דייטש וג'יימס גוסלינג, אבל הם התעלמו מהחלק הראשון שלו. הוא קובע כי ההצהרות "הרשת אמינה", "אפס השהייה" ו"תפוקה אינסופית" הן תפיסות שגויות. תפיסות מוטעות אחרות כוללות את ההצהרות "הרשת מאובטחת", "הטופולוגיה לעולם לא משתנה", "תמיד יש רק מנהל אחד", "עלות העברת הנתונים היא אפס" ו"הרשת הומוגנית".
הם עשו טעות כי הם בדקו את השירות שלהם במכונות מקומיות ומעולם לא התחברו לשירותים חיצוניים. בפיתוח מקומי ושימוש במטמון מקומי, הם מעולם לא נתקלו בדילוגים ברשת. בכל 18 חודשי הפיתוח, הם מעולם לא תהו מה עלול לקרות אם שירותים חיצוניים יושפעו.
אם מסתכלים על גבולות השירות בתמונה הקודמת, אפשר לראות שכולם שגויים. יש המון מקורות המייעצים כיצד להגדיר גבולות שירות, ורובם עושים זאת לא נכון, כמו מיקרוסופט בשקף הבא.
תמונה זו היא מהבלוג של MS בנושא "איך לבנות מיקרו-שירותים". זה מציג יישום אינטרנט פשוט, בלוק של היגיון עסקי ומסד נתונים. הבקשה מגיעה ישירות, יש כנראה שרת אחד לרשת, שרת אחד לעסק ואחד לבסיס הנתונים. אם תגדיל את התנועה, התמונה תשתנה מעט.
כאן מגיע מאזן עומסים לחלוקת תעבורה בין שני שרתי אינטרנט, מטמון הממוקם בין שירות האינטרנט והלוגיקה העסקית, ומטמון נוסף בין ההיגיון העסקי למסד הנתונים. זו בדיוק הארכיטקטורה שבה השתמש Bell לאיזון העומס ויישום הפריסה הכחול/ירוק שלה באמצע שנות ה-2000. עד זמן מה הכל עבד היטב, שכן תוכנית זו נועדה למבנה מונוליטי.
התמונה הבאה מראה כיצד MS ממליצה לעבור ממונוליט למיקרו-שירותים - פשוט פיצלו כל אחד מהשירותים הראשיים למיקרו-שירותים נפרדים. במהלך יישום התוכנית הזו בל עשה טעות.
הם חילקו את כל השירותים שלהם לשכבות שונות, שכל אחת מהן מורכבת משירותים בודדים רבים. לדוגמא, שירות האינטרנט כלל שירותי מיקרו לעיבוד תוכן ואימות, שירות ההיגיון העסקי כלל משירותי מיקרו לעיבוד הזמנות ופרטי חשבון, בסיס הנתונים חולק לחבורה של מיקרו-שירותים עם נתונים מיוחדים. גם האינטרנט, ההיגיון העסקי וגם מסד הנתונים היו שירותים חסרי מדינה.
עם זאת, התמונה הזו הייתה שגויה לחלוטין מכיוון שהיא לא מיפתה אף יחידה עסקית מחוץ לאשכול ה-IT של החברה. תוכנית זו לא לקחה בחשבון שום קשר עם העולם החיצון, ולכן לא היה ברור כיצד, למשל, להשיג ניתוח עסקי של צד שלישי. אני מציין שהם גם הומצאו כמה שירותים פשוט כדי לפתח את הקריירה של עובדים בודדים שביקשו לנהל כמה שיותר אנשים כדי לקבל על זה יותר כסף.
הם האמינו שהמעבר לשירותי מיקרו היה קל כמו לקחת את תשתית השכבה הפיזית הפנימית שלהם ב-N-tier ולהדביק עליה את Docker. בואו נסתכל איך נראית ארכיטקטורת N-tier מסורתית.
הוא מורכב מ-4 רמות: רמת ממשק המשתמש, רמת הלוגיקה העסקית, רמת הגישה לנתונים ומסד הנתונים. מתקדמת יותר היא DDD (עיצוב מונחה תחום), או ארכיטקטורה מוכוונת תוכנה, כאשר שתי הרמות האמצעיות הן אובייקטי תחום ומאגר.
ניסיתי להסתכל על תחומי שינוי שונים, תחומי אחריות שונים בארכיטקטורה הזו. ביישום טיפוסי N-tier, אזורי שינוי שונים מסווגים המחלחלים למבנה בצורה אנכית מלמעלה למטה. אלו הן קטלוג, הגדרות תצורה שבוצעו במחשבים בודדים ובדיקות Checkout, שטופלו על ידי הצוות שלי.
הייחודיות של תכנית זו היא שגבולות תחומי השינוי הללו משפיעים לא רק על רמת ההיגיון העסקי, אלא גם משתרעים על מסד הנתונים.
בואו נסתכל מה זה אומר להיות שירות. ישנם 6 מאפיינים אופייניים להגדרת שירות - תוכנה היא ש:
- נוצר ומשתמש בארגון מסוים;
- אחראי לתוכן, עיבוד ו/או מסירת מידע מסוג מסוים בתוך המערכת;
- ניתן לבנות, לפרוס ולהפעיל באופן עצמאי כדי לענות על צרכים תפעוליים ספציפיים;
- מתקשר עם צרכנים ושירותים אחרים, מספק מידע המבוסס על הסכמים או ערבויות חוזיות;
- מגן על עצמו מפני גישה בלתי מורשית, ועל המידע שלו מפני אובדן;
- מטפל בתקלות באופן שלא יביאו לפגיעה במידע.
ניתן לבטא את כל המאפיינים הללו במילה אחת "אוטונומיה". השירותים פועלים ללא תלות זה בזה, עומדים בהגבלות מסוימות ומגדירים חוזים שעל בסיסם אנשים יכולים לקבל את המידע שהם צריכים. לא הזכרתי טכנולוגיות ספציפיות שהשימוש בהן מובן מאליו.
כעת נסתכל על ההגדרה של שירותי מיקרו:
- שירות מיקרו קטן בגודלו ונועד לפתור בעיה ספציפית אחת;
- שירות המיקרו הוא אוטונומי;
- בעת יצירת ארכיטקטורת שירות מיקרו, נעשה שימוש במטאפורת תכנון העיר. זו ההגדרה מספרו של סם ניומן, Building Microservices.
ההגדרה של Bounded Context לקוחה מספרו של אריק אוונס (Domain-Driven Design). זוהי דפוס ליבה ב-DDD, מרכז עיצוב אדריכלי שעובד עם מודלים אדריכליים נפחיים, מחלק אותם להקשרים מוגבלים שונים ומגדיר במפורש את האינטראקציות ביניהם.
במילים פשוטות, Bounded Context מציין את ההיקף שבו ניתן להשתמש במודול מסוים. בהקשר זה נמצא מודל מאוחד מבחינה לוגית שניתן לראות, למשל, בתחום העסקי שלך. אם תשאל "מי זה לקוח" לאנשי המעורבים בהזמנות, תקבל הגדרה אחת, אם תשאל את העוסקים במכירות, תקבל אחרת, והמבצעים יתנו לך הגדרה שלישית.
אז, Bounded Context אומר שאם אנחנו לא יכולים לתת הגדרה ברורה של מה זה צרכן של השירותים שלנו, בואו נגדיר את הגבולות שבתוכם נוכל לדבר על המשמעות של המונח הזה, ואז נגדיר את נקודות המעבר בין ההגדרות השונות הללו. כלומר, אם מדובר בלקוח מבחינת ביצוע הזמנות, זה אומר כך וכך, ואם מבחינת המכירות, זה אומר כך וכך.
ההגדרה הבאה של שירות מיקרו היא עטיפה של כל סוג של פעולות פנימיות, מניעת "דליפה" של מרכיבי תהליך העבודה לסביבה. לאחר מכן מגיעה "ההגדרה של חוזים מפורשים לאינטראקציות חיצוניות, או תקשורת חיצונית", המיוצגת על ידי הרעיון של חוזים שחוזרים מ-SLAs. ההגדרה האחרונה היא המטאפורה של תא, או תא, שמשמעותה עטיפה מלאה של קבוצת פעולות בתוך מיקרו-שירות ונוכחות בו של קולטנים לתקשורת עם העולם החיצון.
אז אמרנו לחבר'ה בבל מחשבים, "אנחנו לא יכולים לתקן אף אחד מהתוהו ובוהו שיצרתם כי פשוט אין לכם כסף לעשות את זה, אבל אנחנו נתקן רק שירות אחד כדי להפוך את הכל לָחוּשׁ." בשלב זה, אתחיל בלספר לכם כיצד תיקנו את השירות היחיד שלנו כך שהוא ענה לבקשות מהר יותר מ-9 וחצי דקות.
22:30 דקות
המשך בקרוב מאוד...
קצת פרסום
תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, , אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).
Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על
מקור: www.habr.com