app后端版本升级后如何编排不同版本的服务

问题的产生

服务的错乱

相信做app后台的朋友们都会遇见这样的情况，在不断的版本迭代中，整个工程项目的代码特别的臃肿，而且包含着错综复杂的调用，比如粉丝模块依赖于用户信息的获取，直播模块依赖用户的获取，往往在版本的更新迭代中，我们不能整理好相互之间的调用，再加上互联网项目对迭代速度极致般的追求，导致代码的维护变得越来越困难。

版本依赖

在app的更新迭代中，可能会因为需要版本兼容的关系出现一些传统web不会遇到的关系，比如我们要修改一些用户信息，那么我们可能要思考是否会影响到关联的模块，是否会影响到上一个版本的服务。

举个例子：

例如我有个a服务，从1.0到2.0版本的时候可能就多了点参数返回，这时候我核心服务加上多的参数就够了，能保证api层面的兼容，代码层面也不会影响1.0的服务。
但是这时候我有个b服务，从1.0到2.0的话类型都变了，但是这个服务里的service层代码有一半相同代码，还有一半不同的代码，而这段代码是属于那种参数赋值类型（诸如此类没有必要提出来成公共代码的）。
那这时候我就要为b实现1.0和2.0两个版本的代码，然而又很多重复之处，那如果到3.0或者4.0我这个代码就很臃肿了，实现看起来就很不优雅了

问题的原因

上述的描述中，我们大概发现一些问题产生的原因，就是我们在每次的迭代中，没有规划好我们的每个服务。导致我们的服务直接的依赖特别错综复杂，才会出现上述的问题。

如何解决

初期设计

在业务编排上做出一个模型的抽象，吧现有业务抽象做到最大化，做好基层架构。

业务编排

首先普及一下服务类型的概念

服务分为原子服务、组合服务、流程服务
流程服务指的是整合跨各个业务领域的组合 服务或原子服务 的一个特殊的组合服务
如果是属于跨部门，跨公司一些服务的话（提现在流程性方面的），可以划分到服务编排这里

例如一个充值服务中，分成校验模块、加钱模块、日志模块等，那么加钱这个模块是不能再往下细分的，这时候我们的加钱模块就可以称之为一个原子服务。而这个充值服务是对因为一个业务流程而对若干个原子服务的组合，但是这个充值服务更偏于一个整个模块的业务，所以充值服务可以称为流程服务

其实流程服务是一种特殊的组合服务，流程服务也可以是一个原子服务的对接。
而为什么要有组合服务的出现呢，因为某些原子服务的组合出来之后，可以针对更多的业务流程所公用，所以这时候比流程服务小一级的组合型的服务，就叫做组合服务。

流程服务可以对任何服务进行流程化，主要是一些业务流程易变的，可以通过业务编排语言来进行灵活性的编排。从我们的产品编码开始到之后的版本迭代甚至重构中，一定要把服务抽象(分离)化做好。

如何解决版本迭代带来的问题

• 首先，我们先把公共的逻辑可以抽象出来下移一层，没必要非得在api层去实现。
• 其次，服务调用方需要有一个字段指明版本号
• 吧服务层变成多个层级，例如接入层和逻辑层等等，接入层实现版本控制，逻辑层去实现重复逻辑
• 在协议里指明版本，然后服务端把不同的版本调用路由到不同的handler里，可以理解为，不同版本的业务service层，会有多个版本的service实现
• 对于某些特定需求的大版本迭代，需要制定可以兼容的最低版本。
• 对于新增的版本服务，采用逻辑增加的方式，保证服务的兼容性。