כדי למקסם את הערך של הנתונים מהמכשירים המחוברים, ארגונים צריכים להיות מסוגלים לבצע ניתוח נתונים. יש הרבה דרכים שבהן ארגונים יכולים לחבר את המכשירים שלהם לאפליקציות ניתוח הנתונים שלהם, והיתרונות של ארכיטקטורות מסוימות של מכשירים מחוברים יכולים להשתנות בהתאם לתרחיש השימוש של הארגון. כדי לעזור לכם, במאמר הזה מתוארים כמה סוגים של ארכיטקטורות של מכשירים מחוברים ב- Google Cloud. הארכיטקטורות האלה מתאימות למגוון רחב של תרחישי שימוש ודרישות למכשירים מחוברים.
המסמך הזה הוא חלק מסדרת מסמכים שמספקים מידע על ארכיטקטורות של IoT ב- Google Cloud. מסמכים אחרים בסדרה הזו כוללים את:
- ארכיטקטורות של מכשירים מחוברים במאמר Google Cloud סקירה כללית (המסמך הזה).
- שרת MQTT עצמאי: שרת MQTT מספק תקשורת דו-כיוונית בין מכשירים מחוברים לבין פרויקטים שלGoogle Cloud , ובין המכשירים עצמם.
- ארכיטקטורה של פלטפורמת IoT ב- Google Cloud: פלטפורמת IoT מספקת יכולות נוספות לניהול מכשירים, וגם קישוריות נתונים, שחשובה כשפורסים מספר גדול של מכשירים מחוברים.
- חיבור ישיר ל-Pub/Sub: כדי להטמיע נתונים, יכול להיות שהאפשרות הכי טובה היא שהמכשירים שלכם יתחברו ישירות ל-Pub/Sub.
- שיטות מומלצות להרצת קצה עורפי של IoT ב- Google Cloud.
- שיטות מומלצות להקצאה ולהגדרה אוטומטיות של מערכות ושרתים מסוג Edge ו-Bare Metal.
סיכום של ארכיטקטורות של מכשירים מחוברים
במסמך הזה ריכזנו תרחישים לדוגמה לשימוש במכשירים מחוברים בשלוש קטגוריות, על סמך המאפיינים הבאים שכדאי לקחת בחשבון כשמתכננים ארכיטקטורה של מכשירים מחוברים:
מספר המכשירים: חשוב לקחת בחשבון כמה מכשירים מחוברים ישירות לאפליקציה. אם לאפליקציה שלכם יש הרבה מכשירי קצה (כמו מכונות, חיישנים או מצלמות), והמכשירים האלה מחוברים לשער ביניים או למכשיר אחר (כמו טלפון נייד), חשוב לזהות אם מכשירי הקצה האלה צריכים להיות מיוצגים ומנוהלים באפליקציה שלכם. במקרים מסוימים, יכול להיות שתצטרכו לייצג כל מכשיר בנפרד. במקרים אחרים, יכול להיות שתצטרכו לייצג רק את המכשיר המתווך.
ניהול צי: כדאי לשקול אם אתם צריכים יכולות כמו מעקב אחרי סטטוס המכשיר, עדכוני תוכנה וקושחה, ניהול הגדרות ותכונות אחרות של ניהול צי. הדרישות האלה עוזרות לכם לבחור את ארכיטקטורת האפליקציה.
העברת הודעות בין מכשירים: תקשורת בין מכשירים באמצעות ארכיטקטורת האפליקציה היא גורם חשוב. לדוגמה, יש אפליקציות שמסתמכות על תקשורת בין המכשירים המחוברים באמצעות ארכיטקטורת האפליקציה. באפליקציות אחרות, זרימות הנתונים מתרחשות אך ורק בין כל מכשיר לבין האפליקציה, ללא העברת הודעות בין המכשירים.
טבלת סיכום
הבנת המאפיינים של האפליקציה יכולה לעזור לכם לבחור את הארכיטקטורה הטובה ביותר לתרחיש השימוש שלכם. כדי לעזור לכם לבחור, בטבלה הבאה מפורטות אפשרויות התמיכה שכל אחת מהארכיטקטורות המחוברות שמתוארות בסדרה הזו מציעה:
| מגבלות על תמיכה במכשירים | העברת הודעות בין מכשירים | תמיכה בניהול ה-Fleet | |
|---|---|---|---|
| MQTT Broker | מיליונים | מומלץ | לא נתמך |
| פלטפורמת IoT | מיליונים | תמיכה מסוימת | מומלץ |
| מכשיר ל-Pub/Sub | מאות | תמיכה מסוימת | לא נתמך |
המאמרים הבאים
- כדאי לקרוא על הארכיטקטורה הטובה ביותר של מכשירים מחוברים לתרחיש השימוש שלכם:
- בקורס Intelligent Products Essentials תלמדו איך לחבר מכשירים ולפתח אפליקציות IoT ב- Google Cloud .
- מידע על שיטות מומלצות להקצאה אוטומטית ולהגדרה של מערכות ושרתים מסוג Edge ו-Bare Metal
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.