microservices- כאילו .. מה?

[TakeCtrl]

microservices- כאילו .. מה?

לאחרונה התחלתי לשמוע יותר ויותר על זה... ואיכשהו זה נראה לי כאילו fad-ware, או דרך להוציא כסף מאנשים ע"י הזמנת הרצאות...

"בואו נפריד את התוכנה שלנו לחלקים ברורים וקטנים שידברו אחד עם השני בעזרת ממשקים מוגדרים " ככה פחות או יותר זה נשמע לי... מהמעט שקראתי

timeout, לא קוראים לזה הנדסת תוכנה? לא היה לנו את זה כ-dcom או כ WF במיקרוסופט , rmi ב java או corba, או SOA, במה החידוש פה? שכל חלק יהיה כתוב בשפה אחרת וירוץ כ- process נפרד באותה מכונה? באמת לא הבנתי, כאילו דוחפים את זה כהדבר הגדול הבא..

ניסיתי אפילו לחפש תשתיות, או חבילות תוכנה שעוסקות בזה, אבל מלבד storm או spark, לא ראיתי הרבה כאלה, אבל לא ראיתי מקום מרכזי שמרכז רשימת תשתיות כאלה (אבל אני יודע שיש כאלה כגון consul)

 

[joblist]

דעה

אני חושב שעיקר הפואנטה היא צימצום תלויות ככל האפשר, עד רמת ה-persistance אפילו, ומצד שני כל יחידה נותנת מענה מלא ("ורטיקלי"), מה-DATA ועד ה-GUI.
המטרה היא לבנות אוסף של יחידות קטנות ואוטונומיות ככל האפשר, כי אז ה-scale נהיה הרבה יותר פשוט וקל לניהול. זה מתחבר עם טרנדים אחרים כמו 12 factor וכולי.
יש כאן גם משמעות ארגונית, כי מתכנת לא נדרש לדעת הרבה מעבר לגבולות ה-service שלו.
אני חושב שליאור בר און נתן על זה פוסט יפה כאן, כולל מה בעצם ההבדלים לעומת ה-buzz words הקודמים.
http://www.softwarearchiblog.com/2014/12/micro-services-architecture.html

 

[choo]

כל 2-3 שנים ממציאים את הגלגל מחדש

&nbsp
אם אתה מסתכל על זה לאורך זמן - יש תחומים שבהם זה מוביל לשיפור. יש תחומים שבהם זה מוביל להדרדרות

 

[user32]

באז שאין מאחוריו כמעט כלום

עוד דרך להעביר שעתיים הרצאה בכנס.
מצטרף לקודמיו: SOA, Web 2.0, ועוד ועוד.

במשפט אחד: אם התנאים מתאימים לכך תשתדל לפתח סרביסים עצמאיים שיכולים לרוץ ללא תלויות. שזה בטח מה שעשית לפני 15 שנה וכנראה נמשיך לעשות את זה גם בעוד 20 שנה.

 

[TakeCtrl]

most.depressing.statement.ever

אבל לפני 15 שנה עבדתי במג'יק ..

 

[Grosseto]

ככה אני עובד

שכבת UI , שכבה לוגית, שכבה של DB
הכל בעזרת ממשקי IDL
&nbsp
ככה אם מחליפים DB או UI ההחלפה נעשית בצורה נקייה.
הבעיה היא שיש הרבה חאפרים שלא עובדים בצורה כזאת, אפילו משתמשים במונובוקס רחמנא לצנן

 

[טרול המתכנן]

נשמע שבאמת לא הבנת.

הרעיון הוא להפריד רכיבי מערכת לקומפוננטות ש*אינן* תלויות בשפת תכנות או מ"ה.
אמרת "process נפרד באותה מכונה"? אולי כן תלך לקורס.
המבנה הזה מיועד להיות מבוזר.
האם היה לנו off the shelf distrubuted, persistent, job Q or pub/sub לפני 20 שנה?
האם אתה יודע לבנות מערכת מבוזרת שהיא לחלוטין stateless, במובן ש-node יכול להתרסק לך באמצע אופרציה וה-flow ימשיך כאילו כלום, בעזרת אחת הטכנולוגיות שהזכרת למעלה? אני לא.

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

