מבוא לארכיטקטורת Micro services
מהי ארכיטקטורת מיקרו שירותים ?
ארכיטקטורת מיקרו שירותים היא ארכיטקטורה שבה בונים אפליקציה "גדולה"
שאמורה לתת מענה לשירותים רבים, מהמון אפליקציות קטנות.
כאשר כל אפליקציה קטנה כזו, מסוגלת לרוץ באופן עצמאי לחלוטין, היעד שלה
הוא לבצע משימות קטנות שקשורות בנושא יחיד.
את האפליקציות הקטנות האלו בונים ברמת תלות נמוכה מאד בין המודולים השונים של המערכת (צימוד רפוי) עד כמה שניתן.
הדבר דומה ליום שבו החלטתי להוציא דרכון חדש, אז נסעתי לבניין של משרד
הפנים,דמיינו לכם…בניין גדול עם המון שכבות (קומות).
כל קומה נותנת מענה לנושא כזה או אחר, למשל
הוצאת דרכון,
חידוש רישיון, רישום רך נולד, תשלום עבור
העברת כתובת מגורים ועוד.
אבל הכניסה לבניין הייתה סגורה, כי שלושה זקנים החליטו לריב שם מכות בטוטו 💥👴 וסגרו את כל הבניין! כעסתי, אבל לא רק אני, עוד עשרות אנשים שבאו בשביל לקבל שירותים נוספים שנמצאים בקומות השונות של הבניין.
אנשים כועסים זה תמיד דבר שמבשר רעות.
תארו לכם עכשיו, שהיו לוקחים כל קומה בבניין, ובונים עבורה, בניין שלם.
במצב כזה אם הבניין של חידוש רישיון היה נסגר, איך זה היה מפריע לי? עדיין הייתי יכול לגשת לבניין של הוצאת דרכון.
אז מיקרו שירותים זה בדיוק זה, לוקחים את האפליקציה המונוליטית (אפליקציה
מבוססת שכבות) ומפרקים אותה למיני אפליקציות.
לאפליקציות האלו יש את היכולת לעבוד בצורה עצמאית לגמרי, כך שבמידה
ואפליקציה אחת לא זמינה, שאר האפליקציות ממשיכות לתפקד!
לפני שנמשיך ונתעמק מה הם מיקרו שירותים ומהי אפליקציה מונוליטית, מה החסרונות והיתרונות של כל ארכיטקטורה, בואו נחזור קצת למקורות ונדבר רגע על שרת.
מה זה שרת?
שרת, הוא כל מחשב שמסוגל להריץ תוכנה שמהותה לקבל ולענות לבקשות שנשלחות ממחשבים אחרים.
זה לא הופך בפוטנציה כל מחשב עם אינטרנט לשרת ?
כן, כמעט כל מחשב שמחובר לאינטרנט יכול לשמש כשרת, אם נתקין את מערכת ההפעלה הנדרשת, התוכנות הנדרשות, נפתח פורטים במכשיר התקשורת שברשותינו כמו הראוטר, בעצם, כל מחשב יכול להפוך לשרת שמשרת מחשבים מכל קצוות העולם.
אז, המחשב שלנו יכול לשמש כשרת…המחשב של אבא יכול לשמש כשרת… (לא מומלץ אבא יגלה אבא יכעס). אפילו המחשבים המיושנים בספרייה של האוניברסיטה יכולים לשרת כשרתים, סתם אל תחשבו על זה אפילו זה אסור ואף לא חוקי להתקין תוכנות / שרתים על מחשבים של מוסדות המדינה ללא אישור.
אז, איזו שפות ישר קופצות לכם לראש שאתם מדמיינים שרת? נכון, ג'אווה סקריפט, סי שארפ, ג'אווה, פייתון.
בעשור האחרון גאווה סקריפט תפסה תאוצה לא רק בגלל שהיא השפה היחידה המאפשרת פיתוח בצד הקליינט, אלא כי גאווה סקריפט עברה שינוי מעניין והיא מסוגלת כיום לרוץ על סביבות שונות, ואף לתפקד כמו שרת בעזרה קטנה מצידו של nodeJS, משמע, אנחנו יכולים לכתוב אפליקציה אחורית שתרוץ על שרת מרוחק או לוקאלי ותשמש בתור הקוד שמקבל ועונה לבקשות שנשלחות לשרת.
בניית שרת באמצעות ארכיטקטורה מונוליטית
ארכיטקטורה מונוליטית היא ארכיטקטורה שבה אנחנו בונים את האפליקציה שלנו משכבות רבות, כל שכבה אמורה לטפל בנושא יחיד, ונקראת, "שירות" ( service ).
ככל שהאפליקציה גדלה כך באופן טבעי גם כמות השירותים שהיא מספקת.
את האפליקציה המונוליטית פורסים על גבי מחשב מרוחק, למה דווקא מחשב מרוחק? כי ישנם חסרונות ענקיים בהרמת שרת על המחשב הביתי שלנו, אז מה עושים?
משתמשים בשירותים של חברות ענק להשכרת משאבים כמו AWS של חברת אמזון או AZURE של חברת מייקרוסופט.
בואו נדמיין רגע, קוד מונוליטי שרץ על שרת:
קוד המסוגל לרשום משתמשים חדשים , להציג מוצרים בחנות ולהציג את היסטוריית הרכישות של המשתמש.
בואו נצפה בסרטון אנימציה, אשר תסביר איך אפליקציה מונוליטית מתפקדת כשורה
אז מה אנחנו רואים פה?
אנחנו רואים פה שרת שמריץ את האפליקציה המונוליטית שלנו, האפליקציה משתמשת בשירותים שונים כדי לענות על בקשות שהמשתמש שולח מהנייד שלו.
תחילה המשתמש לוחץ על כפתור מוצרים, נשלחת בקשה לשרת שלנו, השרת משתמש באפליקצית שרת שכתבנו בנוד או פייתון ווטאבר והאפליקציה משתמשת בשירות המתאים כדי לענות על הבקשה.
בדיוק אותו הדבר קורה כאשר המשתמש לוחץ על כפתור ששולח בקשה הקשורה לתשלומים.
בואו נצפה באנימציה נוספת שמתארת בעיה כלשהיא
מה אנחנו רואים בסרטון? אנחנו יכולים לראות שהמשתמש שולח בקשה שקשורה לשירות "מוצרים", כאשר הבקשה מגיעה לשרת ועוברת לאפליקציה שלנו, מרחשת שגיאה בשירות "מוצרים".
שגיאה כזו שלא מטופלת נכון, גורמת לנפילה של כל אפליקציית השרת, תנסו להזכר בדוגמה מתחילת המאמר על בניין יחיד שאם חוסמים את הכניסה לבניין, שום שירות בשום קומה לא נגיש יותר.
בשיא תמימותו המשתמש ממשיך ומנסה לגשת להיסטוריית הרכישות שלו, אבל בגלל שהשירות כשל, והפיל איתו את כל האפליקציה שרצה על השרת, למשתמש אין שום תשובה.
המצב הזה גורם להשבתה נרחבת של האפליקציה הקדמית (האפליקציה שמותקנת על המכשיר של המשתמש), או אתר האינטרנט שבו הוא גולש.
וזה בעצם אחד החסרונות הכי גדולים בבניה עם ארכיטקטורה מונוליטית,
החיסרון הזה נקרא
SPOF - Single Point Of Failure.
בעברית לא תקנית שמנו את כל הביצים בסל אחד!
בכל זאת מהם היתרונות של ארכיטקטורה מונוליטית?
- פשטות - יתרון בבניה של אפליקציה מונוליטית הוא שדיי פשוט לפתח אפליקציה שכזו, תהליך בניית הקוד הוא פשוט, תהליך הפיתוח גם הוא פשוט כי כל הקוד מרוכז במקום אחד.
- תחזוק - תחשבו על הדוגמה מתחילת המאמר, אם לקחנו כל קומה בבניין הגדול של משרד הפנים ובנינו בניין שלם עבורה, תארו לכם את כמות כוח האדם שצריך עבור כל בניין חדש! אותו דבר בתכנות, קל יותר לתחזק אפליקציה אחת.
- מהירות - לפעמים ולא תמיד אפליקציה מונוליטית יכולה להיות מהירה יותר בביצוע משימות מרובות שדורשות מספר גישות לדאטה בייסס שונים, אגרגציה של נתונים ועוד.
- בדיקות - פיתוח בדיקות הקצה נעשה בצורה קלה יותר, לרוב מדובר בשרת אחד שגם רוב הסיכויים יושב על אותו הדומיין,דבר אשר מקל את העבודה ביצירת הטסטים.
מהם החסרונות של ארכיטקטורה מונוליטית?
- סיבוך ומשקל הפרויקט - עם כמה שזה כיף לפתח ולראות את כל הקוד מול העיניים תמיד, זה גם חסרון מאוד גדול, באופן טבעי ככל שפרוייקט גדל ככה גם כמות השירותים שהוא אמור לספק.
- מורכבות - פרוייקט המכיל עשרות שירותים מביא איתו מורכבות עצומה, מה שיכול להוביל איטיות רבה בהמשך הפיתוח, הקושי לנהל את הפרויקט מכל המשתמע גדל משמעותית עם הזמן, אופן וקצב גדילת הקוד הינם אקספוננציאלים משמע ככל שהפרוייקט גדל ככה האיטיות תגמור אותנו.
- טעויות אנוש - אם מתרחש באג בשירות מסוים זה עלול להפיל את כל האפליקציה כולה, משמע אם מתכנת החליט לעדכן שירות מסוים שקשור אולי לרכישות, ונכנס באג לשירות הזה, אם הבאג מתרחש בזמן אמת כל האפליקציה וכל השירותים לא יהיו זמינים יותר.
- דיפלויי (פריסה) - פריסה חוזרת, כל פעם שמתכנתים החליטו לעדכן שירות מסויים,אם מדובר בעדכון גרסה או תיקון באג יהיה צורך מחודש לפרוס שוב את כל האפליקציה על השרת, זה לרוב קשוח יותר אם האפליקציה כוללת בתוכה גם את שכבת ה UI.
- איטיות בתהליך CI CD - איטיות בבניה, ככל שהאפליקציה גדלה כך גם תהליך הבנייה (build) של האפליקציה גדל.
- סקיילינג (הרחבת משאבים) - החיסרון אולי הכי בולט בבנייה של אפליקציה מונוליטית היא האי יכולת להרחיב משאב ספציפי, למשל אם יש עומס על השרת רק בגלל שירות מסויים אין לנו דרך להרחיב את המשאבים שלנו רק לשירות הספציפי הזה.
חזרה למיקרו שירותים!
המונח "מיקרו שירותים" הומצא איי שם בשנת 2005 לא חשוב שמות וגם לא מעניין האמת, אבל! המניע העיקרי היה לבזר את אפליקציית השרת המונוליטי הגדול והשמנמן להמון מיקרו אפליקציות קטנות ועצמאיות, שכל אחת מהן תהיה אחראית רק על נושא אחד (Single Responsibility Principle).
בין היתר לפתור את בעיית הדילוור האיטי, כי עכשיו, כאשר כל יחידה ניתנת לפריסה ולעדכון באופן כזה שלא דורש עדכון של יחידות אחרות, זה נותן את החופש לעדכן רק חלקים ספציפיים בתוך האפליקציה הגדולה שלנו, ובמהירות!
מניע נוסף ולא פחות חשוב הוא הסקיילינג, באפליקציה מונוליטית יש גבול להרחת המשאבים למחשב בודד, נמשיך לדון בזה מאוחר יותר.
בשורה התחתונה, כל שירות באפליקציה המונוליטית, הופך לאפליקציה מונוליטית בפני עצמה, בכך יש לנו בעצם המון אפליקציות קטנות ומבוזרות.
בואו נצפה בסרטון אנימציה שמדמה סנריו דומה עם מיקרו שירותים
מה אנחנו רואים כאן?
אנחנו רואים את אותו סנריו ממקודם, רק שבאפליקציה שבנויה ממיקרו שירותים, כאשר המשתמש נכשל לקבל נתונים משירות ה"מוצרים" הוא ממשיך ומנסה לקבל נתונים משירות ה"תשלומים" ומכיוון שהם מופרדים, שירותים התשלומים מחזיר נתונים ולכן האפליקציה של המשתמש ממשיכה לעבוד באופן חלקי, שזה אדיר.
תארו לכם נטפליקס, השירות של יצירת משתמש נוסף הפסיק לעבוד, ועכשיו אנחנו לא יכולים ליצור משתמש לאותו אח, שאוהב לקבל יוזרים בחינם, אבל...השירות שמאפשר צפייה בסרטים ממשיך לעבוד אז אנחנו שמים סרט ואומרים לאח הקרצייה, שיעשה מנוי לעצמו ויעזוב אותנו בשקט!
מה הם היתרונות של ארכיטקטורת מיקרו שירותים?
- זריזות בפיתוח - יותר מהר לעבוד על מקור קוד קטן, בבסיס של מאות שורות קוד ולא אלפי או עשרות אלפי שורות קוד כמו באפליקציה מונוליטית.
- מהירות שדרוג - מיקרו שירותים הביאו אותנו לעידן אחר לגמרי מבחינת יכולת עבודה מתמשכת, כל עניין ה continuous delivery בא לידי ביטוי בצורה מושלמת, תארו לכם צוות שלא תלוי בצוותים אחרים, הצוות יכול לשחרר עדכונים על בסיס יומי ואף מספר פעמים ביום, כאשר בעבר זה היה קורה פעם בשבוע או שבועיים כאשר היו "מחכים" לעדכון מספיק גדול כדי לעדכן בפעם אחת.
- טכנולוגיה - ההפרדה של מיקרו שירותים אחד מהשנייה, מאפשרת לראשי צוותים ולמנהלים את הנוחות לבחור שפות או טכנולוגיות שונות לפיתוח של שירותים שונים , זה אפשרי לגמרי לראות שירות אחד בשפת go ואחר בשפת python.
- המשכיות - מיקרו שירותים בנויים בצורה כזו שהם לגמרי מבוזרים ולא מודעים אחד על השנייה, הדבר עוזר מאד לצד המשתמש, כי האפליקציה בצד הקליינט יכולה להמשיך לעבודה גם אם מדובר בעבודה חלקית.
- הפרדת סמכויות - באפליקציה מונוליטית יכול להיות מצב שיש ל 100 מתכנתים גישה לאותו הקוד, מה שמגדיל באופן משמעותי את הסיכויים לבאגים חדשים, באפליקציה מבוססת מיקרו שירותים ישנו צוות קטן שעובד על כל שירות כל צוות מקבל גישה רק ל repository עליו הוא אחראי וכך נוצרת הפרדת סמכויות בין הצוותים השונים.
- סקיילינג - בגלל שכל שירות עובד בתור אפליקציה עצמאית לחלוטין, ניתן להגדיל את כמות החישובים והמשאבים רק עבור שירות זה,בהמשך המאמר נראה את הבדלי הסקיילינג שבין הארכיטקטורות.
מה הם החסרונות של ארכיטקטורת מיקרו שירותים?
- ניפוי שגיאות - הרבה יותר קל למצוא באג באפליקציה מונוליטית גדולה, כי כל השירותים נמצאים באותו מקום. לפעמים מציאת הבאג הוא עניין של הוספת debugger, במיקרו שירותים הרבה יותר קשה למצוא שגיאות כי השירותים מבוזרים וקשה לעקוב ולבדוק באיזה שירות נוצרה הבעיה שגרמה לבאג.
- עלויות - תארו לכם את המשאבים ש 20 בניינים דורשים לעומת בניין אחד, בשורה תחתונה, נדרשים יותר מתכנתים ודבאופס סופר מקצועיים כדי להרים מערכת מבוססת מיקרו שירותים, לכן באופן טבעי העלויות גדלות בארכיטקטורה זו.
- חוסר עקביות - באפליקציה מונוליטית קל יותר לעקוב אחרי דברים שקרו, אם זה רכישה של מוצר או יצירה של משתמש, הכל תחת אותו כנף הכל נעשה בצורה סינכרונית או אסינכרונית אבל במקום אחד. במיקרו שירותים, לפעמים הביזור נעשה על ידי ברוקרים של הודעות Kafka או SQS, כך שמאד קשה לעקוב אחרי שגיאות בארכיטקטורה הזו, באופן כללי, הנושא של חוסר עקביות קיים ודורש מחשבה מאומצת במגוון נושאים שהרבה יותר קל לפתור באפליקציה מונוליטית.
- פריסה - אם אתם חושבים שלפרוס מיקרו שירותים מסתכם בלגרור את התקייה של הפרוייקט לאיזה drag and drop של שירות כמו הירוקו וקאפיש, אז אתם טועים ובגדול, בשביל לפרוס מיקרו שרתים צריך לדעת סט כלים רחב ( infrastructure,kubernetes, containers, orchestration ועוד...) שלרוב מכירים רק אנשי devops בוגרים ומפותחים, ולא, סרטוני הודים ביוטיוב לא יעזרו.
סקיילינג (הרחבת משאבים)
בתצורה של מיקרו שירותים בהם כל שירות רץ על שרת בפני עצמו (או לפחות חלקיק שרת), אפשר להגדיל את המשאבים רק של אותו שירות, לרוב בתצורת מיקרו שירותים אפשר לעשות מה שנקרא horizontal scaling.
מה זה horizontal scaling? בשרת מונוליטי שפרוס על מחשב בודד, כדי לקבל יותר כוח נצטרך לבקש מחשב חזק יותר (vertical scaling), במיקרו שירותים אפשרי לבקש עוד יחידות קטנות של חומרה ולפרוס עליהן את אותה האפליקציה!
איך הדבר הזה נראה? הדוקטור הכין לכם אנימציה שתעזור לכם לזכור
מה אנחנו רואים פה? אנחנו רואים כמות של בקשות שהולכות וגדלות, השרת המונוליטי מגדיל את עצמו לשרת גדול יותר וחזק יותר וגדל בצורה אנכית. בעוד שהמיקרו שירות, פשוט מבקש עוד משאבים מאותו הסוג וגדל רוחבית, ומשכפל את הקוד שרץ גם למשאבים החדשים.
אבל איך יכול להיות שהבקשות שמגיעות יודעות לאיזה משאב לפנות?
בעזרת ה - software load balancer (שהיא תוכנה, שאף פעם לא תצטרכו לרשום בעצמכם), הבקשות מפוזרות לשכפולים השונים בצורה חכמה ויעילה, הלואד באלנסר מכיר ועוקב אחרי מצב הצריכה של כל משאב ויודע לפזר את הבקשות בצורה חכמה בניהם.
אומנם, ישנם משאבים מספיק חזקים בתור יחידה בודדה, למשל מחשב חזק שתוכלו
לרכוש ב AWS שמכיל 64 ליבות ו 128 גיגה זיכרון, אבל המשאב הזה עולה הון
תועפות.
מה אם נצטרך אפילו מחשב חזק יותר שאמזון לא יכולים להציע לנו? זהו אכלנו
אותה?
בגדילה רוחבית אנחנו לא צריכים בכלל מחשב חזק , הרי ש 50 יחידות עם 4
ליבות ו4 גיגה זיכרון חזקות יותר מהמחשב המפלצתי היחיד בעל 64 הליבות.
כך שגדילה רוחבית תמיד יעילה יותר מגדילה אנכית.
איזה בעיות נוספות יכולה להביא גדילה אנכית? בזמן שהמשאב משדרג את עצמו למשאב גדול יותר, יכולים להיות שיבושים למשתמשים לגשת למשאב שלנו. הדבר הזה לא קורה בגדילה רוחבית, כי בגדילה רוחבית תמיד יש משאבים זמינים, והלואד באלנסר יודע מתי לנתב את הבקשות למשאבים החדשים שנוצרים.
לסיכום
מיקרו שירותים היא התצורה החדשנית ביותר לפיתוח שרתים גדולים יציבים וחזקים, החברות הגדולות ביותר בעולם שמספקות תכנים כמו amazon או netflix, מפתחות כבר מזמן באמצעות מיקרו שירותים.
בשנים האחרונות, חברות רבות שיש להם אפליקציה מונוליטית שרצה על שרת עוברות לשימוש במיקרו שירותים, אחרי קריאת המאמר הדוקטור מקווה שהבנתם למה.
- אם אתם בונים תיק עבודות ראשוני או אם אתם מפתחים רעיון אבטיפוס.
- אם אתם סטרטאפ קטן שצריך קודם להוכיח שהמוצר שלו עובד! אל תבזבזו את ההשקעות הראשונות שלכם על לבנות תשתיות ולהכין את הקרקע למליוני משתמשים, תתפקסו בלהוכיח את הרעיון של המוצר, אם זה אומר אפליקציה מונוליטית, אז תבנו אותה בצורה שלאחר מכן יהיה קל לפרק אותה למיקרו שירותים.
מיקרו שירותים הם לא נושא פשוט ללמידה, אבל תהיו בטוחים שכל מראיין עתידי יתן לכם נקודות זכות רבות אם תוכיחו שאתם יודעים על מה מדובר.
הצטרפו לקהילות השונות ותרשמו לדוקטור איזה נושאים הכי בא לכם לקרוא עליהם, הדוקטור יעשה מאמץ להכין אנימציות מגניבות ומאמר או דוגמאות שיעזרו לכם לזכור את הנושא הזה שנים קדימה.
רוצים ייעוץ חינם מהדוקטור?
צרו איתי קשר לכל שאלה ואשמח לעזור!
לכל המעוניינים ללמוד תכנות
אני שמח להזמין אתכם להצטרף לקהילת הלומדים שלי, שם תוכלו ליהנות מהנחיה צמודה בלימודי תכנות ופיתוח, חומרי לימוד איכותיים, ועזרה הדדית של חברי הקהילה.
אל תהססו להצטרף ולקחת חלק - יחד נוכל לקדם את כישורי התכנות שלכם ולהגיע להישגים מרשימים! שאלות ובקשות נוספות יתקבלו בברכה.
