微服务网关是否稳定（微服务为什么要用网关）

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

本文目录一览：

• 1、微服务架构的缺点
• 2、谈谈微服务架构是一个怎样的存在？
• 3、微服务 六：服务网关
• 4、Spring Cloud微服务体系的组成
• 5、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署

微服务架构的缺点

介绍微服务架构好处的文章比较多，最近交付的一个项目发现的缺点也比较明显，给方案设计，性能，测试，运维，问题排查，数据管理，配置管理，事务管理，研发管理都带来了不少挑战。如果使用不慎，研发成本，交付成本和运维成本都可能会大幅度上升。

自己的体会，不能简单通过技术角度看待微服务化，为了微服务而微服务潜在风险很大，不好的微服务切分会带来不必要的沟通路径，而沟通路径增加会带来更大的复杂度，这违背了微服务设计的初衷。微服务“入门容易，掌握难，出门难”。

建议的原则是业务驱动，设计保障，演进式迭代，保守治疗的方式。搞不清楚，有争议的地方先尽量不要拆，如果确实要拆，要经过业务分析后慎重设计，把真正相对独立的部分拆分出来，可以借鉴DDD的方式。拆了以后要观察微服务的接口是否稳定，针对业务需求的变更微服务的模块是否可以保持相对稳定，是否可以独立演进。

正好看了一个国外帖子，总结的不错，翻译并增加了自己的一些体会：

以下是微服务架构的缺点：

架构演进应该还是需要业务驱动和演进式迭代的，重新看了Martin Fowler的那篇
Microservices 经典之作。再来体会一下这句话会有不同的体验：
“One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith , keep it modular, and split it into microservices once the monolith becomes a problem.”
不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。

另外看到一篇文章《Microservices - Not A Free Lunch!》,也提出了微服务的几个潜在问题：

谈谈微服务架构是一个怎样的存在？

微服务是近些年被广泛提及的一个概念微服务网关是否稳定， 微服务架构可以理解为一个轻量级的服务治理方案， 也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。

微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是 将功能发布成服务，应用程序通过调用不同的服务来实现业务， 这种设计架构称之为微服务。

微服务架构的优点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之， 微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要， 适当的技术用在适当的场景，才能发挥合适的价值。

微服务架构是当前最流行的技术架构，主要组件有注册中心、网关、配置中心和各种微服务模块。架构灵活、易扩展、可动态扩容。

在微服务之前，系统架构经历很长时间的演变，简述如下微服务网关是否稳定：

1.无架构

页面逻辑和业务逻辑混在一起，甚至页面直接访问数据库。

优点：因为没有太多的访问路径转换，效率是最高的；

缺点：没有分层，逻辑混乱，维护难，扩展难。

2.MVC

架构

单系统，表现层、逻辑层、业务层分开，各层分工协作。

优点：逻辑清晰、分工明确、易维护。

缺点：系统集中部署，属于强耦合，某些业务模块出现异常时，会导致整个系统无法访问。

3.SOA架构

面向服务的架构，多个系统分布式部署，通过消息总线进行通讯。

优点：各个系统的业务相对独立，耦合低；

缺点：消息总线负担太重，中心化太重，接口缺乏规范。

4.微服务架构

一个系统，按照粒度规划，划分为很多的微服务，而每个微服务，对应一个具体的业务实现，并可拥有自己独立的数据库，整个就是微服务架构。

优点：如上，架构灵活、易扩展，在实际运营时，按需扩容，集群部署。各个微服务业务互不影响，耦合性低；

缺点：开发成本高，对部署有一定的专业性要求。

从技术而言，微服务已经是一个设计理念很成熟的架构，可满足不同层次，不同业务场景的需要，而且经过多个版本的迭代，该踩的坑也基本踩完，生态系统完整，开源组件选择多多，很有一统天下的趋势，值得尝试。

但，不要为了微服务而微服务，要根据自己实际的要求去做抉择和取舍。

比较，适合自己的，才是最好的！

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、 时尚 版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。

那微服务为什么流行起来微服务网关是否稳定？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构。

国内流行起来的微服务架构——RestCloud

