مرحبا بالجميع!
نحن مجتمع من مطوري .NET في Raiffeisenbank ونريد أن نتحدث عن مجموعة من مكتبات البنية التحتية المستندة إلى .NET Core لإنشاء خدمات صغيرة بسرعة باستخدام نظام بيئي واحد. لقد أحضروه إلى المصدر المفتوح!
القليل من التاريخ
ذات مرة كان لدينا مشروع كبير متجانس، والذي تحول تدريجياً إلى مجموعة من الخدمات المصغرة (يمكنك القراءة عن ميزات هذه العملية في
مر الوقت، وتم تجزئة المشروع تدريجيًا، وكانت هناك رغبة في إنشاء وحدات جديدة من جانب العميل على إطار عمل JS حديث وتشغيلها في المتصفح. لقد بدأنا في الانتقال من WCF/SOAP إلى REST/HTTP، لذلك كنا بحاجة إلى مكتبات جديدة لإطلاق الخدمات بسرعة استنادًا إلى AspNet WebApi. تم إنشاء الإصدار الأول على .Net Framework 4.5 من قبل مهندسنا المعماري وهو جاثي تقريبًا على ركبتيه في وقت فراغه، ولكنه أتاح إمكانية إطلاق خدمة بثلاثة أسطر في Program.cs تحتوي على ترخيص (NTLM)، تسجيل الدخول، Swagger، IoC/DI استنادًا إلى Castle Windsor، عملاء HTTP المخصصين الذين يعيدون توجيه الرؤوس المختلفة لتوفير تسجيل شامل طوال المشروع بأكمله. ويمكن تكوين هذا الأمر برمته مباشرةً في ملف تكوين الخدمة.
ومع ذلك، لم يكن كل شيء سلسا: تبين أن هذه المكتبة غير مرنة للغاية من حيث إدخال وحدات جديدة. على سبيل المثال، إذا كنت بحاجة إلى إضافة بعض البرامج الوسيطة الخاصة، كان عليك إنشاء تجميع جديد والوراثة من الفئة الأساسية التي تدير الخدمة، وهو أمر غير مريح للغاية. ولحسن الحظ، لم يكن هناك الكثير من هذه الحالات.
عصر Docker وKubernetes
لقد حان الوقت عندما وصلت إلينا موجة Docker وKubernetes، والتي شاهدناها عن كثب: بعد كل شيء، كانت فرصة عظيمة لبدء المضي قدمًا عبر التقنيات، في .Net Core. وهذا يعني أننا سنحتاج إلى بنية تحتية جديدة لتشغيل الخدمات: لقد انتقلت بعض المكتبات من .Net Framework إلى .Net Standard و.Net Core عمليًا بدون تغييرات، وبعضها مع تحسينات طفيفة. ولكن الأهم من ذلك كله أنني أردت إعادة صياغة الوظائف المرتبطة بإطلاق الخدمات على AspNet Core.
أول شيء فكرنا فيه هو المفهوم الذي من شأنه أن يزيل العيب الرئيسي للإصدار السابق: الافتقار إلى المرونة. لذلك، تقرر جعل نظام المكتبة بأكمله مستقلاً ومعياريًا قدر الإمكان وجمع الخدمات اللازمة للوظيفة كمنشئ.
الهدف الرئيسي هو إنشاء نهج موحد يصف كيفية التفاعل مع قواعد البيانات والحافلات والخدمات الأخرى. لقد حاولنا أن نجعل عمليات التكامل سريعة وغير مؤلمة، ويمكن للمطورين التركيز على كتابة منطق الأعمال بدلاً من البنية التحتية - فهي جاهزة بالفعل. يساعد المستودع المشترك على تحسين تجربة التفاعل داخل الفرق: عند استخدام بنيات تحتية داخلية متشابهة جدًا، يكون من الأسهل الانضمام إلى عملية تطوير فريق آخر وتبادل الخبرات.
ولماذا نحتاج إلى المصادر المفتوحة؟
نريد أن نظهر نضج خبرتنا وأن نتلقى تعليقات عالية الجودة: سيتمكن أي شخص من خارج البنك من تقديم شيء ما من تلقاء نفسه. نحن مهتمون أيضًا بتطوير ممارسات العمل مع الخدمات الصغيرة وDDD على .NET في الصناعة؛ ربما يرغب شخص ما في تولي أجزاء معينة من إطار العمل.
في الواقع، فيينا نت
الآن دعونا نلقي نظرة فاحصة.
فييناNET.WebApi.*
تتكون هذه المجموعة من المكتبات من ViennaNET.WebApi "الجذر"، الذي يحتوي على فئة الإنشاء لخدمة CompanyHostBuilder، ومجموعة من أدوات التهيئة ViennaNET.WebApi.Configurators.*، والتي تتيح لك كل منها إضافة وتكوين بعض الوظائف إلى المكتبات التي تم إنشاؤها خدمة. من بين أدوات التهيئة، يمكنك العثور على اتصالات للتسجيل والتشخيص وأنواع المصادقة والتفويض والتباهي وما إلى ذلك.
يحتوي ViennaNET.WebApi.Runners.* أيضًا على منشئي خدمات تم تكوينهم مسبقًا. تسمح لك هذه الحزم بعدم التذكر في كل مرة تقوم فيها بإنشاء خدمة جديدة والتي يحتاج المكوّنون إلى توصيلها. ومع ذلك، فهي لا تحد من وظائف منشئ الخدمة بأي شكل من الأشكال.
فييناNET.Mediator.*
المكتبات التي تسمح لك بإنشاء ناقل وسيط داخلي للأوامر والطلبات داخل الخدمة. يتيح لك هذا الأسلوب تقليل عدد حقن DI إلى حقنة واحدة، على سبيل المثال، في وحدات التحكم. ونتيجة لذلك، يمكنك إضافة العديد من أدوات الديكور للطلبات، مما يوحد معالجتها ويقلل من كمية التعليمات البرمجية.
فييناNET.Validation
تجميع يحتوي على مجموعة من الفئات لإنشاء قواعد وتسلسلات التحقق منها. إنه مناسب جدًا لتنفيذ التحقق من صحة النطاق، لأنه يسمح لك بوصف كل حالة عمل في شكل قاعدة بسيطة ومنفصلة.
فييناNET.Redis
مكتبة بها أغلفة للعمل المريح مع Redis كذاكرة تخزين مؤقت في الذاكرة.
فيينا نت. المواصفات
تجميع يحتوي على فئات تقوم بتنفيذ نمط المواصفات.
وهذا ليس كل ما في مجموعتنا. يمكنك رؤية الباقي
شكرا لاهتمامكم، ونحن نتطلع إلى تعليقاتكم وسحب الطلبات.
المصدر: www.habr.com