主要矛盾是随着系统越来越大，有了业务解耦的需求，把大系统抽象成模块（服务），提升开发体验的，方便找到出系统瓶颈。 至于微服务的实现是 HTTP 、grpc,甚至是 jar 包 都没问题，取决于你怎么去划分业务，没有绝对正确，跟业务需求匹配就好了。 以前还有一个老东西——SOA ，也是面向服务架构，只是以过去系统规模，把单一的支付系统归为一个大的服务，现在有了微服务，再细化，把支付拆分成微信支付服务，支付宝服务，银联支付服务等。 至于分成支付系统服务，还是多个渠道支付服务拆分，都是没错的。业务的发展进度不同，都是合理的。

组织架构决定系统架构，并不完全是项目大不大来决定的

本来我维护一个没什么流量的小业务，重新部署 10 台机器就够了。现在你这么搞，我改一行代码就得重新部署一万台服务器。 本来这个服务 4c8g 的容器就够了，现在你这么搞，我直接上物理机也不够啊，天知道几千万行代码里哪些天杀的业务吃完了内存。 本来这个服务只有我们两三个人改，想什么时候发布就什么时候发布。现在你这么搞，每次发布前面排着几百个发布单，一个月才能发布成功一次。万一再出个故障要回滚代码，那真是画面太美我不敢看。。 啥，整个业务总用才用了不到 100 核？那你上什么微服务嘛……

脱离 Java ，在异构世界中会有更广大的视野。例如规模较大的团队把 Java 、Python 、Golang 不同的系统串起来… 而且，重点是为了解决康威定律带来的组织效率问题（大部分企业的沟通成本和协作效率的成本远大于设备的开支），如 1 楼所述。而为了微服务而实施微服务，这是一种本末倒置了。

我工作一两年经验的时候也思考过类似问题，也是接触到更大的项目、流量才有了实际的改观 1 、微服务本身就是模块化方案：相比单体，协作（功能设计、代码开发）、运维（版本、发布、监控）都更敏捷 2 、服务健壮性：单体一旦引入了内存溢出、死循环等问题，直接影响整个服务 3 、压力：（图挂了看文字描述不太理解）单体项目一旦过于庞大，如何做压力评估？哪些模块需要支持多少 qps ？出现某个模块压力，单体只能扩充一台实例 4 、。。。