סקירה קצרה של מערכות תגובתיות

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

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

מהן מערכות תגובתיות?

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

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

זרמים ריאקטיביים

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

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

לחץ אחורי

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

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

מה לגבי תכנות תגובתי?

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

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

אם איור עם קוד עובד טוב יותר, אני ממליץ לקרוא את פוסט ההדרכה של אנדרה סטאלץ שעוסק בתמצית התכנות תגובתי ב- JavaScript באמצעות RxJS.

תגובתי X

ReactiveX, המכונה Extensions Reactive, היא ספריית API המאפשרת שימוש בפעולות קומפוזיציה לטיפול בזרמים של אירועים אסינכרוניים. הרחבה מתבנית הצפייה, תצפיות ותצפיתנים (שהם מנויים לתצפיות) מהווים את מרכיבי המפתח בספרייה עם קבוצה של אופרטורים להלחנה לסינון, טרנספורמציה, צבירה וכו '. RxJS ו- RxJava הם שניים מהיישומים הפופולריים ביותר של ReactiveX ב- JavaScript וב- Java בהתאמה.

שחקני עכה

Akka היא ספרייה מבוססת-שחקן הממוקדת לבניית יישומים ניתנים להרחבה בו זמנית ומופצת ב- JVM (Java Virtual Machine). בבסיסו פרימיטיבים חישוביים הנקראים שחקנים השומרים על מצב והתנהגות, ומתקשרים ביניהם באמצעות העברת מסרים א-סינכרונית.

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

עכו נחלים

מצטיין (וחבר מייסד) של יוזמת הזרמים התגובתיים הוא Akka Streams. הוא בנוי על גבי שחקני Akka ומספק מערך ממשקי API נרחב לבניית טופולוגיות זרם ועיבוד זרמים בצורה קומפוזיטיבית ביותר. פוסט בבלוג שלי לאחרונה מתרכז סביב זרמי עכו וכיצד ניתן להשתמש בו לביצוע כריית טקסט בסיסית.

ככל הנראה, עכו זורם כיוזמה תגובתית חותר בימים אלה. מנהלי התקנים מבוססי Akka-Streams כגון Reactive Rabbit ו- ReactiveMongo for RabbitMQ ו- MongoDB החלו לצבור תאוצה מסוימת בתעשיית הטכנולוגיה. בנוסף, Akka HTTP, שהוא הדור הבא של ערכת הכלים Spray REST / HTTP, בנוי גם כדי להיות מופעל לזרם עם זרמי Akka כמנוע הבסיסי שלו.

כל הזרמים מכוונים - בצורה כלשהי

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

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

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