微服务网关运维（微服务网关的主要功能）

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

本文目录一览：

• 1、微服务网关层
• 2、什么是微服务架构？主流的微服务如何实现？
• 3、Spring Cloud——微服务网关介绍
• 4、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署
• 5、微服务方式实现双重网关
• 6、开源推荐-C++开发的微服务框架Tars

微服务网关层

API网关是所有客户端微服务网关运维的统一入口。路由服务可以被用于很多目的微服务网关运维，例如日志、限流、认证，从而做到应用无感知。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务；还有一些请求需要拆分到多个服务。API Gateway是实现微服务重要的组件之一，常用的网关Zuul, Nginx, Spring Cloud, Linkerd，Envoy，UnderTow。

为微服务网关运维了评估API网关各自的性能，微服务网关运维我们使用Apache的ab作为压测工具。（另外还可以用Gatling做性能测试）

测试结果和心得如下：

什么是微服务架构？主流的微服务如何实现？

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- HTTP、gRPC 和 TCP 网络流量自动负载均衡；
- 提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；
- 流量加密、服务件认证，以及强身份声明；
- 全范围（Fleet-wide）的策略执行；
- 深度遥测和报告。

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

【知识总结】4.微服务的治理去中心化，服务发现，安全，部署

通常“治理”的意思是构建方案，并且迫使人们通过努力达到组织的目标。SOA治理指导开发者开发可重用的服务，以及随着时间推移，服务应该怎么被设计和开发。治理建立了服务提供者和消费者之间对于服务的协定，告诉消费者能从服务提供获取到什么样的支持。

SOA中有两种常见的治理：

那么微服务中的治理是什么意思呢？

在微服务架构中，不同的微服务之间相互独立，并且基于不同的平台和技术。因此，没有必要为服务的设计和开发定义一个通用的标准。

总结微服务的治理去中心化如下：

微服务架构下，有大量的微服务需要处理。由于微服务的快速和敏捷研发，他们的位置可能会动态变化。因此在运行时需要能够发现服务所在的位置，服务发现可以解决这个问题。

注册中心有微服务的实例和位置信息，微服务在启动时向注册中心注册自己的信息，关闭时注销。其它使用者能够通过注册中心找到可用的微服务和相关信息。

为了能找到可用的服务和他们的位置信息，需要服务发现机制。有两种发现机制，客户端发现和服务端发现。

客户端发现 - 客户端或者API网关通过查询服务注册中心或者服务的位置信息。

客户端/API网关必须调用服务注册中心组件，实现服务发现的逻辑。

服务端发现 - 客户端/API网关把请求发送到已知位置信息的组件（比如负载均衡器）。组件去访问注册中心，找到微服务的位置信息。

类似Kubernetes（ http://kubernetes.io/v1.1/docs/user-guide/services.html ）这种微服务部署解决方案，就提供了服务器端的自动发现机制。

微服务的部署方式也特别重要，以下是关键：

Docker（一个运行在linux上并且开源的应用，能够协助开发和运维把应用运行在容器中）能够快速部署微服务，包括关键几点：

相对于传统的虚拟机模式，利用docker容器，构建、发布、启动微服务将会变得十分快捷。

通过Kubernetes能够进一步扩展Docker的能力，能够从单个linux主机扩展到linux集群，支持多主机，管理容器位置，服务发现，多实例。都是微服务需求的重要特性。因此，利用Kubernetes管理微服务和容器的发布，是一个非常有力的方案。

图11，展示了零售应用的微服务部署。每个服务都在独立的容器中，每个主机有两个容器，通过kubernetes可以随意调整容器的数量。

在实际运行环境中，微服务的安全也非常重要。我们先看下单体架构下安全是如何实现的。

一个典型的单体应用，安全问题主要是“谁调用”，“调用者能做什么”，“如何处理”。服务器接收到请求后，一般都在处理链条的最开始，通过安全组件来对请求的信息进行安全处理。

