微服务的流程和组织，终于有人讲明白了 _微服务

导语：微服务架构最重要的好处是它可以实现大型的复杂应用程序的持续交付和持续部署。持续交付和持续部署是DevOps的一部分，DevOps是一套快速、频繁、可靠的软件交付实践。高效能的DevOps组织通常在将软件部署到生产环境时面临更少的问题和故障。

作者：克里斯·理查森
如需转载请联系华章科技
对于大型和复杂的应用程序，微服务架构往往是最佳的选择。然而，除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付流程方面做一些工作。
图1展示了架构、流程和组织之间的关系：

文章插图
图1
▲大型复杂应用程序快速、频繁和可靠地交付软件需要具备几项DevOps关键能力，其中包括持续交付和持续部署，小型自治团队和微服务架构
我们已经谈过了微服务架构，现在来看看组织和流程。
01 进行软件开发和交付的组织【微服务的流程和组织，终于有人讲明白了】成功往往意味着研发团队规模的扩大。一方面，这是个好事，因为人多力量大。但是团队大了以后，正如Fred Brooks在《人月神话》这本书中提到的，沟通成本会随着团队的规模呈O(N ^ 2)的速度上升。如果团队太大，由于沟通成本过高，往往会使得团队的效率降低。想想看，如果每天早上的站会规模达到20人会是怎样？
解决之道是把大团队拆分成一系列小团队。每个团队都足够小，人员规模为8～12人。每个团队都有一个明确的职责：开发并且可能也负责运维一个或者多个服务，这些服务实现了一个或多个业务能力。这些团队都是跨职能的。他们可以独立地完成开发、测试和部署等任务，而不需要频繁地与其他团队沟通或者协调。

逆向的康威定律

为了在使用微服务架构时有效地交付软件，你需要考虑康威定律，它规定了如下内容：

设计系统的组织……往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本。
——梅尔文·康威

换句话说，应用程序的架构往往反映了开发它的组织的结构。因此，反向应用康威定律并设计你的企业组织，使其结构与微服务的架构一一对应。通过这样做，可以确保你的开发团队与服务一样松耦合。
若干个小团队的效率显然要高于一个单一的大团队。微服务架构使得团队可以实现某种程度的“自治” 。每个团队都可以开发、部署和运维扩展他们负责的服务，而不必与其他团队协调。更进一步，当出现了某个服务故障或没有满足SLA等要求时，对应的责任人（团队）也非常清楚。
而且，开发组织的可扩展性更高。你可以通过添加团队来扩展组织。如果单个团队变得太大，则将其拆分并关联到各自负责的服务。由于团队松散耦合，你可以避免大型团队的沟通开销。因此，你可以在不影响工作效率的情况下添加人员。

文章插图

02 进行软件开发和交付的流程采用微服务架构以后，如果仍旧沿用瀑布式开发流程，那就跟用一匹马来拉法拉利跑车没什么区别—我们需要充分利用微服务带来的各种便利。如果你希望通过微服务架构来完成一个应用程序的开发，那么采用类似Scrum或Kanban这类敏捷开发和部署实践就是必不可少的。同时也需要积极实践持续交付和持续部署，这是DevOps中的关键环节。
Jez Humble把持续交付定义为：
持续交付能够以可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中。
持续交付的一个关键特征是软件总是随时可以交付的。它依赖于高水平的自动化，包括自动化测试。在将代码自动部署到生产环境的过程中，持续部署把持续交付提升到了一个新的水准。实施持续部署的高绩效组织每天多次部署到生产环境中，生产中断的次数要少得多，并且可以从发生的任何事情中快速恢复。微服务架构直接支持持续交付和持续部署。