RestCloud 为了保证服务不注册中心癿高可用性，服务不注册中心通过水平扩展癿能

力允许对服务不注册中心迚行集群配置，开在网关层做了服务癿注册癿数据缓存。

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中癿一部分，它基于 Netflix Eureka做了二次封装。主要负责完成微服务架极中的服务治理功能。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

网站链接：http://www.restcloud.cn/restcloud/mycms/index.html

参考资料：https://blog.csdn.net/kezi/article/details/81276727

微服务 六：服务网关

服务除微服务网关是否稳定了内部相互之间调用和通信之外微服务网关是否稳定，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(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）简化的微服务架构图

Spring Cloud微服务体系的组成

Netflix Eureka是Spring Cloud服务注册发现的基础组件
Eureka提供RESTful风格(HTTP协议)的服务注册与发现
Eureka采用C/S架构,Spring Cloud内置客户端

启用应用,访问 http://localhost:8761
Eureka客户端开发要点
maven依赖spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口类增加@EnableEurekaClient

先启动注册中心,在启动客户端,访问 localhost:8761查看eureka注册中心,看到客户端注册

Eureka名词概念
Register - 服务注册, 向Eureka进行注册登记
Renew - 服务续约,30秒/次心跳包健康检查.90秒未收到剔除服务
Fetch Registries - 获取服务注册列表,获取其他微服务地址
Cancel - 服务下线, 某个微服务通知注册中心暂停服务
Eviction - 服务剔除,90秒未续约,从服务注册表进行剔除
Eureka自我保护机制
Eureka在运行期去统计心跳失败率在15分钟之内是否低于 85%
如果低于 85%，会将这些实例保护起来，让这些实例不会被剔除
关闭自我保护:eureka.服务实例.
enable-self-preservation: false
PS: 如非网络特别不稳定,建议关闭

Eureka高可用配置步骤
服务提供者defaultZone指向其他的Eureka
客户端添加所有Eureka 服务实例 URL

Actuator自动为微服务创建一系列的用于监控的端点
Actuator在SpringBoot自带，SpringCloud进行扩展
pom.xml依赖spring-boot-starter-actuator

RestTemplate + @LoadBalanced 显式调用
OpenFeign 隐藏微服务间通信细节

Ribbon是RestTemplate与OpenFeign的通信基础

Feign是一个开源声明式WebService客户端，用于简化服务通信
Feign采用“接口+注解”方式开发，屏蔽了网络通信的细节
OpenFeign是SpringCloud对Feign的增强，支持Spring MVC注解

1.新建Spring boot Web项目，application name 为 product-service
在pom.xml中引入依赖

spring-cloud-starter-alibaba-nacos-discovery作用为向Nacos server注册服务。
spring-cloud-starter-openfeign作用为实现服务调用。
2.修改application.yml配置文件

3.在启动类上添加@EnableDiscoveryClient、@EnableFeignClients注解

4.编写OrderClient Interface
注：/api/v1/order/test 会在下面order-service声明。
OrderClient.java

5.编写Controller和service
ProductController.java

ProductService.java

1.OpenFeign开启通信日志
基于SpringBoot的logback输出,默认debug级别
设置项：feign.client.config.微服务id.loggerLevel
微服务id：default代表全局默认配置
2.通信日志输出格式
NONE: 不输出任何通信日志
BASIC: 只包含URL、请求方法、状态码、执行时间
HEADERS：在BASIC基础上，额外包含请求与响应头
FULL：包含请求与响应内容最完整的信息
3.OpenFeign日志配置项
LoggerLevel开启通信日志
ConnectionTimeout与ReadTimeout
利用httpclient或okhttp发送请求

1.OpenFeign通信组件
OpenFeign基于JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient与Square OkHttp
SpringCloud按条件自动加载应用通信组件
2.应用条件
Maven引入feign-okhttp或者feign-httpclient依赖
设置feign.[httpclient|okhttp].enabled=true

POST方式传递对象使用@RequestBody注解描述参数
GET方式将对象转换为Map后利用@RequestParam注解描述

雪崩效应:服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口,这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。
服务熔断:熔断机制目的为了保护服务，在高并发的情况下，如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值，让后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一起使用。

1.Hystrix熔断器
Hystrix（豪猪）是Netflix开源的熔断器组件，用于为微服务提供熔断机制预防雪崩，保护整体微服务架构的健康
2.Hystrix功能
预防微服务由于故障，请求长时间等待导致Web容器线程崩溃
提供故障备选方案，通过回退（fallback)机制提供”服务降级”
提供监控仪表盘,实时监控运行状态
3.Hystrix 熔断器工作原理