אני לא אומר שזה חדש או טוב, אבל להכיר לא מזיק.

 

[TakeCtrl]

אבל , להכיר מה , בדיוק?

מאמרים שמדברים על webserver מדגימים את IIS, apache , מאמרים שמדברים על SOA מדברים biztalk ודומיו, אלו שמדברים על ORM מדגימים hibernate, אלה שעל webservices מדגימים על axis ו .net services...
&nbsp
רכיבי קומפוננטות שאינן תלויות במ"ה כבר קיימים בשפות שאינן תלויות במ"ה, אני לא בטוח עד כמה זה טוב לחברה לכתוב כל קומפננטה בשפה תכנות חדשה, כי אם כל הכבוד אפילו אם אתה מסוגל ללמוד שפה חדשה מהר, זה עדיין עקומת לימוד, וחברי צוות לא יכולים לדבר עם אחרים כל כך טוב, אתה מאבד את היכולת לנייד אנשים בין צוותים.
&nbsp
כל פעם שאני רואה מאמר microservices זה מסתכם בערימה של ציורי קוביות וקווים אין משהו מוחשי מאחוריהם, איזה application stack או אפילו כמה מהם שיכולים להדגים את זה. בסוף או באמצע מאמרים אני רגיל לראות קישורים למספר תשתיות מאותו הסוג שאני יכול לקרוא עליהם ולראות תבנית מתגבשת, פה אני נשאר עם הלשון בחוץ...

 

[טרול המתכנן]

אז אתה כבר מכיר. עכשיו אתה חופשי לבחור ולא מתוך בורות.

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

אבל אתה ממשיך לזרוק שמות של "דברים" שאין להם שום קשר לנושא. apache או IIS הם שרתים. מה הקשר לשרתים? אין.

 

[TakeCtrl]

התכוונתי לשרתים מבחינת התפקוד שלהם...

נגיד הייתי רוצה לכתוב מאמר על CGI, או דפי script כגון ASP או PHP, עם עצם זה המושג והעיקרון ששרת יכול לבצע דפים באופן דינמי הייתי מביא אותם בתור דוגמא.. אין להם קשר ישיר לנושא הזה, אבל הם סוג מסויים של תוכנה, תבנית, שאפשר להביא אותם בתור הפנייה מוחשית למה שמאמר מדבר. ודברים כאלה לא ראיתי עד עכשיו במאמרים,
&nbsp
לא סתם אמרתי על consul, זה משהו שרץ במוצר של שותף שאנחנו עובדים איתו שמבוסס על תשתיות microservices, אבל למה אותו, ומה יכול להיות מקביל אליו? אילו היו מאמרים שמדברים של שורת תשתיות כאלה ואיך משלבים אותם ביחד, זה היה עושה הרבה יותר שכל.

 

[טרול המתכנן]

מה זה "אילו היו מאמרים"? כל ייצור שיש לו scale משמעותי...

Netflix, twitter, paypal, uber...

לגבי פרטי מימוש, מבחינתי מעבר לתור אין פרטי מימוש. יש הרבה תורים:
kafka, rabbit, sqs, redis.

 

[TakeCtrl]

אבל microservices הם יותר מתורים...

ו redis מגדיר את עצמו כ"data structure store" משהו כמו database מאשר תור..

 

[טרול המתכנן]

שאלת מה ההבדל בין X ל-Y.

ההבדל הוא שב-X היה לנו שרת, והיית קורא ל"שירותים" שונים דרך ה"שרת".

ב-Y אין, או יכול שלא להיות, "שרת", ואין, או יכול שלא להיות, צורך לקרוא באופן ישיר ל"שירותים".
ב-Y יש, או יכול להיות, "תור", ויש, או יכולים להיות, "צרכנים" ש"נרשמים" להאזנה על התור.
זהו. כן זה ה TLDR של כל המאמרים והקורסים בנושא.

 

