מדריך ל-Java Microservices. חלק 2: פריסה ובדיקה

תרגום והתאמה של Java Microservices: מדריך מעשי . קישור לחלק הראשון של המדריך . כל תוכנית Java בצד השרת, ולפיכך כל שירות מיקרו, הוא רק קובץ עם סיומת .jar או .war. יש דבר אחד נהדר במערכת האקולוגית של Java, או ליתר דיוק ה-JVM: אתה צריך לכתוב רק קוד Java פעם אחת והוא יכול לפעול כמעט על כל מערכת הפעלה, כל עוד לא הידור הקוד שלך עם גרסה חדשה יותר של Java מאשר שלך גרסת יעד JVM. חשוב להבין זאת, במיוחד כשמדובר בנושאים כמו Docker, Kubernetes או (תופים!) הענן. למה? בואו נסתכל על תרחישי פריסה שונים.

דוגמה לפריסת Java Microservice מינימליסטית

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

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

שְׁנִיָה:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

זה משאיר את השאלה פתוחה: כיצד יגיעו קבצי ה-.properties ו-.jar לשרת? למרבה הצער, עשויות להיות תשובות רבות.

כיצד להשתמש בכלי Build, SSH ו-Ansible לפריסת שירותי Java Microservices

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

• כלי הבנייה המועדף עליך (Maven, Gradle)
• SSH/SCP ישן וטוב להעתקת .jars לשרתים
• סקריפטים Bash לניהול סקריפטים ושרתים של פריסה
• או אפילו טוב יותר: כמה סקריפטים של Ansible.

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

כיצד להשתמש ב-Docker לפריסת Java Microservices

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

• מיכל (פשוט) דומה למכונה הוירטואלית הישנה והטובה, אבל "קל יותר". אם לא ברור לך מה המשמעות של "קל יותר" בהקשר הזה, אנא בדוק את התשובה הזו ב-Stackoverflow .
• המכולה מבטיחה ניידות משלה. כלומר, זה עובד בכל מקום. נשמע מוכר, לא?

זה מצחיק שלאור הניידות והתאימות לאחור של ה-JVM, התכונה הזו לא נראית כמו יתרון כזה. אתה יכול פשוט להוריד את JVM.zip בכל Raspberry Pi (או אפילו טלפון נייד), לחלץ אותו ולהפעיל כל קובץ jar. המצב משתנה בשפות כמו PHP או Python, שבהן אי תאימות גרסאות או הגדרות פריסה מורכבות יותר. או אם אפליקציית Java שלך תלויה בשירותים מותקנים רבים אחרים (עם מספרי הגרסה הנכונים): לדוגמה, מסד נתונים Postgres, או מאגר ערכי מפתח Redis. אז, היתרון העיקרי של Docker for Java microservices, או ליתר דיוק עבור יישומי Java, הוא זה: היכולת להגדיר סביבות בדיקות הומוגניות או אינטגרציה באמצעות כלים כמו Testcontainers . פיתוחים מורכבים קלים יותר להתקנה. קח תוכנת פורום שיח . אתה יכול להתקין אותו עם תמונת Docker אחת, וזו מכילה את כל מה שאתה צריך, מתוכנת Discourse שנכתבה ברובי, דרך מסד נתונים Postgres ועד Redis וכיור המטבח. אם הפריסות שלך דומות או שאתה רוצה להפעיל מסד נתונים קטן של Oracle, נסה את Docker. אז לסיכום, במקום להסתכל רק על קובץ ה-.jar, אתה עכשיו:

• אגד את קובץ ה-jar שלך לתמונת Docker
• דחוף תמונה זו לרישום דוקר פרטי
• משוך והפעל את התמונה הזו על פלטפורמת היעד שלך
• או העתק את תמונת Docker ישירות למערכת הייצור שלך והפעל אותה.

כיצד להשתמש ב-Docker Swarm או Kubernetes כדי לפרוס שירותי Java Microservices

נניח שהחלטת לנסות את Docker. בכל פעם שאתה פורס מיקרו-שירות Java, אתה יוצר תמונת Docker המאגדת את קובץ ה-.jar שלך. נניח שיש לך כמה משירותי המיקרו האלה של Java, ואתה רוצה לפרוס את השירותים האלה במספר מחשבים (באשכול). נשאלת השאלה: איך לנהל את האשכול הזה? להפעיל קונטיינרים של Docker, לבדוק ביצועים, לפרוס עדכונים, לשנות את קנה המידה של המערכת (brrr)? שתי תשובות אפשריות לשאלה זו הן Docker Swarm ו-Kubernetes. פירוט של שתי האפשרויות יהפוך את המדריך הארוך הזה כבר ארוך מדי, אבל אנחנו חושבים שחשוב להזכיר ששתי האפשרויות מסתמכות בסופו של דבר על כך שאתה כותב קבצי YAML (ראה סיפורי הזחה של Yaml ) כדי לנהל את האשכול שלך. אם אתה רוצה לדעת איך זה גורם לך להרגיש בפועל, פשוט הקלד שאילתה דומה בחיפוש בטוויטר. אז תהליך הפריסה עבור שירותי המיקרו של Java שלך נראה כעת בערך כך:

• הגדרה וניהול של Docker Swarm/Kubernetes
• כל השלבים עבור Docker (ראה למעלה)
• כתוב והפעל YAML עד שהעיניים שלך מדממות עד שהכל יעבוד.

כיצד לבדוק Java Microservices

נניח שאתה מחליט ליישם שירותי מיקרו בייצור. כיצד נוכל לבדוק אינטגרציה של n-microservices במהלך הפיתוח כעת? איך אתה יכול לראות אם זרימת העבודה כולה עובדת, ולא רק חלקים ממנה? בפועל, אתה יכול להשתמש באחת משלוש שיטות:

1. עם קצת עבודה (אם אתה משתמש במסגרות כמו Spring Boot), אתה יכול לשלב את כל שירותי המיקרו שלך למחלקה אחת של משגר ולטעון את כל שירותי המיקרו באמצעות מחלקה אחת של Wrapper.java - תלוי אם יש לך מספיק זיכרון במחשב שלך כדי להפעיל את כל שירותי המיקרו שלך.
2. אתה יכול להעתיק את הגדרות Docker Swarm או Kubernetes באופן מקומי.
3. פשוט אל תפעיל יותר מבחני אינטגרציה מקומית. במקום זאת, פרוס סביבת DEV/TEST ייעודית. זה משהו שלא מעט צוותים באמת עושים כשהם נכנעים לכאב של הגדרות מיקרו-שירות מקומיות.

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