微服务之上：组织和流程

最近在看《Microservices Patterns 微服务架构模式》这本书，第一章有一小节深有体会，名字就是微服务之上：流程和组织，在这里我把组织和流程换个位置，在我看来组织的优先级要更高。

微服务不仅仅是架构

在言必及微服务的今天，规模较大或者复杂的应用，采用微服务架构往往是最优解。然而我们平时谈及微服务的时候，更多听到的都是使用什么技术、如何拆分服务、如何解决拆分产生的问题等等，总而言之更多的停留在技术范畴上。

但是微服务真的仅仅只是技术架构上的事情？至少现在我不这么认为！

成功的软件开发还需要在组织、开发和交付流程方面做一些工作。

我们为什么要微服务

微服务最初的目的在我看来是解决单体应用不断庞大带来的各种问题，单体应用的缺点即是微服务的优点。包括：

• 使大型的复杂应用程序可以持续交付和持续部署
• 每个服务都相对较小并容易维护
• 服务可以独立部署
• 服务可以独立扩展
• 微服务架构可以实现团队的自治
• 更容易实验和采纳新的技术
• 更好的容错性

伴随着敏捷开发、DevOps思想的兴起，与微服务架构中的很多思想不谋而合，愈加显得微服务架构的优越性，但真正想要践行好微服务却不是简单的事情。

组织的困境

大部分企业应该还是延续着职能型组织结构，也称为U型组织，不同职能人员分别隶属于不同的团队，比如产品、开发、测试、运维团队之间彼此独立。以我而言，现在的团队由于项目的特性，更多的采用研发资源池共享的方法，团队组建初期，只有研发和测试人员，研发效率非常高，但是随着职能团队的增加，产品、PMO，研发效率直线下降，项目相关人等越来越多，流程混乱不统一，无尽的会议和无意义的讨论等等问题一下就全出现了。

屁股决定脑袋

每个职能岗位由于岗位职能、目标甚至是绩效标准都不同，导致都会站在各自的立场去考虑问题和做事情，俗称屁股决定脑袋。

屁股决定脑袋往往被当作贬义词，形容眼界不够开阔，思维方式比较单一。我个人并不完全这么认为，有些时候在什么位置做什么事情，不代表你眼界小或者能力不行，只是你当前的话语权只有这么多而已。

但是由于职能的不同以及组织规模的越来越大，屁股决定脑袋给研发流程确实带来了不利的影响。

• 产品：业务连自己要什么都不知道，研发老是讨价还价，业务就是这么提的需求。
• 研发：产品提的需求技术难度大，业务流程不合理。测试连需求也不理解，自以为是提好多改进意见，到底是产品还是测试。
• 测试：研发开发的东西是人用的吗，还不配合测试，提了bug半天没反应。
• 运维：频繁的版本发布都影响线上环境稳定了，而且每次版本发布都会发生问题，也不知道测试怎么测的。

上面的场景时时刻刻发生在工作中，错了吗？我觉得不是，只是职能不同、KPI导向不同、利益不同导致的目标不一致而已。

甚至在研发内部前后端团队之间都会因为分工的灰色地带而产生矛盾，比如接口由谁设计、某个校验到底前端做还是后端做等等讨价还价，这是我亲身经历过的。

沟通成本高

当需要做某一个需求的时候，从各部门抽调人员组成临时的项目团队，项目做完之后，人员再回到各自组织。这样的组织架构有一个主要的问题：沟通协调成本高。

例如：

• 项目团队人员之间需要互相熟悉协调；
• 遇见问题沟通难度大，如果点对点沟通，会带来很多问题；如果什么事都组织所有人，代价又太大。

反馈链路很长

沟通成本太高会导致需求推进缓慢。需求从产品团队到运维团队，中间经历了层层关卡。同样反过来看，当生产出现问题时，从运维逐层反馈给产品的过程也很缓慢。如果再加上部门之间职责界限不清楚，互相推诿那就更是雪上加霜。

分而治之

在组织划分上有个著名的定律，康威定律：

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

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

