he

איך זה עובד?

זקוק לעזרה לעסקים?

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

מונוליטי או מיקרו שירות?

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

אפשרות 1. ארכיטקטורה מונוליתית (מונולית)

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

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

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

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

אפשרות 2. ארכיטקטורת Microservice

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

ניתן להשוות

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

לארכיטקטורה זו יש יתרונות רבים, אך אציין את החשובים שבהם:

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

דוגמאות מהחיים האמיתיים

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

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

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

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

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

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

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

.