迁移到微服务架构，为什么你还没有发现它的内在优势在《持续演进的Cloud Native》一书中，王启军总结了七种微服务架构未能发挥其内在优势的原因。看看你有没有中枪！1.使用传统方法构建微服务微服务架构和传统架构方法的思维方式是完全不同的。比如传统方式实现高可用，我们更相信过程和KPI对人的影响。因此，流程需要经过更多人的测试，制定更严格的发布流程。微服务架构强调自动化发布、灰度发布、DesignForFailure、自动化测试、故障隔离和自我修复。在很多失败的案例中，微服务架构都是用传统的方式构建的。什么都没有改变，但服务被拆解了。无法享受微服务架构带来的便利。反而遇到了更多的麻烦。最明显的是对开发人员的影响。他们质疑微服务架构是否适合自己的业务场景，充满质疑的团队不可能有强大的战斗力。2、组织架构不变。要想充分发挥微服务架构的优势，就必须改变组织架构，建立一个支持微服务的小团队，并且要有绝对的自主权。事实上，有不少实施微服务架构的团队未能做到这一点，因为组织结构总是涉及利益。一个典型的问题是，一个小团队不需要团队外的任何人来批准是否上线、架构如何演进、使用什么数据库。如果小团队没有权利，任何变化都必须等待高层决策，这将形成决策瓶颈点，导致效率低下。这违背了微服务架构的初衷，团队成员会失去主动性。3、习惯领导的工作安排。传统的研发模式非常依赖流程，因为没有人愿意承担责任，每个人都把责任推到流程上。微服务架构和敏捷开发流程是天作之合。传统的研发模式需要领导审批，然后组长直接分解任务，安排工作，安排任务组长。按照敏捷开发流程，开发方案由团队决定，任务独立认领。精英团队不仅仅是人员能力更强的小团队那么简单。这只是表面现象。更重要的是责任感、主观能动性和信任感！某公司CEO曾说过这样的话，员工请假的流程提交给“我”让“我”审批，但“我”根本不需要审批，因为“我”不能拒绝任何你刚才说的理由，就算你拒绝，下次也会有更难拒绝的理由。以后公司所有的请假都不需要审批了。你只需要在群里发消息，让相关的同事知道。4.纠结于如何拆分服务，不了解微服务架构的人，通常是从字面理解。他们认为微服务架构中最重要的是服务拆分。拆分的有多详细？与其浪费更多的时间思考这个问题，不如拆分出几个服务跑起来感受一下。架构是一个持续的过程，有时很难从技术角度完全解释。另一个错误是无法更改的一次性拆分。由于技术人员对业务领域知识理解的不断加深，运行一段时间后业务逻辑可能会发生变化，此时发生变化是不可避免的。合并再分裂是正常的进化过程。架构是动态的，而不是静态的。5、启动大规模拆分服务的微服务架构需要一个适配过程，不断拆分效果更好。如果从大规模拆分服务开始，需要满足三个条件，否则可能会遇到很多麻烦。团队拥有微服务架构经验。微服务架构的先决条件已经具备，包括自动化的研发环境、全面的健康检查、必要的公共服务和框架以及敏捷的基础设施。业务目标很明确，未来规模已经可以预见，业务变化不大。6、高估架构的可移植性架构是一门艺术，不能随便复制。谷歌、亚马逊、Facebook的架构由来已久，研发人员跳槽频繁，但没有一家公司可以模仿。好的。MySQL开源了这么多年，放到不同的人手里，结果是截然不同的。事实上，在一个业务场景中实施微服务架构的优势很可能在另一个业务场景中变成劣势。如果仔细观察，大多数公司实现的微服务架构就像每个公司的管理体系一样不同。很多公司为了展示自己的架构有多厉害而去实现微服务架构，到头来只会害了团队，因为只关注微服务架构可能会减少对业务实现和用户体验的关注。7、没做过微服务架构的人带你完成迁移。如果改造团队由没有经验的人带领，那么结果就是只关注表面，拆了多少服务，服务粒度，服务注册发现，负载均衡，调用链分析，而隐藏的性能问题，可扩展性问题，可用性问题没有得到足够的重视。如果您只是从几个服务的拆分开始积累经验，那也没关系。一旦大规模拆分，整个团队都会质疑微服务架构的意义。架构需要实践。不要以为看了几篇文章就能领悟到建筑的真谛。细节会“杀死”团队。本文选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》，作者王其军，电子工业出版社10月出版。作者站在全局的角度，全面阐释了CloudNative的关键技术，以及衍生工具、团队文化等核心要素。对于正在部署微服务架构或开展云原生业务的企业和组织，终于有了切实可行的解决方案实用参考和全面指导。
