ג'וש אוונס מדבר על העולם הכאוטי והצבעוני של שירותי המיקרו של נטפליקס, החל מהיסודות מאוד - האנטומיה של שירותי המיקרו, האתגרים הקשורים למערכות מבוזרות והיתרונות שלהם. בהתבסס על בסיס זה, הוא בוחן את הפרקטיקות התרבותיות, האדריכליות והתפעוליות המובילות לשליטה בשירותי מיקרו.
בניגוד לסחף תפעולי, הכנסת שפות חדשות לבינאום שירותים וטכנולוגיות חדשות כגון קונטיינרים הן החלטות מודעת להוסיף מורכבות חדשה לסביבה. צוות התפעול שלי תקן את מפת הדרכים הטכנולוגית הטובה ביותר עבור נטפליקס, שנאפה בשיטות מומלצות מוגדרות מראש המבוססות על Java ו-EC2, אך ככל שהעסק גדל, מפתחים החלו להוסיף רכיבים חדשים כמו Python, Ruby, Node-JS ו-Docker.
אני מאוד גאה שהיינו הראשונים שדגלנו שהמוצר שלנו יעבוד מצוין בלי לחכות לתלונות של לקוחות. הכל התחיל מספיק פשוט - היו לנו תוכניות הפעלה ב-Python וכמה יישומי משרד אחורי ברובי, אבל הדברים נעשו הרבה יותר מעניינים כשמפתחי האינטרנט שלנו הודיעו שהם עומדים לבטל את ה-JVM ומתכוונים להעביר את האינטרנט יישום לפלטפורמת התוכנה Node. js. לאחר הצגתו של Docker, הדברים נעשו הרבה יותר מורכבים. פעלנו לפי ההיגיון והטכנולוגיות שהמצאנו הפכו למציאות כשהטמענו אותן עבור לקוחות כי הן היו הגיוניות מאוד. אני אגיד לך למה זה כך.
API Gateway למעשה יש את היכולת לשלב סקריפטים מצוינים שיכולים לשמש כנקודות קצה עבור מפתחי ממשק משתמש. הם המירו כל אחד מהסקריפטים הללו בצורה כזו שלאחר ביצוע שינויים הם יכלו לפרוס אותם לייצור ולאחר מכן למכשירי משתמש, וכל השינויים הללו סונכרנו עם נקודות קצה שרצו בשער ה-API.
עם זאת, זה חזר על הבעיה של יצירת מונוליט חדש שבו שירות ה-API היה עמוס בקוד בצורה כזו שהתרחשו תרחישי כשל שונים. לדוגמה, כמה נקודות קצה הוסרו, או שסקריפטים יצרו באופן אקראי כל כך הרבה גרסאות של משהו שהגרסאות תפסו את כל הזיכרון הזמין של שירות ה-API.
זה היה הגיוני לקחת את נקודות הקצה הללו ולשלוף אותן משירות ה-API. לשם כך, יצרנו רכיבי Node.js שפעלו כאפליקציות קטנות בקונטיינרים של Docker. זה איפשר לנו לבודד כל בעיות וקריסות שנגרמו על ידי יישומי צומת אלה.
העלות של שינויים אלה היא די גדולה והיא מורכבת מהגורמים הבאים:
- כלי פרודוקטיביות. ניהול טכנולוגיות חדשות דרש כלים חדשים מכיוון שצוות ה-UI, שמשתמש בסקריפטים טובים מאוד ליצירת מודל יעיל, לא היה צריך להשקיע זמן רב בניהול התשתית, הם היו צריכים רק לכתוב סקריפטים ולבדוק את הפונקציונליות שלהם.
תובנה ומיון הזדמנויות - דוגמה מרכזית היא הכלים החדשים הדרושים כדי לחשוף מידע על מנהלי ביצועים. היה צורך לדעת כמה המעבד תפוס, כיצד נעשה שימוש בזיכרון, ואיסוף המידע הזה דרש כלים שונים. - פיצול של תמונות בסיס – ה-AMI הבסיסי הפשוט הפך למפוצל ומתמחה יותר.
- ניהול צמתים. אין ארכיטקטורת מדף או טכנולוגיה זמינה המאפשרת לנהל צמתים בענן, ולכן בנינו את Titus, פלטפורמת ניהול קונטיינרים המספקת פריסת קונטיינרים מדרגית ואמינה ושילוב ענן עם Amazon AWS.
- שכפול של ספרייה או פלטפורמה. אספקת טכנולוגיות חדשות עם אותה פונקציונליות ליבה של הפלטפורמה דרשה שכפול שלה לכלי מפתחים מבוססי ענן של Node.js.
- עקומת למידה וניסיון תעשייתי. הכנסת טכנולוגיות חדשות יוצרת בהכרח אתגרים חדשים שיש להתגבר עליהם וללמוד מהם.
לפיכך, לא יכולנו להגביל את עצמנו ל"כביש סלול" אחד והיינו צריכים לבנות כל הזמן דרכים חדשות לקידום הטכנולוגיות שלנו. כדי להוזיל עלויות, הגבלנו את התמיכה הריכוזית והתמקדנו ב-JVM, בצמתים חדשים וב-Docker. תעדפנו השפעה אפקטיבית, עדכנו את הצוותים לגבי עלות ההחלטות שלהם ועודדנו אותם לחפש דרכים לעשות שימוש חוזר בפתרונות רבי ההשפעה שהם כבר פיתחו. השתמשנו בגישה זו בעת תרגום השירות לשפות זרות כדי לספק את המוצר ללקוחות בינלאומיים. דוגמאות כוללות ספריות לקוח פשוטות יחסית שניתן ליצור באופן אוטומטי, כך שקל למדי ליצור גרסת Python, גרסת Ruby, גרסת Java וכו'.
חיפשנו כל הזמן הזדמנויות להשתמש בטכנולוגיות מוכחות שהוכיחו את עצמן במקום אחד ובמצבים דומים אחרים.
בואו נדבר על האלמנט האחרון - שינויים, או וריאציות. תראו איך הצריכה של המוצר שלנו משתנה באופן לא אחיד לפי יום בשבוע ולפי שעה לאורך היום. אפשר לומר ששעה 9 בבוקר היא הזמן הקשה ביותר עבור נטפליקס, כשהעומס על המערכת מגיע למקסימום.
כיצד נוכל להגיע למהירות גבוהה של הטמעה של חידושי תוכנה, כלומר לבצע כל הזמן שינויים חדשים במערכת, מבלי לגרום להפרעות במתן השירות ומבלי ליצור אי נוחות ללקוחותינו? נטפליקס השיגה זאת באמצעות שימוש ב- Spinnaker, פלטפורמת ניהול עולמית מבוססת ענן ואספקה רציפה (CD).
באופן קריטי, Spinnaker תוכנן לשלב את השיטות המומלצות שלנו, כך שכאשר אנו פורסים רכיבים לייצור, נוכל לשלב את הפלט ישירות בטכנולוגיית אספקת המדיה שלנו.
הצלחנו לשלב שתי טכנולוגיות בצנרת האספקה שלנו שאנו מעריכים מאוד: ניתוח קנרי אוטומטי ופריסה מדורגת. ניתוח קנרי אומר שאנו מפנים טפטוף של תעבורה לגרסה החדשה של הקוד, ומעבירים את שאר תעבורת הייצור דרך הגרסה הישנה. לאחר מכן אנו בודקים כיצד הקוד החדש מתמודד עם המשימה - טוב יותר או גרוע יותר מהקיים.
השקה מדורגת פירושה שאם יש בעיות בהשקה באזור אחד, אנו עוברים להשקה באזור אחר. במקרה זה, יש לכלול בצנרת הייצור את רשימת הבדיקה הנ"ל. אני אחסוך לך קצת זמן ואמליץ לך לבדוק את ההרצאה הקודמת שלי, הנדסת נטפליקס גלובלית בענן, אם אתה מעוניין לצלול עמוק יותר לתוך הנושא הזה. את הקלטת הווידאו של הנאום ניתן לצפות בקישור בתחתית השקף.
בסוף השיחה אדבר בקצרה על הארגון והארכיטקטורה של נטפליקס. ממש בהתחלה הייתה לנו תוכנית בשם Electronic Delivery, שהייתה הגרסה הראשונה של הזרמת מדיה NRDP 1.x. ניתן להשתמש במונח "בקסטרים" כאן מכיוון שבתחילה המשתמש יכול היה להוריד תוכן רק להשמעה מאוחרת יותר במכשיר. פלטפורמת המסירה הדיגיטלית הראשונה של נטפליקס, בשנת 2009, נראתה בערך כך.
מכשיר המשתמש הכיל את אפליקציית Netflix, שהורכבה ממשק ממשק משתמש, מודולי אבטחה, הפעלת שירות והשמעה, המבוססת על פלטפורמת NRDP - Netflix Ready Device Platform.
באותה תקופה ממשק המשתמש היה פשוט מאוד. הוא הכיל את מה שנקרא Queque Reader, והמשתמש היה עובר לאתר כדי להוסיף משהו ל-Queque ולאחר מכן להציג את התוכן שנוסף במכשיר שלו. החיובי היה שצוות הקצה הקדמי וצוות הקצה האחורי השתייכו לאותו ארגון משלוח אלקטרוני והיו להם יחסי עבודה הדוקים. המטען נוצר על בסיס XML. במקביל, נוצר ממשק ה-API של Netflix עבור עסקי ה-DVD, שעודד יישומי צד שלישי להפנות תנועה לשירות שלנו.
עם זאת, ה-API של Netflix היה מוכן היטב לעזור לנו עם ממשק משתמש חדשני, המכיל מטא נתונים של כל התוכן, מידע על הסרטים הזמינים, מה שיצר את היכולת ליצור רשימות צפייה. היה לו REST API גנרי המבוסס על סכימת JSON, HTTP Response Code, אותו קוד המשמש בארכיטקטורה מודרנית, ומודל אבטחה OAuth, שהיה מה שנדרש באותה תקופה עבור יישום חזיתי. זה איפשר לעבור ממודל ציבורי של אספקת תוכן זורמת למודל פרטי.
הבעיה במעבר הייתה פרגמנטציה, שכן כעת המערכת שלנו הפעילה שני שירותים המבוססים על עקרונות פעולה שונים לחלוטין – האחד על Rest, JSON ו-OAuth, השני על RPC, XML ומנגנון אבטחת משתמש המבוסס על מערכת האסימון NTBA. זו הייתה הארכיטקטורה ההיברידית הראשונה.
בעצם הייתה חומת אש בין שני הצוותים שלנו מכיוון שבתחילה ה-API לא התרחב היטב עם NCCP וזה הוביל לחיכוכים בין הצוותים. ההבדלים היו בשירותים, פרוטוקולים, מעגלים, מודולי אבטחה, ולעתים קרובות מפתחים נאלצו לעבור בין הקשרים שונים לחלוטין.
בעניין זה, שוחחתי עם אחד מבכירי המהנדסים של החברה, אליו שאלתי את השאלה: "מה צריכה להיות האדריכלות הנכונה לטווח ארוך?" והוא שאל את השאלה הנגדית: "אתה כנראה מודאג יותר. לגבי ההשלכות הארגוניות - מה קורה אם נשלב את הדברים האלה, והם שוברים את מה שלמדנו לעשות טוב? גישה זו רלוונטית מאוד לחוק קונווי: "ארגונים שמתכננים מערכות מוגבלות על ידי עיצוב המשכפל את מבנה התקשורת של אותו ארגון". זו הגדרה מאוד מופשטת, אז אני מעדיף הגדרה יותר ספציפית: "כל פיסת תוכנה משקפת את המבנה הארגוני שיצר אותה." הנה הציטוט האהוב עלי מאריק ריימונד: "אם יש לך ארבעה צוותים של מפתחים שעובדים על מהדר, בסופו של דבר יהיה לך מהדר של ארבעה מעברים." ובכן, לנטפליקס יש מהדר לארבעה מעברים, וככה אנחנו עובדים.
אנו יכולים לומר שבמקרה זה הזנב מכשכש בכלב. העדיפות הראשונה שלנו היא לא הפתרון, אלא הארגון; הארגון הוא שמניע את הארכיטקטורה שיש לנו. בהדרגה, ממכלול שירותים, עברנו לארכיטקטורה שקראנו לה Blade Runner, כי כאן אנחנו מדברים על שירותי קצה והיכולת של NCCP להיות מופרדים ומשולבים ישירות ב-Zul proxy, API gateway והפונקציונלי המקביל "חתיכות" הפכו לשירותי מיקרו חדשים עם תכונות אבטחה מתקדמות יותר, שידור חוזר, מיון נתונים וכו'.
לפיכך, ניתן לומר שמבנים מחלקים ודינמיקה של החברה ממלאים תפקיד חשוב בעיצוב תכנון המערכת ומהווים גורם המקדם או מעכב שינוי. ארכיטקטורת Microservices מורכבת ואורגנית, והבריאות שלה מבוססת על משמעת וכאוס שהוצג.
קצת פרסום
תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, , אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: (זמין עם 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