转载

为什么总觉得微服务架构很别扭？看看命中几条

点击上方↑↑↑ “蓝字” 关注我们

1

用传统方式构建微服务

微服务架构和传统的架构方式思路完全不一样，例如传统方式实现高可用，更相信流程，kpi，让更多的人去测试，更严格的发布流程，而微服务架构强调的是自动化发布、灰度发布，design for failure，自动化测试，故障隔离，自愈。很多团队还在以传统的方式去构建微服务架构，一切都没有转变，只是把服务拆开。根本无法享受微服务架构带来的收益。反而由此遇到了很多麻烦。最明显的是对开发人员的影响，质疑微服务架构是否适合自己的业务场景，一个充满质疑的团队是不可能具备强大战斗力的。

2

组织结构不变

如果要充分发挥微服务架构的优势，组织结构必须发生转变，构建和微服务配套的小团队，并且有绝对的自主权。实际上大多数实施微服务的团队都没有做到，因为组织结构总是涉及利益。比较典型的问题是，小团队不需要团队以外的任何人来批准是否上线，架构如何演进，使用什么数据库，如果小团队没有权利，你怎么让团队去感觉到自己是主人。

3

习惯于工作被领导安排

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

想起一件事，我的前公司CEO曾经说过这样一件事情，他说你们都把请假流程提给我，让我审批，我根本没有审批的必要，因为你随便说一个理由我都不可能拒绝，就算拒绝了，下回来一个更难以拒绝的理由，后来我们所有的请假都不需要经过审批，只要在群里发一个消息，让相关人都知道就可以了。但是并没有觉得有什么问题啊。

4

纠结如何拆分服务

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

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

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

5

以大规模拆分服务开始

大规模拆分服务开始需要具备三个条件：

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

6

高估架构的移植性

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

7

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

见过很多转型的团队由没有经验的人来领导，那结果就是只是关注表面，拆了多少服务，服务粒度，服务注册发现，负载均衡，调用链分析，而隐藏的各种性能问题、扩展性问题、可用性问题都没有得到足够尊重。如果只是从几个服务拆分开始积累经验还好，一旦大规模拆分，会让整个团队都质疑微服务架构的意义。架构是需要实践的，看几篇文章就侃侃而谈，认为已经得到了架构的真谛，我的绝大多数灵感来自于实践。如果你让CTO去值班运维，相信自动化运维早就列为高优先级了。

为什么总觉得微服务架构很别扭？看看命中几条