微服务除了「微」这个优点，其它都是痛点

在这微服务还在大行其道的时代，也许是时候应该考虑下微服务到底有什么优点了，恕我愚钝，我觉得微服务的优点只有一个「微」字。

1、因为微，所以系统可以简单发布。不同于单体应用牵一发而动全身，微服务发布变得如此简单。

2、因为微，所以系统可以简单扩展。不同于单体应用，基于注册中心微服务可以很容易做到水平扩展。

3、因为微，所以系统支持系统异构。不同于单体应用统一的技术栈，微服务只要保证接口协议，系统自身可以选择不同的技术栈。

那微服务有哪些缺点呢，那就多了去了，也是源于「微」，成也微也，败也微也。微服务的缺点很多，但就是没有人指出来。

1、只见树木不见森林。微服务多了，没有一个人是可以把整个系统架构说的清楚，每个人只盯着自己的问题，出了问题上游到下游逐个排查。而且服务多了，服务之间的调用也必然增多，所以复杂性自然而然提高了。

2、职责划分混乱。我经历过太多公司内部都是一种跑马圈地式的上马微服务项目，谁的项目多谁的业绩就高 。搞微服务根本没有系统边界的分析和划分，通常都是有人不想把一些服务放到自己项目里，有的人想把一些服务接过去，还有的一言堂，“受益”于人的因素，微服务划分全走了样。

3、拆分粒度不好把握。我见过就一个消息系统，短信搞一个微服务，微信搞一个微服务，邮件一个微服务，push一个微服务，真有必要分的这么细吗？再来一个站内信，也搞一个微服务。把这些消息全部融在一个微服务系统里呢，好像微信消息又比较独立一些，所以粒度的把控本身也是个难题。

4、资源浪费。我见过自从微服务拆分后，每个拆分系统都带着自己的task服务，task上只有1～2个定时任务，服务拆分越多，需要的服务器资源也越多。其它诸如crm的服务也是类似，都需占用独立的资源。

5、调用混乱。自从有了微服务我发现已经没有上游下游的概念了，大家都是你中有我，我中有你。上游调用完下游服务，下游还要再调用上游服务。

6、重复代码太多。这个很明显，既然微服务独立部署了，所以很多公共的东西都或多或少的都会出现重复代码，即便使用了公共包，版本也非常多，我见过就加一个常量都要发布jar包的情况。更有甚者，依赖Spirng还自己封装StringUtils类似的方法。

7、分布式事务。这个是正常说来是避不开的话题，单体应用可以写在一个事务里，拆分后如果有多个调用链，那就悲剧了。再夹杂着各种服务异常，网络超时，考虑最终一致性是有原因的。