编码技巧——项目结构

现在服务端架构一般使用微服务，各个功能模块独立成单个服务，服务之间通过RPC或MQ、ZK等通信；

这里举例自己设计的一个会员系统的服务架构：

（1）服务架构

系统包含：

1. member-core 核心服务，包含：通用处理逻辑（如重试、异步消息投递）、对外提供的dubbo接口、对内包装外部dubbo接口、实体/异常/枚举/状态码/工具类的定义（如分页实体、HTTP返参、dubbo返参、业务异常、系统状态码、Utils、Enums、通用的Constants如配置key）、消息的Listener等；此服务一般在前期发布较多，填充基础能力，而在后期发版次数会很少，因为基础能力都已经扩展完毕，最多是一些打包；

2. member-api web服务，这一层就是名副其实的业务层，距离用户最近的一层，会有大量的controller和service，操作Mysql（对于用户侧的数据可以查DB，对于非用户侧数据需要调用服务，明确各个微服务的职责）、redis、cache，调用core服务的基础能力和工具，使用core定义的枚举、状态码、返回实体；对于C端请求需要做限流，对调用服务需要做熔断；

3. member-mng 管理后台，这一层主要是服务内部运营同事，涉及后台页面及运营消息发放；比较简单；运营后台虽简单，但是运营权限较大，涉及读和写操作，一般会在controller层做一些提示和防呆，以便捷和风险控制为主，需要控制数据的读写权限（一般url会做权限的读写分离）；

4. member-order 订单服务，经典的数据服务，一般包括订单的新增、查询、更新、废单处理、下游通知等；这一层重要的是数据服务的稳定性和可靠性，夸系统数据读写，会涉及分布式事务，一般会以最终一致性为保证，系统异常时能告警并自恢复；禁止其他微服务直接操作订单领域的数据，最好做到存储的物理隔离；

5. member-task 定时任务，存放一些定时任务，主要是方便检索各业务的定时任务；这个应用必要性不是特别大，可以去除，将定时任务分散在各个微服务，写在各个业务场景的与service同一层的地方；

（2）项目结构

对于每一个项目工程，内部又分为多个module，每个module应该由自己的职责：

 工程结构：

1. boot，java包下可以存放config、handler/filter和启动类Application；config包括一些插件引入，如mybatis、分布式调度、消息mq、分布式限流sentinel、分布式锁、监控插件，放一些@Configuration和相关的@Bean；handler/filter可以放如dubboFilter，也可以将这部分放到service里，因为可能会涉及业务逻辑；resource包下，可以放配置文件xx.property、lua脚本、SPI方式的service；

2. web，顾名思义，就是网络层，主要就是放controller的，如果项目没有boot，也可以把config放在这里；此外，可以放全局异常捕获器@controllerAdvice；

3. service，这一层就是写复杂的业务逻辑了，禁止把复杂的业务逻辑写在web层，web层就是调用service，返回结果；一般按照业务场景分包，内部写service的接口、实现类、枚举、常量、模型；各业务包的外层可以放一些通用的handle/helper/convertor，如校验登录态的切面、业务异常处理统一封装返回体、日志工具、bean转换工具等；

4. common，这一层可以打包出去，一些通用的内部使用的常量、枚举、工具包、模型，异常；

5. facade， 这一层放dubbo接口，外层放dubbo统一返回体，dubbo状态码，dubbo接口的业务异常；也是按照业务分包，包内有service、enum、constant、model；

为什么要把dubbo业务异常也放在facade工程里打包出去呢？

之前开发遇到了这个问题，即在项目中使用dubboFilter，发现定义的dubbo业务异常在filter内未被正确的捕获，反而是进入了RuntimeException的捕获处理流程去了，所以去看了下dubboFilter的源码，分析如下：

 因此，将业务异常放在二方jar包中（这也是中间件二方包的常用做法）；

6. dao，这一层放数据库相关的实体、分库和非分库的DAO接口（在定义数据源时绑定不同的DAO接口所在的包路径）、xml文件、mybatis配置、分表策略；

这里举个例子，会员系统的core工程结构：

通用点的微服务工程结构：