大家好！
我們是 Raiffeisenbank 的 .NET 開發人員社區，我們想討論一組基於 .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 時代
當 Docker 和 Kubernetes 的浪潮席捲我們時，我們密切關注的時機已經到來：畢竟，這是一個在 .Net Core 中開始進一步推動技術發展的絕佳機會。 這意味著我們需要一個新的基礎設施來運行服務：有些程式庫已經從 .Net Framework 遷移到 .Net Standard 和 .Net Core，幾乎沒有任何變化，有些程式庫做了一些小的改進。 但最重要的是，我想重新設計與在 AspNet Core 上啟動服務相關的功能。
我們首先考慮的是一個可以消除先前版本的主要缺點的概念：缺乏靈活性。 因此，決定使整個圖書館系統盡可能獨立和模組化，並作為建構者收集功能所需的服務。
主要目標是創建一個統一的方法來描述如何與資料庫、匯流排和其他服務互動。 我們試圖使整合快速、輕鬆，開發人員可以專注於編寫業務邏輯而不是基礎設施 - 它已經準備好了。 通用儲存庫有助於改善團隊內部互動的體驗：當使用非常相似的內部基礎架構時，可以更輕鬆地加入另一個團隊的開發流程並交流專業知識。
為什麼我們需要開源？
我們希望展示我們專業知識的成熟度並獲得高品質的回饋：銀行以外的人將能夠帶來自己的東西。 我們也對業界在 .NET 上使用微服務和 DDD 的實踐開發感興趣；也許有人會想要接管框架的某些部分。
事實上，維也納網絡
現在讓我們仔細看看。 .
ViennaNET.WebApi.*
這組庫由「根」ViennaNET.WebApi（包含 CompanyHostBuilder 服務的建構器類別）和一組設定器 ViennaNET.WebApi.Configurators.* 組成，每個配置器都允許您在建立的物件中新增和配置一些功能。服務。 在設定器中，您可以找到用於日誌記錄、診斷、身份驗證和授權類型、swagger 等的連線。
ViennaNET.WebApi.Runners.* 也包含預先設定的服務建構器。 這些套件使您不必每次建立新服務時都記住需要連接哪些配置器。 但是，它們不會以任何方式限制服務建構器的功能。
ViennaNET.Mediator.*
允許您為服務內的命令和請求建立內部中間匯流排的庫。 這種方法可讓您將控制器中的 DI 注入次數減少到一次。 因此，您可以為請求添加各種裝飾器，從而統一它們的處理並減少程式碼量。
ViennaNET.驗證
包含一組類別的程序集，用於根據它們建立驗證規則和序列。 它對於實作網域驗證非常方便，因為它允許您以簡單且單獨的規則的形式描述每個業務條件。
維也納NET.Redis
帶有包裝器的庫，可輕鬆地將 Redis 用作記憶體快取。
ViennaNET.規格
包含實作規範模式的類別的程序集。
這不是我們系列中的全部內容。 剩下的你就可以看到 。 我們計劃很快將用於資料庫工作的庫發佈到開源。
感謝您的關注，我們期待您的評論和請求。
來源： www.habr.com