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

前言

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

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

什么是 WebApi 多版本

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

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

应用场景

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

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

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

解决方案

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

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

1. 通过在 URL 中追加版本号或作为查询字符串参数。
2. 通过Http自定义标头。

ASP.NET Core 中解决方案

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

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

基于 K8s 和 Kong 的解决方案

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

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

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

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

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

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 的配合

在进行大版本升级的时候，微服务的DevOps基础设施就显得非常重要了，此时我们需要动态的创建路由到kong，这就需要利用DevOps的配合，你可以将创建调用kong提供的rest接口来创建路由，也许一开始会花费比较多的时间，但是从长远来看的话还是非常重要的，可以节约后续的很多时间。

以我司来举例，当进行大版本升级时，DevOps 脚本中会检测到版本号为大版本，此时就会运行创建新环境的脚本，这个脚本负责初始化新的 大版本的 k8s 集群环境以及kong的服务和路由配置，然后自动发布新版本的各个服务，最终会提供出来一个新的服务地址出来，类似 /api/v2/xxxx

数据中间件服务的配合

在进行新的大版本开发和迭代的过程中，还会涉及到一些关于新版本数据和旧版本不兼容的情况，比如 Redis 的缓存数据结构变化，消息队列的数据结构的变化，以及 Elasticsearch 等索引数据结构的变化。

那么如何处理以上数据服务的版本兼容问题呢？ 最简单的方案是起一套新的环境，新版本完全使用一套新的中间件服务环境来进行运行，但是这样有一个缺点就是会使用更多的服务器资源，照成服务器资源浪费的情况，当然如果是土豪公司可以无视了。

那如果想不同的版本使用相同的数据中间件服务怎么办呢？ 其实办法也是有的，大部分数据中间件都是支持版本划分的，比如 Elasticsearch，CAP 等都支持使用版本来区分数据，对于不支持的可以在程序中进行控制了，比如像 Redis 这种就可以使用不同的逻辑DB来区分。

总结

本篇文章主要讲述了如果利用 kong 网关和 k8s 服务来处理 webapi 多版本的问题。

同时还讲述了在开发的过程中一些不同版本的数据应该如何处理以及需求的规划等，希望以上的东西能够帮助到有需要的人。

如果你觉得本篇文章对您有帮助的话，感谢您的【推荐】。

如果你对 .NET Core 有兴趣的话可以关注我，我会定期的在博客分享我的学习心得。

---

本文地址：http://www.cnblogs.com/savorboard/p/webapi-versions.html
作者博客：Savorboard
本文原创授权为：署名 - 非商业性使用 - 禁止演绎，协议普通文本 | 协议法律文本

转载于:https://www.cnblogs.com/savorboard/p/webapi-versions.html