云原生微服务网关（云原生 微服务）

本篇文章给大家谈谈云原生微服务网关，以及云原生 微服务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享云原生微服务网关的知识，其中也会对云原生 微服务进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Apache APISIX 2.12.0 发布，云原生的微服务 API 网关
• 2、国产开源API网关项目APISIX进入Apache孵化器
• 3、云原生相关知识？
• 4、云原生有哪些优势？
• 5、Spring Cloud——微服务网关介绍
• 6、深入理解Kubernetes的认证与授权机制

Apache APISIX 2.12.0 发布，云原生的微服务 API 网关

继 2.11.0 版本发布之后，Apache APISIX 也在即将到来的新春佳节，为大家带来 2022 年 第一个带有新功能的版本 。

新功能

更多的 Serverless 集成

在上个版本里，Apache APISIX 增加了对 Azure Function 的支持。而这次新版本在功能上又加入了对更多 Serverless 厂商的支持。如今用户也可以在 Apache APISIX 中结合 AWS Lambda 和 Apache OpenWhisk，在网关上进行特定函数的暴露。

更多的鉴权插件

此次的新版本，还将带来两个众人翘首以盼的新插件： forward-auth 和 opa 。

通过上述两个插件，将为 Apache APISIX 的鉴权功能锦上添花，给用户带来更多丰富和上手简单的鉴权操作。

更多的日志功能

除了上边提到的鉴权插件，本次新版本还将带来三个新的日志插件： google-cloud-logging 、 splunk-hec-logging 以及 rocketmq-logger 。

从插件名称上也很容易理解，通过上述三个插件可以把日志分别发送到 Google Cloud、Splunk 和 Apache RocketMQ。未来，Apache APISIX 将会对接越来越多的日志服务商和开源 Broker，让日志处理变得更加轻松。

同时，此次 2.12.0 版本还在日志层面支持记录响应体。与 Apache APISIX 其他功能一样，该功能也可以通过表达式进行动态开启。这样在使用中，就可以实现仅在上游返回特定的 Content-Type 和 Content-Length 时进行日志记录，不用再去顾虑全量采集响应体而带来的问题了。

具体示例可参考下方：

上述配置会仅在 Content-Length < 4096 且 Content-Type 为 "application/json" 才记录日志。

另一个跟日志紧密相关的功能，就是新版本的 Apache APISIX 已支持注册自定义变量。同时结合 APISIX 的自定义日志格式，就可以实现完全自定义上报的日志内容。即无需修改具体的日志插件，就能实现日志生成和上报的解耦合。这里我们通过一个示例进行简单演示一下。

比如我们可以在自己的插件中注册一个 a6_route_labels 的变量：

并在自定义日志格式中使用它：

假设我们的 Route 长这样：

最终就会收到如下所示的日志：

L4 代理支持 TLS over TCP 上游

在 2.12.0 版本中还引入了新的 Upstream Scheme，现在 Apache APISIX 已支持代理到 TLS over TCP 上游了。

具体做法可参考下方，只需在 Upstream 配置中指明 Scheme 为 TLS 即可。

至此 Apache APISIX 的 TCP 代理功能得到了 TLS 全方位的支持。此外，我们还支持在静态文件中配置 L4 代理的 Access Log：

更新

多语言插件持续完善

在之前版本中，Apache APISIX 已开放了对 WASM 生态的支持。而在 2.12.0 版本中，针对 WASM 生态又做了不少的更新细节。

目前 Apache APISIX 已经支持在 header_filter 的阶段运行 WASM 代码，弥补了现有外部插件无法修改响应的不足。

此外，我们还支持在 WASM 里面通过 Apache APISIX 这个宿主进行 HTTP 通讯。借助这一功能，我们用 WASM 也重新实现了 forward-auth 插件。该插件的功能几乎和 Lua 版本一模一样，甚至连测试用例也是在 Lua 版本上改了下名字就能通过了。

当然，我们也没有忘记针对现有的外部插件进行更新，本次 2.12.0 版本中，Apache APISIX 已允许外部插件获取请求体。

比如最近发布的 Java Plugin Runner 第二版就包含了这一功能。新版本的 Java Plugin Runner 还支持在运行时动态获取 APISIX 变量。

完善

更多细节

除了上述新功能和组件外，Apache APISIX 2.12.0 版本还更新了如下功能：

