דף זה תורגם על ידי Cloud Translation API.

רמפה קשתית של מיקרו-שירות (microservice)

1. מבוא

תאריך עדכון אחרון: 6 במאי 2021

Rumpus ברמת מיקרו-שירות (microservice)

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

ייתכן שאתם תוהים... אבל איך מיקרו-שירות 'שולח' קשת למיקרו-שירותים אחרים? מיקרו-שירות (microservice) יכול לקבל בקשות רשת (בדרך כלל באמצעות HTTP) ולהחזיר תגובות. יש 'מנהל של זירת הלחימה' ששולח למיקרו-שירות את המצב הנוכחי של הזירה, ואז המיקרו-שירות מגיב עם פקודה שמציינת מה צריך לעשות.

ברור שהמטרה היא לנצח, אבל בהמשך תלמדו על יצירה ופריסה של מיקרו-שירותים (microservices) ב-Google Cloud.

איך זה עובד

נפתח מיקרו-שירות (microservice) בכל טכנולוגיה שרוצים (או לבחור מבין האפשרויות הבאות: Go, Java, Kotlin, Scala, NodeJS או Python), ולאחר מכן פורסים את המיקרו-שירות (microservice) ב-Google Cloud. לאחר הפריסה, תצטרכו לשלוח לנו את כתובת ה-URL של המיקרו-שירות, ואז נוסיף אותו לארנה.

בזירה נמצאים כל השחקנים בקרב נתון. ל-Rainbow Rumpus יהיו מגרשים משלו. כל שחקן מייצג מיקרו-שירות (microservice) שזז סביבו וזורק קשת בענן לשחקנים האחרים.

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

כך נראית אצטדיון בעבר:

דוגמה לזירת קרב ב-Battle One

התנגשויות חוזרות

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

צפייה בקרב

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

Battle API

כדי לעבוד עם מנהל הזירה שלנו, תצטרכו להטמיע ב-microservice API ספציפי כדי להשתתף בזירה. מנהל האצטדיון ישלח את המצב הנוכחי של האצטדיון בבקשת HTTP POST לכתובת ה-URL שתספקו לנו, עם מבנה ה-JSON הבא:

{
  "_links": {
    "self": {
      "href": "https://YOUR_SERVICE_URL"
    }
  },
  "arena": {
    "dims": [4,3], // width, height
    "state": {
      "https://A_PLAYERS_URL": {
        "x": 0, // zero-based x position, where 0 = left
        "y": 0, // zero-based y position, where 0 = top
        "direction": "N", // N = North, W = West, S = South, E = East
        "wasHit": false,
        "score": 0
      }
      ... // also you and the other players
    }
  }
}

תגובת ה-HTTP חייבת להיות קוד סטטוס 200 (OK) עם גוף תגובה שמכיל את הפעולה הבאה, והיא מקודדת כתו גדולה אחת של אחד או יותר מהערכים הבאים:

F <- move Forward
R <- turn Right
L <- turn Left
T <- Throw

זהו! נלמד איך לפרוס מיקרו-שירות ב-Cloud Run, שירות של Google Cloud להרצת מיקרו-שירותים ואפליקציות אחרות.

2. התחברות ל-Google Cloud

כדי לפרוס את המיקרו-שירות ב-Cloud Run, צריך להיכנס לחשבון ב-Google Cloud. נוסיף קרדיט לחשבון שלך ולא תצטרך להזין כרטיס אשראי. בדרך כלל פחות בעייתי להשתמש בחשבון אישי (למשל, gmail.com) במקום בחשבון G Suite, כי לפעמים האדמינים ב-G Suite מונעים מהמשתמשים שלהם להשתמש בתכונות מסוימות של Google Cloud. בנוסף, מסוף האינטרנט שבו נשתמש אמור לפעול היטב עם Chrome או עם Firefox, אבל ייתכן שיהיו בו בעיות ב-Safari.

3. פריסת המיקרו-שירות