我们能直接把这种处理方式应用在微服务架构中吗？答案是可以的，需要每个微服务都实现一个安全组件从资源中心获取对应的用户信息，实现安全控制。这是比较初级的处理方式。可以尝试采用一些标准的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下这两种安全协议以及如何使用。

OAuth2-是一个访问委托协议。需要获得权限的客户端，向授权服务申请一个访问令牌。访问令牌没有任何关于用户/客户端的信息，仅仅是一个给授权服务器使用的用户引用信息。因此，这个“引用的令牌”也没有安全问题。

OpenID类似于OAuth，不过除了访问令牌以外，授权服务器还会颁发一个ID令牌，包含用户信息。通常由授权服务器以JWT（JSON Web Token）的方式实现。通过这种方式确保客户和服务器端的互信。JWT令牌是一种“有内容的令牌”，包含用户的身份信息，在公共环境中使用不安全。

现在我们看下如何在网络零售网站中应用这些协议保障微服务的安全。

图12中所示，是实现微服务安全的关键几步：

JWT包含必要的用户信息，如果每个微服务都能够解析JWT，那么你的系统中每个服务都能处理身份相关的业务。在每个微服务中，可以有一个处理JWT的轻量级的组件。

在微服务中怎么支持事务呢？事实上，跨多个微服务的分布式事务支持非常复杂，微服务的设计思路是尽量避免多个服务之间的事务操作。

解决办法是微服务的设计需要遵循功能自包含和单职责原则。跨越多个微服务支持分布式事务在微服务架构中不是一个好的设计思路，通常需要重新划定微服务的职责。某些场景下，必须要跨越服务支持分布式事务，可以在每个微服务内部利用“组合操作”。

最关键的事情是，基于单职责原则设计微服务，如果某个服务不能正常执行某些操作，那么这个服务是有问题的。那么上游的操作，都需要在各自的微服务中执行回滚操作。

微服务架构相比较单体的设计而言，引入了更多服务，在每个服务级别会增加发生错误的可能性。一个服务可能由于网络问题、底层资源等各种问题导致失败。某个服务的不可能不应该影响整个应用的崩溃。因此，微服务系统必须容错，甚至自动回复，对客户端无感知。

任何服务在任何时间都有可能出问题，监控系统需要能够发现问题，并且自动恢复。微服务环境下有不少常用的模式。

微服务中请求的失败率达到一定程度后，系统中的监控可以激活线路中断。当正常请求的数量恢复到一定程度后，再关闭线路中断的开关，使系统回复到正常状态。

这个模式可以避免不必要的资源消耗，请求的处理延迟会导致超时，借此可以把监控系统做的更完善。

一个应用会有很多微服务租车，单个微服务的失败不应该影响整个系统。防火墙模式强调服务直接的隔离性，微服务不会受到其它微服务失败的影响。

超时机制是在确定不会再有应答的情况下，主动放弃等待微服务的响应。这种超时应该是可配置的。

哪些情况下，如何使用这些模式呢？大多数情况，都应该在网关处理。当微服务不可用或者没有回复时，网关能够决定是否执行线路中断或者启动超时机制。防火墙机制同样重要，网关是所有请求的唯一入口，一个微服务的失败不应该影响到其它微服务。网关也是获得微服务状态、监控信息的中心。

我们已经讨论了微服务的架构和各种特性，以及如何应用在一个现代的IT系统中。同时也需要意识到，微服务不是解决所有问题的灵丹妙药。盲目追求流行的技术概念并不能解决掉企业IT系统的问题。

微服务有很多优势，但是仅靠微服务不能解决企业IT中的所有问题。例如，微服务需要去除ESB，但是现实的IT系统中，大量的应用和服务是基于ESB而不是微服务。集成现有的系统，需要一些集成总线。实际情况是，微服务和其它企业架构并存。

微服务方式实现双重网关

最近在做一个多项目整合的工作，因为每个项目都有自己的一套网关，每个网关都有自己的加解密算法，整合到一起要求对外提供统一的用户鉴权，而且不对原有系统做大规模的重构，基于这些现实考虑使用两重API网关架构来构建新系统的统一网关体系。

