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

标签: kong kubernetes web | 发表时间:2020-04-09 07:25 | 作者:JetLee
出处:http://weekly.dockone.io

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

什么是Web API多版本

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

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

应用场景

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

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

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

解决方案

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

API请求服务端携带版本信息可以通过两种方式:
  1. 通过在URL中追加版本号或作为查询字符串参数。
  2. 通过Http自定义标头。


ASP.NET Core中解决方案

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

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

基于Kubernetes和Kong的解决方案

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

我们采用的是在URL中追加版本号来实现的版本控制,这样做有两个好处:
  1. 方便Kong进行路由解析,可以直接通过配置方式实现,如果通过header来路由的话,需要自己进行扩展才行。
  2. 从日志记录的时候可以很直观到看到当前的API版本,在发生问题时候可以快速定位的具体版本的服务。


下面是我画的一个我们的基于Kubernetes的大致的架构图,像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方式部署到Kubernetes集群中,路由服务指向Kubernetes内部服务的DNS集群地址。Kong的多个实例他们之间共享配置信息,可以把配置存储到PostgreSQL或者Cassandra中。
  4. 后端微服务集群内部提供集群地址配置到Kong的Service中。


业务需求的配合

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

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

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

DevOps 的配合

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

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

数据中间件服务的配合

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

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

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

总结

本篇文章主要讲述了如何利用Kong网关和Kubernetes服务来处理Web API多版本的问题。

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

原文链接: https://www.cnblogs.com/savorb ... .html

相关 [kong kubernetes web] 推荐:

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

- - DockOne.io
今天分享一个我们正在使用的一个基于Kubernetes以及Kong网关的Web API多版本管理的解决方案,这种方案已经在我们的生产环境运行了将近两年,也迭代了很多个版本,我们觉得这个方案非常的适合用在微服务当中. 什么是Web API多版本. 版本的概念大家应该都知道,那么什么是Web API的版本呢.

Kong 微服务网关在 Kubernetes 的实践

- - DockOne.io
译者:qianghaohao. 本文主要介绍将 Kong 微服务网关作为 Kubernetes 集群统一入口的最佳实践,之前写过一篇文章使用 Nginx Ingress Controller 作为集群统一的流量入口:使用 Kubernetes Ingress 对外暴露服务,但是相比于 Kong Ingress Controller来说,Kong 支持的功能更加强大,更适合微服务架构:.

API 网关 Kong

- - IT瘾-tuicool
所谓网关,主要作用就是连接两个不同网络的设备,而今天所讲的 API 网关是指承接和分发客户端所有请求的网关层. 最初是单体服务时,客户端发起的所有请求都可以直接请求到该服务,但随着产品用户越来越多,单体应用存在显而易见的单点问题,除此之外,当单体应用大小升至几个 G 时,持续发布将会非常缓慢,所以服务的拆分成为了必然趋势.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享,整理成文章发布出来. 谈微服务之前,先澄清一下概念. 微服务这个词的准确定义很难,不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』,坚持微服务一定是无状态的 http API 服务,其他的都是『邪魔歪道』,它和 SOA,RPC,分布式系统之间有明显的分界.

基于kong的微服务解决方案 | kong

- -
最近处理了几个客户的需求,需求有相似之处,解决方案迭代几次以后也具备了一定的复制性. 目前应用用springboot写的,以业务分块,大概形成了几十个(30+)部署单元;每个部署单元都是独立的jar,其中每个包含十个左右的endpoints. 目前用了eureka和zuul做服务注册/发现以及负载均衡;在整体部署规模超过200个jvm之后,出现了一些问题.

花椒直播 Kong 应用实践

- - DockOne.io
Kong 是面向现代架构(混合云,混合组织)的下一代 API 网关平台,具有云原生、高性能,易用、可扩展等特性. 适用于 API Gateway,Kubernetes Ingress,Service Mesh Sidecar 等场景. 云原生:与平台无关,Kong 可以从裸机运行到 Kubernetes.

Kubernetes 完全教程

- - 午夜咖啡
经过一个阶段的准备,视频版本的 《Kubernetes 完全教程》出炉了. 课程一共分为七节,另外有一节 Docker 预备课,每节课大约一个多小时. 目标是让从没接触过 Kubernetes 的同学也能通过这个课程掌握 Kubernetes. 为什么要学习 Kubernetes. 在介绍课程之前,先说说为什么要学习 Kubernetes 以及什么人需要学习 Kubernetes.

Kubernetes 监控详解

- - DockOne.io
【编者的话】监控 Kubernetes 并不是件容易的事. 本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes. 如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用. 就目前而言,监控 Kubernetes 并不是件容易的事.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

Kubernetes 日志收集方案

- - IT瘾-dev
Kubernetes 中的基本日志. Kubernetes 日志收集. 以 sidecar 容器收集日志. 用 sidecar 容器重新输出日志. 使用 sidecar 运行日志采集 agent. 前面的课程中和大家一起学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集.