在.NET中从单块到微服务体系结构转换时，有哪些重要的考虑因素？

Question

我们正在考虑逐步将我们的单块怪物分解为基于微服务的体系结构。我们有5个团队，每个团队包含2-3个C#开发人员、至少一个数据库开发人员和两个QA工程师。除了巨大的文化和范式的转变，从单一的架构到微服务，也有技术挑战。我想向社会人士寻求一些智慧和意见，以避免犯同样的错误。

是否有任何良好的工业例子，其中基于.NET的微服务已经成功地使用在一个生产系统？以下方面的战略是什么？

• 你是如何组织.NET解决方案/项目的？
• 开发计划:在开发计划方面，您是如何跨团队分解工作的？确保跨微服务的合同遵从性是跨团队协商的总体策略是什么？
• 负载平衡/路由/API网关:用于负载平衡、冗余和扩展的策略是什么？您是使用完整的异步体系结构，使用队列进行微服务通信，还是通过负载均衡器/API网关进行对等操作？为什么？
• 测试自动化:您是如何处理测试自动化的。对于微服务体系结构来说，这与持续集成似乎是绝对必要的。你是怎么做的？
• 部署:您是如何部署的？一个VM/微服务或一个容器/微服务或其他什么东西？您如何处理这样一个事实:现在您有几十个数据库--如果不是更多的话--考虑到每个微服务都有其数据存储，这对您的基础设施做了什么?DBA是如何处理的？
• 基础设施:您的基础架构是如何与此体系结构相结合的。这是超级聊天，你必须微调它，或者网络处理它没有任何问题？是自我托管的还是云中的？
• 监控:你的监控策略是什么？你是如何监视数十个甚至数百个微服务的？主要是通过测井和中央监控吗？

Answer 1

我做过很多微型服务项目。不可避免的是，公司选择了这条道路，因为它们的大DB方法无法进一步扩大规模。以下是我的经历/建议。

Org.每台微型服务有一个解决方案。用于共享库的nuget包

开发。规模较大的5-6个团队一次开发一个功能区域。重构为接口服务。将内存服务替换为微服务的客户端。

测试。使用实际输入/输出数据进行集成测试。您希望能够针对任何正在运行的实例激发它们，以检查它们是否正确、本地实例、测试/uat启用程序以及用于单元测试的内存实例。确保可以通过健康检查接口或类似的方法测试实例的版本。

缩放。基于队列的是最好的，因为它可以处理多级分布式进程。兔子MQ、Zero MQ、MSMQ等，但是负载平衡的REST服务可以用于rpc风格的调用，并且可以是一个简单的起点。

部署。章鱼。db项目，自我创建非sql.dbs，如Mongo。虽然我认为如果您有多个dbs，您就走错了路。相反，有大量的消息，其中包含进程所需的数据，以及隐藏在自己apis后面的几个较大的dbs用于数据存储。

没有DBA！如果您有一个DBA绞接sql，那么您做错了。

基础设施。没问题。从队列中读出。做过程。写入队列。每个盒子可以有多个实例，即使是在云微实例上，对于小的或不经常调用的服务也是如此。

监测。所有服务的健康检查接口，通常通过监控软件和在大板上调用。

自动故障转移和恢复是很重要的，在需要时，实例应该是旋转的，并且是无状态的，因此一次崩溃不会使服务中断。

主要的问题不在于服务的下降，而在于微服务的本质使它们在这方面更加健壮。这是您处理无法/尚未处理的消息的方式。

使用logstash或类似的方法来跟踪消息流，并找出问题所在和问题所在。确保您可以重新运行失败的消息，以便一个固定的进程能够继续它停止的地方。

最后注意事项。所有的版本，dll，nuget，数据，接口。由于多个服务实例和历史消息在周围浮动，它可能是问题的主要原因。

Answer 2

在过去的两年中，我们将一个单核分解成微服务，下面是我们正在做的一些事情。

组织:每项服务都是一个解决方案，没有任何其他服务的共同项目。最后，合同本身是一个单独的解决方案，每个版本都是一个.nuget包。

开发:每个团队都在处理应用程序的一个部分，对于每个新服务，我们从合同创建开始，然后将服务分离，但仍然将其保留在主要应用程序/解决方案中(所以还没有HTTP调用)。在未来的一步中，我们将把这项服务完全分开。

路由:我们的所有服务都在负载均衡器后面，每个服务都部署在几个vms上。我们为多个服务共享相同的vm。在我看来，每个服务使用一个vm似乎是浪费资源，因为服务很小，而Windows需要大约2G才能正常工作。一些与用户交互无关的服务(如发送电子邮件/通知)使用队列。

测试:最初，我们认为单元测试服务和测试不同版本的客户端之间的合同兼容性以及使用Pact.Net的服务就足够了。但是，当一个新版本的服务没有被部署时，我们遇到了问题，我们使用了前一个版本。所有的测试都通过了，但是整个平台都不正常。因此，我们在主流上添加了一些高级(集成)测试。

部署:所有平台都安装在几个vms上，我们使用TFS进行构建，AWS S3用于工件，可抗用于vm创建、部署和配置。Ansible在这里扮演着重要的角色，它是无代理的，并且使用powershell远程处理连接到windows。我们停止使用web.config的xml，移到Ansible模板，这样我们就可以在Ansible文件中进行所有配置。与章鱼相比，它的好处在于它是免费的和开源的。全新的vms用于新版本，只有在必须部署修复程序时才更新服务。

缩放:在这样的部署中，您只能缩放vms，而不能缩放服务本身。因此，监视您的性能(CPU、RAM)、收到的请求数量，甚至是基于时间的请求(比如周末的流量减少)，您可以启动和停止新的vms。

监控:我们正在使用AWS，我们有时间序列警报的CloudWatch，但是我们计划去Grafana和Prometheus (离码头更近了一步，现在是Server 2016)。在日志记录方面，我们使用的是格雷洛格 (它使用的是后面的ElastiSearch )。采用它很容易，因为我们以前使用的是带有文件附加器的Log4Net，并且有一个阿彭德，特别是针对Graylog的。您可以在此基础上构建大量的警报，我们意识到这实际上是一个持续的过程。