微服务项目的依赖关系

在微服务化架构中, 软件项目被拆分成多个自治的服务, 服务之间通过网络协议进行调用, 通常使用透明的 RPC 远程调用.

在 Java 领域, 每个服务上线后, 对外输出的接口为一个 jar 包. 在微服务领域, jar 包被分为一方库、二方库、三方库.

• 一方库: 本服务在 JVM 进程内依赖的 jar 包.
• 二方库: 在服务外通过网络通信或 RPC 调用的服务的 JAR 包.
• 三方库: 所依赖的其他公司或者组织提供的服务或者模块.

微服务项目的层级结构

Java 微服务项目的层级结构一般为: 服务导出层、接口层和逻辑实现层, 如下图.

其中, 每个层级的职责和最终的表现形式如下:

• 服务导出层: 最后会打包成一个 War 包, 包含服务的实现 Jar 包、接口 Jar 包, 以及 Web 项目导出 RPC 服务所需要的配置文件等.
• 服务接口层: 包含业务接口、依赖的 DTO 及需要的枚举类等, 最后打包成 Jar 包, 并发布到 Maven 服务器上, 也包含在服务导出层的 War 包中.
• 服务实现层: 包含业务逻辑实现类、依赖的第三方服务的包装类, 以及下层数据库访问的 DAO 类等, 最后打包成 Jar 包, 包含在服务导出层的 War 包中.

Java 平台下微服务实现层的架构图:

本地服务层通过 DAO 层与数据库进行交互. 这里使用了数据库事务, 保证了数据存取的强一致性, 业务流程层通过组合本地服务和外部服务来完成业务逻辑的实现, 由于有远程服务的依赖, 因此只能保证数据的最终一致性.

这里有一个反模式, 切记永远不要在本地事务终调用远程服务, 在这种场景下如果远程服务出现了问题, 则会拖长事务, 导致应用服务器占用太多的数据库连接, 让服务器负载迅速攀升, 在严重情况下会压垮数据库. 顺便说一下, 虽然我们要竭力避免这种场景的发生, 但是数据库也应该有负载熔断机制.

Java 平台下微服务实现层的反模式架构