微服务架构下迷途
大略是老马提出微服务有以下几个特征：
- 通过服务实现组件化；
- 按业务能力来划分服务与组织团队；
- 服务即产品；
- 智能终端与哑管道；
- 去中心统一化；
- 基础设施自动化；
- Design for failure；
- 进化设计
还有人说微服务是RESTful协议；微服务技术栈可以变。我想说，这些未必是微服务的必要条件。
迷信微服务不可取，我们看一下微服务具体有哪些坑。
- 服务划分过细，服务间关系复杂
服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。
从理论的角度来计算，n个服务的复杂度是n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度。
粗粒度划分服务时，系统被划分为3个服务，虽然单个服务较大，但服务间的关系很简单；细粒度划分服务时，虽然单个服务小了一些，但服务间的关系却复杂了很多。
- 服务数量太多，团队效率急剧下降
微服务的“微”字，本身就是一个陷阱，很多团队看到“微”字后，就想到必须将服务拆分得很细，有的团队人员规模是5~6个人，然而却拆分出30多个微服务，平均每个人要维护5个以上的微服务。
这样做给工作效率带来了明显的影响，一个简单的需求开发就需要涉及多个微服务，光是微服务之间的接口就有6~7个，无论设计、开发，还是测试、部署，都需要工程师不停地在不同的服务间切换。
- 开发工程师要设计多个接口，打开多个工程，调试时要部署多个程序，提测时打多个包。
- 测试工程师要部署多个环境，准备多个微服务的数据，测试多个接口。
- 运维工程师每次上线都要操作多个微服务，并且微服务之间可能还有依赖关系。
- 调用链太长，性能下降
由于微服务之间都是通过HTTP或RPC调用的，每次调用必须经过网络。一般线上的业务接口之间的调用，平均响应时间大约为50ms，如果用户的一起请求需要经过6次微服务调用，则性能消耗就是300ms，这在很多高性能业务场景下是难以满足需求的。为了支撑业务请求，可能需要大幅增加硬件，这就导致了硬件成本的大幅上升。
- 调用链太长，问题定位困难（略）
- 没有自动化支撑，无法快速交付
如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。例如：
- 没有自动化测试支撑，每次测试时需要测试大量接口。
- 没有自动化部署支撑，每次部署6~7个服务，几十台机器，运维人员敲shell命令逐台部署，手都要敲麻。
- 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。
- 没有服务治理，微服务数量多了后管理混乱
信奉微服务理念的设计人员总是强调微服务的lightweight特性，并举出ESB的反例来证明微服务的优越之处。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的lightweight就会变成问题。主要问题如下。
- 服务路由：假设某个微服务有60个节点，部署在20台机器上，那么其他依赖的微服务如何知道这个部署情况呢？
- 服务故障隔离：假设上述例子中的60个节点有5个节点发生故障了，依赖的微服务如何处理这种情况呢？
- 服务注册和发现：同样是上述的例子，现在我们决定从60个节点扩容到80个节点，或者将60个节点缩减为40个节点，新增或减少的节点如何让依赖的服务知道呢？
- 微服务引入的技术复杂度，如分布式事务
信奉微服务理念的设计人员总是强调微服务的lightweight特性，并举出ESB的反例来证明微服务的优越之处。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的lightweight就会变成问题。
末了，总结一下。不要照搬微服务，如同当年的SOA一样，获得对应的收益必然要付出相应的成本。如果对于自己团队的业务阶段、技术水平、业务特性识别不清楚，可能南辕北辙。
注：本文2/3篇幅节选自《从零开始学架构：照着做，你也能成为架构师》一书，获电子工业出版社授权发布，当当有售。
