前言
微服务开发中很重要的rpc功能，实现上不管是springcloud还是dubbo方式，代码结构上看，都是分为api层和service层。
前者就是纯粹接口定义+数据对象，轻量打包。后者就是对api的实现。
然后注入api，然后各自去注册中心获取需要的服务实现。
结构上一般如下：
一、api或者interface
这个module就是包含接口定义和数据定义，没有任何实现。注意：也不能引用其他业务单元的api
1，api
实际操作中会用业务（比如订单order）关键字命名，定义一个xxxApi，只有接口的定义。
2、数据对象
比如BO, DTO或者其他重要枚举等，复杂的业务操作需要一个模型，或者说就是给1api中提供出入参的包装。
二、service
以springcloud为例，有如下几层。
1、controller
这层就是对api的实现，主要是对出入参的检查，或者从上下文中获取特定参数，然后调用底层服务进行功能实现，千万不可在这一层进行复杂业务处理，这一层不支持事务回滚。
2、service层
主要的业务实现层，这里建议在分为两层
2.1 基础服务层（entityService）
对应对entity，对单表的基础操作，而且这些操作建议是用api中定义的数据对象来进行，而不用entity对象。
可以各种省去entity dto的转化。
2.2 聚合服务层（XXXFacadeService）
就是对2.1 entityService的各种聚合，这些entityService不止包括自己模块，也可以引用其他模块，完成特定的业务功能。
3、dao层
现在有很多的orm框架，比如mybatis plus ，也提供了较好的集成方式，不在展开。
4、sql层
逻辑上其实没有这一层，只是物理上它一般放在resource里了，作为dao实现的重要组成。
三、类图
如图，上图就是一个具体的实现。
该类图中重要的一个补充是，把entityService和bizService的区分开来。
实际开发中，每个微服务模块负责人的理解及习惯有差，无法做到真正的高内聚，低耦合。比如你就只需要查询或者修改其中一个表的某个状态，但就是没有这个接口。
针对这种单表的操作，其实是可以定制统一接口，要求统一提供对单表的操作的。对于复杂多变的业务，也许是未来的，都可以使用这些基础服务来操作。
比如OrderEntityApi 针对Order单表的操作，OrderCountApi，订单统计相关的api。
四、其他补充
不同的状态，应当用枚举定义。
xxBizUtills,用来做静态类的业务工具（没有注入任何springbean，且都是publish static）。
xxBizHelper,用来做动态注入的帮助类（允许注入其他springbean）。
entityService应当多用对象参数。争取最大复用。
bizFacadeService 建议多用基础类型参数，简化调用人的学习负担，重要的是，应当对业务进行重要提炼，
cache也在这一层处理，如果有多个模块都能调用这层的某个方法，说明业务设计很精湛了。
待补充。。。
