做360手机网站优,普通电脑怎么建设网站,邢台路桥建设总公司网站,wordpress 上下篇 插件前言大家好#xff0c;很久没有写博客了#xff0c;最近半年也是比较的忙#xff0c;所以给关注我的粉丝们道个歉。去年和朱永光大哥聊的时候提了一下我们的这个方案#xff0c;他说让我有空写篇博客讲一下#xff0c;之前是非常的忙#xff0c;所以这次趁着有些时间就写… 前言大家好很久没有写博客了最近半年也是比较的忙所以给关注我的粉丝们道个歉。去年和朱永光大哥聊的时候提了一下我们的这个方案他说让我有空写篇博客讲一下之前是非常的忙所以这次趁着有些时间就写一下我们这边关于版本控制的方案吧。那么今天给大家分享一个我们正在使用的一个基于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 这些我就给省掉了。主要流程分为以下几个步骤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 等索引数据结构的变化。那么如何处理以上数据服务的版本兼容问题呢最简单的方案是起一套新的环境新版本完全使用一套新的中间件服务环境来进行运行但是这样有一个缺点就是会使用更多的服务器资源照成服务器资源浪费的情况当然如果是土豪公司可以无视了。那如果想不同的版本使用相同的数据中间件服务怎么办呢其实办法也是有的大部分数据中间件都是支持版本划分的比如 ElasticsearchCAP 等都支持使用版本来区分数据对于不支持的可以在程序中进行控制了比如像 Redis 这种就可以使用不同的逻辑DB来区分。总结本篇文章主要讲述了如果利用 kong 网关和 k8s 服务来处理 webapi 多版本的问题。同时还讲述了在开发的过程中一些不同版本的数据应该如何处理以及需求的规划等希望以上的东西能够帮助到有需要的人。如果你觉得本篇文章对您有帮助的话感谢您的【推荐】。如果你对 .NET Core 有兴趣的话可以关注我我会定期的在博客分享我的学习心得。原文地址http://www.cnblogs.com/savorboard/p/webapi-versions.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
