一文了解微服务的流程和组织

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

成都一家集口碑和实力的网站建设服务商，拥有专业的企业建站团队和靠谱的建站技术，十多年企业及个人网站建设经验 ,为成都上千余家客户提供网页设计制作,网站开发,企业网站制作建设等服务,包括成都营销型网站建设，高端网站设计，同时也为不同行业的客户提供成都网站建设、做网站的服务,包括成都电商型网站制作建设,装修行业网站制作建设，传统机械行业网站建设,传统农业行业网站制作建设。在成都做网站,选网站制作建设服务商就选创新互联公司。

对于大型和复杂的应用程序，微服务架构往往是最佳的选择。然而，除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付流程方面做一些工作。

图1展示了架构、流程和组织之间的关系：

图1　大型复杂应用程序快速、频繁和可靠地交付软件需要具备几项DevOps关键能力，其中包括持续交付和持续部署，小型自治团队和微服务架构

1.　进行软件开发和交付的组织

成功往往意味着研发团队规模的扩大。一方面，这是个好事，因为人多力量大。但是团队大了以后，正如Fred Brooks在《人月神话》这本书中提到的，沟通成本会随着团队的规模呈O(N ^ 2)的速度上升。如果团队太大，由于沟通成本过高，往往会使得团队的效率降低。想想看，如果每天早上的站会规模达到20人会是怎样？

解决之道是把大团队拆分成一系列小团队。每个团队都足够小，人员规模为8～12人。每个团队都有一个明确的职责：开发并且可能也负责运维一个或者多个服务，这些服务实现了一个或多个业务能力。这些团队都是跨职能的。他们可以独立地完成开发、测试和部署等任务，而不需要频繁地与其他团队沟通或者协调。

逆向的康威定律

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

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

(梅尔文·康威)

换句话说，应用程序的架构往往反映了开发它的组织的结构。因此，反向应用康威定律并设计你的企业组织，使其结构与微服务的架构一一对应。通过这样做，可以确保你的开发团队与服务一样松耦合。

若干个小团队的效率显然要高于一个单一的大团队。微服务架构使得团队可以实现某种程度的“自治”。每个团队都可以开发、部署和运维扩展他们负责的服务，而不必与其他团队协调。更进一步，当出现了某个服务故障或没有满足SLA等要求时，对应的责任人（团队）也非常清楚。

而且，开发组织的可扩展性更高。你可以通过添加团队来扩展组织。如果单个团队变得太大，则将其拆分并关联到各自负责的服务。由于团队松散耦合，你可以避免大型团队的沟通开销。因此，你可以在不影响工作效率的情况下添加人员。

2　进行软件开发和交付的流程

采用微服务架构以后，如果仍旧沿用瀑布式开发流程，那就跟用一匹马来拉法拉利跑车没什么区别—我们需要充分利用微服务带来的各种便利。如果你希望通过微服务架构来完成一个应用程序的开发，那么采用类似Scrum或Kanban这类敏捷开发和部署实践就是必不可少的。同时也需要积极实践持续交付和持续部署，这是DevOps中的关键环节。

Jez Humble把持续交付定义为：

持续交付能够以可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中。

持续交付的一个关键特征是软件总是随时可以交付的。它依赖于高水平的自动化，包括自动化测试。在将代码自动部署到生产环境的过程中，持续部署把持续交付提升到了一个新的水准。实施持续部署的高绩效组织每天多次部署到生产环境中，生产中断的次数要少得多，并且可以从发生的任何事情中快速恢复。微服务架构直接支持持续交付和持续部署。

快速推进同时不把事情搞砸

持续交付和持续部署（以及更一般地说，DevOps）的目标是快速可靠地交付软件。评估软件开发的四个有用指标如下：

·部署频率：软件部署到生产环境中的频率。

·交付时间：从开发人员提交变更到变更被部署的时间。

·平均恢复时间：从生产环境问题中恢复的时间。

·变更失败率：导致生产环境问题的变更提交百分比。

在传统组织中，部署频率低，交付的时间很长。特别是开发人员和运维人员通常都会在维护窗口期间熬夜到最后一刻。相比之下，DevOps组织经常发布软件，通常每天多次发布，生产环境问题要少得多。例如，亚马逊在2014年每隔11.6秒就将代码更改部署到生产环境中，Netflix的一个软件组件的交付时间为16分钟。

3　采用微服务架构时的人为因素

采用微服务架构以后，不仅改变了技术架构，也改变了组织结构和开发的流程。归根到底，这是对工作环境中的人（正如之前提到的，情绪化的生物）进行的一系列改变。如果忽略人们的情绪，那么采纳微服务架构将会是一个非常纠结和折腾的过程。FTGO的首席技术官玛丽和其他的管理层，正面临着如何改变FTGO软件开发方式的挑战。

畅销书《Managing Transitions》介绍了转型（transition）的概念，其中阐述了人们如何对变化做出情绪化的反应。它包括以下三个阶段。

1.结束、失落和放弃：当人们被告知某种变化，这类变化会把他们从舒适区中拉出，这类情绪开始滋生和蔓延。人们会念叨失去之前的种种好处。例如，当被重组到一个新的跨职能团队时，人们会想念他们之前的同事。再比如，对于负责全局数据建模的团队来说，每个服务团队负责自己的数据建模，这对他们是一种威胁。

2.中立区：处理新旧工作方式交替过程中，人们普遍会对新的工作方式无所适从。人们开始纠结并必须要学习处理新工作的方式。

3.新的开始：最终阶段，人们开始发自内心地热情拥抱新的工作方式，并且开始体验到新工作方式所带来的种种好处。

总结

单体架构模式将应用程序构建为单个可部署单元。

微服务架构模式将系统分解为一组可独立部署的服务，每个服务都有自己的数据库。

单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好选择。

微服务架构使小型自治团队能够并行工作，从而加快软件开发的速度。

微服务架构不是银弹：它存在包括复杂性在内的诸多弊端。

微服务架构模式语言是一组模式，可帮助你使用微服务架构构建应用程序。它可以帮助你决定是否使用微服务架构，如果你选择微服务架构，模式语言可以帮助你有效地应用它。

你需要的不仅仅是通过微服务架构来加速软件交付。成功的软件开发还需要DevOps和小而自治的团队。

不要忘记采纳微服务过程中的人性层面。你需要考虑员工的情绪才能成功转换到微服务架构。

本文摘自《微服务架构设计模式》，经出版方授权发布。