巧妙构建单体模式和微服务模式的双模架构

前言

我们在做应用系统架构设计的时候，经常会遇到一个问题，是使用单体架构模式，还是使用微服务架构模式？这是两种最常见的软件架构方式，他们各有优劣势。

有时候我们在项目设计初期，因为信息不准确或思路不完善，不得不进行二选一，而项目到了后期，发现设计不能满足项目需要的时候，再去转变架构模式，则需要付出巨大代价。

两种架构模式介绍

简单介绍下两种架构模式的优劣势。

1、单体模式：在单体模式中，整个应用被构建为一个单一的、统一部署的单元。所有的功能模块都打包在一起，共享同一个代码库、数据存储和资源。单体应用通常由多个层组成，如用户界面层、业务逻辑层和数据访问层等。优点包括开发简单、部署方便、调试容易等。但是，随着应用的规模不断增大，单体模式可能会面临代码耦合度高、扩展性差、部署和维护困难等问题。

2、微服务模式：微服务模式是一种将应用拆分成多个小型、独立部署的服务的架构设计方式。每个服务都可以独立开发、部署和扩展，服务之间通过轻量级的通信机制（如HTTP、消息队列等）进行通信。微服务架构的优点包括服务之间解耦、各服务可独立扩展、技术栈灵活等。但是，微服务架构也增加了系统的复杂性，需要额外考虑服务发现、负载均衡、监控等方面。

双模架构思路

应用系统如何实现一种既能支持单体模式、也能支持微服务模式的双模架构呢？笔者基于自己的实战经验，提供一个思路，供大家参考。

1、我们可以将应用系统拆分成多个小型的、独立的模块，按照微服务的思维方式去进行开发，每个模块的拆分粒度，可以根据项目情况自己把握，个人建议，粒度不需要太细。

2、我们使用maven进行工程代码结构的管理，每个模块都是一个独立的maven工程。模块内可以拆分成多个包，包含controller层的包、entity层的包、service+dao层的包。

3、模块与模块之间的调用，不要直接使用maven配置的方式将被调用模块service包引入当前模块，而是要在被调用模块内，定义一个api接口包，将api接口包引入当前模块的maven配置，然后使用被调用的api接口进行编程。注意，这里只引用api接口，不引用接口的实现类。

4、api接口包需要实现类，我们再定义两个包作为api接口的实现包，一个叫做 local 本地实现包，一个叫做 remote 远程实现包。local包引入模块的service包，基于service接口进行实现；remote包不引入模块的任何包，基于服务调用的方式，调用模块的controller服务进行实现。

5、构建单体启动工程，与微服务模式不同，工程的启动类和工程启动的配置文件，不直接在模块的代码中编写，而是独立出来。编写启动类和单体配置文件，基于maven配置，把所有模块的controller包、service+dao的包都引入进来，把用到的api接口的 local 本地实现包也引入进来，实现单体模式。

6、每个模块单独构建微服务启动工程，编写启动类和微服务配置文件、实现nacos注册、发现等微服务功能，每个模块分别引入模块的controller包、service+dao的包，把用到的api接口的 remote 远程实现包也引入进来，实现微服务模式。

双模架构示意图

下面是一个调用关系示意图，供参考。

总结

这样的架构模式，通过面向接口编程，我们开发一套代码，基于maven管理代码结构的方式，即可以组装单体模式的启动工程、也可以组装微服务模式的启动工程，而无需改动任何业务代码。当我们本地开发时，为了节省资源，可以使用单体模式，线上部署时，则直接按照微服务模式进行部署即可。无论项目需求如何变化，我们都能灵活应对。