微服务治理和服务网关（微服务架构 网关）

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

本文目录一览：

• 1、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署
• 2、微服务 六：服务网关
• 3、微服务有什么作用？
• 4、微服务方式实现双重网关
• 5、微服务入门这一篇就够了

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

微服务 六：服务网关

服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图

微服务有什么作用？

维基上对微服务的定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
微服务的最重要的单一特征可能是，由于服务较小且可独立部署，因此不再需要繁琐的行动才能更改应用程序中的一行文字。
在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在变化，由多个较小的服务组成的应用程序随着更理想的技术的发展而变得更容易且成本更低。
使用微服务，可以单独部署单个服务，但是也可以单独扩展它们。由此带来的好处是显而易见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。
比如像HC服务网格是基于Istio及容器技术的微服务治理平台，以无侵入方式为多语言、不同部署形态的异构应用提供服务治理、服务监控和安全控制等微服务管理能力。能够将服务通信、观测与安全能力下沉到基础设施层，降低分布式应用开发复杂度，为应用运维减负，推动企业应用整体向服务治理平台迁移，提升IT系统的整体承载能力、高可用能力。

微服务方式实现双重网关

最近在做一个多项目整合的工作，因为每个项目都有自己的一套网关，每个网关都有自己的加解密算法，整合到一起要求对外提供统一的用户鉴权，而且不对原有系统做大规模的重构，基于这些现实考虑使用两重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鉴权后访问业务微服务的流程。

微服务入门这一篇就够了

刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？

但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！

首先，什么是微服务呢？

相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：

但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：

后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：

上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：

我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。

撇开架构先不说，什么样的服务才算微服务呢？

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。

应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件： 服务注册中心 ，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件： 配置中心 ，微服务架构就变成下面这样了：

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：

本章节主要介绍如何基于Spring Cloud相关组件搭建一个典型的微服务架构。
首先，创建一个Maven父项目 spring-cloud-examples ，用于管理项目依赖包版本。由于Spring Cloud组件很多，为保证不同组件之间的兼容性，一般通过 spring-cloud-dependencies 统一管理Spring Cloud组件版本，而非每个组件单独引入。

pom.xml配置如下：

参考上面业务服务A搭建另外一个业务服务B。

目前网上很多说是下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。Service Mesh我接触还不多，但是个人感觉并不一定能称为下一代微服务架构，可能认为是服务治理的另外一种解决方案更合适，是否能够取代当前的微服务架构还需要持续观察。

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

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