微服务是不是一种错误的方向？

先说想法

这个标题并非一时兴起，也并非哗众取宠，而是我这段时间以来的思考。为什么会出现这样的想法？这还得从一个事实说起。

众所周知，微服务并不能提升整个项目的吞吐量，它的作用仅仅只是把项目按照一定的规则拆分成各种模块，然后每个模块都可以交给不同小组去开发。他解决的仅仅是大项目的团队协作问题。而真正能提升吞吐量的，除了程序本身的质量那就是负载均衡了，而且事实上微服务的架构中，每个服务都是以负载均衡的形式部署的，所以这里就有一个问题了：

如果仅仅是为了解决 [大项目的团队协作问题] 那么常规的模块化设计是不是也能做到？

现在由于 maven 的出现，再加上企业内部可以搭建私服，我们完全可以让每一个服务都以 jar 包的形式来开发。举个很简单的一个例子，比如有一个用户服务，订单服务，现在一般的做法是写一个聚合服务去调用这两个服务的接口，来实现业务逻辑的整合。

那如果把用户服务换成用户模块 jar 包、订单服务换成订单模块 jar 包，以 jar 包的形似传到私服，然后同样的写一个聚合服务，聚合服务把这两个 jar 包引入进来，是不是也能达到这样的效果？

如果需要负载均衡，那我们把这个聚合服务部署多个就好了，完全不影响。我完全想不到跟微服务比起来有什么坏处，如果有，欢迎大家指正。

微服务有什么缺点

耦合性太高，虽然开发和部署不会影响别的服务，但是你如果动了接口的出入参，那么其他服务就得同步升级了，而且是调用了这个接口的服务都要升级，又或者你需要为此单拎一个接口出来，做版本区分。
需要注册中心，项目会多出一个中间件，提升复杂度。
会消耗内网带宽，甚至是公网带宽，因为服务之间的调用都是通过网络完成的。
会出现分布式事务的问题，因为一个事务的操作可能会分布在不同的服务上执行。

如果用常规的模块化方案

虽然耦合也高，但是如果你动了接口的出入参甚至是接口名，别的服务是不需要立刻升级的，除非你是在改 bug ，但这是被业务逼着升级，因为不升级是有 bug 的，但他不会被技术逼得升级，因为模块只是被打成了一个 jar 包引入了其他模块里，无论你怎么变，已经部署在线上的别的模块里依然是用的你的老代码。
不需要注册中心
不会消耗多余的带宽资源
不需要分布式事务了

还是压力问题

一定会有人说，你把这么多模块都塞进一个服务里，那这个服务得部署多少台机器啊。

说到这里，就不得不从全局来看待问题了。我们可以看两张图（不好意思，有错别字，但是已经截图了就懒得改了，能看懂就行）

图 1

图 2

根据上面的两个图，我们是不是可以这么说，微服务在面对相同的流量时根本没有节约服务器的数量？反而还多了？

假如左边的聚合服务，他的业务量需要 10 台服务器才能支撑，右边的需要 5 台才能支撑，那么一共是 15 台。而微服务会导致 A 部署 15 台，B 也部署 15 台，再加上两个聚合服务，一共需要 32 台以上。

当然了，这只是极端的情况，现实中可能 A 服务不需要处理这么多业务，他可以少部署一点，又或者 B 服务可以少部署一点。但无论怎么算，服务器都是多了。

如果采用 jar 包的形式，那么只需要 15 台就够了，10 台用来部署左边的聚合服务，5 台用来部署右边的聚合服务。

说到底

这其实就是以三方库的思想在设计模块化，如果有一个工具类叫用户管理，有一个工具类叫支付管理。当你需要开发登录功能的时候，只需要引入一个 jar 包，然后调用里面的某个方法就好了，当你需要开发支付功能的时候也一样，你不需要去学习 dubbo ，不需要去学习 springcloud ，甚至不需要去关注注册中心是否挂没挂，注册中心的 url 是多少，服务到底有没有正常发布，有没有正常被发现。你会不会觉得这样有什么不妥呢？

以上只是个人的一点浅薄见解，欢迎大家理性探讨。