אתם יכולים לפתח מיקרו-שירות (microservice) בכל טכנולוגיה ולפרוס אותו בכל מקום, כל עוד אפשר לגשת אליו באופן ציבורי ותואם ל-Battle API. אבל כדי להקל עליכם, אנחנו נעזור לכם להתחיל משירות לדוגמה ולפרוס אותו ב-Cloud Run.

בחירת דוגמה להתחלה

אפשר להתחיל מדוגמאות רבות של מיקרו-שירות (microservice):

קוטלין מגף קפיץ	מקור
Kotlin ו-Micronaut	מקור
Kotlin ו-Quarkus	מקור
Java ו- מגף קפיץ	מקור
Java ו-Quarkus	מקור
Go	מקור
Node.js ו- אקספרס	מקור
Python ו- בקבוקון לשתייה חריפה	מקור

אחרי שבוחרים באיזה דוגמה להתחיל, לוחצים על הלחצן 'פריסה ב-Cloud Run' למעלה. פעולה זו תפעיל את Cloud Shell (מסוף מבוסס-אינטרנט למכונה וירטואלית בענן) שבה יש לשכפל את המקור ואז ליצור חבילה שניתן לפרוס (תמונת קונטיינר של Docer). לאחר מכן תתבצע העלאה אל Google Container Registry ואז נפרס ב-Cloud Run.

כשתתבקשו, ציינו את האזור us-central1.

בצילום המסך למטה מוצג הפלט של Cloud Shell לפיתוח ולפריסה של מיקרו-שירות (microservice)

אימות שהמיקרו-שירות פועל

ב-Cloud Shell אפשר לשלוח בקשה למיקרו-שירות שהפרסתם, ולהחליף את YOUR_SERVICE_URL בכתובת ה-URL של השירות (שמוצגת ב-Cloud Shell אחרי השורה 'Your application is now live here'):

curl -d '{
  "_links": {
    "self": {
      "href": "https://foo.com"
    }
  },
  "arena": {
    "dims": [4,3],
    "state": {
      "https://foo.com": {
        "x": 0,
        "y": 0,
        "direction": "N",
        "wasHit": false,
        "score": 0
      }
    }
  }
}' -H "Content-Type: application/json" -X POST -w "\n" \
  https://YOUR_SERVICE_URL

המחרוזת של התגובה אמורה להיות F,‏ L,‏ R או T.

4. שליחת בקשה להצטרפות ל-Arena

כדי להצטרף ל-Rainbow Rumpus, תצטרכו להצטרף לארנה. פותחים את rainbowrumpus.dev ולוחצים על 'הצטרפות' באזור שבו תספקו את כתובת ה-URL של המיקרו-שירות.

5. ביצוע שינויים ופריסה שלהם

לפני שתוכלו לבצע שינויים, תצטרכו להגדיר ב-Cloud Shell מידע על פרויקט GCP ועל הדוגמה שבה השתמשתם. ראשית, יש לרשום את הפרויקטים שלך ב-GCP:

gcloud projects list

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

export PROJECT_ID=YOUR_PROJECT_ID

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

# Copy and paste ONLY ONE of these
export SAMPLE=kotlin-micronaut
export SAMPLE=kotlin-quarkus
export SAMPLE=kotlin-springboot
export SAMPLE=java-quarkus
export SAMPLE=java-springboot
export SAMPLE=go
export SAMPLE=nodejs
export SAMPLE=python

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

cloudshell edit cloudbowl-microservice-game/samples/$SAMPLE/README.md

לאחר מכן יוצגו הוראות נוספות לביצוע שינויים.

Cloud Shell בכלי לעריכה עם פרויקט לדוגמה פתוח

אחרי שמירת השינויים, מפעילים את האפליקציה ב-Cloud Shell באמצעות הפקודה בקובץ README.md, אבל קודם צריך לוודא שנמצאים בתיקיית הדוגמאות הנכונה ב-Cloud Shell:

cd cloudbowl-microservice-game/samples/$SAMPLE

אחרי שהאפליקציה פועלת, פותחים כרטיסייה חדשה ב-Cloud Shell ובודקים את השירות באמצעות curl:

