Xin chào tất cả mọi người!
Chúng tôi là một cộng đồng gồm các nhà phát triển .NET tại Raiffeisenbank và chúng tôi muốn nói về một bộ thư viện cơ sở hạ tầng dựa trên .NET Core để nhanh chóng tạo ra các dịch vụ vi mô với một hệ sinh thái duy nhất. Họ đã mang nó đến Nguồn mở!
Một chút lịch sử
Ngày xửa ngày xưa, chúng tôi có một dự án nguyên khối lớn, dần dần biến thành một tập hợp các dịch vụ vi mô (bạn có thể đọc về các tính năng của quy trình này trong ). Trong quá trình này, chúng tôi gặp phải vấn đề là khi tạo microservice mới, chúng tôi thường phải sao chép nhiều giải pháp cơ sở hạ tầng khác nhau - chẳng hạn như thiết lập ghi nhật ký, làm việc với cơ sở dữ liệu, WCF, v.v. Một nhóm đã làm việc trong dự án này và mọi người đều đã quen với một số cách tiếp cận đã được thiết lập để làm việc với cơ sở hạ tầng. Do đó, chúng tôi đã tách mã chung thành một kho lưu trữ riêng, gói các thư viện đã thu thập được trong các gói Nuget và đặt chúng vào kho lưu trữ Nuget nội bộ của chúng tôi.
Thời gian trôi qua, dự án dần bị phân mảnh và có mong muốn tạo ra các mô-đun phía máy khách mới trên khung JS hiện đại và chạy chúng trên trình duyệt. Chúng tôi đã bắt đầu chuyển từ WCF/SOAP sang REST/HTTP, vì vậy chúng tôi cần các thư viện mới để nhanh chóng khởi chạy các dịch vụ dựa trên AspNet WebApi. Phiên bản đầu tiên trên .Net Framework 4.5 được kiến trúc sư của chúng tôi tạo ra gần như hoàn toàn trong thời gian rảnh rỗi, nhưng ngay từ đầu, nó đã có thể khởi chạy một dịch vụ với ba dòng trong Program.cs có chứa ủy quyền (NTLM), ghi nhật ký, Swagger, IoC/DI dựa trên Castle Windsor, các máy khách HTTP tùy chỉnh chuyển tiếp các tiêu đề khác nhau để cung cấp tính năng ghi nhật ký từ đầu đến cuối trong toàn bộ dự án. Và toàn bộ điều này có thể được cấu hình thêm trực tiếp trong tệp cấu hình dịch vụ.
Tuy nhiên, không phải mọi thứ đều suôn sẻ: thư viện này hóa ra lại cực kỳ thiếu linh hoạt trong việc giới thiệu các mô-đun mới. Ví dụ: nếu bạn cần thêm một số phần mềm trung gian đặc biệt, bạn phải tạo một tập hợp mới và kế thừa từ lớp cơ sở chạy dịch vụ, điều này cực kỳ bất tiện. May mắn thay, những trường hợp như vậy không có nhiều.
Kỷ nguyên của Docker và Kubernetes
Đã đến lúc làn sóng Docker và Kubernetes đến với chúng tôi, điều mà chúng tôi đã theo dõi chặt chẽ: xét cho cùng, đây là cơ hội tuyệt vời để bắt đầu tiến xa hơn về công nghệ, trong .Net Core. Điều này có nghĩa là chúng tôi sẽ cần cơ sở hạ tầng mới để chạy các dịch vụ: một số thư viện đã di chuyển từ .Net Framework sang .Net Standard và .Net Core trên thực tế mà không có thay đổi nào, một số có những cải tiến nhỏ. Nhưng trên hết tôi muốn làm lại chức năng liên quan đến việc khởi chạy các dịch vụ trên AspNet Core.
Điều đầu tiên chúng tôi xem xét là một ý tưởng có thể loại bỏ nhược điểm chính của phiên bản trước: thiếu tính linh hoạt. Do đó, người ta đã quyết định làm cho toàn bộ hệ thống thư viện trở nên độc lập và mô-đun nhất có thể, đồng thời thu thập các dịch vụ cần thiết cho chức năng với tư cách là một nhà xây dựng.
Mục tiêu chính là tạo ra một cách tiếp cận thống nhất mô tả cách tương tác với cơ sở dữ liệu, xe buýt và các dịch vụ khác. Chúng tôi đã cố gắng tích hợp nhanh chóng và dễ dàng, đồng thời các nhà phát triển có thể tập trung vào việc viết logic nghiệp vụ thay vì cơ sở hạ tầng - nó đã sẵn sàng. Một kho lưu trữ chung giúp cải thiện trải nghiệm tương tác trong các nhóm: khi sử dụng cơ sở hạ tầng nội bộ rất giống nhau, việc tham gia vào quá trình phát triển của nhóm khác và trao đổi kiến thức chuyên môn sẽ dễ dàng hơn.
Và tại sao chúng ta cần Nguồn mở?
Chúng tôi muốn thể hiện sự trưởng thành về chuyên môn của mình và nhận được phản hồi chất lượng cao: một người bên ngoài ngân hàng sẽ có thể mang lại điều gì đó cho riêng họ. Chúng tôi cũng quan tâm đến việc phát triển các phương pháp làm việc với microservice và DDD trên .NET trong ngành; có lẽ ai đó sẽ muốn tiếp quản một số phần nhất định của khung.
Trên thực tế, ViennaNET
Bây giờ chúng ta hãy xem xét kỹ hơn. .
ViennaNET.WebApi.*
Bộ thư viện này bao gồm ViennaNET.WebApi “gốc”, chứa lớp trình xây dựng cho dịch vụ CompanyHostBuilder và một bộ cấu hình ViennaNET.WebApi.Configurators.*, mỗi bộ cho phép bạn thêm và định cấu hình một số chức năng cho các chức năng đã tạo dịch vụ. Trong số các bộ cấu hình, bạn có thể tìm thấy các kết nối để ghi nhật ký, chẩn đoán, các loại xác thực và ủy quyền, vênh vang, v.v.
ViennaNET.WebApi.Runners.* cũng chứa các trình tạo dịch vụ được định cấu hình sẵn. Các gói này cho phép bạn không nhớ mỗi khi tạo một dịch vụ mới mà các bộ cấu hình cần được kết nối. Tuy nhiên, chúng không giới hạn chức năng của người xây dựng dịch vụ dưới bất kỳ hình thức nào.
ViennaNET.Mediator.*
Các thư viện cho phép bạn tạo một bus trung gian nội bộ cho các lệnh và yêu cầu trong một dịch vụ. Cách tiếp cận này cho phép bạn giảm số lần tiêm DI xuống còn một, chẳng hạn như trong bộ điều khiển. Do đó, bạn có thể thêm nhiều trình trang trí khác nhau vào các yêu cầu, điều này sẽ thống nhất quá trình xử lý của chúng và giảm số lượng mã.
ViennaNET.Validation
Một tập hợp chứa một tập hợp các lớp để tạo các quy tắc và trình tự xác thực từ chúng. Nó rất thuận tiện cho việc triển khai xác thực miền vì nó cho phép bạn mô tả từng điều kiện kinh doanh dưới dạng một quy tắc đơn giản và riêng biệt.
ViennaNET.Redis
Một thư viện có các trình bao bọc để làm việc thuận tiện với Redis dưới dạng bộ nhớ đệm trong bộ nhớ.
ViennaNET.Thông số kỹ thuật
Một tập hợp chứa các lớp triển khai mẫu Đặc tả.
Đây không phải là tất cả những gì có trong bộ của chúng tôi. Bạn có thể thấy phần còn lại . Chúng tôi đang có kế hoạch sớm phát hành các thư viện để làm việc với cơ sở dữ liệu sang OpenSource.
Cảm ơn bạn đã quan tâm, chúng tôi rất mong nhận được ý kiến và yêu cầu kéo của bạn.
Nguồn: www.habr.com
