一、目录管理

每个微服务xxx-service只有两个model

1、xxx-service-api:只对外提供最基本的inteface接口和一些枚举和扩展vo

2、xxx-service-provider:实现api的具体逻辑，对外提供dubbo协议的微服务实现

二、依赖管理

在公用starter里新建sqg-bom，类似dubbo-dependencies-bom。对所有的依赖版本进行统一管理。

https://github.com/apache/dubbo/tree/master/dubbo-dependencies-bom

三、代码生成

使用统一的代码目录有利于对代码的维护，每一个开发都可以快速进入业务代码的研究，没有过多的负担。

四、迭代

1、迭代完成对外提供约定的api层version应该升级

2、新的迭代不应对任何接口字段进行删减，也不能删除表字段，只能增加。

五、Dubbo

1、重试

没有确定下游服务是否有幂等性处理时，请关闭Dubbo默认的2次重试

• 针对全服务的关闭重试

dubbo:
  application:
    name: ${spring.application.name}
  provider:
    retries: 0
  consumer:
    retries: 0

• 针对单个服务的关闭重试

@Reference(version="1.0.0",retries = 0)
DemoService demoSerivce;

2、微服务不是银弹

2.1、每个服务管理自己的数据库，之前的联表查询就要变成接口查询。为了避免返回列表时的大批量微服务调用，应该在设计表时，保证字段冗余。

3、分包

建议将服务接口、服务模型、服务异常等均放在 API 包中，因为服务模型和异常也是 API 的一部分，这样做也符合分包原则：重用发布等价原则(REP)，共同重用原则(CRP)。

如果需要，也可以考虑在 API 包中放置一份 Spring 的引用配置，这样使用方只需在 Spring 加载过程中引用此配置即可。配置建议放在模块的包目录下，以免冲突，如：`com/alibaba/china/xxx/dubbo-reference.xml`。

4、粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。

服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。

不建议使用过于抽象的通用接口，如：`Map query(Map)`，这样的接口没有明确语义，会给后期维护带来不便。

5、版本

每个接口都应定义版本号，为后续不兼容升级提供可能，如： `<dubbo:service interface="com.xxx.XxxService" version="1.0" />`。

建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。

当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

6、兼容性

服务接口增加方法，或服务模型增加字段，可向后兼容，删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。

各协议的兼容性不同，参见：[服务协议](../references/protocol/)

7、枚举值

如果是完备集，可以用 `Enum`，比如：`ENABLE`, `DISABLE`。

如果是业务种类，以后明显会有类型增加，不建议用 `Enum`，可以用 `String` 代替。

如果是在返回值中用了 `Enum`，并新增了 `Enum` 值，建议先升级服务消费方，这样服务提供方不会返回新值。

如果是在传入参数中用了 `Enum`，并新增了 `Enum` 值，建议先升级服务提供方，这样服务消费方不会传入新值。

8、序列化

服务参数及返回值建议使用 POJO 对象，即通过 `setter`, `getter` 方法表示属性的对象。

服务参数及返回值不建议使用接口，因为数据模型抽象的意义不大，并且序列化需要接口实现类的元信息，并不能起到隐藏实现的意图。

服务参数及返回值都必须是[传值调用]，而不能是[传引用调用]，消费方和提供方的参数或返回值引用并不是同一个，只是值相同，Dubbo 不支持引用远程对象。

9、异常

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。

如果担心性能问题，在必要时，可以通过 override 掉异常类的 `fillInStackTrace()` 方法为空方法，使其不拷贝栈信息。

查询方法不建议抛出 checked 异常，否则调用方在查询时将过多的 `try...catch`，并且不能进行有效处理。

服务提供方不应将 DAO 或 SQL 等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。

10、调用

不要只是因为是 Dubbo 调用，而把调用 `try...catch` 起来。`try...catch` 应该加上合适的回滚边界上。

Provider 端需要对输入参数进行校验。如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。

11、配置

11.1 在 Provider 端尽量多配置 Consumer 端属性

原因如下：

• 作为服务的提供方，比服务消费方更清楚服务的性能参数，如调用的超时时间、合理的重试次数等
• 在 Provider 端配置后，Consumer 端不配置则会使用 Provider 端的配置，即 Provider 端的配置可以作为 Consumer 的缺省值 。否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 是不可控的，并且往往是不合理的