更多关于 Apache APISIX 2.12.0 的更新细节，可以查看本次发布对应的 Change log 。

下载

想要获取最新的 Apache APISIX 2.12.0 版本，可通过以下路径下载：

源代码： https://apisix.apache.org/downloads/

二进制安装包： https://apisix.apache.org/zh/docs/apisix/how-to-build/

国产开源API网关项目APISIX进入Apache孵化器

近几年，国内的开源热情越来越高涨，不论个人还是企业，都开始拥抱开源。从过去的使用开源，到参与开源，贡献开源，一步步的在国际开源组织中展露头角。之前，国庆期间，我们一起盘点了一些进入国际视野的顶级国产开源项目： 开源大阅兵：盘点那些走向世界的中国项目 。其中，有很加入的开源组织就是Apache基金会。

近日，又有一个开源项目加入了这个Java开源界大名鼎鼎的Apache基金会，开始进行孵化器。

项目名称 ：APISIX

项目地址 ：https://github.com/apache/incubator-apisix/

官方网站 ：https://www.iresty.com/

项目简介 ：APISIX 是一个云原生、高性能、可扩展的微服务 API 网关。它是基于 OpenResty 和 etcd 来实现，和传统 API 网关相比，APISIX 具备动态路由和插件热加载，特别适合微服务体系下的 API 管理。

为什么选择 APISIX？

如果你正在构建网站、移动设备或 IoT（物联网）的应用，那么你可能需要使用 API 网关来处理接口流量。

APISIX 是基于云原生的微服务 API 网关，可以处理传统的南北向流量，也可以处理服务间的东西向流量。

APISIX 通过插件机制，提供动态负载平衡、身份验证、限流限速等功能，并且支持你自己开发的插件。

功能

更多关于APISIX的功能与使用介绍，可通过下方文档链接查看详细：

https://github.com/apache/incubator-apisix/blob/master/doc/README_CN.md

云原生相关知识？

云原生技术使企业/组织能够在公共、私有和混合云等现代动态环境中云原生微服务网关，构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明式 API 就是这种方法的例证。

这些技术支持具有弹性、可管理和可观察的松散耦合系统。结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。

云原生包含哪些技术云原生微服务网关？

云原生技术以微服务、DevOps、容器、多云业务管理为代表，目前已经成为云原生微服务网关了加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。

微服务实现云原生微服务网关了软件的模块化、组件化、共享化，实现了开发团队的独立化、小型化和协同化，为数 字化应用研发创新更敏捷、更高效打下了坚实的基础。

DevOps 实现了软件研运过程标准统一，强化应用研发运营全周期的管理、打破部门壁垒，从应用 需求到生产运维的全流程改进和优化，结合统一工具链，实现文化、流程、工具的一致性，提升数 字化应用创新整体协同效率，提升软件交付效率。

容器技术实现了应用与资源的解耦和应用交付件的标准化，有效解决了异构环境的部署一致性问 题，促进了资源的标准化，为面向应用的服务化、自动化提供了基础。标准容器化的打包方式实现 了真正的应用可移植性，不再受限于特定的基础架构环境。

多云业务管理实现在私有云模式、混合云模式、多云模式下应用的部署、跨云迁移、应用运维和治 理，满足企业多样化 IT 资源需求，同时避免企业被云服务商绑定，实现自主可控。多云业务管理 同时可实现云端+边缘设备的应用一体化交付和管理。

云原生景观图

云原生景观图

截图只是部分，百度搜索会有完整景观图。

云原生有哪些优势？

第一，极致弹性能力，以容器化方式运行的应用程序，其启动和停止非常快，一般处在秒级或毫秒级。
第二，故障自愈、服务自治能力，采用容器编排框架，可以管理成千上万的应用容器，当某个应用出现故障时，编排系统能够及时发现并自动摘除问题应用，同时智能调度到有效资源上，保证了应用系统的稳定运行。
第三，大规模跨环境扩展能力，基于容器编排系统的PaaS平台，可以跨越部署到不同的环境中，包括不同的网络环境，不同的机房，不同的数据中心或不同的公有云，利用联邦集群的模式，可以让应用在跨云的环境中流转，可以让不同的云环境作为资源补充，或者创建相同的应用到不同的数据中心，以此作为容灾备份。
基于云原生以上的几个特点，在容器云PaaS、DevOps、微服务治理、服务网格、API网关等等方面，时速云做的还不错，他们是一家全栈云原生技术服务提供商，你可以了解一下。