备注：其中的统一网关、业务网关、业务微服务都是微服务的模式注册到微服务中心。

这个网关采用zuul来进行网关过滤及路由，其中过滤规则由各个业务网关以微服务方式提供，通过Feign来调用，这个方式也是区别于传统网关的，也是实现双重网关的关键所在。
这里要遵循的基本原则是：授权/鉴权一体化，即授权策略和鉴权方法都是由各个业务网关自己维护，这样就确保了功能的封闭性和一致性，在开发和后期维护中都非常的方便高效。

备注：这个类是zuul的主类实现了过滤/路由，其中的鉴权部分调用了相关的微服务，这些微服务以@Autowired的方式注入进来。
接口定义如下：

路由策略通过配置实现，因为是微服务所以直接指定路由到的微服务id即可，配置文件可以存储到微服务治理中心的配置中心。

备注：其中的user-base、user-org分别是两个业务微服务。

这个网关集群按照业务划分，每个网关实现了授权和鉴权的策略算法，并以微服务的方式提供，其中授权是对相关敏感信息做加密并以token的方式存储到cookie中，鉴权是将存储在客户端的token通过相应的解密算法进行核验和鉴权，确保该token的合法性、有效性，只有有效的token才能够通过鉴权并解析出敏感信息传递到指定的路由服务中。

备注：该网关使用JWT进行敏感数据加密

备注：该网关使用RSA进行敏感数据加密
H5业务网关以微服务方式提供了授权/鉴权服务，其中授权服务直接暴露给客户端，客户端调用后将业务类型app_type和授权token写入cookie，鉴权服务暴露给统一网关，对传递的token进行鉴权，鉴权成功后将token中的加密信息解析出来后返回给统一网关，由统一网关路由到业务微服务并将该参数传递下去。

备注：其中register、login是生成授权token流程，readUserinfo是通过token鉴权后访问业务微服务的流程。

开源推荐-C++开发的微服务框架Tars

Tars致力于建设微服务技术生态，在底层基础设施、服务框架、上层应用以及DevOps等方面，都做了较为深入的研发。

2020年3月10日，Linux基金会正式宣布旗下的TARS开源项目成立TARS子基金会。这是一个 专注于微服务领域 的开源基金会，致力于帮助企业拥抱微服务体系架构，解决在使用微服务方面可能出现的问题。这是首个 起源于中国开源项目 的国际开源基金会，也是Linux基金会下 唯一聚焦微服务技术生态 的子基金会。

Tars基金会里目前收录了9个项目，分为5部分微服务网关运维：工具集（Tars Lab）、服务治理（Service Governance）、微服务开发框架（Development Framwork）、存储（DCache）和基础设施（Infrustructure）。

1、Tars Lab

Tars Lab项目提供了压力测试TarsJMeter，基准测试集TarsBenchmark和一些开发工具包。TarsJavaStart，可以生成服务端和客户端的TarsJava脚手架，快速开始Tars服务的开发。TarsTools，是一款支持多种IDE的JetBrains插件，为实现编辑Jce/Tars文件使用的（支持Intellij IDEA、Android Studio、PhpStorm、WebStorm、GoLand、CLion等）。

2、服务治理

服务治理包含了2个项目：TSeer专注于处理服务注册与发现；TarsGateway是基于Tars框架开发的微服务网关，除具备网关的基础功能外，还可以自动将HTTP转换成Tars-RPC协议。

3、微服务开发框架

这部分只包含Tars一个项目，核心模块由C++开发，提供了多语言开发框架，默认rpc调用，是Tars基金会的核心项目。其他项目都是围绕这个项目研发的。

4、微服务存储

这部分只包含DCache一个项目，它是基于Tars框架开发的 分布式共享内存存储系统 ，支持常用的kv数据结构、支持二级索引、支持在线扩缩容、支持自动持久化到后端db等特性。DCache依赖Tars框架的运行，但也得益于Tars，使得存储服务的运维成本几乎为0。

5、微服务基础设施

这是一个将Tars与K8S融合使用的项目，致力于将Tars融入到K8S生态中。