curl -d '{
  "_links": {
    "self": {
      "href": "https://foo.com"
    }
  },
  "arena": {
    "dims": [4,3],
    "state": {
      "https://foo.com": {
        "x": 0,
        "y": 0,
        "direction": "N",
        "wasHit": false,
        "score": 0
      }
    }
  }
}' -H "Content-Type: application/json" -X POST -w "\n" \
  http://localhost:8080

כשתהיו מוכנים לפרוס את השינויים, תצטרכו ליצור את הפרויקט ב-Cloud Shell באמצעות הפקודה pack. הפקודה הזו משתמשת ב-Buildpacks כדי לזהות את סוג הפרויקט, לקמפל אותו וליצור את הארטיפקט שניתן לפריסה (קובץ אימג' בקונטיינר של Docker).

# Make sure you are in a Cloud Shell tab where you set the PROJECT_ID
# and SAMPLE env vars. Otherwise, set them again.
pack build gcr.io/$PROJECT_ID/$SAMPLE \
  --path ~/cloudbowl-microservice-game/samples/$SAMPLE \
  --builder gcr.io/buildpacks/builder

עכשיו, אחרי שתיצרו את קובץ האימג' בקונטיינר, תוכלו להשתמש בפקודת Docer (ב-Cloud Shell) להעביר את קובץ האימג' בקונטיינר ל-Google Container Registry, כדי ש-Cloud Run יוכל לגשת אליו:

docker push gcr.io/$PROJECT_ID/$SAMPLE

עכשיו פורסים את הגרסה החדשה ב-Cloud Run:

gcloud run deploy $SAMPLE \
          --project=$PROJECT_ID \
          --platform=managed \
          --region=us-central1 \
          --image=gcr.io/$PROJECT_ID/$SAMPLE \
          --allow-unauthenticated

עכשיו האצטדיון ישתמש בגרסה החדשה!

6. פיתוח מקומי (אופציונלי)

כדי לעבוד על הפרויקט באופן מקומי באמצעות סביבת הפיתוח המשולבת (IDE) שלכם, פועלים לפי השלבים הבאים:

[ב-Cloud Shell] יוצרים ZIP של הדוגמה:

# Make sure the SAMPLE env var is still set. If not, re-set it.
cd ~/cloudbowl-microservice-game/samples
zip -r cloudbowl-sample.zip $SAMPLE

[ב-Cloud Shell] מורידים את קובץ ה-zip למכונה:

cloudshell download-file cloudbowl-sample.zip

[במחשב] מחלצים את הקובץ ואז יוצרים & בדיקת השינויים
[במכונה שלכם] התקנת ה-CLI של gcloud
[במכונה שלכם] התחברות ל-Google Cloud:

gcloud auth login

[במכונה] מגדירים את משתני הסביבה PROJECT_ID ו-SAMPLE לאותו ערך כמו ב-Cloud Shell.
[במכונה שלכם] משתמשים ב-Cloud Build כדי ליצור את הקונטיינר (מספריית הפרויקט ברמה הבסיסית):

gcloud alpha builds submit . \
  --pack=image=gcr.io/$PROJECT_ID/$SAMPLE \
  --project=$PROJECT_ID

[במכונה] פורסים את הקונטיינר החדש:

gcloud run deploy $SAMPLE \
  --project=$PROJECT_ID \
  --platform=managed \
  --region=us-central1 \
  --image=gcr.io/$PROJECT_ID/$SAMPLE \
  --allow-unauthenticated

7. פיתוח רציף (continuous delivery)

הגדרת SCM

מגדירים את GitHub כדי שתוכלו לשתף פעולה עם הצוות על המיקרו-שירות:

התחברות ל-GitHub
יצירת מאגר חדש
אם אתם עובדים במחשב המקומי, אתם יכולים להשתמש בממשק שורת הפקודה (CLI) של git או באפליקציית GitHub Desktop עם ממשק משתמש גרפי (Windows או Mac). אם אתם משתמשים ב-Cloud Shell, תצטרכו להשתמש ב-Git CLI. כדי לקבל את הקוד של המיקרו-שירות (microservice) ב-GitHub, צריך לפעול לפי ההוראות לשימוש ב-CLI או ב-GitHub Desktop.

דחיפת הקוד באמצעות git CLI

פועלים לפי ההוראות ב-git over https עם אסימון גישה אישי.
בוחרים 'מאגר' היקף
הגדרת Git:

git config --global credential.helper \
  'cache --timeout=172800'
git config --global push.default current
git config --global user.email "YOUR@EMAIL"
git config --global user.name "YOUR NAME"

הגדרת משתני סביבה לארגון ולמאגר ב-GitHub (https://github.com/ORG/REPO)

export GITHUB_ORG=YOUR_GITHUB_ORG
export GITHUB_REPO=YOUR_GITHUB_REPO

דחיפת הקוד למאגר החדש

# Make sure the SAMPLE env var is still set. If not, re-set it.
cd ~/cloudbowl-microservice-game/samples/$SAMPLE
git init
git add .
git commit -m init
git remote add origin https://github.com/$GITHUB_ORG/$GITHUB_REPO.git
git branch -M main

# This will now ask for your GitHub username & password
# for the password use the personal access token
git push -u origin main

אחרי שמבצעים שינויים, אפשר לשמור ולדחוף את השינויים ל-GitHub:

git add .
git status
git diff --staged
git commit -am "my changes"
git push

איך מעבירים את הקוד באמצעות GitHub Desktop

מורידים את הקוד לפי ההוראות שמפורטות ביעד "פיתוח מקומי" הקודם שיעור Lab
מתקינים את GitHub Desktop, פותחים אותו ונכנסים לחשבון
יצירת עותקים (cloning) של המאגר החדש

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

פרסום ההסתעפות הראשית ב-GitHub

הגדרת פריסה רציפה (CI) של Cloud Run

באמצעות הגדרת SCM ב-GitHub, אפשר עכשיו להגדיר continuous Delivery כך שבכל פעם שהתחייבויות חדשות יועברו להסתעפות main, Cloud Build ייצור ויתפרס באופן אוטומטי את השינויים. אפשר גם להוסיף אינטגרציה רציפה (CI) שמריצה את הבדיקות לפני הפריסה, אבל השלב הזה נותר עבורכם לתרגול כי הדוגמאות המקוריות לא מכילות בדיקות.

במסוף Cloud, עוברים לשירות Cloud Run.
לוחצים על 'הגדרת חלוקה מתמשכת'. לחצן
אימות באמצעות GitHub ובחירת המאגר של המיקרו-שירות

בוחרים את המאגר ב-GitHub ומגדירים את ההסתעפות ל-^main$.

הגדרת סוג ה-build לשימוש ב-Buildpacks
לוחצים על Save כדי להגדיר את Continuous Deployment.

8. ניראות (observability)

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

מדדים

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

לוחצים על התפריט ⋮ של מדד מסוים ואז בוחרים באפשרות 'הצגה ב-Metrics Explorer'
עכשיו אפשר לשנות מדדים של משאבים, מסננים, קיבוץ ואפשרויות אחרות. לדוגמה, אפשר לראות את זמן האחזור הממוצע של השירות של כל השירותים:

יומנים

הפלט של STDOUT מהשירותים נשלח למערכת Google Cloud Logging. אפשר לגשת לתצוגת יומן בסיסית מדף האדמין של שירות Cloud Run, כמו:

ביומני Cloud Run אפשר לסנן לפי רמת החומרה ולסנן את היומנים. כדי ליהנות מגמישות רבה יותר, אפשר ללחוץ על

התראות

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

org.springframework.boot:spring-boot-starter-actuator

יוצרים או מעדכנים את src/main/resources/application.properties ומשביטים את הבדיקה של נפח האחסון בדיסק:

management.health.diskspace.enabled=false

יוצרים התראה על זמן פעולה תקינה, ומציינים את הפרוטוקול, שם המארח והנתיב. באתחול אביב, הנתיב הוא: /actuator/health
בדיקת ההתראה

יצירת ההתראה

9. מזל טוב

מזל טוב, יצרתם ומימשתם מיקרו-שירות שיכול להתחרות במיקרו-שירותים אחרים! בהצלחה!

מסמכי עזר

מסמכי Docs של Cloud Run