[eveik]

אתה מפספס מה זה..

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

 

[TakeCtrl]

גם SOA זה ארכיטקטורה. גם שם רצים אפילקציות על מכונות שונות.

בשפות שונות ומתקשרות דרך ממשקים סטנדרטים, בשבילי עד עכשיו microservices אומר קח אותו הדבר כמו בsoa , רק תכתוב את זה יותר בקטן, במקום לכתוב אפליקציה , תכתוב סט של פונקנצליות שירוצו על מכונות שונות,, את זה תארוטית שנינו היינו יכולים לעשות לפני 5 שנים.
הבעיה שהיא היו עוצרים אותנו על המקום מכמה סיבות הראשונה היא הoverhead שהיה נוצר בתקשורת rest או יותר גרוע בsoap, השנייה היא שכל כזה service צריך לרוץ בשרת, להקים war (במקרה של java) שלם לסט קטן מאוד של תפקודים , או יותר גרוע להקים שרת שלם באותה מכונה (ולפתור התנגשויות בין port) הוא overkil לגמרי וש j2ee לא מתאים לזה. מצד שני זה לא לעניין לכתוב לעצמך שרת קטן מחדש כל פעם, אז משהוא השתנה בדרך, נוצרו כלים שהם Lightweight להריץ שירותים ונוצרו תשתיות תקשורת בינהם וניהול תורים ואולי כותבים אליהם במאמרים נפרדים, אבל הייתי מצפה שכמו שמאמר על SOA היה מספר לי על Biztalk או על OpenEsb ככלי עזר למימוש שמאמר על Microservices היה מזכיר דברים מקבילים לזה.

 

[eveik]

אם אתה לוקח את זה ל Microservices vs SOA

אז כן - אני לא חושב שיש המון הבדלים, ואתה מוזמן לקרוא מאמרים שדנים בדיוק בזה בשביל הדקויות.
&nbsp
כל מה שציינת לגבי איך להקים סרוויס, או שכמה סרוויסים ירוצו על אותה מכונה (והטענה שלך שj2ee לא מתאים לזה) - זה בדיוק הסיבה למה המאמרים האלה נשארים תיאורטיים. את אף אחד לא מעניין המגבלות של ג׳אווה או j2ee - מדברים פה על ארכיטקטורה כללית. בג׳אווה יש בעיות מסויימות, ובעולם שלי (רובי/ריילס) הן בכלל לא רלוונטיות, אז למה שיהיה אכפת לי לקרוא במאמר כללי על מיקרוסרוויסים למה j2ee לא מתאים להריץ כמה סרוויסים על פורטים שונים?
&nbsp
אני משוכנע שאם תנסה לחפש micro services implementation in x תתחיל לקבל תשובות קצת יותר ברורות לגבי העולם הספציפי שאתה מדבר עליו. בעולם שלי אין שום בעיה להריץ 5 סרוויסים על שרת אחד, כשכל אחד רץ בפורט שלו, ושוקל 200 מגה (אני סתם זורק, המספרים משתנים כמובן).
&nbsp
לגבי זה שיש המון overhead בהקמה של שירותים חדשים - כן, וזה אחת הבעיות עם סרוויסים. ברגע שמקימים מספיק תשתיות - זה הופך להיות יחסית קל, הבעיה היא שלהקים את כל התשתיות האלו לוקח המון זמן (והאם זה בסוף שווה את זה? שאלה טובה).
&nbsp
דוגמאות? צריך template לכתוב סרוויס חדש, אפשרות לעבור בין גירסאות של סרוויסים, דרך נוחה ומהירה להרים שרת/סרוויס על שרת, דרך קלה להודיע לסרוויסים אחרים על הסרוויס החדש, להוסיף תשתית לmessaging אם צריך, ובעיקר המון מוניטורינג על הסרוויסים (כמה רצים, איפה, כמה בקשות הם מקבלים, response time ממוצע וכו׳).
&nbsp
אישית, ובלי להיכנס כרגע להאם זה חדשני או לא, בהשוואה ישירה של microservice vs monolith אני מעדיף מיקרוסרוויס (לפחות בטווח הארוך - לסטארט אפ חדש זאת בחירה גרועה), אבל צריך להשקיע המון מאמץ בשביל שזה באמת ייעשה בצורה טובה ויפה. כמו שuser32 כבר ציין - נורא קל לעשות לזה massive abuse ולהגיע למאות/אלפי סרוויסים - וברור ששם זה מתיש/מיותר/לא נכון. מצד שני - אפשר להגיד על כל דבר שאפשר לעשות לו massive abuse ולהגיע לתוצאות נוראיות לאחר מספיק זמן (וקוד), אז אני באמת מאמין שבסופו של דבר זה מה שחשוב זה האנשים שאחראים על הדברים האלו. אנשים טובים ידעו (בהינתן מספיק זמן וניסיון) איך לעשות את זה כמו שצריך (ו״כמו שצריך״ גם משתנה עם הזמן כי צרכי החברה משתנים), ואנשים שלא ממש יודעים מה הם עושים או שלא אכפת להם מה עושים - יימצאו את עצמם בבוץ רציני (ואז אולי מגיע השלב של ״בוא נכתוב הכל מחדש״).

 

