🥇ViennaNET: קבוצה של ספריות עבור הקצה האחורי

שלום לכולם!

אנחנו קהילה של מפתחי .NET ב- Raiffeisenbank ואנחנו רוצים לדבר על קבוצה של ספריות תשתית המבוססות על .NET Core ליצירה מהירה של שירותי מיקרו עם מערכת אקולוגית אחת. הם הביאו את זה לקוד פתוח!

קצת היסטוריה

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

הזמן חלף, הפרויקט התפצל בהדרגה, והיה רצון ליצור מודולים חדשים בצד הלקוח על מסגרת JS מודרנית ולהפעיל אותם בדפדפן. התחלנו לעבור מ-WCF/SOAP ל-REST/HTTP, אז היינו צריכים ספריות חדשות כדי להשיק במהירות שירותים המבוססים על AspNet WebApi. הגרסה הראשונה ב-.Net Framework 4.5 נעשתה על ידי האדריכל שלנו כמעט על ברכיו בזמנו הפנוי, אך מחוץ לקופסה היא אפשרה להשיק שירות עם שלוש שורות ב-Program.cs שהכיל הרשאה (NTLM), רישום, Swagger, IoC/DI מבוסס על Castle Windsor, לקוחות HTTP מותאמים אישית שמעבירים כותרות שונות כדי לספק רישום מקצה לקצה לאורך כל הפרויקט. ואפשר להגדיר את כל העניין הזה ישירות בקובץ תצורת השירות.

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

עידן דוקר וקוברנטס

הגיע הזמן שהגל של Docker ו-Kubernetes הגיע אלינו, שצפינו בו מקרוב: אחרי הכל, זו הייתה הזדמנות מצוינת להתחיל להתקדם הלאה לאורך הטכנולוגיות, ב-.Net Core. המשמעות היא שנצטרך תשתית חדשה להפעלת שירותים: חלק מהספריות עברו מ-.Net Framework ל-.Net Standard ו-.Net Core כמעט ללא שינויים, חלקן עם שיפורים קלים. אבל יותר מכל רציתי לעבד מחדש את הפונקציונליות הקשורה בהשקת שירותים ב-AspNet Core.

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

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

ולמה אנחנו צריכים קוד פתוח?

אנחנו רוצים להראות את הבשלות של המומחיות שלנו ולקבל משוב איכותי: אדם מחוץ לבנק יוכל להביא משהו מעצמו. אנו מעוניינים גם בפיתוח שיטות עבודה עם מיקרו-שירותים ו-DDD ב-.NET בתעשייה; אולי מישהו ירצה להשתלט על חלקים מסוימים של המסגרת.

למעשה, ViennaNET

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

ViennaNET.WebApi.*

קבוצת ספריות זו מורכבת מה-"שורש" ViennaNET.WebApi, המכילה את מחלקת ה-Builder עבור שירות CompanyHostBuilder, ומערכת קופיגורטורים ViennaNET.WebApi.Configurators.*, שכל אחת מהן מאפשרת לך להוסיף ולהגדיר פונקציונליות מסוימת לקובץ שנוצר. שֵׁרוּת. בין הקונפיגורטורים ניתן למצוא חיבורים לרישום, דיאגנוסטיקה, סוגי אימות והרשאות, סוויץ' וכו'.

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

ViennaNET.Mediator.*

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