前言：

当我们使用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 {@Overridepublic 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