先说想法
这个标题并非一时兴起，也并非哗众取宠，而是我这段时间以来的思考。为什么会出现这样的想法？这还得从一个事实说起。
众所周知，微服务并不能提升整个项目的吞吐量，它的作用仅仅只是把项目按照一定的规则拆分成各种模块，然后每个模块都可以交给不同小组去开发。他解决的仅仅是大项目的团队协作问题。而真正能提升吞吐量的，除了程序本身的质量那就是负载均衡了，而且事实上微服务的架构中，每个服务都是以负载均衡的形式部署的，所以这里就有一个问题了：
如果仅仅是为了解决 [大项目的团队协作问题] 那么常规的模块化设计是不是也能做到？
现在由于 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 是多少，服务到底有没有正常发布，有没有正常被发现。你会不会觉得这样有什么不妥呢？
以上只是个人的一点浅薄见解，欢迎大家理性探讨。
| 
