אפשר לחלק את רכיבי הארכיטקטורה של אפליקציה לקצה קדמי או לבק-אנד. בתרחישים מסוימים, אפשר לארח את הרכיבים האלה כדי להפעיל אותם בסביבות מחשוב שונות. כחלק מתבנית הארכיטקטורה של היברידיות מדורגת, סביבות המחשוב ממוקמות בסביבת מחשוב פרטית מקומית וב- Google Cloud.
רכיבי אפליקציות של קצה קדמי חשופים ישירות למשתמשי קצה או למכשירים. כתוצאה מכך, האפליקציות האלה רגישות לביצועים. כדי לפתח תכונות חדשות ולשפר את הקיימות, יכול להיות שיהיו עדכוני תוכנה בתדירות גבוהה. מכיוון שאפליקציות frontend בדרך כלל מסתמכות על אפליקציות backend כדי לאחסן ולנהל נתונים – ואולי גם לוגיקה עסקית ועיבוד של קלט משתמשים – הן לרוב חסרות מצב או שהן מנהלות רק נפחים מוגבלים של נתונים.
כדי שאפליקציות הקצה הקדמי יהיו נגישות ושימושיות, אפשר ליצור אותן באמצעות מגוון מסגרות וטכנולוגיות. כמה גורמים חשובים להצלחה של אפליקציית frontend הם ביצועי האפליקציה, מהירות התגובה והתאימות לדפדפן.
רכיבי אפליקציות של קצה עורפי מתמקדים בדרך כלל באחסון ובניהול של נתונים. בארכיטקטורות מסוימות, יכול להיות שהלוגיקה העסקית משולבת ברכיב הקצה העורפי. גרסאות חדשות של אפליקציות backend נוטות להיות פחות תכופות מגרסאות של אפליקציות frontend. יש כמה אתגרים בניהול אפליקציות בקצה העורפי:
- טיפול במספר גדול של בקשות
- טיפול בנפח גדול של נתונים
- אבטחת נתונים
- שמירה על נתונים עדכניים בכל העותקים של המערכת
פתרון אפליקציית האינטרנט בתלת-שכבות הוא אחד מהיישומים הפופולריים ביותר לבניית אפליקציות אינטרנט עסקיות, כמו אתרי מסחר אלקטרוני שמכילים רכיבי אפליקציה שונים. הארכיטקטורה הזו מכילה את הרמות הבאות. כל רמה פועלת באופן עצמאי, אבל הרמות קשורות זו לזו ופועלות יחד.
- חזית אינטרנט ושכבת הצגה
- רמת האפליקציה
- גישה לנתונים או לרמת ה-backend
הכנסת השכבות האלה למאגרי תגים מפרידה בין הצרכים הטכניים שלהן, כמו דרישות לגבי שינוי גודל, ועוזרת להעביר אותן בגישה מדורגת. בנוסף, אפשר לפרוס אותם בשירותי ענן שאינם תלויים בפלטפורמה, שאפשר להעביר בין סביבות, להשתמש בניהול אוטומטי ולשנות את קנה המידה שלהם באמצעות פלטפורמות מנוהלות בענן, כמו Cloud Run או מהדורת Google Kubernetes Engine (GKE) Enterprise. בנוסף, Google Cloudמסדי נתונים מנוהלים כמו Cloud SQL עוזרים לספק את הקצה העורפי כשכבת מסד הנתונים.
דפוס הארכיטקטורה ההיברידית המדורגת מתמקד בפריסת רכיבי אפליקציות קיימים של קצה קדמי בענן הציבורי. בדפוס הזה, שומרים את כל רכיבי האפליקציה הקיימים של ה-Backend בסביבת המחשוב הפרטית שלהם. בהתאם להיקף ולעיצוב הספציפי של האפליקציה, אפשר להעביר רכיבי אפליקציות של קצה קדמי על בסיס כל מקרה לגופו. מידע נוסף זמין במאמר מעבר אל Google Cloud.
אם יש לכם אפליקציה קיימת עם רכיבי קצה עורפי וקצה חזיתי שמתארחים בסביבה המקומית שלכם, כדאי לקחת בחשבון את המגבלות של הארכיטקטורה הנוכחית. לדוגמה, ככל שהאפליקציה שלכם גדלה והדרישות לגבי הביצועים והאמינות שלה עולות, כדאי להתחיל לבדוק אם צריך לבצע רפקטורינג בחלקים של האפליקציה או להעביר אותם לארכיטקטורה שונה ואופטימלית יותר. תבנית הארכיטקטורה היברידית מדורגת מאפשרת להעביר חלק מעומסי העבודה והרכיבים של האפליקציה לענן לפני שמבצעים מעבר מלא. חשוב גם לקחת בחשבון את העלות, הזמן והסיכון הכרוכים בהעברה כזו.
התרשים הבא מציג דוגמה אופיינית של תבנית ארכיטקטורה היברידית מדורגת.
בתרשים שלמעלה, בקשות של לקוחות נשלחות לקצה הקדמי של האפליקציה שמארח ב- Google Cloud. בתמורה, הקצה הקדמי של האפליקציה שולח נתונים בחזרה לסביבה המקומית שבה מתארח הבק-אנד של האפליקציה (באופן אידיאלי דרך API Gateway).
בעזרת תבנית הארכיטקטורה tiered hybrid, תוכלו ליהנות מGoogle Cloud שירותי תשתית ושירותים גלובליים, כמו שמוצג בארכיטקטורה לדוגמה בתרשים הבא. אפשר לגשת לחלק הקדמי של האפליקציה דרך Google Cloud. בנוסף, אפשר להוסיף גמישות לקצה הקדמי באמצעות התאמה אוטומטית לעומס, כדי להגיב באופן דינמי ויעיל לביקוש להגדלת הקיבולת בלי להקצות יותר מדי משאבים לתשתית. יש ארכיטקטורות שונות שבהן אפשר להשתמש כדי ליצור ולהפעיל אפליקציות אינטרנט שניתנות להרחבה ב- Google Cloud. לכל ארכיטקטורה יש יתרונות וחסרונות שמתאימים לדרישות שונות.
מידע נוסף זמין בסרטון Three ways to run scalable web apps on Google Cloud ב-YouTube. כדי לקבל מידע נוסף על דרכים שונות למודרניזציה של פלטפורמת המסחר האלקטרוני ב-Google Cloud, אפשר לעיין במאמר איך לבנות פלטפורמת מסחר דיגיטלי ב- Google Cloud.
בתרשים שלמעלה, חזית האפליקציה מתארחת ב-Google Cloud כדי לספק חוויית משתמש במספר אזורים ומותאמת גלובלית שמשתמשת במאזן עומסים גלובלי, בהתאמה אוטומטית לעומס ובהגנה מפני מתקפות DDoS באמצעות Google Cloud Armor.
עם הזמן, מספר האפליקציות שאתם פורסים בענן הציבורי עשוי לגדול עד לנקודה שבה כדאי לשקול להעביר רכיבי אפליקציות של קצה עורפי לענן הציבורי. אם אתם צופים עומס תנועה כבד, כדאי לבחור בשירותים מנוהלים בענן כדי לחסוך במאמצי הנדסה כשמנהלים את התשתית שלכם. כדאי לשקול את האפשרות הזו אלא אם יש אילוצים או דרישות שמחייבים אירוח של רכיבי אפליקציית קצה עורפיים במקום. לדוגמה, אם נתוני ה-Backend שלכם כפופים להגבלות רגולטוריות, כנראה שתצטרכו לשמור את הנתונים האלה בשרתים מקומיים. עם זאת, במקרים שבהם הדבר רלוונטי ועומד בדרישות, אפשר להשתמש ביכולות של Sensitive Data Protection, כמו טכניקות להסרת פרטים מזהים, כדי להעביר את הנתונים האלה כשצריך.
בתבנית של ארכיטקטורה היברידית מדורגת, אפשר להשתמש גם ב-Google Distributed Cloud בתרחישים מסוימים. Distributed Cloud מאפשר להריץ אשכולות של Google Kubernetes Engine בחומרה ייעודית שמסופקת ומתוחזקת על ידי Google, בנפרד ממרכז הנתונים. Google Cloud כדי לוודא ש-Distributed Cloud עונה על הדרישות הנוכחיות והעתידיות שלכם, חשוב להכיר את המגבלות של Distributed Cloud בהשוואה לאזור GKE רגיל שמבוסס על ענן.
יתרונות
להתמקד קודם באפליקציות חזיתיות יש כמה יתרונות, כולל:
- רכיבי קצה קדמי תלויים במשאבי בק-אנד ולפעמים ברכיבי קצה קדמי אחרים.
- רכיבי ה-Backend לא תלויים ברכיבי ה-Frontend. לכן, בידוד של אפליקציות frontend והעברה שלהן נוטים להיות פחות מורכבים מהעברה של אפליקציות backend.
- אפליקציות frontend הן לרוב חסרות מצב (stateless) או שהן לא מנהלות נתונים בעצמן, ולכן בדרך כלל קל יותר להעביר אותן מאשר אפליקציות backend.
- אפשר לבצע אופטימיזציה לרכיבי קצה קדמי כחלק מההעברה לשימוש בארכיטקטורה בלי שמירת מצב. מידע נוסף זמין בסרטון How to port stateful web apps to Cloud Run ב-YouTube.
פריסת אפליקציות קצה קדמי קיימות או אפליקציות שפותחו לאחרונה בענן הציבורי מציעה כמה יתרונות:
- הרבה אפליקציות frontend כפופות לשינויים תכופים. הפעלת האפליקציות האלה בענן הציבורי מפשטת את ההגדרה של תהליך אינטגרציה רציפה/פריסה רציפה (CI/CD). אתם יכולים להשתמש ב-CI/CD כדי לשלוח עדכונים בצורה יעילה ואוטומטית. מידע נוסף זמין במאמר בנושא CI/CD ב- Google Cloud.
- מערכות קצה קדמי רגישות לביצועים עם עומס תנועה משתנה יכולות להפיק תועלת משמעותית מאיזון העומסים, מפריסות מרובות אזורים, מCloud CDN, משמירה במטמון, מבלי שרת ומיכולות של התאמה אוטומטית לעומס (autoscaling) שפריסה מבוססת-ענן מאפשרת (באופן אידיאלי עם ארכיטקטורה בלי שמירת מצב).
אימוץ מיקרו-שירותים עם קונטיינרים באמצעות פלטפורמה שמנוהלת בענן, כמו GKE, מאפשר לכם להשתמש בארכיטקטורות מודרניות כמו מיקרו-קצה קדמי, שמרחיבות את המיקרו-שירותים לרכיבי הקצה הקדמי.
הרחבת מיקרו-שירותים נפוצה בשימוש עם ממשקי קצה שבהם כמה צוותים משתפים פעולה באותה אפליקציה. מבנה צוות כזה דורש גישה איטרטיבית ותחזוקה שוטפת. אלה כמה מהיתרונות של שימוש במיקרו-פרונט-אנד:
- אפשר להפוך אותו למודולים עצמאיים של מיקרו-שירותים לצורך פיתוח, בדיקה ופריסה.
- הוא מאפשר הפרדה שבה צוותי פיתוח יכולים לבחור את הטכנולוגיות והקוד המועדפים עליהם.
- הוא יכול לעודד מחזורי פיתוח ופריסה מהירים בלי להשפיע על שאר רכיבי ה-Frontend שאולי מנוהלים על ידי צוותים אחרים.
בין אם מדובר בהטמעה של ממשקי משתמש או ממשקי API, או בטיפול בהטמעה של נתונים מ-IoT (האינטרנט של הדברים), אפליקציות frontend יכולות להפיק תועלת מהיכולות של שירותי ענן כמו Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine או Cloud Run.
פרוקסי של ממשקי API שמנוהלים בענן עוזרים לכם:
- הפרדה בין ה-API שפונה לאפליקציה לבין השירותים לקצה העורפי, כמו מיקרו-שירותים.
- הגנה על אפליקציות מפני שינויים בקוד הקצה העורפי.
- תמיכה בארכיטקטורות קצה קדמי קיימות שמבוססות על API, כמו קצה עורפי לקצה קדמי (BFF), מיקרו-קצה קדמי ואחרות.
- אפשר לחשוף את ממשקי ה-API ב- Google Cloud או בסביבות אחרות באמצעות הטמעה של שרתי proxy ל-API ב-Apigee.
אפשר גם להשתמש בתבנית היברידית מדורגת באופן הפוך, כלומר לפרוס את ה-בק-אנד בענן ולהשאיר את ה-קצה קדמי בסביבות מחשוב פרטיות. הגישה הזו פחות נפוצה, אבל היא הכי מתאימה כשמדובר בקצה קדמי כבד ומונוליטי. במקרים כאלה, יכול להיות שיהיה קל יותר לחלץ את פונקציונליות הבק-אנד באופן איטרטיבי, ולפרוס את הבק-אנדים החדשים האלה בענן.
בחלק השלישי בסדרה הזו נדון בדפוסי רישות אפשריים כדי לאפשר ארכיטקטורה כזו. Apigee hybrid משמש כפלטפורמה ליצירה ולניהול של פרוקסי API במודל פריסה היברידי. מידע נוסף זמין במאמר ארכיטקטורה בצימוד חלש, כולל ארכיטקטורות מונוליתיות ומיקרו-שירותים מדורגים.
שיטות מומלצות
השתמשו במידע שבקטע הזה כדי לתכנן את הארכיטקטורה ההיברידית המדורגת שלכם.
שיטות מומלצות לצמצום המורכבות
כשמיישמים את דפוס הארכיטקטורה היברידית מדורגת, כדאי להשתמש בשיטות המומלצות הבאות כדי לצמצם את המורכבות הכוללת של ה-Deployment (פריסה) והתפעול:
- על סמך ההערכה של מודלים התקשורת של האפליקציות שזוהו, בוחרים את פתרון התקשורת היעיל והאפקטיבי ביותר לאפליקציות האלה.
מכיוון שרוב האינטראקציות של המשתמשים כוללות מערכות שמתחברות בין סביבות מחשוב מרובות, חשוב שיהיה חיבור מהיר עם זמן אחזור נמוך בין המערכות האלה. כדי לעמוד בציפיות לגבי זמינות וביצועים, צריך לתכנן זמינות גבוהה, זמן אחזור נמוך ורמות מתאימות של קצב העברת נתונים. מבחינת אבטחה, התקשורת צריכה להיות פרטנית ומבוקרת. מומלץ לחשוף רכיבי אפליקציה באמצעות ממשקי API מאובטחים. מידע נוסף זמין במאמר בנושא יציאה מוגבלת.
- כדי לצמצם את זמן האחזור של התקשורת בין הסביבות, בוחרים Google Cloud אזור שקרוב מבחינה גיאוגרפית לסביבת המחשוב הפרטית שבה מתארחים רכיבי ה-Backend של האפליקציה. למידע נוסף, ראו שיטות מומלצות לבחירת אזורים ב-Compute Engine.
- צריך לצמצם את התלות הגבוהה בין מערכות שפועלות בסביבות שונות, במיוחד כשמדובר בתקשורת סינכרונית. התלות הזו עלולה להאט את הביצועים, להפחית את הזמינות הכוללת ולגרום לחיובים נוספים על העברת נתונים יוצאים.
- בדפוס הארכיטקטורה היברידית מדורגת, יכול להיות שנפח התנועה הנכנסת מסביבות מקומיות אלGoogle Cloud יהיה גדול יותר מנפח התנועה היוצאת מ- Google Cloud. עם זאת, חשוב לדעת מהו נפח העברת הנתונים היוצאים הצפוי מ- Google Cloud. אם אתם מתכננים להשתמש בארכיטקטורה הזו לטווח ארוך עם נפחי העברת נתונים גבוהים, כדאי לשקול שימוש ב-Cloud Interconnect. Cloud Interconnect יכול לעזור לבצע אופטימיזציה של ביצועי הקישוריות, ועשוי להפחית את העלויות של העברת נתונים יוצאים לתנועה שעומדת בתנאים מסוימים. מידע נוסף זמין במאמר בנושא תמחור של Cloud Interconnect.
- כדי להגן על מידע רגיש, מומלץ להצפין את כל התקשורת בזמן ההעברה. אם נדרשת הצפנה בשכבת הקישוריות, אפשר להשתמש במנהרות VPN, ב-HA VPN over Cloud Interconnect וב-MACsec for Cloud Interconnect.
כדי להתגבר על חוסר עקביות בפרוטוקולים, בממשקי API ובמנגנוני אימות במגוון רחב של בק-אנד, מומלץ, במקרים הרלוונטיים, לפרוס API Gateway או שרת proxy כחזית מאחדת. השער או ה-proxy האלה פועלים כנקודת בקרה מרכזית ומבצעים את הפעולות הבאות:
- הטמעה של אמצעי אבטחה נוספים.
- מגנים על אפליקציות לקוח ושירותים אחרים מפני שינויים בקוד הקצה העורפי.
- מאפשרת יצירת נתיבי ביקורת לתקשורת בין כל האפליקציות בסביבות שונות לבין הרכיבים המופרדים שלה.
- פועל כשכבת תקשורת ביניים בין שירותים מדור קודם לשירותים מודרניים.
- Apigee ו-Apigee Hybrid מאפשרים לארח ולנהל שערים היברידיים ברמת הארגון בסביבות מקומיות, ב-Edge, בעננים אחרים ובסביבותGoogle Cloud .
כדי להקל על הקמת הגדרות היברידיות, השתמשו ב-Cloud Load Balancing עם קישוריות היברידית. המשמעות היא שאתם יכולים להרחיב את היתרונות של איזון עומסים בענן לשירותים שמארחים בסביבת המחשוב המקומית שלכם. הגישה הזו מאפשרת העברות מדורגות של עומסי עבודה אל Google Cloud עם הפרעה מינימלית או ללא הפרעה לשירות, וכך מבטיחה מעבר חלק לשירותים המבוזרים. מידע נוסף זמין במאמר סקירה כללית על קבוצות של נקודות קצה ברשת עם קישוריות היברידית.
לפעמים, שימוש בשער API או בשרת proxy וב-Application Load Balancer ביחד יכול לספק פתרון חזק יותר לניהול, לאבטחה ולהפצה של תנועת נתונים ב-API בהיקף גדול. שימוש ב-Cloud Load Balancing עם שערים ל-API מאפשר לכם לבצע את הפעולות הבאות:
- שימוש ב-Apigee וב-Cloud CDN כדי לספק ממשקי API עם ביצועים גבוהים, להפחית את זמן האחזור, לארח ממשקי API באופן גלובלי ולהגדיל את הזמינות בעונות של תעבורה גבוהה. מידע נוסף זמין בסרטון Delivering high-performing APIs with Apigee and Cloud CDN ב-YouTube.
- הטמעה של ניהול מתקדם של תעבורת נתונים.
- כדי להגן על ממשקי ה-API, אפשר להשתמש ב-Cloud Armor כשירות להגנה מפני DDoS ולאבטחת רשת.
- ניהול יעיל של איזון עומסים בין שערים בכמה אזורים. מידע נוסף זמין בסרטון Securing APIs and Implementing במספר אזורים יתירות כשל with Private Service Connect and Apigee ב-YouTube.
שימוש בניהול API וברשת שירותים כדי לאבטח ולשלוט בתקשורת ובחשיפה של שירותים עם ארכיטקטורת מיקרו-שירותים.
- אפשר להשתמש ב-Cloud Service Mesh כדי לאפשר תקשורת מסוג שירות-לשירות, שתשמור על איכות השירות במערכת שמורכבת משירותים מבוזרים, שבה אפשר לנהל אימות, הרשאה והצפנה בין שירותים.
- שימוש בפלטפורמה לניהול ממשקי API כמו Apigee, שמאפשרת לארגון ולגורמים חיצוניים להשתמש בשירותים האלה על ידי חשיפתם כממשקי API.
הגדרת זהות משותפת בין סביבות כדי שהמערכות יוכלו לבצע אימות בצורה מאובטחת בגבולות הסביבה.
פריסת מערכות CI/CD וניהול הגדרות בענן ציבורי. מידע נוסף זמין במאמר בנושא דפוס ארכיטקטורה של רשת משוכפלת.
כדי לשפר את היעילות התפעולית, כדאי להשתמש בכלים עקביים ובצינורות CI/CD בכל הסביבות.
שיטות מומלצות לארכיטקטורות של עומסי עבודה ואפליקציות ספציפיות
- הדגש בתבנית הזו הוא על אפליקציות frontend, אבל חשוב לזכור שצריך גם לעדכן את אפליקציות ה-backend. אם קצב הפיתוח של אפליקציות backend איטי משמעותית מקצב הפיתוח של אפליקציות frontend, ההבדל הזה עלול לגרום למורכבות נוספת.
- התייחסות לממשקי API כממשקים לקצה העורפי מייעלת את השילובים, את פיתוח הקצה הקדמי, את האינטראקציות עם השירותים ומסתירה את המורכבויות של המערכת בקצה העורפי. כדי להתמודד עם האתגרים האלה, Apigee מאפשרת פיתוח וניהול של API Gateway או שרת proxy לפריסות היברידיות ופריסות מרובות עננים (multi-cloud).
- בוחרים את גישת הרינדור לאפליקציית האינטרנט של הקצה הקדמי בהתאם לתוכן (סטטי לעומת דינמי), לביצועי האופטימיזציה למנועי חיפוש ולציפיות לגבי מהירויות טעינת הדפים.
- כשבוחרים ארכיטקטורה לאפליקציות אינטרנט מבוססות-תוכן, יש מגוון אפשרויות, כולל ארכיטקטורות מונוליתיות, ללא שרתים, מבוססות-אירועים ומיקרו-שירותים. כדי לבחור את הארכיטקטורה המתאימה ביותר, חשוב להעריך את האפשרויות האלה ביחס לדרישות הנוכחיות והעתידיות של האפליקציה. כדי לעזור לכם לקבל החלטה לגבי הארכיטקטורה שתתאים ליעדים העסקיים והטכניים שלכם, תוכלו לעיין במאמרים השוואה בין ארכיטקטורות שונות של קצה עורפי לאפליקציות אינטרנט מבוססות-תוכן ונקודות מרכזיות לגבי קצה עורפי לאתרים.
באמצעות ארכיטקטורה של מיקרו-שירותים, אפשר להשתמש באפליקציות בקונטיינרים עם Kubernetes כשכבת זמן הריצה המשותפת. בעזרת דפוס הארכיטקטורה ההיברידית המדורגת, אפשר להריץ אותו באחד מהתרחישים הבאים:
בכל הסביבות (Google Cloud ובסביבות המקומיות).
- כשמשתמשים בקונטיינרים וב-Kubernetes בסביבות שונות, אפשר לשדרג את עומסי העבודה (workloads) ואז להעביר אותם אל Google Cloud בזמנים שונים. זה עוזר כשעומס עבודה תלוי מאוד בעומס עבודה אחר ולא ניתן להעביר אותו בנפרד, או כשרוצים להשתמש בניידות של עומסי עבודה היברידיים כדי להשתמש במשאבים הטובים ביותר שזמינים בכל סביבה. בכל המקרים, GKE Enterprise יכולה להיות טכנולוגיה מרכזית שמאפשרת את הפעולות האלה. למידע נוסף, ראו סביבה היברידית של GKE Enterprise.
בסביבה Google Cloud לרכיבי האפליקציה שהועברו ועברו מודרניזציה.
- כדאי להשתמש בגישה הזו אם יש לכם מערכות עורפיות מדור קודם במקום, שלא תומכות בשימוש בקונטיינרים או שנדרשים זמן ומשאבים משמעותיים כדי לעדכן אותן בטווח הקצר.
מידע נוסף על תכנון וארגון הקוד מחדש של אפליקציה מונוליתית לארכיטקטורת מיקרו-שירותים כדי לעדכן את ארכיטקטורת אפליקציית האינטרנט זמין במאמר מבוא למיקרו-שירותים.
אתם יכולים לשלב בין טכנולוגיות לאחסון נתונים בהתאם לצרכים של אפליקציות האינטרנט שלכם. שימוש ב-Cloud SQL לנתונים מובְנים וב-Cloud Storage לקובצי מדיה היא גישה נפוצה לטיפול בצרכים מגוונים של אחסון נתונים. עם זאת, הבחירה תלויה מאוד בתרחיש לדוגמה. למידע נוסף על אפשרויות לאחסון נתונים עבור קצה עורפי של אפליקציות מבוססות-תוכן ומודלים יעילים, ראו אפשרויות לאחסון נתונים עבור אפליקציות אינטרנט מבוססות-תוכן. אפשר גם לעיין במאמר הסבר על אפשרויות מסד הנתונים Google Cloud .