למד כיצד לפרוס שירותי מיקרו. חלק 1. Spring Boot and Docker

היי הבר.

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

בתחילה פירקתי את יצירת הפרויקט למספר שלבים:

1. צור שני שירותים - 'backend' (backend) ו-'gateway' (שער), ארוז אותם לתמונות docker והגדר אותם לעבוד יחד

   מילות מפתח: Java 11, Spring Boot, Docker, אופטימיזציית תמונה

2. פיתוח תצורת Kubernetes ופריסה של מערכת ב-Google Kubernetes Engine

   מילות מפתח: Kubernetes, GKE, ניהול משאבים, קנה מידה אוטומטי, סודות

3. יצירת תרשים עם Helm 3 לניהול טוב יותר של אשכולות

   תגיות: Helm 3, פריסת תרשים

4. הגדרת Jenkins ו-pipeline למסירה אוטומטית של קוד לאשכול

   מילות מפתח: תצורת Jenkins, תוספים, מאגר הגדרות נפרד

אני מתכנן להקדיש מאמר נפרד לכל שלב.

הפוקוס של סדרת מאמרים זו אינו כיצד לכתוב מיקרו-שירותים, אלא כיצד לגרום להם לעבוד במערכת אחת. למרות שכל הדברים האלה הם בדרך כלל מעבר לאחריות המפתח, אני חושב שעדיין כדאי להכיר אותם לפחות 20% (שכפי שאתם יודעים, נותנים 80% מהתוצאה). חלק מהנושאים החשובים ללא תנאי, כגון אבטחה, יישארו מחוץ לפרויקט זה, מכיוון שהמחבר מבין מעט על המערכת הזו שנוצרה אך ורק לשימוש אישי. אשמח לכל דעה וביקורת בונה.

יצירת שירותי מיקרו

השירותים נכתבו ב-Java 11 באמצעות Spring Boot. האינטראקציה הבין-שירותית מאורגנת באמצעות REST. הפרויקט יכלול מספר מינימלי של מבחנים (כדי שבהמשך יהיה מה לבדוק בג'נקינס). קוד המקור של השירותים זמין ב-GitHub: אחורי и שער.

כדי להיות מסוגל לבדוק את הסטטוס של כל אחד מהשירותים, נוסף מפעיל קפיץ לתלות שלהם. זה יצור /actuator/healthpoint קצה ויחזיר סטטוס 200 אם השירות מוכן לקבל תעבורה, או 504 אם יש בעיה. במקרה זה, מדובר בבדיקה די פיקטיבית, שכן השירותים פשוטים מאוד, ובמקרה של כוח עליון, סביר יותר שהם יהיו בלתי זמינים לחלוטין מאשר יישארו פעילים חלקית. אבל במערכות אמיתיות, Actuator יכול לעזור לאבחן בעיה לפני שמשתמשים מתחילים להיאבק עליה. לדוגמה, אם יש בעיות בגישה למסד הנתונים, נוכל להגיב לכך באופן אוטומטי על ידי הפסקת עיבוד בקשות עם מופע שירות שבור.

שירות אחורי

שירות הקצה האחורי פשוט יספור ויחזיר את מספר הבקשות המקובלות.

קוד בקר:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/requests")
    public Long getRequestsCount() {
        return counter.incrementAndGet();
    }
}

בדיקת בקר:

@WebMvcTest(RequestsCounterController.class)
public class RequestsCounterControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void firstRequest_one() throws Exception {
        mockMvc.perform(get("/requests"))
            .andExpect(status().isOk())
            .andExpect(MockMvcResultMatchers.content().string("1"));
    }
}

שער שירות

השער יעביר את הבקשה לשירות העורף, וישלים אותה במידע הבא:

• מזהה שער. זה נחוץ כדי שיהיה אפשר להבחין בין מופע אחד של השער למשנהו על ידי תגובת השרת
• איזה "סוד" שישחק את התפקיד של סיסמה חשובה מאוד (מספר מפתח ההצפנה של עוגייה חשובה)

תצורה ב- application.properties:

