基于dubbo设计过程需要注意的事项

原理回顾：

远程服务器调用流程

1.客户端发起接口调用

2.服务中间件进行路由选址：找到具体接口实现的服务地址

3.客户端将请求信息进行编码（方法名，接口名，参数，版本号等序列化后，转成字节通过本地代理对像socket写入）

4.建立与服务端的通讯（客户端与服务端通过TCP socket直连）

5.服务端将接收到的信息进行反编码（socket读出字节，反序列化后，还原成方法名，接口名，参数，版本号等）

6.根据信息找到服务端的接口实现类（根据反序列化后得到的接口调用信息，反射找到要调用的接口实现的实例）

7.将执行结果反馈给客户端

涉及的核心知识储备

1.java多线程

2.JVM

3.网络通讯（NIO）

4.动态代理

5.反射

6.序列化

7.路由节点管理（zookeeper）

包划分：

1.dubbo-api

服务接口，服务模型，服务异常等均放在API包中，因为服务模型及异常也是API的一部分。

关于服务接口

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

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

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

每个接口都应定义版本号，为后续不兼容升级提供可能

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

关于常量 

完备集，使用Enum，如ENABLE, DISABLE。

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

序列化

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

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

异常

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

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

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

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

调用

不要只是因为是Dubbo调用，而把调用Try-Catch起来。Try-Catch应该加上合适的回滚边界上。

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

版本控制

在dubbo最佳实践中有写到，所有接口都应定义版本，在这里有几点需要注意下，接口服务如果更新频繁，并且兼容老版本的，不建议更改版本号，因为dubbo这边对除 * 以外的版本号，都是采用完全匹配的方式进行匹配。即服务端的版本号如果从1.0升级为1.1，并且未保留原有的1.0的服务，那么客户端必须同时也将服务版本号升级为1.1，否则将无法匹配到远处服务。

dubbo常见调优参数项：

timeout，调用超时时间，默认为1000毫秒，即超过1000毫秒没有返回数据，就会执行重试机制

retries，失败重试次数，默认为2，即失败（超时）之后的重试次数

connections，对每个提供者的最大链接数，默认为100，建议根据服务器配置进行调整

loadbalance，负载均衡策略，默认为random

async, 是否异步执行，默认为false