גילוי שירות במערכות מבוזרות תוך שימוש בדוגמה של קונסול. אלכסנדר סיגאצ'ב

אני מציע לך לקרוא את תמליל הדו"ח של אלכסנדר סיגאצ'ב שירות גילוי במערכות מבוזרות תוך שימוש בקונסול כדוגמה.

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

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

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

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

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

מה עוד נוח לעשות עם Service Discovery? Service Discovery יכול לאחסן תצורות nginx, אישורים ורשימת שרתי קצה פעילים.

Service Discovery מאפשר גם לזהות כשלים ולאתר כשלים. מהן הסכמות האפשריות לאיתור כשלים?

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

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

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

זו דוגמה אחת. מאזן עומסים בצורה של nginx מופעל מחדש. זהו כלי עזר אופציונלי שמסופק עם Consul. זו תבנית קונסול. אנו מתארים את הכלל. אנו אומרים שאנו משתמשים בתבנית (Golang Template Engine). כאשר מתרחשים אירועים, כאשר הודעות על שינויים שהתרחשו, הוא נוצר מחדש והפקודה "טעינה מחדש" נשלחת ל-Service Discovery. הדוגמה הפשוטה ביותר היא כאשר nginx מוגדר מחדש על ידי אירוע ומופעל מחדש.

מה זה קונסול?

• קודם כל, זה שירות גילוי.

• יש לו מנגנון בדיקת זמינות - בדיקת בריאות.

• יש לו גם חנות KV.

• והוא מבוסס על היכולת להשתמש ב-Multi Datacenter.

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

בואו נבין קצת על המונחים המשמשים בקונסול.

• קונסול הוא שירות שנכתב בגו. אחד היתרונות של תוכנית Go הוא קובץ בינארי אחד שאתה פשוט מוריד. הושק מכל מקום ואין לך שום תלות.
• לאחר מכן, באמצעות המקשים, נוכל להפעיל שירות זה במצב לקוח או במצב שרת.
• כמו כן, התכונה "מרכז נתונים" מאפשרת לך להגדיר דגל לאיזה מרכז נתונים שייך השרת הזה.
• קונצנזוס - מבוסס על פרוטוקול הרפסודה. אם מישהו מעוניין, תוכלו לקרוא על כך עוד באתר קונסול. זהו פרוטוקול המאפשר לקבוע את המנהיג ולקבוע איזה כסף נחשב תקף ונגיש.
• רכילות היא פרוטוקול המאפשר אינטראקציה בין צמתים. יתרה מכך, מערכת זו מבוזרת. בתוך מרכז נתונים אחד, כל הצמתים מתקשרים עם שכניהם. ובהתאם, מידע על המצב הנוכחי מועבר זה לזה. אפשר לומר שזו רכילות בין שכנים.
• LAN Gossip – חילופי נתונים מקומיים בין שכנים בתוך אותו מרכז נתונים.
• WAN Gossip - משמש כאשר אנו צריכים לסנכרן מידע בין שני מרכזי נתונים. מידע זורם בין צמתים המסומנים כשרת.
• RPC - מאפשר לך לבצע בקשות דרך לקוח בשרת.

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

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

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

איזה API מספקת Consul? על מנת לקבל מידע, לקונסול יש שני סוגים של API.

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

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

מה אתה צריך כדי להפעיל את קונסול?

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

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

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

כיצד מתבצעות בדיקות בריאות? אנו כותבים כלל אימות בצורה של Json בספריית התצורה של Consul. האפשרות הראשונה היא הזמינות של הדומיין google.com בדוגמה זו. ואנחנו אומרים שצריך לבצע את הבדיקה הזו במרווחים של 30 שניות. כך אנו בודקים שלצומת שלנו יש גישה לרשת החיצונית.

האפשרות השנייה היא לבדוק את עצמך. אנו משתמשים בסלסול רגיל כדי לקרוא ל-localhost ביציאה שצוינה במרווחים של 10 שניות.

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

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

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

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

אתה יכול גם להעביר מידע לקונסול על מצב הדיסקים והעומס הממוצע.

שאלות

שאלה: יש לנו מיכל דוקר, איך להשתמש בו עם קונסול?

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

שאלה: אז קונסול בעצמו מתחיל את קונטיינר הדוקר?

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

שאלה: מסתבר שבתוך הקונטיינר של Docker שאנחנו מנסים לחבר ל-Service Discovery צריך להיות איזשהו היגיון שיכול לשלוח נתונים לקונסול?

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

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

תשובה: בממשק המשתמש יש נתונים ממסד הנתונים ומ-Service Discovery. אנחנו קובעים סיסמאות בהגדרות בעצמנו.

שאלה: האם אפשר לפרסם את זה באינטרנט?

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

שאלה: האם הוא מספק נתונים היסטוריים מחוץ לקופסה? מעניין להסתכל על הסטטיסטיקה על בדיקות בריאות. אתה יכול גם לאבחן בעיות אם השרת נכשל לעתים קרובות.

תשובה: אני לא בטוח שיש שם פרטים של צ'קים.

שאלה: המצב הנוכחי לא כל כך חשוב כמו הדינמיקה.

תשובה: לניתוח - כן.

שאלה: האם עדיף לא להשתמש ב-Service Discovery עבור Consul Docker?

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

שאלה: האם התוכנית עם שרת מובילה לא מאטה את תחילת היישום בכללותו? ואיך קובע קונסול מנהיג חדש אם זה משקר?

תשובה: יש להם פרוטוקול שלם שתואר. אם אתה מעוניין, אתה יכול לקרוא אותו.

שאלה: קונסול פועל עבורנו כשרת מן המניין וכל הבקשות עפות דרכו?

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

שאלה: כלומר, אם אנחנו רוצים לגשת למסד נתונים, אז בכל מקרה נמשוך את קונסול למצוא את המאגר הזה קודם, נכון?

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

צ'אט מוצרים של hashicorp — צ'אט משתמש של Hashicorp: קונסול, נומד, Terraform

נ.ב לגבי בדיקות בריאות. קונסול, כמו Kubernetes, משתמש באותה מערכת לבדיקת מצב השרידות של שירות על סמך מצב הקוד.

200 OK for healthy
503 Service Unavailable for unhealthy

מקורות:
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

מקור: www.habr.com