backend.url=http://localhost:8081
instance.id=${random.int}
secret="default-secret"

מתאם אחורי:

@Service
public class BackendAdapter {

    private static final String REQUESTS_ENDPOINT = "/requests";

    private final RestTemplate restTemplate;

    @Value("${backend.url}")
    private String backendUrl;

    public BackendAdapter(RestTemplateBuilder builder) {
        restTemplate = builder.build();
    }

    public String getRequests() {
        ResponseEntity<String> response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

בקר:

@RestController
@RequiredArgsConstructor
public class EndpointController {

    private final BackendAdapter backendAdapter;

    @Value("${instance.id}")
    private int instanceId;

    @Value("${secret}")
    private String secret;

    @GetMapping("/")
    public String getRequestsCount() {
        return String.format("Number of requests %s (gateway %d, secret %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

לְהַשִׁיק:

אנחנו מתחילים את הקצה האחורי:

./mvnw package -DskipTests
java -Dserver.port=8081 -jar target/microservices-backend-1.0.0.jar

הפעלת השער:

./mvnw package -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

אנו בודקים:

$ curl http://localhost:8080/
Number of requests 1 (gateway 38560358, secret "default-secret")

הכל עובד. קורא קשוב יציין ששום דבר לא מונע מאיתנו לגשת ישירות ל-backend, תוך עקיפת השער (http://localhost:8081/requests). כדי לתקן זאת, יש לשלב את השירותים לרשת אחת, ורק השער צריך "לבלוט" בחוץ.
כמו כן, שני השירותים חולקים מערכת קבצים אחת, מייצרים זרמים וברגע אחד יכולים להתחיל להפריע אחד לשני. זה יהיה נחמד לבודד את שירותי המיקרו שלנו. ניתן להשיג זאת על ידי הפצת יישומים על מכונות שונות (הרבה כסף, קשה), שימוש במכונות וירטואליות (עתיר משאבים, הפעלה ארוכה), או שימוש בקונטיינריזציה. כצפוי, אנו בוחרים באפשרות השלישית ו סַוָר ככלי למיכל.

סַוָר

בקיצור, docker יוצר מכולות מבודדות, אחת לכל אפליקציה. כדי להשתמש ב-docer, עליך לכתוב Dockerfile - הוראות לבנייה והרצה של האפליקציה. לאחר מכן, אתה יכול לבנות את התמונה, להעלות אותה לרישום התמונות (מס. Dockerhub) ופרוס את המיקרו-שירות שלך בכל סביבה מעוגנת בפקודה אחת.

דוקרפיל

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

בתור התחלה, ננסה לכתוב Dockerfile "על המצח" (אני אגיד מיד שזו דרך גרועה, אל תעשה את זה):

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests
EXPOSE 8080
ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

כאן אנו משתמשים בתמונת בסיס מבוססת אלפיני כשה-JDK כבר מותקן לבניית הפרויקט שלנו. עם הפקודה ADD, אנו מוסיפים לתמונה את ספריית ה-src הנוכחית, מסמנים אותה כעובדת (WORKDIR) ומתחילים את הבנייה. הפקודה EXPOSE 8080 מאותתת ל-docker שהאפליקציה במכולה תשתמש ביציאה 8080 שלה (זה לא יהפוך את האפליקציה לנגישה מבחוץ, אלא יאפשר גישה לאפליקציה, למשל, ממיכל אחר באותה רשת docker ).

כדי לארוז שירותים לתמונות, עליך להפעיל פקודות מהשורש של כל פרויקט:

docker image build . -t msvc-backend:1.0.0

התוצאה היא תמונה של 456 מגה-בייט (מתוכו תמונת ה-JDK הבסיסית תפסה 340 מגה-בייט). והכל למרות שניתן לספור את הכיתות בפרויקט שלנו על אצבע. כדי להקטין את גודל התמונה שלנו:

• אנו משתמשים בהרכבה רב-שלבית. בשלב הראשון נבנה את הפרויקט, בשלב השני נתקין את ה-JRE, ובשלב השלישי נעתיק את הכל לתמונה אלפינית נקייה חדשה. בסך הכל, רק הרכיבים הדרושים יהיו בתמונה הסופית.
• בואו נשתמש במודולריזציה של ג'אווה. החל מ-Java 9, אתה יכול להשתמש בכלי jlink כדי ליצור JRE רק מהמודולים שאתה צריך

עבור הסקרנים, הנה מאמר טוב על גישות להפחתת תמונה. https://habr.com/ru/company/ruvds/blog/485650/.

קובץ דוקר סופי:

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine as builder
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests

FROM alpine:3.10.3 as packager
RUN apk --no-cache add openjdk11-jdk openjdk11-jmods
ENV JAVA_MINIMAL="/opt/java-minimal"
RUN /usr/lib/jvm/java-11-openjdk/bin/jlink 
    --verbose 
    --add-modules 
        java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
    --compress 2 --strip-debug --no-header-files --no-man-pages 
    --release-info="add:IMPLEMENTOR=radistao:IMPLEMENTOR_VERSION=radistao_JRE" 
    --output "$JAVA_MINIMAL"

FROM alpine:3.10.3
LABEL maintainer="Anton Shelenkov [email protected]"
ENV JAVA_HOME=/opt/java-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"
COPY --from=packager "$JAVA_HOME" "$JAVA_HOME"
COPY --from=builder /src/target/microservices-backend-*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

אנו יוצרים מחדש את התמונה, וכתוצאה מכך היא איבדה פי 6 ממשקלה, בהיקף של 77 מגה-בייט. לא רע. לאחר מכן, ניתן להעלות תמונות מוכנות למרשם התמונות כך שהתמונות שלכם יהיו זמינות להורדה מהאינטרנט.

הפעלה משותפת של שירותים ב-Docker

מלכתחילה, השירותים שלנו חייבים להיות באותה רשת. ישנם מספר סוגים של רשתות ב-docker, ואנחנו משתמשים בפרימיטיבית שבהן - bridge, המאפשר לך לרשת קונטיינרים הפועלים על אותו מארח. צור רשת עם הפקודה הבאה:

docker network create msvc-network

לאחר מכן, התחל את מיכל הקצה האחורי בשם 'גבי' עם תמונת microservices-backend:1.0.0:

docker run -dit --name backend --network msvc-net microservices-backend:1.0.0

ראוי לציין כי רשת הגשרים מספקת שירות גילוי מחוץ לקופסה עבור קונטיינרים בשמותיהם. כלומר, שירות הקצה האחורי יהיה זמין בתוך רשת docker ב http://backend:8080.

הפעלת השער:

docker run -dit -p 80:8080 --env secret=my-real-secret --env BACKEND_URL=http://backend:8080/ --name gateway --network msvc-net microservices-gateway:1.0.0

בפקודה זו, אנו מציינים שאנו מעבירים את יציאה 80 של המארח שלנו ליציאה 8080 של המכולה. אנו משתמשים באפשרויות env כדי להגדיר משתני סביבה שייקראו אוטומטית על ידי קפיץ ויעקפו מאפיינים מ- application.properties.

אחרי שמתחילים אנחנו מתקשרים http://localhost/ ולוודא שהכל עובד, כמו במקרה הקודם.

מסקנה

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

• סובלנות תקלות לקויה - הכל עובד לנו על שרת אחד
• מדרגיות לקויה - כאשר העומס גדל, יהיה נחמד לפרוס אוטומטית מופעי שירות נוספים ולאזן את העומס ביניהם
• מורכבות ההשקה - היינו צריכים להזין לפחות 3 פקודות, ועם פרמטרים מסוימים (זה רק עבור 2 שירותים)

כדי לתקן את הבעיות לעיל, ישנם מספר פתרונות כגון Docker Swarm, Nomad, Kubernetes או OpenShift. אם כל המערכת כתובה ב-Java, אתה יכול להסתכל לכיוון Spring Cloud (מאמר טוב).

В החלק הבא אני אדבר על האופן שבו הגדרתי Kubernetes ופרסתי את הפרויקט ב-Google Kubernetes Engine.

מקור: www.habr.com