服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.
当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于
设定阈值, 开关则切换为打开状态.
当熔断器开关打开时, 请求被禁止通过.
当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用
成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.
熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.
4.什么情况下会触发服务降级
FAILURE: 执行失败，抛出异常
TIMEOUT:执行超时（默认1秒）
SHORT_CIRCUITED:熔断器状态为Open
THREAD_POOL_REJECTED:线程池拒绝
SEMAPHORE_REJECTED:信号量拒绝
5.使用Hystrix步骤
1.引入pom文件依赖

6.OpenFeign与Hystrix整合
OpenFeign中使用Hystrix
OpenFeign内置Hystrix，feign.hystrix.enable开启即可
feign: hystrix: enabled: true
在@FeignClient增加fallback属性说明Fallback类
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback类要实现相同接口，重写服务降级业务逻辑
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服务暂时无法使用，短信发送失败"); } }
7.Hystrix超时设置
8.部署Hystrix Dashboard监控
Hystrix Client依赖hystrix-metrics-event-stream
Hystrix Client注册HystrixMetricsStreamServlet
监控微服务依赖spring-cloud-starter-netflix-hystrix-dashboard
监控微服务利用@EnableHystrixDashboard开启仪表盘
9.Hystrix熔断设置
产生熔断的条件:
当一个Rolling Window(滑动窗口）的时间内（默认：10秒），最近20次调用请求，请求错误率超过50%，则触发熔断5秒，期间快速失败。
TIPS: 如10秒内未累计到20次，则不会触发熔断
Hystrix熔断设置项:

统一访问出入口,微服务对前台透明
安全、过滤、流控等API管理功能
易于监控、方便管理

Netflix Zuul
Spring Cloud Gateway

Zuul 是Netflix开源的一个API网关, 核心实现是Servlet
Spring Cloud内置Zuul 1.x
Zuul 1.x 核心实现是Servlet，采用同步方式通信
Zuul 2.x 基于Netty Server，提供异步通信

认证和安全
性能监测
动态路由
负载卸载
静态资源处理
压力测试

Spring Cloud Gateway，是Spring“亲儿子”
Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式
Gateway基于Spring 5.0与Spring WebFlux开发，采用Reactor响应式设计

1.使用三部曲
依赖spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服务映射
2.微服务映射

Spring Cloud Zuul内置Hystrix
服务降级实现接口：FallbackProvider

1.微服务网关流量控制
微服务网关是应用入口，必须对入口流量进行控制
RateLimit是Spring Cloud Zuul的限流组件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit采用“令牌桶”算法实现限流
2.什么是令牌桶
1.Zuul的执行过程

2.Http请求生命周期

1.需要实现ZuulFilter接口
shouldFilter() - 是否启用该过滤器
filterOrder() - 设置过滤器执行次序
filterType() - 过滤器类型:pre|routing|post
run() - 过滤逻辑
2.Zuul内置过滤器

3.Zuul+JWT跨域身份验证

1.Spring Cloud Config
2.携程 Apollo
3.阿里巴巴Nacos

1.依赖"spring-cloud-starter-config"
2.删除application.yml,新建bootstrap.yml
3.配置"配置中心"服务地址与环境信息

1、微服务依赖"spring-boot-starter-actuator";
2、动态刷新类上增加@RefreshScope注解
3、通过/actuator/refresh刷新配置

1、通过加入重试机制、提高应用启动的可靠性;
2、重试触发条件1:配置中心无法与仓库正常通信
3、重试触发条件2:微服务无法配置中心正常通信

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

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

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