很多系统迁移到微服务架构之后，并没有明显感觉到微服务架构带来的优势，反而觉得带来了更高的复杂度，王启军在《持续演进的Cloud Native》书中总结了七种微服务架构没能发挥出固有优势的原因，看看自己“中枪”了没！

微服务架构和传统的架构方式思路完全不一样。例如传统方式实现高可用，更相信流程，更相信KPI对人的影响，因此流程需要让更多的人去测试，制定更严格的发布流程。

而微服务架构强调的是自动化发布、灰度发布、Design For Failure、自动化测试、故障隔离、自愈。很多失败的案例以传统的方式去构建微服务架构，一切都没有转变，只是把服务拆开，根本无法享受微服务架构带来的便利，反而因此遇到了更多麻烦。最明显的是对开发人员的影响，他们质疑微服务架构是否适合自己的业务场景，而一个充满质疑的团队是不可能具备强大战斗力的。

如果要充分发挥微服务架构的优势，组织结构必须发生转变，构建和微服务配套的小团队，并且让他们拥有绝对的自主权。实际上，相当一部分实施微服务架构的团队都没有做到这一点，因为组织结构总是涉及利益。比较典型的问题是，小团队不需要团队以外的任何人来批准是否上线，架构如何演进，使用什么数据库。如果小团队没有权利，任何变动都要等待高层进行决策，就会形成决策瓶颈点，导致效率低下，这违背了微服务架构的初衷，团队成员也会因此失去主动性。

传统的研发模式严重依赖流程，原因是没有人愿意承担责任，所有人都把责任推到流程上。微服务架构和敏捷开发流程是天作之合，传统研发模式需要领导批准，然后由团队负责人直接分解任务、定工时、安排任务负责人，而按照敏捷开发流程，开发计划应该是团队决定的，任务自主认领。精英化团队绝不仅仅是团队人数更少，人员能力更强这么简单，这只是表面上的，更重要的是责任感和主观能动性以及信任！

某公司CEO 曾经说过这样一件事情，员工把请假流程提给“我”，让“我”审批，但是“我”根本没有审批的必要，因为你随便说一个理由“我”都不可能拒绝，就算拒绝了，下回会来一个更难以拒绝的理由。后来公司所有的请假都不需要审批了，只要在群里发一条消息，让相关同事知道就可以了。

不理解微服务架构的人，通常从字面理解，他们认为微服务架构的重中之重就是服务拆分。

到底拆分多细？与其浪费更多的时间思考这个问题，不如先拆出几个服务运行一下，感受一下。架构是一个持续的过程，有时候很难从技术角度完全解释清楚。

另一个错误是一次性拆分，不能改变。由于技术人员对业务领域知识的理解不断加深，业务逻辑有可能运行一段时间也会转变，这时候改变是不可避免的。重新合并、划分，是一个正常的演变过程。架构是动态的，不是静态的。

微服务架构需要一个适应过程，持续拆分效果更佳。如果从大规模拆分服务开始，需要具备三个条件，否则可能会遇到相当多的麻烦。

• 团队有微服务架构经验。
  
• 已具备微服务架构的先决条件，包括自动化的研发环境、全面的健康检查、必要的公共服务及框架，以及敏捷基础设施。
  
• 业务目标非常明确，已经可以预期未来的规模，业务几乎无变化。
  

架构是一门艺术，不是随随便便复制一下就可以的，Google、Amazon、Facebook 的架构问世已经很长时间了，研发人员跳槽这么频繁，但是没有哪个公司能模仿好。MySQL 开源了这么多年，放到不同人的手里，结果完全不一样。实际上实施微服务架构在一个业务场景中的优势在另一个场景中很可能会变成一种劣势。如果你仔细研究就会发现，大多数公司实施的微服务架构就跟各个公司的管理制度一样各不相同。很多公司为了显示自己的架构有多厉害而实施微服务架构，最终只会害了团队，因为只把精力放在微服务架构上，可能就减少了对业务实现、用户体验的关注。

如果转型的团队由没有经验的人来领导，那么结果就是只关注表面，拆了多少服务、服务粒度、服务注册发现、负载均衡、调用链分析，而隐藏的各种性能问题、扩展性问题、可用性问题都没有得到足够的关注。如果只是从几个服务拆分开始积累经验还好，一旦大规模拆分，就会让整个团队都质疑微服务架构的意义。架构是需要实践的，不要以为看几篇文章就得到了架构的真谛，细节会“杀死”团队。

---

本文选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》，作者王启军 ，电子工业出版社10月出版。

作者从全局视角出发，全面阐释Cloud Native 的关键技术，以及其衍生出来的工具、团队文化等核心要素，对于正在部署微服务架构或开展云原生业务的企业和组织而言，终于有了面向落地的务实参考和全面指导。