Spring Cloud——微服务网关介绍

为云原生微服务网关了解决以上的问题云原生微服务网关，API网关应运而生，加入网关后应用架构变为下图所示。

当引入API网关后，在用户端与微服务之间建立了一道屏障，通过API网关对微服务提供了统一的访问入口，所有用户端的请求被API网关拦截，并在此基础上可以实现额外的功能云原生微服务网关：

OpenResty是一个强大的Web应用服务器，web开发人员可以使用Lua脚本语言调用Nginx支持的各种以C以及Lua模块。

在性能方面，OpenResty可以快速构造出足以胜任10K以上并发连接响应的超高性能Web应用系统。

在国内，360、阿里云、腾讯网、去哪儿、酷狗音乐、新浪等都是OpenResty的深度用户。

但OpenResty是一款独立的产品，与主流的注册中心，存在一定的兼容问题，需要架构师独立实现其服务注册、发现功能。

Zuul是Netflix开源的微服务网关，主要职责是对用户请求进行路由转发与过滤。早期Spring Cloud与Netflix合作，使用Zuul作为微服务架构网关首选产品。

Zuul是基于J2EE Servlet实现路由转发，网络通信采用同步方式。

zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

Zuul的核心是一系列的filters，其作用可以类比Servlet框架的Filter，或者AOP。工作原理如下图所示：

Zuul可以对Groovy过滤器进行动态的加载，编译，运行。

Zuul2.x设计更为先进，基于Netty 非阻塞和支持长连接， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。

Zuul2.x引入了Netty和RxJava，正如之前的 ZuulFilter 分为了 Pre、Post、Route、Error，Zuul2的Filter分为三种类型：

Spring 自己开发的新一代API网关产品，基于NIO异步处理，摒弃了Zuul基于Servlet同步通信的设计。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

关键特征：

在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍。

Spring Cloud Gateway十分优秀，Spring Cloud Alibaba也默认选用该组件作为网关产品。

客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

Spring Cloud Gateway 的特征：

参考：
http://www.ityouknow.com/springcloud/2018/12/12/spring-cloud-gateway-start.html

http://www.likecs.com/show-50293.html

https://zhuanlan.zhihu.com/p/299608850?utm_source=wechat_session

https://juejin.cn/post/6844903965352525838

https://blog.csdn.net/weixin_38361347/article/details/114108368

http://www.zyiz.net/tech/detail-98256.html

深入理解Kubernetes的认证与授权机制

众所周知，任意一个系统的安全机制的核心都是基于 认证与授权 （Authentication and Authorization）,即首先通过某种方式确认“你”的身份，再根据一定的授权策略确定“你”在我的系统里面能做什么操作。对于K8S来说，就是体现为客户端对于 kube-apiserver 的api接口操作的鉴权（客户端可以是集群内的工作负载pod，任意服务器上的kubectl程序，或是计算节点上的kubelet组件等等）。Kubernets项目作为一个成熟的开源云计算基础设施项目，让我们来看看他们是如何解决认证与授权这两个核心问题的：

k8s的用户认证机制的官方文档地址： https://kubernetes.io/docs/reference/access-authn-authz/authentication/ 。

Kubernetes中的用户类型分为 service accounts 和 normal users 两类。service accounts是k8s内部自建的一套用户认证体系，主要用于pod里直接调用kube-apiserver过程中的认证。而普通用户类型依赖于外部认证服务，k8本身不关心。

当创建service account对象时，会对应的创建一个secret对象，内含了这个用户的认证token，当pod启动时，只要yaml里申明了绑定特定的service account账号，那么系统会自动把secret的token注入到pod中的指定目录，接下来当pod调用apiserver接口时，系统都会自动的附加上这个token，这样apiserver就可以识别出这个pod的身份，结合role和rolebinding的配置信息，就可以正确的授权了。service account是基于k8内部的认证体系，使用起来比较方便，直接在集群内创建sa资源即可。此种类型的用户不是本篇文章讨论的重点，想了解具体的操作可以参考我之前的这篇文章： 构建云原生微服务网关系列-篇二：Zuul ，里面有详细的service account的使用说明。

本文讨论的重点，针对普通用户类型，很多人的理解会比较模糊，对此官网有一段说明：