Provider 端尽量多配置 Consumer 端的属性，让 Provider 的实现者一开始就思考 Provider 端的服务特点和服务质量等问题。

示例：

<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
timeout="300" retries="2" loadbalance="random" actives="0" />

<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
timeout="300" retries="2" loadbalance="random" actives="0" >
<dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>

建议在 Provider 端配置的 Consumer 端属性有：

1. `timeout`：方法调用的超时时间

2. `retries`：失败重试次数，缺省是 2

3. `loadbalance`：负载均衡算法 ，缺省是随机 `random`。还可以配置轮询 `roundrobin`、最不活跃优先 `leastactive` 和一致性哈希 `consistenthash` 等

4. `actives`：消费者端的最大并发调用限制，即当 Consumer 对一个服务的并发调用到上限后，新调用会阻塞直到超时，在方法上配置 `dubbo:method` 则针对该方法进行并发限制，在接口上配置 `dubbo:service`，则针对该服务进行并发限制

详细配置说明请参考：[Dubbo配置参考手册](../references/xml/)

11.2 在 Provider 端配置合理的 Provider 端属性

<dubbo:protocol threads="200" />
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
executes="200" >
<dubbo:method name="findAllPerson" executes="50" />
</dubbo:service>

11.2.1 建议在 Provider 端配置的 Provider 端属性有：

1. `threads`：服务线程池大小

2. `executes`：一个服务提供者并行执行请求上限，即当 Provider 对一个服务的并发调用达到上限后，新调用会阻塞，此时 Consumer 可能会超时。在方法上配置 `dubbo:method` 则针对该方法进行并发限制，在接口上配置 `dubbo:service`，则针对该服务进行并发限制

11.3 配置管理信息

目前有负责人信息和组织信息用于区分站点。以便于在发现问题时找到服务对应负责人，建议至少配置两个人以便备份。负责人和组织信息可以在运维平台 (Dubbo Ops) 上看到。

在应用层面配置负责人、组织信息：

<dubbo:application owner=”ding.lid,william.liangf” organization=”intl” />

在服务层面（服务端）配置负责人：

<dubbo:service owner=”ding.lid,william.liangf” />

在服务层面（消费端）配置负责人：

<dubbo:reference owner=”ding.lid,william.liangf” />

若没有配置服务层面的负责人，则默认使用 `dubbo:application` 设置的负责人。

11.4 配置 Dubbo 缓存文件

提供者列表缓存文件：

<dubbo:registry file=”${user.home}/output/dubbo.cache” />

注意：

1. 可以根据需要调整缓存文件的路径，保证这个文件不会在发布过程中被清除；

2. 如果有多个应用进程，请注意不要使用同一个文件，避免内容被覆盖；

该文件会缓存注册中心列表和服务提供者列表。配置缓存文件后，应用重启过程中，若注册中心不可用，应用会从该缓存文件读取服务提供者列表，进一步保证应用可靠性。

11.5 监控配置

11.5.1. 使用固定端口暴露服务，而不要使用随机端口

这样在注册中心推送有延迟的情况下，消费者通过缓存列表也能调用到原地址，保证调用成功。

11.5.2. 使用 Dubbo Admin 监控注册中心上的服务提供方

使用 [Dubbo Admin](https://github.com/apache/dubbo-admin) 监控服务在注册中心上的状态，确保注册中心上有该服务的存在。

11.5.3. 服务提供方可使用 Dubbo Qos 的 telnet 或 shell 监控项

监控服务提供者端口状态：`echo status | nc -i 1 20880 | grep OK | wc -l`，其中的 20880 为服务端口

11.5.4. 服务消费方可通过将服务强制转型为 EchoService，并调用 `$echo()` 测试该服务的提供者是可用

如 `assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));`

11.6 不要使用 dubbo.properties 文件配置，推荐使用对应 XML 配置

Dubbo 中所有的配置项都可以配置在 Spring 配置文件中，并且可以针对单个服务配置。

如完全不配置则使用 Dubbo 缺省值，详情请参考 [Dubbo配置参考手册](../references/xml/) 中的说明。

11.7 其他解释

11.7.1 配置的覆盖规则

1) 方法级别配置优于接口级别，即小 Scope 优先

2) Consumer 端配置优于 Provider 端配置，优于全局配置，最后是 Dubbo 硬编码的配置值 Dubbo 配置参考手册