微服务网关研究现状（微服务网关的主要功能）

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

本文目录一览：

• 1、记网关APISIX调研
• 2、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署
• 3、业务网关思考以及实践（一）

记网关APISIX调研

公司现状，生产上的服务器服务仅仅是使用nginx反向代理，随着公司发展，项目不断新增，需要频繁的修改生产服务器配置；证书过期需要开发人员配置（运营人员不熟悉生产环境不会配置，开发人员需要回公司找运营人员获取生产权限才能配置），更新麻烦；不具备限流、黑白名单配置等功能。更重要的是每更新配置nginx配置生效，都需要· nginx -s reload 重新加载配置影响用户使用。
为了进一步保障生产环境的 安全性 ，决定引入网关API

API网关 并非一个新兴的概念，在十几年前就已经存在了，它的作用主要是作为流量的入口，统一处理和业务相关的请求，让API更佳安全、快速和准确的得到处理，它有以下传统功能：

APISIX 是一个云原声，高性能，可扩展的微服务API网关，基于OpenResty和etcd实现。它进行动态路由和插件热加载，特别适合微服务体系下的API管理。

APISIX 是基于云原声的 微服务API网关 ，可以处理传统的南北向流量，也可以处理服务间的东西向流量。
APISIX通过插件机制，提供动态负载均衡，身份验证，限流限速等功能，并支持你自己开发的插件。
虽说 APISIX 是新出的产品，但它却功能强大具有蓬勃活力与生机。对比现有流行的网关，他具有强大的优势。而且市区活跃，对于用户的疑惑能够得到很快的回复解答，产品问题也及时完善修复。具体的大家可自己市区了解，我这里就仅做简单介绍。

网关APISIX 实战 分享敬请关注（ https://www.jianshu.com/p/4f52aaf44738 ）。

【知识总结】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而不是微服务。集成现有的系统，需要一些集成总线。实际情况是，微服务和其它企业架构并存。

业务网关思考以及实践（一）

相信现在在微服务思想盛行的互联网行业中，网关这个名词已经是家喻户晓了，很多一线互联网公司都有自研的网关，其主要还是分为两大类 流量网关和业务网关。

流量网关类似于 基于OpenResty的APISIX,基于K8S的 Envoy,Ingress 都是比较好的选择,Kong从理论上讲也算是流量网关,但是性能没有前面的高。 而业务网关 主要以 Zuul,Spring Cloud Gateway以及异步Servelt等方式实现的较多。比如 美团自研的 Shepherd 就是基于Java语言实现的 ,个人认为是基于异步Servlet 实现的。我也认为基于JAVA实现业务网关是比较容易也比较容易扩展，更容易让其他团队理解和使用。

如上面提到的 美团自研的 Shepherd ，业务网关的基础功能我就不描述了。那么如何整合公司现现有业务需求，去深入挖掘，将业务需求抽象为一个组件整合进业务网关，也是作为一个资深基础组件开发做需要做的。我这里就是基于现有公司的业务需求去抽象出了一个组件，来满足未来更多类似场景的接口请求需求。

目前我就职于 一家 国际保险科技公司，为其他国家提供数字化保险金融解决方案。公司有自己的一套保险解决方案产品,但是众所周知,保险的售卖不光靠自己公司，还要寻找其他 销售渠道，比如 支付宝的保险售卖渠道，微信的保险售卖渠道以及手机银行APP等保险售卖渠道等等。因此光有自己的一套产品，不足以满足所有的渠道售卖需求，我们需要根据不同的渠道以及该渠道能满足的售卖保险方式来做定制开发。比如很简单的保险理赔业务，基础架构图如下:

抛开自营的C端和B端服务不谈,由上方第三方渠理赔可以看出,如果多个渠道商有不同的理赔逻辑或者方式，比如渠道A 只能提供报案人以及保险持有人信息，无法提供赔付人信息，渠道B 能提供报案人，保险持有人以及赔付人信息。那么按照正常来说，渠道理赔服务分别需要给渠道A和渠道B提供两个理赔接口，渠道A则不提供赔付人信息传参，渠道B则提供赔付人信息传参以及校验。如图所示:

现在由于保险产品深受大家喜爱，又接入了渠道C，渠道C是大厂商，可以提供所有理赔数据，包括 报案人、保险持有人、被保险人人以及赔付人。可以看到又多了一个入参信息。按照正常的逻辑 那么肯定会针对渠道C单独开发一个API。如下图所示

现在来看 是不是还可以 因为最多也就三个API，不足为惧。那么问题来了，由于渠道A系统升级，可以提供被保险人信息，但是！ 只能提供几个基本信息，可能信息给的不是很全。那么很明显 API-C的接口也无法满足，只能升级接口API-A。 那么由于渠道商也在不断更新迭代系统，我们就是不断地适配适配再适配。

是不是很无奈。

相信多年的老兵看到这里，就想到了解决方案。不错,提供一个统一的接口，包括所有的入参逻辑。让大家都统一调这一个接口不就好了。设计一个统一的接口并不难，难点是在于 各个参数的校验上。有的渠道厂商能提供参数，就需要校验，有的不能提供参数就不能去校验，否则API就过不了。

根据这种需求，我想业务网关的作用就体现了淋漓尽致。我们只需要在业务网关上进行可配置参数校验以及可配置入参。将一个统一的API打散成不同的API，当有某个API需要新增参数时，只需要在业务网关层进行参数设置，将对应的参数 映射到 统一的理赔API就可以了。如下图所示:

本文主要是讲解了 某业务的场景以及对应需求变更时所带来的 人力成本和时间成本。针对某业务场景，将基础需求抽象出来，同时设计一个业务网关通用组件来满足当前的需求的思想。下一篇文章将主要针对技术上的预研以及实践进行探讨。

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

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