精华内容
下载资源
问答
  • 微服务治理方案

    2018-06-01 20:02:58
    微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案微服务治理方案...
  • 7微服务治理 7.1微服务治理介绍 7.1.1什么是微服务治理 微服务开发上线后由于数量众多,并且微服务之间调用关系复杂,需要对微服务进行统一治理,微服务治理提供了 熔断、容错、限流、降级等高级服务治理能力,最大...

    7微服务治理

    7.1微服务治理介绍

    7.1.1什么是微服务治理
    微服务开发上线后由于数量众多,并且微服务之间调用关系复杂,需要对微服务进行统一治理,微服务治理提供了 熔断、容错、限流、降级等高级服务治理能力,最大限度保障服务的可用性。
    7.1.2云平台如何微服务治理
    在学习ServiceComb时采用微服务治理都需要我们在配置文件中配置治理策略,而采用云平台的方式进行微服务治理只需要在微服务中配置少量的必要配置,具体的治理参数通过云平台配置,微服务也会把自已的信息上报给云 平台,并且微服务通过配置中心获取治理参数,从而实现通过云平台对微服务进行治理。
    如何学习微服务治理:
    1、测试阶段 可以在本地开发环境运行微服务,接入CSE平台,在云平台配置微服务治理的参数,观察微服务治理的效果。
    2、生产阶段将微服务部署到云平台,并接入CSE平台。

    7.2准备工作

    7.2.1连接配置中心
    微服务要通过云平台治理需要连接服务注册中心和配置中心,在云平台设置微服务治理参数,通过配置中心将配置 信息下发到微服务。
    在微服务中配置服务注册中心和配置中心: 在microservice.yaml中配置:

    
    cse:
    service:
    registry:
    address: https://cse.cn‐north‐1.myhuaweicloud.com instance:
    watch: false config:
    client:
    serverUri: https://cse.cn‐north‐1.myhuaweicloud.com refreshMode: 1 #默认为定时拉取
    refresh_interval: 30 #客户端主动从配置中心拉取配置的周期 单位秒
    

    7.2.2配置Handler
    服务治理主要涉及熔断、容错、限流、负载均衡等。需要增加下面治理相关的handler。

    cse:
    handler:
    chain:
    Provider:
    default: bizkeeper‐provider,qps‐flowcontrol‐provider Consumer:
    default: bizkeeper‐consumer,loadbalance,qps‐flowcontrol‐consumer
    

    每个Handler就是独立的处理模块,CSE提供如下的Handler:

    handler-loadbalance	负载均衡模块。提供各种路由策略和配置方法。一般客户端使用。
    handler-bizkeeper	和服务治理相关的功能,比如隔离、熔断、容错。
    handler-tracing	调用链跟踪模块,对接监控系统,吐出打点数据。
    handler-tcc	提供TCC事务开发管理能力。
    

    7.3负载均衡策略

    7.3.1策略介绍
    当出现访问量和流量较大,一台服务器无法负载的情况下,我们可以通过设置负载均衡的方式将流量分发到多个服 务器均衡处理,从而优化响应时长,防止服务器过载。
    可以通过新增规则配置负载均衡策略,设置参数支持轮询、随机、响应时间权值、会话保持等多种负载均衡策略。
    7.3.2策略实现
    设置负载均衡:
    1、进入服务目录
    在这里插入图片描述
    2、单击需要治理的微服务,进入微服务治理配置页面。
    在这里插入图片描述
    在这里插入图片描述
    3、在微服务治理配置页面,单击“负载均衡”,展开负载均衡详情页。
    在这里插入图片描述
    4、单击“新增”,进入负载均衡策略配置。先选择需要治理的微服务,再选择合理的负载均衡策略,请参见下表。

    策略名	策略说明
    轮询	支持按照服务实例的位置信息顺序路由。
    随机	提供服务实例随机路由。
    响应时间权值	提供最小活跃数(时延)的权重路由,支持业务处理慢的服务实例接收较少的请求,防止系统停止响  应。这种负载均衡策略适合请求量少且稳定的应用。
    会话粘滞	会话粘滞是负载均衡器上的一种机制,在设定的会话保持时间内,会保证同一用户相关联的访问请求  会被分配到同一实例上。会话保持时间:会话保持的限制时间,0-86400,单位为秒。失败次数阈    值:访问失败次数,0-10。当微服务访问下属实例的失败次数和会话保持时间超过设定的值时,微服务不再访问该实例。
    

    7.4限流策略

    7.4.1策略介绍
    限流主要解决微服务之间的流量分配问题,保证微服务在自己的资源池运行,互不影响。当限流对象对当前服务实 例的每秒请求数量超过设定的值,当前服务实例不再接受该对象的请求。
    常用的检测方法是请求超时、流量过大等,设置参数包括限流对象、QPS阈值等。

    7.4.2策略实现
    使用云平台服务治理功能,通过图形界面完成限流设置,如下:
    在这里插入图片描述

    7.5容错策略

    7.5.1策略介绍
    容错是服务调用者访问服务实例,服务实例出现异常时的一种处理策略,出现异常后按照定义的策略进行重试或访 问新的服务实例。一旦发生异常,服务会根据容错机制来进行尝试重新访问或直接返回失败。
    7.5.2策略实现
    设置容错:
    1.单击需要治理的微服务,进入微服务治理配置页面。
    2.服务治理配置页面,单击“容错”,展开容错详情页。
    3.单击“新增”,进入容错策略配置页面。
    4.在容错策略配置页面选择合理的策略,容错策略配置项如下表所示。

    配置项	配置项说明
    容错对象	该应用依赖的应用或方法,下拉菜单可直接选择。
    
    是否开启容错	开启:向容错对象发起请求时发生错误的处理策略,开启后,会根据选择的处理策略处理请求。关闭:关闭容错策略,即使请求失败也会等到超时后,再返回失败结果。
    容错策略说明:当“是否开启容错”配置项设置 为“开启”时配置	Failover:在不同服务器上重新尝试建立连接。
    同上	Failfast:不再重新尝试建立连接,即请求失败时会立即返回失败结果。
    同上	Failback:在同一个服务器上重新尝试建立连接。
    同上	custom:同一个服务器上尝试重新建立连接的次数,取值范围0-9的整数。在不同服务器上尝试建立连接的次数,取值范围0-9的整数。
    

    测试:
    1、先设置负载均衡
    2、断掉一个服务,测试发现远程连接3、容错设置为Failback或Failover

    7.6降级策略

    7.6.1策略介绍
    降级是容错的一种特殊形式,当出现服务吞吐量巨大,资源不够用等情况,我们可使用降级机制关掉部分不重要、 性能较差的服务,避免占用资源,以保证主体业务功能可正常使用。
    7.6.2策略实现
    设置降级:
    1.单击需要治理的微服务,进入微服务治理配置页面。
    2.在服务治理配置页面,单击“降级”,展开降级详情页。
    3.单击“新增”,进入降级策略配置页面。
    4.在降级策略配置页面选择合理的策略,降级策略配置项如下表所示。

    
    配置项	配置项说明
    降级对象	选择需要降级的服务。
    降级策略	开启:开启降级关闭:关闭降级
    

    7.7熔断策略

    7.7.1策略介绍
    当我们发现由于某些原因导致服务出现了过载现象,为避免造成整个系统故障,可采用熔断来进行保护。熔断在服 务请求处理出现异常时产生作用。进入熔断状态后,hystrix会认为被请求的服务已经无法处理请求,在第一时间截断请求直接返回错误给调用者。hystrix每隔一段时间会尝试访问后端服务,如果服务恢复正常,会退出熔断状态, 恢复正常的请求访问。
    7.7.2策略实现
    设置熔断:
    1.单击需要治理的微服务,进入微服务治理配置页面。
    2.在服务治理配置页面,单击“熔断”,展开熔断详情页。
    3.单击“新增”,进入熔断策略配置页面。
    4.在熔断策略配置页面选择合理的策略,熔断策略配置项如下表所示。
    在这里插入图片描述
    1、手动熔断
    设置手动相当于实现降级功能。
    2、取消熔断相关于删除熔断
    3、自动熔断
    测试流程为:设置失败率10、窗口请求数为10,熔断时间窗为2分钟,断掉服务,触发熔断,此时再启动服务也需要等待2分钟才可恢复

    7.8错误注入策略

    7.8.1策略介绍
    错误注入策略用于测试微服务的容错能力,可以让用户知道,当出现延时或错误时,系统是否能够正常运行。 错误注入通过延时、错误等方式,供用户测试微服务的容错能力。
    7.8.2策略实现
    需要在消费微服务中配置hander: fault-injection-consumer
    例如:

    
    handler:
    chain:
    Provider:
    default: bizkeeper‐provider,qps‐flowcontrol‐provider Consumer:
    default: bizkeeper‐consumer,loadbalance,qps‐flowcontrol‐consumer,fault‐injection‐consumer
    

    测试:
    通过错误注入来测试熔断功能,思路如下:
    1、通过注入触发消费方请求延时。
    向网关设置错误注入,如下图,表示网关请求portalview出现3600ms延时。
    在这里插入图片描述
    2、向网关设置消费超时时间,当错误注入触发延迟,由于网关消费超时时间小于上图设置的3600ms,则请求失败。

    
    cse:
    isolation:
    Consumer:
    timeout:
    enabled: true
    timeoutInMilliseconds: 2000 #消费者超时时间
    

    3、设置网关熔断策略,如下图,表示熔断后将停止90s时间。
    在这里插入图片描述
    4、熔断触发后将错误注入取消,并观察90s后恢复正常。

    展开全文
  • 微服务治理

    2019-12-16 23:20:20
    服务治理就是让服务子维护,微服务做为服务提供方主动向服务治理中心注册,服务的消费者通过服务治理中心查询需要的服务并调用,如下图: 二、springcloud如何实现服务治理 springcloud通过对Eureka的二次封装来...

    一、什么是服务治理
    由于微服务数量太多导致维护成本巨大,服务治理就是来解决这个问题。服务治理就是让服务子维护,微服务做为服务提供方主动向服务治理中心注册,服务的消费者通过服务治理中心查询需要的服务并调用,如下图:
    在这里插入图片描述

    二、springcloud如何实现服务治理
    springcloud通过对Eureka的二次封装来实现服务治理。Eureka提供了服务端和客户端,服务端是服务注册中心,客户端完成服务的注册和发现,其关系如下:

    Eureka的架构:
    

    在这里插入图片描述

    注:1.微服务A向Eureka Server注册,并通过心跳机制告诉Server自己的状态。如果微服务A需要下线也要告诉Server;如果一段时间Server没有收到微服务A的心跳,那么认为微服务A已经宕机

        2.微服务B从Server中发现微服务A,然后向微服务A发起请求
    
        3.Server 有多个节点,一旦一个节点宕机,还能用其他的Server
    

    三、Eureka Server的开发
    1.创建springboot工程 ,并选择Eureka Server

    1. 在启动类上加注解 @EnableEurekaServer

    3.增加application.yml配置文件

    4.启动2台eureka server ,将自己注册到对方

    spring-boot:run -Dport=6868 -Deureka.server=http://127.0.0.1:6869/eureka/
    
    spring-boot:run -Dport=6869 -Deureka.server=http://127.0.0.1:6868/eureka/
    

    5.通过浏览器访问,查看是否启动成功http://localhost:6868/ http://localhost:6869/

        eureka server 有2个,端口号是6868,6869 ,说明启动成功
    

    四、微服务的开发
    1.创建springboot工程 ,并选择Eureka Server

    2.增加application.yml配置文件
    

    3.具体的controller、server、mapper开发省略,见springboot

    4.启动2台微服务

    spring-boot:run -Dport=6801 -Deureka.server=http://127.0.0.1:6869/eureka/
    
    spring-boot:run -Dport=6802 -Deureka.server=http://127.0.0.1:6868/eureka/
    

    5.验证微服务是否注册到eureka中

    展开全文
  • 微服务治理 tracing-demo

    2020-09-25 16:11:44
    k8s环境微服务组件helm模板,可用于测试微服务治理;k8s环境微服务组件helm模板,可用于测试微服务治理;k8s环境微服务组件helm模板,可用于测试微服务治理;k8s环境微服务组件helm模板,可用于测试微服务治理;k8s...
  • 微服务治理读书笔记xmind 整书整理几个xmind文件
  • 从天气项目看Spring Cloud微服务治理从天气项目看Spring Cloud微服务治理从天气项目看Spring Cloud微服务治理
  • "The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, oft
  • 哈啰在分布式消息治理和微服务治理中的实践.pdf
  • 驰狼课堂Spring Cloud 微服务治理视频教学源码,提供给大伙学习
  • 微服务治理实践:服务契约.pdf
  • 本文来自InfoQ,重点将介绍Discovery中的Go语言最佳实践以及微服务治理的复杂性问题。大家都知道微服务有两个痛点,一个是如何拆分微服务,微服务的边界怎么划分制定;二是微服务上了规模之后如何管理,因为只要上了...
  • 微服务治理策略

    2019-10-28 20:42:20
    微服务治理策略 Author: HuiFer Description: 该文简单介绍微服务的治理策略以及应用技术 服务的注册和发 解决问题: 集中管理服务 解决方法: eureka 、zookeeper 负载均衡 解决问题: 降低服务器硬件压力 ...

    微服务治理策略

    • Author: HuiFer
    • Description: 该文简单介绍微服务的治理策略以及应用技术

    服务的注册和发

    解决问题: 集中管理服务

    解决方法: eureka 、zookeeper

    负载均衡

    解决问题: 降低服务器硬件压力

    解决方法: nginx 、 Ribbon

    通讯

    解决问题: 各个服务之间的沟通桥梁

    解决方法 :

    • 同步消息
      1. rest
      2. rpc
    • 异步消息
      1. MQ

    配置管理

    解决问题: 随着服务的增加配置也在增加,如何管理各个服务的配置

    解决方法: nacos 、 spring cloud config 、 Apollo

    容错和服务降级

    解决问题: 在微服务当中,一个请求经常会涉及到调用几个服务,如果其中某个服务不可以,没有做服务容错的话,极有可能会造成一连串的服务不可用,这就是雪崩效应.

    解决方法: hystrix

    服务依赖关系

    解决问题: 多个服务之间来回依赖,启动关系的不明确

    解决方法:

    1. 应用分层: 数据层,业务层 数据层不需要依赖业务层,业务层依赖数据,规定上下依赖关系避免循环圈

    服务文档

    解决问题: 降低沟通成本

    解决方法: swagger 、 java doc

    服务安全问题

    解决问题: 敏感数据的安全性

    解决方法: oauth 、 shiro 、 spring security

    流量控制

    解决问题: 避免一个服务上的流量过大拖垮整个服务体系

    解决方法: Hystrix

    自动化测试

    解决问题: 提前预知异常,确定服务是否可用

    解决方法: junit

    服务上线,下线的流程

    解决问题: 避免服务随意的上线下线

    解决方法: 新服务上线需要经过管理人员审核.服务下线需要告知各个调用方进行修改,直到没有调用该服务才可以进行下线.

    兼容性

    解决问题: 服务开发持续进行如何做到兼容

    解决方法: 通过版本号的形式进行管理,修改完成进行回归测试

    服务编排

    解决问题: 解决服务依赖问题的一种方式

    解决方法: docker & k8s

    资源调度

    解决问题: 每个服务的资源占用量不同,如何分配

    解决方法: JVM 隔离、classload 隔离 ; 硬件隔离

    容量规划

    解决问题: 随着时间增长,调用逐步增加,什么时候追加机器

    解决方法: 统计每日调用量和响应时间, 根据机器情况设置阈值,超过阈值就可以追加机器

    展开全文
  • 微服务治理实践:服务契约

    千次阅读 2020-10-13 10:38:59
    第一篇:《微服务治理解密》第二篇:《微服务治理实践:服务查询》第三篇:《微服务治理实践:金丝雀发布》在详细讲述服务契约之前,先给大家讲一个场景。前言随着微服务架构越来越流行,越来越多的公司使用微服务...
    简介:随着微服务架构越来越流行,越来越多的公司使用微服务框架进行开发。甚至不止是公司,连笔者的研究生导师都要对实验室的Spring Boot工程项目转型使用微服务框架了。

    本文是《微服务治理实践》系列篇的第四篇文章,主要分享Spring Cloud微服务框架下的服务契约。
    第一篇:《微服务治理解密》
    第二篇:《微服务治理实践:服务查询》
    第三篇:《微服务治理实践:金丝雀发布》
    在详细讲述服务契约之前,先给大家讲一个场景。

    前言

    随着微服务架构越来越流行,越来越多的公司使用微服务框架进行开发。甚至不止是公司,连笔者的研究生导师都要对实验室的Spring Boot工程项目转型使用微服务框架了。随着时间的推移,服务量逐渐上升,小学妹吃不消跑来问我问题:

    一姐,我来交接你之前写的项目啦,你什么时间方便我想问你一些问题。这么多微服务接口,感觉不知道从哪里去看会比较好呢。

    我想了想自己刚入门时候写的垃圾代码,还没有注释,无语凝噎。

    好。我平时工作日在实习,周末给你讲哈。

    于是到周末,花了整整一个晚上的时间,终于给零基础学妹从众多接口的含义,到参数列表的解析,最后到讲解百度应该搜什么关键词(我好南),全方位视频指导。学妹十分感动:

    一姐你太贴心了555,跟别人协作项目的时候,经常能讲上几句就不错了,然后我还是什么都不明白,改完接口也不及时告诉我。还是你最好了,后面还有什么不懂的我再来问你哦。

    从以上场景,我们可以总结出使用微服务框架后,会带来的几点进度协同问题:
    1、不及时提供接口API:
    尤其体现在项目交接上,该问题对人员变动比较频繁的组织,如高校项目的准毕业生和新生交接、企业项目的外包人员交接,问题会显得更加突出。开发人员经常过于关注微服务的内部实现,相对较少设计API接口。

    程序员最讨厌的两件事:1. 写注释 2. 别人不写注释

    是不是经常想着写完代码再写注释,但真正把代码写完以后,注释/接口描述一拖再拖最后就没有了?别告诉我你没有过。

    2、不及时变更接口:
    即使有了API文档,但由于文档的离线管理,微服务接口变更以后,文档却没有及时变更,影响协作人员的开发进度。

    综上我们看到,我们不但希望所有的微服务接口都可以很方便的添加规范的接口描述,而且也能随着接口的变更及时更新文档。因此,我们需要服务契约来帮助我们解决这些问题。

    为什么我们需要服务契约

    首先我们来看服务契约的定义:

    服务契约指基于OpenAPI规范的微服务接口描述,是微服务系统运行和治理的基础。

    有人可能会问了,既然想要规范的描述接口,我有很多其他的方式啊,为什么我要用服务契约?

    1、 我用Javadoc来描述接口然后生成文档不可以吗?
    可以,但刚刚我们也提到了“程序员最讨厌的两件事”,要求所有的开发人员都去主动的按照规范写注释,把所有的接口、参数列表的类型、描述等信息全都写清楚,是一件比较费时费力的事情。我们希望有一个能够减少开发人员负担的方法。

    2、 现在不是有很多专业的API管理工具吗,我直接用专业的API管理工具去维护也是可以的吧。
    API管理工具我们也是有考虑的,但是有如下的问题:
    • 很多工具依然缺少自动化的API生成;
    • 不是专注于解决微服务领域的问题,随着服务量迅速上升,管理起来依旧比较困难。

    3、 那微服务框架本身也会有提供相关的接口管理功能吧,Dubbo可以用Dubbo Admin,Spring Cloud可以用Spring Boot Admin,它们不香吗?

    这里篇幅有限,我们不再去详细讲述开源工具我们怎么去一步步使用,就用一张表格说话:

    image.png

    从表格可以看到,EDAS微服务治理的服务契约,支持版本更广泛了,配置难度更低了,代码侵入性没有了,直接用EDAS的Agent方案,它不是更香了?

    EDAS 服务契约实践

    下面我们来体验一下,EDAS上如何查看Spring Cloud的微服务契约。

    创建应用

    根据你的需要,选择集群类型和应用运行环境,创建Provider和Consumer应用。

    image.png

    服务查询控制台

    1、 登录EDAS控制台,在页面左上角选择地域;
    2、 左侧导航栏选择:微服务治理 -> Spring Cloud / Dubbo / HSF -> 服务查询;
    3、 服务查询页面单击某个服务的详情;

    image.png

    查看服务契约

    服务详情页面包括基本信息、服务调用关系、接口元数据、元数据等信息。在“接口元数据”一栏,便可查看服务的API信息。当用户使用Swagger注解时,会在“描述”列显示相应信息。
    image.png

    服务契约实现细节

    在设计服务契约功能的时候,我们不但解决了开源框架中配置难度大,且部分方案具有代码侵入性的问题,而且针对如下阶段的难点都做了相应的方案,相信这些地方也是微服务框架的使用者会关心的:

    1、数据获取

    • 获取的同时是否还需要其他配置?
    • 如何获取所需的方法名及描述、参数列表及描述、返回类型等信息?
    • 会不会影响服务的性能?
    • 信息能不能全面的拿到?
    • 能不能同步接口的变更?

    2、数据解析

    • 能不能看到参数类型/返回值类型的详细结构?
    • 解析参数结构的时候会不会影响启动时间?
    • 泛型、枚举是否支持?
    • 循环引用如何解决?
    下面我们来详细介绍一下这几点都是如何解决的。

    数据获取

    为了减少用户的配置和使用难度,我们采用了Agent方案,用户无需任何额外的代码和配置,就可以使用我们的微服务治理功能。

    Java Agent是一种字节码增强技术,运行时插入我们的代码,便可稳定的享受到所有的增强功能。

    而且通过测试可得,只要在SpringMVC的映射处理阶段,选取合适的拦截点,就可以获取到所有的方法映射信息,包括方法名、参数列表、返回值类型、注解信息。由于该点在应用启动过程中只发生一次,因此不会有性能的影响。

    我们获取的注解主要是针对Swagger注解。作为OpenAPI规范的主要指定者,Swagger虽并非是唯一支持OpenAPI的工具,但也基本属于一种事实标准。注解解析的内容在表格的描述部分进行展示:
    • Swagger2的注解解析(如@ApiOperation,@ApiParam,@ApiImplicitParam),解析value值在“描述”列显示;
    • OpenAPI3的注解解析(如@Operation,@Parameter),解析description值在“描述”列显示。

    当接口发生变更时,只要将新版本的应用部署上去,显示的服务契约信息就会是最新的,无需担心接口描述信息不能同步的问题。

    数据解析

    如果参数列表/返回值的类型是一个复杂类型,一般情况我们只看到一个类型名。那么有没有办法可以看到这个复杂类型的具体构成呢?

    聪明的你可能就会想到,通过反射来递归遍历该类所有的Field,不就都解决了?思路确实如此,但实际要考虑的情况会更复杂一些。

    image.png
    以该复杂类型CartItem为例,它可能不但会包含基本类型,还可能会涉及到泛型、枚举,以及存在循环引用的情况。

    因此在解析该类型之前,我们需要先判断一下该类型是否存在泛型、枚举的情况,如果是,需要额外解析并存储泛型列表及枚举列表。

    而循环引用问题,我们只需借助一个typeCache即可解决。如下图,A和B构成了一个循环引用。
    image.png
    如果我们不采取任何措施,递归遍历将永远没有出口。但是,如果我们在遍历A的所有类型之前,先判断一下typeCache里是否存在TypeA。对TypeB也以此类推:
    image.png
    那么当遍历ObjB中所包含类型时,如果遇到了TypeA,同样也会先判断typeCache中是否存在。如存在,就无需再递归遍历ObjA中所有的类型了,而是直接记录一个A的引用。因此,循环引用问题也就得以解决。
    image.png

    最终的解析信息,可以在服务测试功能中得以体现。未来我们可能会支持直接在服务查询中的服务契约页,通过一个入口显示复杂类型的具体解析结构。

    由此我们看到,在服务契约的获取及解析阶段,涉及到的可能影响用户体验的问题都得到了一定的解决。

    不止是服务契约

    本文介绍了几种接口描述方法,并且和开源框架的微服务接口管理功能进行对比,引出了EDAS服务契约。虽然服务契约看起来只是在控制台上的一个接口信息展示功能,但在未来的发展中不可或缺,其上报的关键信息可以很大程度的优化服务测试、服务鉴权、标签路由的体验,是微服务治理体系中的基础功能。

    EDAS微服务治理在未来甚至还可以在服务契约的基础上增加更多的增强功能,欢迎体验。

    除了 EDAS 和 MSE(微服务引擎)这些微服务产品之外,我们还有 ARMS (应用实时监控服务)、ACM(应用配置管理)、SAE(Serverless 应用引擎)等云产品。欢迎加入我们一起,用心服务客户,共同打造产品,让业务永远在线。

    原文链接:https://developer.aliyun.com/article/775503?

    版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
    展开全文
  • 从天气项目看Springcloud微服务治理,springcloud的微服务 java项目
  • 微服务治理权 开发和运维吵架 在前几年刚开始做微服务的时候,面临着一个两难的问题,就是微服务的控制权到底是放到应用内部还是在统一的平台层。Kubernetes具有服务注册和发现、配置、网关路由等功能,spring cloud...
  • 压缩包-springcloud微服务治理天气项目实战压缩包-springcloud微服务治理天气项目实战
  • 从天气项目看Spring Cloud微服务治理
  • RocketMQ 千锤百炼--哈啰在分布式消息治理和微服务治理中的实践.pdf
  • 物联微服务治理基础服务开发:基础服务发现、注册、 配置等等 <module>nbiot-base-config <module>nbiot-base-eureka <module>nbiot-base-hystrix <module>nbiot-base-turbine <module>nbiot-base-zipkin...
  • 完整的11章节,以天气项目为实战来说明springcloud微服务治理,完整的视频教程及源代码,方便大家学习
  • Spring Cloud微服务治理入门时序图,一个微服务与分布式的菜鸟画的图,希望你可以给我一样热门微服务开发,互相分享点滴。
  • Azure_无服务器与微服务治理模式 安全 网络犯罪 可信编译 应用审计 安全建设
  • 如何通过 Serverless 提高 Java 微服务治理效率?.pdf
  • 收藏:微服务治理中要关注的环节.pdf

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 37,527
精华内容 15,010
关键字:

微服务治理