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实现
  • 对于某些特定需求的大版本迭代,需要制定可以兼容的最低版本。
  • 对于新增的版本服务,采用逻辑增加的方式,保证服务的兼容性。
Loading Disqus comments...
Table of Contents