Fred Brooks在《人月神话》这本书中提到的，沟通成本会随着团队的规模呈 O(N ^ 2)的速度上升。如果团队太大，由于沟通成本过高，往往会使得团队的效率降低。想想看，如果每天早上的站会规模达到 20 人会是怎样？

单体应用和传统职能组织结构不断庞大后出现的问题基本是一致的，解决单体应用问题的方法是微服务，解决职能型组织结构问题的方法依然是分而治之，把大团队分为多个小团队。

团队的人数没有明确的要求，最著名的应该是Amazon的两个披萨团队原则。每个团队都有明确的职责：开发并负责运维一个或者多个服务，这些服务实现了一个或者多个业务能力。

最重要的是这些团队都是跨职能的，包括产品、研发、测试人员等等，搞得定用户交互UI设计、后台服务开发，做得了数据库管理、服务运营和运维。他们独立完成分析、开发、测试、部署等任务，而不需要频繁的与其他团队沟通协调。

借用下图：

<img src="http://img.pigpi.cn/650581-20200711172134164-626548522.png" alt="img" style="zoom:150%;" />

小团队内部人员目标能够达到一致，不存在屁股不在一起导致思想不统一的情况，由于人员基本固定，能够培养出团队间的默契，内部沟通的效率也能做到最高。运行良好的团队甚至能达到某种程度的“自治”，而不需要外部协调干预。

当然，并不存在完美解决问题的“银弹”，我们不得不面对一些新出现的问题：

• 团队数量过多后的管理和协调问题
• 团队负载不均衡的问题
• 原本对接业务的入口只有一个，现在可能变成多个
• 团队间的合作问题

上面的每一个问题可能在不同的企业环境，不同的团队氛围下答案都不同，甚至不能完全解决。但是我觉得拆分小团队提升效率和灵活性的方向是没有错的，更多的是我们需要因地制宜的去探索答案。

流程的困境

试想一下，微服务架构如果配合传统瀑布式开发会怎么样？书中这么形容：

采用微服务架构以后，如果仍旧沿用瀑布式开发流程，就跟用一匹马拉法拉利跑车没什么区别——我们需要充分利用微服务带来的各种便利。

我们脑补一下瀑布式的研发过程：需求分析，软件设计，程序编写，软件测试，运行维护。

• 各个阶段的划分完全是固定的，阶段之间产生大量的文档，极大地增加工作量。
• 由于开发是线性的，所以用户只有在开发的末期才可以到成果，所以增加了风险。
• 早期的错误等到最后测试再发现这样会带来严重的后果。

整个过程中还穿插着项目经理组织的各种跨职能的会议，立项会、需求会、评审会等等；每次沟通都是一大帮人在那争论不出结果；甚至一周的需求在那跟你讨论流程、规范。团队和个人就像挣扎在沼泽泥坑中一样寸步难行，最后可能还要被总结为团队效率低下。

微服务拆分业务模块、团队拆分跨职能小团队，都是为了快速反馈和成果输出，瀑布式流程就像它的名字一样，在你准备轻装急行时化身尼亚加拉大瀑布挡在你面前。

敏捷开发

如果你希望通过微服务架构来完成一个应用程序的开发，那么采用类似Scrum或Kanban这类敏捷开发和部署实践就是必不可少的。

敏捷开发的核心思想就是循序渐进的快速迭代产品，更加关注人和团队本身。敏捷开发的价值观如下：

• 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
• 软件能够运行，优于详尽的文档。
• 跟客户的密切协作，优于合同和谈判。
• 能够响应变化，优于遵循计划。

在微服务流行的今天，我想敏捷更适合它。

微服务、流程和组织

贴一下书中关于三者的关系图：

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

微服务架构在技术上可以轻易实现，但是背后需要的流程和组织上的支撑，则是需要不断去探索和践行的。在这方面，所有书中看到的都是理论基础，必须要结合所处的环境因地制宜，而这并不是一件轻易的事情。但不管怎样，我愿意做一些努力。