您好！
我们是 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.规格
包含实现规范模式的类的程序集。
这不是我们系列中的全部内容。 剩下的你就可以看到 。 我们计划很快将用于数据库工作的库发布到开源。
感谢您的关注，我们期待您的评论和请求。
来源： habr.com