[user32]

J2EE בעייתי במימוש של מיקרו סרביסים

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

כשאני כותב מיקרו סרביסים זה בnode.js, פיתון או רובי. שפות שמאפשרות כתיבה של מודול בצורת סקריפט עם 3 שורות קוד, מאפשרים הרצה של שרתים בפחות משניה ובלי כל הסרבול של JEE. אלה פשוט כלים שנועדו לדברים שונים.
היו נסיונות של JEE לעשות מיקרו קונטיינרים ולאפשר להריץ שרתים מהירים (יחסית...) עם שירותים שונים, נדמה לי JBOSS יצאו עם זה. לא יודע אם זה תפס, אני לא ראיתי את זה באף מקום.

 

[eveik]

יופי, אז עכשיו אנחנו מתקדמים

node.js, פייתון ורובי זה השמות שאני גם רגיל לשמוע. לפעמים אני גם שומע דברים יותר סקסיים כמו scala/go ואני מניח שיש עוד כמה חברים בעולם הזה וחברים שיצטרפו בהמשך.
&nbsp
אני לגמרי מקבל את זה שj2ee נועד למשהו אחר ואני בטוח שעבור אפליקציות מסויימות הוא מאוד טוב/נח. בסך הכל ניסיתי להגיד שלדעתי זאת הסיבה (או אחת מהן) למה מדברים בצורה כללית בנושא הזה ולא על מימוש ספציפי. המימוש (או בעיה ספציפית של שפה/פריימוורק כזה או אחר) לא רלוונטי בסקופ הרחב של הנושא עצמו.
&nbsp
לא ידעתי שאתה עושה גם רובי, נחמד.

 

[zaske]

spring boot

מחלקה אחת שהיא ה main שלך לצורך העניין עם האנוטציה שאומרת שזו אפליקציה של spring boot ואיפה לעשות component scanning .
מחלקות אחרות עם אנוטציות של RestController על המחלקה, ואנוטציות של באיזה HTTP method מתודה במחלקה מטפלת.

והכי הוקוס פוקוס? data repositories , האינטגרציה עם מונגו מדהימה -

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

ה"מסמך" ממופה בצורה שמזכירה את המיפוי של hiberntate לאובייקטים

אם הקוד של ההקאת'ון שלי לא היה כזה מחורבן עם כאלה האקים הייתי פותח את ה repo ומראה לכם

 

[user32]

אח אח, הדברים שאני מנסה לשכוח ולהדחיק

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

אבל מה שכתבת עם Spring boot נשמע הגיוני ומאוד ספרינגי. זו חלופה טובה לSpring MVC Rest שזה הדבר האחרון שעשיתי בספרינג וגרר איתו את הסירבול של Servlet container על כל המשתמע.