也就是说，k8项目认为普通用户认证应该由外部服务供应商解决，k8本身不关心认证过程，只要告诉他最终的认证结果，即这个用户是“谁”。认证方式可以用公私钥对，或者openstack 的 keystone认证服务、google的Google Accounts服务，甚至是一个有着用户名和密码列表的文件，对于k8s来说，都是一样的。不管用何种方式去认证，最终结果都是告诉k8s，这个用户是“谁”，也就是它的用户id。这里需要注意的时，对于普通用户类型，k8是不会存储用户信息的，而对于service account类型的用户，k8会保存在etcd里面。普通用户也无法通过api调用直接创建。

Kubernetes 支持使用客户端证书、bearer token、认证代理或者http basic auth等方式进行认证，而无论使用哪种方式，认证插件都需要将以下的用户信息和http请求进行关联：

api-server目前支持的认证方式有：

使用由 k8s 根 CA 签发的证书，提取cn字段作为用户id，O字段作为用户组。我们可以使用openssl工具来进行证书的签发（kubernetes 1.4之后支持了证书中携带用户组信息）：

上述操作会生成一个证书请求，username为 jbeda ，并同时属于两个用户组 app1 和 app2 。

静态token列表文件，需要预先在 API Server 服务器上放置该文件，并且在api server的启动参数中加上 --token-auth-file=SOMEFILE ,token文件为csv格式，应至少包含token, user name, user uid这三个字段(逗号分隔)以及一个可选的group names字段，例如：

注意如果用户组有多个的话，整个用户组需要用双引号括起来。

1.18版本进入稳定版的新特性，支持可以在集群启动时动态的创建和管理token，配置比较多，这里不多赘述，有兴趣直接参考官方文档

跟静态 Token 文件类似，只是使用了用户名密码的形式进行认证，使用的是http basic auth类型的认证方式，启动参数为 --basic-auth-file=SOMEFILE ，文件格式为：

很好理解，不多说了

之前介绍过了，k8s内部用户体系 Service Account 使用的 Token，认证方式也是bearer token。这里需要注意的是官方文档有一个描述：

因为api-server本身并不关注流量是从哪里过来的，所以基于service account创建的token，只要你拿到了这个token，是可以从 集群外部 发起请求的，api-server会将此请求认证为对应的service account用户。拿到token的方式官网也做了说明：

注意和serviceaccount绑定的secret类型为 kubernetes.io/service-account-token ，其中token字段即为我们需要的令牌（jwt格式），拿着这个令牌就可以直接发起请求了。 注意在secret中保存的token是经过base64编码的，实际使用时还需要先进行base64解码操作，可以使用jwt.io网站来查看这个令牌，以下是k8s签发的一个jwt令牌payload部分字段的示例：

新出来的一种认证方式，基于Oauth2，比较复杂，有兴趣可以参考官方文档，这里不介绍了。对于Oauth2认证以及JWT技术比较感兴趣的，可以参考我之前的博文 深入理解Spring Cloud Security OAuth2及JWT 。（阅读量4万多了，也算爆款了:）

搞定了认证，接下来就是授权了。得益于k8s优良的设计，认证和授权是解耦的，所以只要k8系统识别出了用户身份（username或者uid），接下来要做的事情就是一样的了。关于授权部分的官方文档地址： https://kubernetes.io/docs/reference/access-authn-authz/rbac/

事实上k8s本身也支持多种授权类型，比如rbac，abac，node，dynamic admission 等等。这里只介绍下最常用的rbac（基于角色的访问控制），实际使用中，api-server开启 --authorization-mode=RBAC 参数，即启动了rbac功能。

如果你对于rbac本身已经比较了解，那么其实k8s里面的rbac功能就非常容易理解了。涉及rbac的有两个api对象，role定义了一个角色，申明了此角色可以操作的功能列表，rolebinding其实就是把用户和角色做了一个绑定。

role的api对象示例：

这个yaml定义了一个Role对象，名称为 pod-reader ， 作用域为 default 这个namespace，可以对 pods 这个对象进行 get 、 watch 、 list 操作。
kubernetes完整的操作类型列表如下，都很好理解，不一一说明了：

值得注意的是，有些资源还有子类型，比如pod的logs，如果需要查看，也是需要授权的(添加 pods/log 资源类型)

