前言:
当我们使用dubbo作为服务间通信的组件时,在后期的系统维护中可能会因为业务需要,服务提供者某些接口需要升级,对应的服务消费者配合作相应的修改,测试通过后一起发版上线即可。但是在这个过程中,有很多需要注意的点,不妨来梳理一下以作记录,希望对此不清楚的开发者有所帮助。
再次申明一下我们的需求吧。假设服务A提供了一个服务IHelloService,其中有一个方法sayHello,服务B、C、D…都对此有依赖,假设服务A提供的该接口已上线且被服务B、C、D正常消费,线上运行稳定。
升级前:
先将服务提供者和服务消费者分别启动,此时消费方正常消费服务。
api:
public interface IHelloService {
Result sayHello(ModelParent param);
}
服务提供者:
@Component
public class HelloServiceImpl implements IHelloService {
@Override
public Result sayHello(ModelParent param) {
MyDto dto = new MyDto();
dto.setMsg("hello," + param.getName());
return Result.success(dto);
}
}
服务消费者:
@Service
public class MyService {
@DubboReference(group = "test",version = "1.0",registry = "registry2")
private IHelloService helloService;
public Result test(ModelParent param) {
return helloService.sayHello(param);
}
}
过了几个月,服务B接到产品需求,为了满足需求,对服务A的IHelloService.sayHello提出新的要求,因为本次需求不涉及服务C、D的改动,所以服务A对该服务还需要满足服务C、D调用时保持老逻辑不变,因此服务A需要格外注意服务的兼容性。
注意:这里说的服务A、B、C…是一个个应用或系统。应用或系统对外提供多种服务,例如用户服务对外提供用户信息查询服务、用户注册服务等。
升级方案:
假设服务A和服务B的开发人员确认完需求后,服务A的开发人员想到的接口升级方案如下:
新增服务
1.服务A新提供一个sayHelloV2方法或新服务IHelloServiceV2,提供新的业务逻辑,服务B调这个新方法或新服务,原来的sayHello保留,服务C、D继续调用且本次不用修改上线。
老服务兼容
2.服务A修改IHelloService.sayHello,在原来的入参中新增字段,用于区分走新逻辑还是老逻辑。在这种方式下就需要特别注意了,因为入参增加了参数,要考虑是否会影响本次需求不涉及的服务C和服务D。
-
在原入参对象中新增字段。服务C、D对于新增的字段肯定传的是null,所以可以用null标识走老逻辑,用其他值比如1标识走新逻辑。
-
创建新的入参对象 ModelChildren 增加新字段,且该入参对象继承原入参对象。此时又分不同的情况。
-
接口方法入参对象保持原入参对象不变,即,方法签名不变,仍然是Result sayHello(ModelParent param)。仅需改动有新需求的服务B的代码,将入参对象改为新入参对象,由于该对象继承了原入参对象,所以不会有问题,但服务A需要判断传的是父类 ModelParent 还是子类 ModelChildren,并从子类 ModelChildren 中获取新字段。
-
接口方法入参对象改为新入参对象,即,方法签名修改,入参改为新对象Result sayHello(ModelChildren param)。此时,所有消费该服务的消费方均需要修改,如果消费方不改,消费方调用该方法时会抛异常org.apache.dubbo.remoting.RemotingException: Fail to decode request due to:java.lang.IllegalArgumentException:Service not found:com.biggerboy.api.IHelloService, sayHello
-
总结:
End