在这方面还有一个更优秀的项目K8SFramework，致力于将Tars与K8S深度融合，相信未来会纳入到基金会中。

| Tars的前世今生

Tars的前身是腾讯内部的TAF框架，已经经过了10年的验证，稳定运行与1.6w+服务器，100多个业务线中。

据统计， Tars已在超过 120 家公司、 261200 台服务器上稳定运行。

在分布式环境下，所有的微服务（包括DCache的服务）都可以通过框架自带的控制台-TarsWeb进行管理， 可以做到所有服务状态可监控，可以在控制台上进行启停、修改配置、执行运维指令等操作。

在分布式部署的情况下，可以通过Web控制台实现一键升级、回退。

Tars自带配置中心，分级配置，可以统一修改配置，做到“一点修改，全局生效”。

在服务部署时，可以在界面上填写要发布的节点，一键部署、扩容。

框架提供了状态监控的能力，可以监控服务的调用质量，如流量情况，平均耗时、超时率和异常率。

框架状态可以在控制台上一键核查。

Tars提供配套的性能测试工具，这也是Tars基金会的子项目。性能测试工作不再依赖专业的测试人员。

| Tars优势

1、原生RPC调用

Tars使用自研的RPC协议通信，服务之间建立长连接，在通信频繁的场景下具备显著的性能优势。

2、多语言支持

除C++和Java外，Tars还支持NodeJs，PHP，Go等语言，提供了相应的SDK。当团队技术栈多样化时，可以多语言协同开发，无缝对接，开发者可以选择自己熟悉的语言进行开发，提升团队整体效率。

在这方面，Spring Cloud想要支持异构语言，需要借助SideCar构建Service Mesh。 业界现在有一些比较流行的服务网格解决方案，但是 并没有形成统一的标准 ， 可移植性不高 。比较常见的像Istio，由于是代理模式，而且非长连接，会存在 更大的延迟 。另一方面，Istio的部署和运维都非常 复杂 ，需要更多的学习成本和运维成本。

3、内置服务治理功能

Tars框架内嵌了丰富的服务治理功能，包括熔断、限流、负载均衡、认证、加密等。同时，在服务监控、数据采集，以及灰度部署、跨机房部署等方面，都原生支持，集成度高。

Spring Cloud要支持这些功能，要么需要集成其他组件，要么需要设计开发来实现。都需要付出额外的学习成本和研发成本。

4、运维监控

Tars为使用者提供了一体化的运维管理控制台，我们可以在Web上进行一键部署、扩容、升级、回退等运维操作。

Spring Cloud并没有配套的工具。要实现Web管控， 需要借助K8S和容器，同样需要付出额外的成本。

5、国产化

Tars是国内公司主导的开源项目，这一点就不多说什么了。

6、“套装”优势

Tars框架提供了微服务相关的一体化解决方案，常规情况下不需要再去集成其他组件，不存在兼容性问题。这就好比MacBook和兼容机的区别，兼容机微服务网关运维你可能需要付出更多的试错成本才能达到想要的效果。

| 劣势

1、项目热度

Tars开源较晚，到目前只有5年多时间，项目热度不如Spring Cloud，应用也没Spring Cloud广泛。

2、Tars的云原生之路

Tars和K8s的深度融合也开源不久（2020年7月，K8SFramework），还有待落地验证。这个项目现在的更新频率较高，不建议在生产中使用。但是从这一点也可以看到社区工作者对Tars与K8S融合的高涨热情，相信未来这个项目一定会大放异彩！

Tars在微服务开发、运维、监控等方面提供了一体化的解决方案，可以帮助我们低成本构建企业级微服务。适用于各种规模的团队，各种规模的系统。

在做技术选型时，如果团队中有C++开发人员，或者有多语言开发的情况，而且团队规模、资源有限的情况下，建议选择Tars。它在运维、监控、测试等方面会为我们节约大量成本。

未来，随着 K8SFramework 项目的日渐成熟，相信Tars生态会被更多的团队熟知和使用。

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

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