RoleBinding资源的作用也非常容易理解， 就是绑定Role和用户。下面是一个RoleBinding的示例：

这个例子里把一个类型为User，name叫做jane的用户，和pod-reader的Role做了绑定。注意subjects里面的 kind 字段，即用户类型，前面介绍过了，分别是 User 、 Group 和 ServiceAccount 。绑定完成之后，当使用 jane 这个用户身份对k8s的api进行调用，就可以进行指定的 watch 、 get 、 list 操作了。

这两资源其实和Role、RoleBinding的配置方式是完全一样的，区别在于ClusterRole和ClusterRoleBinding的作用域是集群范围的，并且可以操作 node 这样的集群范围资源，而Role、RoleBinding在metadata中需要指定namespace字段，其他方面没有区别。

弄清原理之后，现在让我们来实际操作一下，目标是使用kubectl客户端工具对于给定的k8集群进行受限操作。基于上述的认证策略的介绍，我们使用 客户端证书 方式来进行用户认证，即使用K8集群的根证书来签发一个用户证书，使用该证书来进行用户认证及授权操作。

关于RSA证书的制作，可以参考官网文档： https://kubernetes.io/docs/concepts/cluster-administration/certificates/ ，这里我们使用常用的openssl工具来制作证书：

1、创建一个2048位长度的RSA格式私钥

2、创建证书签名请求(csr)，CN-对应Username O-对应用户组，上面的文章中已经介绍过

3、使用集群根证书签发这个证书请求(days是证书到期时间，可根据实际需要配置)

首先先找到一台准备作为客户端访问k8集群的linux服务器（或者windows、mac都可以），确保客户端与集群的api-server端口网络联通（一般为6443端口，注意必须是https连接），出于安全考虑，最好开一个操作k8的专用的操作系统账号。把集群master节点中的kubectl二进制文件拷贝至此服务器/usr/bin目录内，同时拷贝release.csr、release.key、ca.pem这三个文件至服务器上的指定目录。

在新建用户的home目录下创建.kube目录，在此目录下新建config文件（或者直接执行kubectl config set-cluster test操作，kubectl会自动创建该文件），编辑该文件填写如下内容：

完成之后可以执行 kubectl config view 来验证一下配置是否正确。

使用管理员登陆k8集群，进行权限配置，这里以添加集群范围的运维用户权限为例：

可以看到，我们定义了一个角色 release ，用于应用的部署及日常运维操作。为了满足日常运维，给其分配了一组受限的资源权限。

具体来说，该角色对"deployments","services","configmap","pvc"资源有全部的操作权限，对于"nodes","events","pods","pods/log","endpoints"只有查看权限，对于其他资源没有任何权限。

这里我们定义了一个ClusterRoleBinding，把User和ClusterRole进行了绑定，到这里全部操作就完成了。

登陆客户端，一切顺利的话，执行 kubectl get pods 就可以返回远程集群的default命名空间下的pods列表了，其他配置的权限应该也可以正常操作。而如果这个用户想访问受限资源，比如想查看secrets信息，则会出现如下的报错信息(403 Forbidden)：

验证成功！

基于上述的描述，可以知道，其实在集群里面创建一个service account，把它的token拷贝出来，配置在客户端的kubectl配置文件中，可以达到同样的效果，这里就不再演示了。

因为service account的token机密信息实际上都是存放于secret对象中，而secret经常被人吐槽的是存放的数据是明文（只是做了base64编码），所以这里多说一句secret的安全性问题。其实k8s是支持secret加密存放的，支持的加密类型还挺多，具体可以看我这篇文章： 使用加密插件加密secrets中的数据 。但其实我并不建议使用这种方式，原因是使用加密插件只能加密存放在etcd里面的数据，而使用api server调取出的数据仍然是解密过后的，这意味着你执行 kubectl get secrets 或者是进入容器的环境变量查看，仍然可以看到明文数据。k8s项目更推荐的权限管理方式是：

做好上面两点，对于一般公司的安全管控来讲已经足够，毕竟集群管理员的权限只是掌握在很小一部分人的手中。而对于安全审计要求更高的企业（比如金融机构），审计可能会有要求敏感数据必须加密存放，此时可使用api-server的加密插件。

关于云原生微服务网关和云原生 微服务的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 云原生微服务网关的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于云原生 微服务、云原生微服务网关的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。