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

前言

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

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

两种架构模式介绍

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

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

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

双模架构思路

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

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

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

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