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

1、用传统方式构建微服务

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

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

2、组织结构不变

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

3、习惯于领导安排工作

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

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

4、纠结如何拆分服务

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

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

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

5、以大规模拆分服务开始

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

• 团队有微服务架构经验。

• 已具备微服务架构的先决条件，包括自动化的研发环境、全面的健康检查、必要的公共服务及框架，以及敏捷基础设施。

• 业务目标非常明确，已经可以预期未来的规模，业务几乎无变化。

6、高估架构的移植性

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

7、从来没有做过微服务架构的人领导你完成迁移

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

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

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

为什么你会觉得微服务架构很别扭相关推荐

面向领域的微服务架构
近来,一些关于面向服务架构的话题,特别是针对微服务架构的弊端这个话题上进行了大量的讨论.虽然在几年前,微服务架构受到很多人的青睐,因为它们提供了许多好处,如独立部署的灵活性.明确的所有权.系统稳定性的 ...
blog微服务架构代码_DDD+微服务大型案例：Uber如何从复杂的RPC微服务转向面向业务领域的微服务架构DOMA？ -优步工程博客...
最近,围绕面向服务的体系结构,尤其是微服务体系结构的弊端进行了大量讨论.仅仅几年前,由于许多人宣传微服务架构的好处,例如独立部署形式的灵活性,明确的所有权,系统稳定性的改进以及更好的关注点分离,很多人 ...
微服务架构带来的分布式单体，更好还是更坏，一念之间
前言微服务架构其实是为了服务可以独立的开发.独立的部署,快速迭代,并且技术多样性. 然而我们经常在开发微服务的时候没有弄清楚微服务的边界,导致了一个更大的坑,由单体架构拆分成了微服务单体架构,带来了 ...
Uber——面向领域的微服务架构
介绍最近,围绕面向服务的架构(尤其是微服务架构)的缺点进行了大量讨论.虽然就在几年前,采用微服务架构是比较流行的,因为它们提供了许多好处,例如以独立部署的形式带来的灵活性.职责清晰.系统稳定性和更好 ...
微应用是什么_SpringCloud微服务架构篇1：微服务架构开发
大型分布式系统具有复杂性.隐匿性.配合性和易变性四大难题,不会存在任何单一软件工程上的突破,能让开发生产力得到一个数量级上的提升. 1.单体架构应用的困境一个典型的单体架构应用就是将一个应用中所有的 ...
微服务架构的深入理解-总结的很好
微服务架构目录一.微服务架构介绍二.出现和发展三.传统开发模式和微服务的区别四.微服务的具体特征五.SOA和微服务的区别六.如何具体实践微服务七.常见的微服务设计模式和应用八.微服务 ...
系统架构升级要不要上微服务？历“久”弥新微服务——你真的需要升级微服务架构吗
在 <微服务架构设计模式> 一书中,作者总结了关于微服务的一些"重点",原文如下: 中国企业和开发者对微服务架构的热情让我印象深刻.但如同我给所有客户的忠告一样,我想对 ...
高性能微服务架构设计模式@霞落满天
高性能微服务架构设计模式主讲:霞落满天现在企业开发都是微服务架构,但是有很多问题,比如分布式定义,分布式的微服务怎么拆分,什么时候拆分,怎么做到高性能,中台怎么设计,读写分离模式难道仅仅是MySQ ...
你必须了解的微服务架构设计的10个要点！
近来,几乎人人都在谈论微服务.微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境等.本文将介绍微服务架构设计中的一些要点. 微服务架构设计时有哪些要点 ...
【译】Monolith first —— Martin Fowler 对于微服务架构的看法
转载文章,文章经 LiteCodes 授权,转载至本博客. 原文地址:[译]Monolith first -- Martin Fowler 对于微服务架构的看法整体架构先行(Monolith fir ...

为什么你会觉得微服务架构很别扭