摘要
1) 一句话总结 微服务架构的核心目的不是单纯拆分技术模块，而是通过拆分组织架构来缩小团队规模、降低沟通成本，系统架构的设计必须与组织架构相匹配（即遵循康威定律）。
2) 核心要点
- 微服务的核心目的：微服务只是一种技术手段，其真正目的是将大开发部门拆分为独立的小开发小组，减少团队间的相互依赖与沟通成本。
- 理想的微服务状态：一个需求尽量在一个微服务内解决，实现独立测试与独立上线，避免过多的跨团队协作；同时一个小团队维护的微服务数量应是有限的。
- 少数跨服务需求处理：对于少数需要跨微服务的大需求，应做好任务拆分，提前约定好接口，各团队各自开发、部署后，再进行集中联调。
- 多数跨服务需求处理：如果大多数需求都需要跨微服务才能完成，说明微服务拆分存在问题，需要重新评估拆分合理性，必要时应合并部分微服务。
- 遵循康威定律（Conway’s Law）：系统架构的设计等同于组织架构的设计，软件系统的架构会反映出构建该软件背后团队的沟通结构。
3) 风险/缺口
- 沟通与延期风险：如果微服务拆分不合理（一个需求涉及多个微服务和多名维护人员），会导致跨团队沟通和协调成本过高，进而引发项目延期并产生扩散效应。
- 过度拆分风险：错把技术手段当成目的，为了微服务而盲目将服务拆得过细，反而会大幅增加系统的维护成本。
正文
问: 标准的scrum流程，我这边的问题是微服务后，一个需求涉及到多个微服务，微服务单独有专人维护，这里面的沟通和协调就比较成本高，一个需求需要多个人干，其中的延期就开始扩散，我估计还是ticket太大？。
微服务架构只是一种技术手段，使用微服务架构的目的，不是为了让你的架构更流行更酷，也不是为了让你的服务尽可能小，而是借助微服务的架构，让团队规模变小，大开发部门变成各个小的开发小组，并且各个小组应该尽可能独立，减少相互依赖，减少沟通成本。
而一个常见的问题就是错把手段当目的，为了微服务而微服务，服务拆的太细，反而维护和沟通成本大增。
理想的微服务架构，一个需求在一个微服务内就解决了，独立测试独立上线，基本不需要太多跨团队的协作。同时一个小团队维护的微服务也是有限的。
回到最初的问题，如果少数大需求需要跨微服务，是正常的，但是也要注意任务拆分，把大需求拆分到多个微服务，约定好接口，各自开发，各自部署，集中联调。
如果大多数需求需要跨微服务，那多半你的微服务拆分的是有问题的，你需要重新考虑你的微服务的拆分是否合理，必要的话合并一些微服务。
最后，建议可以了解一下康威定律 (Conway’s Law)。康威（Melvin Conway）博士在 1967 年提交的一篇论文《How Do Committees Invent?》中最有名的一句话是：
Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations. — Melvin Conway
翻译如下：
“你设计的软件系统架构，会以某种方式反映出构建软件背后团队的组织架构，你在设计软件的系统架构时，同时也在设计你的组织架构，反之亦然。也可以简单理解为：组织架构的设计等同于系统架构的设计。”
那么你再审视一下你的微服务架构，把你组织架构的设计也考虑进去，可能很多问题也就迎刃而解了。
