在软件开发领域，技术选型一直是开发者们持续探讨的重要议题。今天分享的观点，并非突发奇想或博人眼球，而是基于我长期以来的思考与实践经验。这一思考的源头，要从微服务架构的本质说起。
大家都知道，微服务架构的主要价值，并非提升项目整体吞吐量。它的核心作用，是将大型项目按特定规则拆解为多个模块，便于不同开发小组并行作业，解决大型项目团队协作的难题。真正能提升吞吐量的，除了程序本身的质量，负载均衡技术起着关键作用。值得注意的是，在微服务架构中，每个服务通常以负载均衡的方式部署。于是，一个值得深思的问题出现了：
如果只是为了解决大型项目的团队协作问题，传统的模块化设计是否同样能够胜任？
随着 Maven 的广泛应用，企业内部搭建私服变得轻而易举。这使得每个服务都能以 JAR 包的形式进行开发。举例来说，在常见的业务场景中，存在用户服务和订单服务。通常的做法是创建一个聚合服务，通过调用这两个服务的接口，实现业务逻辑的整合。
现在，我们换一种思路。将用户服务和订单服务分别打包成 JAR 包上传至私服，然后在聚合服务中引入这两个 JAR 包，同样能够实现业务逻辑的集成。若需要负载均衡，只需多部署几个聚合服务实例，与微服务架构相比，似乎并无二致。如果你能想到这种方案的不足之处，欢迎指出。
一、剖析微服务架构的弊端
1. 耦合性问题突出
尽管微服务在开发和部署时，不会直接影响其他服务，但一旦接口的输入输出参数发生变化，所有调用该接口的服务都必须同步升级。若不及时升级，服务间的通信就会出现问题。有时，为了兼容不同版本的接口，还需要单独创建新接口，进一步增加了开发和维护的复杂度。
2. 增加系统复杂度
微服务架构依赖注册中心来管理服务的注册与发现。这无疑增加了系统的中间件，不仅提高了系统的复杂性，还增加了运维的难度和成本。一旦注册中心出现故障，整个微服务系统的可用性都会受到影响。
3. 带宽消耗显著
由于微服务之间的调用通过网络进行，无论是内网还是公网，都会产生一定的带宽消耗。在高并发场景下，大量的服务间通信会占用宝贵的网络资源，甚至可能导致网络拥堵，影响系统性能。
4. 分布式事务处理困难
当一个事务的操作分布在多个微服务上时，就会引发分布式事务问题。要保证事务的原子性、一致性、隔离性和持久性（ACID），需要采用复杂的分布式事务解决方案，这无疑增加了开发和运维的难度。
二、模块化 Jar 包方案的优势
1. 降低耦合升级压力
在模块化 Jar 包方案中，虽然模块之间也存在一定的耦合性，但当接口的输入输出参数或接口名称发生变化时，已部署上线的其他模块并不需要立即升级。只有在修复业务相关的 Bug 时，才会根据实际情况进行升级。这是因为模块以 JAR 包的形式被引入其他模块，即使原模块代码发生变化，线上已部署的模块仍使用旧版代码，避免了因技术原因被迫升级的情况。
2. 简化系统架构
该方案无需注册中心，减少了中间件的使用，降低了系统的复杂性。开发人员无需关注注册中心的运行状态、URL 配置等问题，专注于业务逻辑的开发，提高了开发效率。
3. 节省带宽资源
由于模块间的调用是在本地进行，无需通过网络传输，因此不会消耗额外的带宽资源。这在网络资源有限的情况下，能够有效提升系统的整体性能。
4. 避免分布式事务问题
在模块化 Jar 包方案中，所有业务逻辑都在同一个服务中执行，不存在分布式事务问题。这大大简化了事务处理的复杂度，降低了开发和运维的难度。
三、从服务器资源利用看两种方案的差异
或许有人会质疑，将多个模块整合到一个服务中，会不会增加服务器的部署数量？为了回答这个问题，我们通过一个简单的案例来分析。
假设有两个服务，左边的聚合服务需要 10 台服务器才能满足业务需求，右边的聚合服务需要 5 台服务器。在这种情况下，总共需要 15 台服务器。
若采用微服务架构，以负载均衡的方式部署，每个微服务可能都需要部署 15 台服务器。再加上两个聚合服务，服务器的总数将超过 32 台。当然，这是一种极端情况，在实际应用中，每个微服务的业务量可能不同，部署的服务器数量也会有所差异，但总体来说，微服务架构需要的服务器数量更多。
而采用模块化 Jar 包方案，只需 15 台服务器，10 台用于部署左边的聚合服务，5 台用于部署右边的聚合服务，就能满足业务需求。
综上所述，模块化 Jar 包方案借鉴了第三方库的设计思想，以更简洁的方式实现了业务模块的集成。在开发登录或支付功能时，只需引入相应的 JAR 包，调用其中的方法即可。这种方式无需学习复杂的分布式框架，也无需关注注册中心的运行状态，大大降低了开发和运维的门槛。
以上是我的一些个人见解，希望能引发大家的思考，欢迎理性探讨。