ארכיטקטורת הקצה העורפי מתייחסת לאופן שבו הקצה העורפי של אפליקציית האינטרנט שלכם בנוי. ארכיטקטורת הקצה העורפי קובעת איך חלקים באפליקציה מתקשרים ביניהם כדי לעבד בקשות נכנסות וליצור תשובות. כשאתם מפתחים אפליקציית אינטרנט, כדאי לבחור ארכיטקטורת קצה עורפי על סמך הדרישות והגורמים הספציפיים שלכם, כולל עלות (מתמשכת וגם בקנה מידה נרחב), המורכבות של האפליקציה, התאמת היעדים והמומחיות של הצוות.
באפליקציות אינטרנט מבוססות-תוכן, כמו מסחר אלקטרוני, עיתונים או בלוגים, הדרישות הקריטיות כוללות עקביות של הנתונים והביצועים, במיוחד כשהאפליקציה הולכת וגדלה בקנה מידה גלובלי ועשויה להיות מבוזרת יותר. באפליקציות אינטרנט מבוססות-תוכן, גם אחסון הנתונים באפליקציה שלכם הוא קריטי, וניתן לדון בו בפירוט במדריך אחסון הנתונים. כדי לבצע אופטימיזציה של ביצועי האפליקציה, חשוב להתקדם מעבר לארכיטקטורות של אפליקציות טיפוסיות, לארח את התוכן ולאפשר גישה אליו. למידע נוסף, אפשר לקרוא את המאמר בחירת אסטרטגיית אירוח מתאימה ואופטימיזציה של האפליקציה במדריך לאירוח.
אם יש לכם קצה עורפי קיים לאפליקציית אינטרנט, צריך להביא בחשבון את מגבלות הארכיטקטורה הנוכחית. לדוגמה, כשהאפליקציה שלכם גדלה ומתרחבת בהתאם לביצועים ולאמינות של האפליקציה, כדאי לבדוק אם צריך להעביר חלקים באפליקציה לארכיטקטורה אחרת או לארכיטקטורה אחרת שמתאימה יותר לקנה המידה המוגדל. לדוגמה, ארכיטקטורות היברידיות (או מרובות עננים) מאפשרות להעביר עומסי עבודה מסוימים לענן לפני ביצוע מעבר מלא. חשוב להביא בחשבון גם את העלות, הזמן והסיכון הכרוכים בהעברה כזו.
ארכיטקטורות מונוליתיות
לארכיטקטורה מונוליתית יש מבנה מאוחד, וכל רכיבי האפליקציה משולבים היטב ב-codebase אחד. האפליקציה כולה בנויה כיחידה אחת שעומדת בפני עצמה. הארכיטקטורה המונוליתית היא רב-שכבתית, שבה שכבות שונות של האפליקציה מבצעות משימות ספציפיות.
שכבות מבניות
- ממשק המשתמש (UI), שכולל רכיבים להצגת התכונות של האפליקציה, הוא בדרך כלל אפליקציה מבוססת-אינטרנט או אפליקציה למחשב שמנהלת אינטראקציה עם המשתמשים.
- הלוגיקה של האפליקציה היא המקום שבו נמצאת הפונקציונליות העיקרית.החלק הזה של ה-codebase מכיל את הכללים, החישובים והפעולות שמגדירים את אופן הפעולה של האפליקציה.
- שכבת הגישה לנתונים מכילה פונקציות לקריאה ולכתיבה של נתונים, ולתרגום בין מבני הנתונים של האפליקציה לסכימת מסד הנתונים. השכבה הזו אחראית לאינטראקציה עם מסד הנתונים או עם אחסון הנתונים של האפליקציה.
- מסד הנתונים הוא המקום שבו האפליקציה מאחסנת את הנתונים שלה. בדרך כלל יש מסד נתונים יחיד שמאחסן את כל נתוני האפליקציה, כולל נתוני משתמשים, הגדרות ומידע נוסף.
- רכיבי תווכה מטפלים במשימות כמו אימות, ניתוב בקשות ואימות נתונים. הרכיבים האלה עוזרים לנהל את זרימת הנתונים והבקשות.
- לאפליקציות מונוליתיות מסוימות יש נקודות שילוב עם שירותים חיצוניים או ממשקי API. הנקודות האלה מאפשרות לאפליקציה ליצור אינטראקציה עם שירותים של צד שלישי, מקורות נתונים או מערכות אחרות.
השכבות המבניות הן בדרך כלל חלק מ-codebase יחיד. בסיס הקוד הזה מכיל את כל האפליקציה, ובדרך כלל הוא מאורגן בספריות, במודולים ובמחלקות. המפתחים עובדים על חלקים שונים ב-codebase כדי לפתח ולתחזק את האפליקציה. עם זאת, כל האפליקציה נפרסת בדרך כלל כיחידה אחת. כשמתבצעים עדכונים או שינויים, כל האפליקציה נפרסת מחדש.
אתגרים פוטנציאליים
- ככל שיישומים מונוליטיים גדלים, קוד ה-codebase נהיה מורכב וקשה יותר לתחזק אותו. לכן יכולות להיות מחזורי פיתוח ארוכים וקשה להבין את כל ה-codebase.
- פריסת שינויים באפליקציה מונוליתית עלולה להיות מסוכנת, כי שינויים שמבצעים בחלק אחד של הקוד עלולים להשפיע בטעות על חלקים אחרים באפליקציה. כך ניתן ליצור תהליך פריסה ארוך ועם נטייה לשגיאות.
- לפעמים קשה לבצע התאמה לעומס (scaling) של אפליקציות מונוליתיות כי הן פרוסות כיחידה אחת. עליכם להתאים את האפליקציה כולה, גם אם רק לרכיב אחד יש ביקוש גבוה יותר.
- לעיתים קרובות, אפליקציות מונוליתיות מסתמכות על סטאק טכנולוגיה יחיד או על שפת תכנות אחת. יכול להיות שתהיה הגבלה על האפשרות להשתמש בכלי הטוב ביותר לביצוע משימה ספציפית באפליקציה.
- גם בתקופות של ביקוש נמוך, כדי להפעיל יישומים מונוליטיים, נדרש משאבים משמעותיים. עלויות התחזוקה עולות גם ככל שהאפליקציות מתקדמות, כי קשה יותר לעדכן ולתקן את האפליקציה בלי לגרום לרגרסיות.
- לעיתים קרובות, צוותי הפיתוח שעובדים על אפליקציות מונוליטיות מאורגנים בכל רחבי האפליקציה, כך שהצוותים גדולים יותר והתיאום בין חברי הצוות מורכב יותר.
שימוש מוצע
ארכיטקטורות מונוליתיות מתאימות במיוחד כאשר לאפליקציה יש דרישות צנועות וצוות הפיתוח קטן. ככל שהמורכבות וקנה המידה של האפליקציות גדלים, או כשחלקים שונים באפליקציה דורשים טכנולוגיה שונה או אסטרטגיות פריסה שונות, הארכיטקטורות המונוליטיות עשויות להיות פחות גמישות ומאתגרות יותר בתחזוקה.
ניתן ליצור ולנהל מכונות וירטואליות שיכולות להריץ אפליקציות מונוליתיות ב-Compute Engine. יש לכם שליטה מלאה במערכות ההפעלה, בתוכנה ובניהול של המכונות הווירטואליות כדי להפעיל את האפליקציה המונוליתית שלכם.
באמצעות שירות של פלטפורמה כשירות, כמו App Engine, אתם יכולים לפתח את האפליקציה ולהפעיל אותה בתשתית מנוהלת שמותאמת לעומס (scaling) באופן אוטומטי לפי בקשות.
אם האפליקציה המונוליתית שלכם היא בקונטיינרים, תוכלו להריץ אותה באמצעות Google Kubernetes Engine (GKE) או באמצעות Cloud Run. אפשר להשתמש בשירותים כמו Cloud SQL או Cloud Spanner כדי לאחסן נתונים של אפליקציות מונוליתיות. כדאי לשקול שילוב של שירותים ומערכות בהתאם לדרישות הספציפיות של האפליקציה שלכם.
ארכיטקטורות ללא שרת (serverless)
באמצעות ארכיטקטורה ללא שרת אפשר ליצור ולהפעיל אפליקציות בלי לנהל שרתים פיזיים או וירטואליים. ספק שירותי הענן מנהל באופן אוטומטי את התשתית, התאמה לעומס (scaling) והקצאת המשאבים, כדי שהמפתחים יוכלו להתמקד בכתיבת הקוד לאפליקציות שלהם. ארכיטקטורות ללא שרת (serverless) יכולות לפשט את הפיתוח, לצמצם את התקורה התפעולית ולייעל את העלויות, כי לא צריך לתחזק שרתים. הם מתאימים במיוחד למיקרו-שירותים, לעיבוד נתונים בזמן אמת, לאפליקציות אינטרנט עם עומסי עבודה משתנים ולעיבוד אירועים.
ארכיטקטורות ללא שרת (serverless) שמבוססות על אירועים
ארכיטקטורות ללא שרת (serverless) הן סוג ספציפי של ארכיטקטורת מחשוב ללא שרת שמסתמכת על אירועים או טריגרים כדי להפעיל את הפונקציות או המיקרו-שירותים. רכיבי המערכת מתקשרים ביניהם באמצעות אירועים, והפונקציות מופעלות בתגובה לאירועים. לעיתים קרובות הם מסתמכים על תקשורת אסינכרונית כי אירועים מופעלים על ידי אירועים, ואז מעבדים אותם באופן עצמאי והם עשויים ליצור אירועים שיפעילו את הפעולות הבאות. הארכיטקטורה ללא שרת (serverless) מהסוג הזה מתאימה לבניית מערכות ניתנות להתאמה, מגיבות ומוצמדות באופן רופף.
בעזרת Google Cloud Functions ו-Cloud Functionss for Firebase אפשר ליצור ולפרוס פונקציות מבוססות-אירועים בסביבה מנוהלת וללא שרת (serverless). היא מאפשרת להריץ קוד בתגובה לאירועים ולטריגרים שונים, כולל בקשות HTTP, הודעות Cloud Pub/Sub, שינויים ב-Google Cloud Storage ועדכונים של מסד הנתונים בזמן אמת ב-Firebase, ללא צורך בניהול התשתית. התכונות העיקריות כוללות תמיכה בשפות מרובות, יכולת התאמה לעומס (scaling), חיוב מפורט, שילוב עם צד שלישי, רישום ביומן ומעקב מבוססים ושילוב עם שירותים אחרים של Google ו-Firebase.
ארכיטקטורות ללא שרת (serverless) יכולות להיות חסכוניות בתרחישים רבים לדוגמה, במיוחד באפליקציות עם עומסי עבודה שונים, צורכי פיתוח מהירים ותעבורת נתונים בלתי צפויה. האמינות תלויה בספק שירותי הענן, תוך שימוש בהסכמי רמת שירות (SLA) כדי להבטיח יעדים ספציפיים של ביצועים ומהימנות. עליכם להעריך את התרחיש לדוגמה ואת הדרישות הספציפיות שלכם, כדי להחליט אם האפשרות הטובה ביותר היא ארכיטקטורה ללא שרת (serverless).
הובלה במכולות
יצירת קונטיינרים מאפשרת לארוז אפליקציות ואת יחסי התלות שלהן בקונטיינרים קלים וניידים. הם מספקים סביבת אפליקציות עקבית שתומכת בפיתוח ובפריסה במערכות ובפלטפורמות שונות. בחלק מהפלטפורמות ללא שרת אפשר להריץ עומסי עבודה בקונטיינרים. הרצת קונטיינרים בסביבה ללא שרת יכולה להיות מועילה כשיש עומסי עבודה מורכבים או כאלה שלא ניתן לבטא כפונקציות בסיסיות. הוא מספק גמישות ביחס לתמיכה בשפות וסביבות זמן ריצה.
Cloud Run הוא פלטפורמת מחשוב ללא שרת, שמאפשרת למפתחים לפרוס ולהפעיל אפליקציות בקונטיינרים בסביבה מנוהלת. היא מספקת דרך פשוטה ליצירה, לפריסה ולהתאמה לעומס (scaling) של אפליקציות בלי לנהל את התשתית הבסיסית. הוא מתאים למגוון רחב של אפליקציות לאינטרנט ומיקרו-שירותים, במיוחד לכאלה עם עומסי עבודה משתנים, ושיצירת קונטיינרים מציעה יתרונות מבחינת אריזה ועקביות של אפליקציות.
ארכיטקטורות מיקרו-שירות
אפליקציות מחולקות לחלקים קטנים שמחוברים באופן רופף ומטמיעות תכונות או יכולות ייחודיות. השירותים האלה עשויים לתקשר באמצעות הודעות אסינכרוניות, ערוצים שמבוססים על אירועים או ישירות על ידי חשיפת ממשק. כל שירות פיתוח, בדיקה והתאמה לעומס (scaling) באופן עצמאי בקונטיינר שלו, שמנוהל בדרך כלל באמצעות שירות תזמור, כמו Kubernetes, או פרוס באמצעות פלטפורמה מנוהלת, כמו Cloud Run.
פריסות של מיקרו-שירותים בדרך כלל מנצלות גם את פרדיגמת האפליקציות ללא שרת (serverless) כי הן לא מסתמכות על שרת מרכזי.
הפרדת אפליקציה לשירותים אוטונומיים יכולה לפשט מערכת מורכבת. גבולות ויעדים מוגדרים היטב יכולים לזרז את הפיתוח ולשפר את התחזוקה. אפשר לפתח כל מיקרו-שירות באופן עצמאי באמצעות המסגרות או הכלים היעילים ביותר. התקשורת בין השירותים מטופלת לעיתים קרובות באמצעות אירועים, תקשורת בין מפרסמים, צינורות עיבוד נתונים של הודעות או קריאות לשירות מרוחק, כמו gRPC.
לתזמור משימות בארכיטקטורת מיקרו-שירותים, כדאי להשתמש במסגרת שתומכת בפלטפורמות שאליהן אתם מטרגטים, שיש מספיק עומק למשימות ולסוגים של תהליכי העבודה שאתם מתזמנים, וגם טיפול בשגיאות וטלמטריה לניפוי באגים. אפשרויות פופולריות כוללות קושר או הצעות של ספק שירותי ענן, כמו Google Workflows.
בגלל האופי המבוזר והצורך בתקשורת בתוך השירות, אפליקציות שמבוססות על מיקרו-שירותים יכולות להיות מסובכות לפיתוח ולתחזק. לכן ניהול הפריסות, המעקב והרישום ביומן הם מורכבים יותר מאפשרויות ארכיטקטורה אחרות. האמינות תלויה בארכיטקטורה של השירותים הנפרדים, ולכן הטבע המבוזר עשוי לספק עמידות נוספת, במיוחד אם פרוסים מעקב וטלמטריה פרוסים ומפעילים אותם במקרה הצורך.
השוואה בין ארכיטקטורות שונות לקצוות עורפיים של אפליקציות אינטרנט מבוססות-תוכן
בטבלה הבאה מוצגת השוואה בין הארכיטקטורות לבין הדרישות של המפתחות לקצה העורפי של אפליקציית אינטרנט מבוססת-תוכן.
| ארכיטקטורות מונוליתיות | ארכיטקטורות ללא שרת (serverless) שמבוססות על אירועים | ארכיטקטורות ללא שרת (serverless) | |
|---|---|---|---|
| מורכבות ותחזוקה |
|
|
|
| מדרגיות וביצועים |
|
|
|
| אסטרטגיות של עמידות לאורך זמן |
|
|
|
| ניסיון בפיתוח |
|
|
|
| עלות |
|
|
|
למידע נוסף על ארכיטקטורות של קצה עורפי עבור אפליקציות אינטרנט מבוססות-תוכן
ריכזנו כאן כמה מקורות מידע עם מידע נוסף על ארכיטקטורות של אפליקציות אינטרנט מבוססות-תוכן, כולל אופן העברת האפליקציה לארכיטקטורה אחרת:
- מידע נוסף על ארכיטקטורות קצה עורפי של אפליקציות אינטרנט בצימוד חלש, כולל אפליקציות אינטרנט מונוליתיות ואפליקציות ללא שרת (serverless).
תרחישים לדוגמה של פונקציות Cloud Functions ללא שרת (serverless).