最近在看《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 要害能力，其中包含继续交付和继续部署，小型自治团队和微服务架构
微服务架构在技术上能够轻易实现，然而背地须要的流程和组织上的撑持，则是须要一直去摸索和践行的。在这方面，所有书中看到的都是实践根底，必须要联合所处的环境就地取材，而这并不是一件轻易的事件。但不管怎样，我违心做一些致力。