原理回顾:
远程服务器调用流程
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