האצת הטרנספורמציה הדיגיטלית בארגון על ידי מתן בסיס זמין מאוד ומוכן לייצור לאפליקציות אינטרנט מודרניות. המדריך הזה יעזור לכם להבין את תבנית האפליקציה Three-tier web app, שבעזרתה תוכלו לפרוס במהירות אפליקציית אינטרנט תלת-שכבתית ב- Google Cloud.
לדוגמה, אפשר להטמיע את התבנית הזו כדי לתת מענה לצרכים העסקיים הבאים:
| דוגמה | הצורך העסקי | הטמעה |
|---|---|---|
| פלטפורמה למסחר אלקטרוני | חברה קמעונאית צריכה נוכחות באינטרנט שיכולה להתמודד עם עליות פתאומיות בתנועה במהלך מכירות עונתיות, תוך שמירה על זמן אחזור נמוך לחיפושים ולרכישות של מוצרים. | משתמשים ברמת השירות של Cloud Run לחנות האינטרנט כדי להתאים את קנה המידה באופן אוטומטי על סמך נפח הבקשות. שכבת האמצע מטפלת בלוגיקה של המלאי, ו-Memorystore for Redis שומרת במטמון קטלוגים של מוצרים כדי להפחית את העומס על מסד הנתונים ואת זמן האחזור. |
| מערכת כרטיסי תמיכה טכנית | מחלקת IT ארגונית צריכה פורטל פנימי שבו העובדים יכולים לדווח על בעיות בחומרה ולעקוב אחרי בקשות תוכנה. | משתמשים בחלק הקדמי של Cloud Run כדי להזין בקשות של עובדים. החלק החזיתי מתקשר עם שכבת API כדי לנהל את הלוגיקה של ניתוב הכרטיסים והקצאת העדיפות. מסד הנתונים של Cloud SQL מכיל נתוני עובדים ויומני ביקורת של החלטות. |
ארכיטקטורה
בתמונה הבאה מוצגים הרכיבים והחיבורים באפליקציה:
תהליך עיבוד הבקשה באפליקציה:
- חלק הקצה הקדמי של Cloud Load Balancing מקבל בקשות חיצוניות ומפיץ את תעבורת הנתונים לקצה העורפי של Cloud Load Balancing.
- הקצה העורפי של Cloud Load Balancing מפזר את התנועה לשירות Cloud Run.
- שירות קצה קדמי מבוסס-אינטרנט של Cloud Run מעבד לקוח HTML בדפדפן של המשתמש.
- שירות הקצה הקדמי שולח בקשות לשכבת API, שגם היא נפרסת כשירות Cloud Run.
- Memorystore for Redis מאחסן במטמון ומציג נתונים שנקראים לעיתים קרובות.
- שכבת ה-API שולחת בקשות שהיא לא יכולה לטפל בהן ממטמון Redis בזיכרון למסד נתונים של Cloud SQL.
המאמרים הבאים
- למידע נוסף על שכפול והתאמה אישית של תבניות, אפשר לעיין במאמר מדריך למתחילים: התאמה אישית ופריסה של תבנית של Google.
- אפשר להגדיר הגדרות משלכם על ידי עיצוב תבניות של אפליקציות.
- כדי לזהות שיטות מומלצות כלליות לארכיטקטורה, אפשר לעיין בGoogle Cloud מסגרת הארכיטקטורה.