基于 Kong 和 Kubernetes 的 WebApi 多版本解决方案

大家好,很久没有写博客了,最近半年也是比较的忙,所以给关注我的粉丝们道个歉。去年和朱永光大哥聊的时候提了一下我们的这个方案,他说让我有空写篇博客讲一下,之前是非常的忙,所以这次趁着有些时间就写一下我们这边关于版本控制的方案吧。

那么今天给大家分享一个我们正在使用的一个基于k8s以及kong网关的WebApi多版本管理的解决方案,这种方案已经在我们的生产环境运行了将近两年,也迭代了很多个版本,我们觉得这个方案非常的适合用在微服务当中。

什么是 WebApi 多版本

版本的概念大家应该都知道,那么什么是 WebApi 的版本呢?

开发App后端的兄弟应该都非常清楚了,在给 App 提供 WebApi 接口的时候,由于安装在用户手机上的 App 存在多个客户端版本的问题,这些版本大部分时候需要进行共存,由于现在 Android 和 IOS 基本上都不允许App内置升级功能,当然有些时候是用户不愿意或者拒绝升级,很多时候业务需求在不停的变化,就避免不了对接口进行调整和增加新功能,所以我们需要保证后端接口的向前兼容性,那些没有升级的客户端App仍然要让它们能够正常工作,这就需要使用到多个不同版本的Api接口来进行控制,很多时候我们是保留旧接口,增加新接口,为了区分不同的客户端,然后给接口进行版本编号,这就是WebApi的多版本控制管理。

应用场景

了解了WebApi多版本的概念之后,应用场景就自然也就明白了。

除了 App 的服务端会用到之后,同样也适用于那些客户端非浏览器的项目的服务端,例如给一些桌面程序提供接口等等。

有些时候针对一些特性的App客户端提供不同的功能也是其应用场景之一。

解决方案

解决方案就是App在请求的时候携带一个版本信息到服务端,然后服务端就能够提供不同的功能了。

Api 请求服务端携带版本信息可以通过两种方式:

通过在 URL 中追加版本号或作为查询字符串参数。

通过Http自定义标头。

ASP.NET Core 中解决方案

在 ASP.NET Core 中的方案,我不打算进行详细介绍了,感兴趣的可以看下下面这个大兄弟的这篇文章:

菠萝吹雪-Code : ASP.Net Core WebApi几种版本控制

基于 K8s 和 Kong 的解决方案

由于我们使用的是基于 Kubernetes 的多版本解决方案,所以此处就详细说明一下。

我们采用的是在 URL 中追加版本号来实现的版本控制,这样做有两个好处:

1、方便 kong 进行路由解析,可以直接通过配置方式实现,如果通过 header 来路由的话,需要自己进行扩展才行。
2、从日志记录的时候可以很直观到看到当前的 API 版本,在发生问题时候可以快速定位的具体版本的服务。

下面是我画的一个我们的基于 Kubernets 的大致的架构图,像 CDN 这些我就给省掉了。

version-isolation.png

主要流程分为以下几个步骤:

1、App 端不同的版本会请求不同的 Api 接口,这些 Api 接口以版本区分,不同的版本可以提供不同的结果。

2、Kong 网关针对 URL 中携带的版本号信息进行路由转发,在配置路由转发的时候需要把携带路径参数开启,例如 /api/v1/ordering/list 这个请求地址,我们可以新建一个路由,然后配置 /api/v1/ordering 这个前缀的URL 转发的到 ordering 这个服务,同时把路径带过去,假如说我们 ordering 微服务的地址为 /api/ordering,那么就可以配置服务的路径为 /api/ordering,由于路由配置了携带路径,所以此时我们的微服务接收到的请求地址就变成了 /api/ordering/list。

3、Kong 网关以 NodePort 方式部署到 Kubernets 集群中,路由服务指向 Kubernets 内部服务的dns集群地址。Kong 的多个实例他们之间共享配置信息,可以把配置存储到 PostgreSql 或者 Cassandra 中。

4、后端微服务集群内部提供集群地址配置到Kong的Service中。

业务需求的配合

这整个方案中有一个重要的点就是开发人员和产品或者业务人员的一个配合问题,也就是整个开发进度的规划需要符合敏捷开发的流程,这样不会导致每个小版本都会有变化非常大的接口这种需求的出现,可以做到平滑升级。

以我司来举例,当有对接口进行大改的需求时,我们会将其规划到大的迭代主版本中,这样在大版本发布的时候,会新起一套大版本的服务集群环境来进行支撑,此时老的版本仍然不会删除,这样就会新旧版本同时共存,当新的版本再迭代几个小版本时候大部分用户其实已经自动升上来了,这个时候就可以把旧的大版本进行强制升级提示了,这样终端App用户就会全部升级到新的版本上了,从而把影响降低到最小。

所以,此处遵循一个原则:小版本做兼容升级,大版本做重大特性的提供以及 Break Changes 和代码重构等工作。

DevOps 的配合

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyyxxy.html