דיכוטומיה של הנתונים: חשיבה מחודשת על הקשר בין נתונים ושירותים

שלום לכולם! יש לנו חדשות טובות, OTUS משיקה את הקורס שוב ביוני "ארכיטקט תוכנה", שבקשר אליו אנו חולקים איתך באופן מסורתי חומר שימושי.

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

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

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

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

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

Encapsulation לא תמיד יהיה חבר שלך

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

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

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

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

רוב השירותים העסקיים משתמשים באותו זרם נתונים, כך שעבודתם קשורה זו בזו.

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

דיכוטומיה של נתונים

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

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

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

וכאן מתעוררת דילמה. סְתִירָה. דיכוטומיה. אחרי הכל, מערכות מידע עוסקות במתן נתונים, ושירותים עוסקים במחבוא.

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

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

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

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

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

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

ככל שהעותקים ניתנים לשינוי, כך הנתונים ישתנו יותר לאורך זמן.

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

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

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

מחזור כשל נתונים

זרימות: גישה מבוזרת לנתונים ושירותים

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

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

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

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

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

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

היפטר מהדיכוטומיה של הנתונים על ידי פיצול זרם המצב הבלתי ניתן לשינוי. לאחר מכן הוסף פונקציונליות זו לכל שירות באמצעות Stateful Stream Processing.

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

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

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

לכן, לגישה שנידונה היום יש מספר יתרונות:

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

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

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

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

למידע נוסף על הקורס.

מקור: www.habr.com