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

    2020-09-14 16:48:38
    服务治理的经验之谈

    1.全服务需进行http/rpc压测,并适当进行机器扩容

    1)计算单实例下机器可承受的最大qps
    压测结果以服务器实际接收到的qps为准,如下图
    在单接口qps50时,服务延迟逐渐升高,故取40qps时服务器实际接收到的qps作为单实例稳定运行qps值。此时服务器实际接收的qps为91(单接口50,其余接口根据转换比设置,故总qps会大于50,并且部分发出的qps可能因为网络延迟丢失,所以取服务器实际接收到的qps为准)
    2)实例扩容至 2✖️实例数✖️压测qps>线上当前峰值总qps

    在这里插入图片描述

    2.熔断时间设置

    查出每个接口的TP999峰值,单独设置每个接口的熔断时间设置为该值*2

    3.慢查询治理

    慢查询会拖垮整个系统的性能,可通过优化sql、缓存等方案进行治理
    我们服务慢查询治理后的效果
    在这里插入图片描述

    4.服务巡检

    大多数错误会因为报警阈值的触发而被发现,也有少部分问题需要服务巡检去观察。
    所以需要定时对系统进行服务巡检,可以发现很多问题,比如某段时间请求数每天都在暴涨,如果不是业务的扩长,就要考虑你的接口是不是被攻击了,或者有没有人在没告知的情况下就接入了你的接口之类的。
    举例可观察的值如:
    1.服务总请求数
    2.请求错误数
    3.慢查询数
    4.CPU峰值
    5.内存使用
    6…
    在这里插入图片描述

    5.上下游依赖梳理与限流

    死道友不死贫道的做法,避免下游对接口的滥用导致服务出现问题,故需要梳理清楚依赖关系并适当进行限流。
    限流需设置告警并周知下游

    展开全文
  • 服务治理相关

    2020-12-13 22:59:36
    服务治理相关
  • 服务治理总结

    2017-11-15 17:44:00
    服务治理

          服务治理是随着服务化的架构理念而出现的,那么什么是服务治理(SOA governance),服务治理指的是用来管理SOA的采用和实现的过程。

          服务治理解决了微服务架构的什么痛点呢?首先我们总结一下微服务的特点:1)按业务、功能、模块、层级分成粒度很细的单独部署的服务,2)服务可以被N个其它服务调用,3)服务之间通过RPC通信。

          我们为什么要用服务化架构而不用一体化架构呢?服务化的好处是:1)人员分工更明确、责任更清晰,2)架构系统更清晰,3)业务复用性强,4)模块式开发管理方便。

          服务化架构带来了什么问题呢?1)随着服务越来越多服务的管理成本会增加,2)服务的依赖错综复杂、服务的调用路径不清晰,3)某个服务上、下线造成的影响不确定,4)服务缺少鉴权带来的安全性问题,5)服务调用等级、是否可以降级,6)服务间调用监控、统计,等等。

          服务治理要解决的问题有哪些呢?1)编译部署,2)服务发现,3)模块调用监控、统计,4)负载均衡与容错,5)服务容量评估、分析,6)服务鉴权,7)调用链跟踪,8)金丝雀部署,9)服务隔离,10)流量调度,11)沙箱模式,12)服务上、下线审批,13)服务责任人管理,14)文档管理


    展开全文
  • 微服务化架构下,面临服务治理问题的企业越来越多,这就像一场“暗夜长征”,只有找到正确的治理方向,才能坚持到底,看到胜利的曙光。希望这篇根据ArchSummit2019北京站两场演讲内容整理的长稿能给深陷其中的朋友...
  • dubbo服务治理

    2018-02-27 18:24:21
    dubbo服务治理的原理,doubbo怎么把一个项目管理成分布式项目等等技术
  • Eureka服务治理在Eureka服务治理的框架中,有三种角色,服务注册中心、服务提供者、服务消费者。1.服务注册中心Eureka服务端,支持高可用配置,能够集群部署,在Eureka服务治理设计中,所有节点既是服务提供方,也是...

    Eureka服务治理

    在Eureka服务治理的框架中,有三种角色,服务注册中心、服务提供者、服务消费者。

    1.服务注册中心

    Eureka服务端,支持高可用配置,能够集群部署,在Eureka服务治理设计中,所有节点既是服务提供方,也是服务消费方,服务注册中心也不例外。不同注册中心相互注册,以实现服务清单的互相同步。

    每个服务单元向注册中心登记自己提供的服务,将主机与端口号信息告诉注册中心,注册中心按服务名分类组织服务清单。注册中心会通过心跳的方式去监测清单中的服务是否可用。

    Eureka客户端既可以作为服务提供者也可以作为服务消费者,当是服务提供者的时候,进行服务的注册,当时服务消费者的时候进行服务的发现。

    2.服务提供者

    作为一个微服务应用向服务注册中心发布自己,也就是进行服务的注册。在配置文件中指定服务命名和服务注册中心的地址,如果注册中心是集群部署,那么就在此指定多个注册中心的地址。

    3.服务消费者

    完成发现服务和消费服务

    发现服务:服务的发现任务是由Eureka的客户端完成,在服务治理的框架下,服务间的调用不再通过具体的实例地址来实现,而是通过向服务名发起请求调用实现。服务调用方在调用服务提供方接口的时候,并不知道具体的服务实例位置。因此,调用方需要向服务注册中心咨询服务,并获取这个服务所有的实例清单。

    消费服务:服务消费人物由Ribbon完成,它是一个客户端负载均衡器,当发起服务调用的的时候,就会从服务清单中以某种轮询的策略取出一个位置来进行服务调用。

    Eureka主要适用于通过java实现的分布式系统,但是由于Eureka服务端的服务治理机制提供了完备的RESTful API,所有它也支持将非java语言构建的微服务应用纳入Eureka的服务治理体系中来。

    Ribbon

    Ribbon可以让我们轻松的将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用,它不需要像注册中心、网关那样独立部署,它几乎存在每一springcloud构建的微服务和基础设施当中,微服务之间的调用,API网关的请求转发实际上都是Ribbon实现,包括Feign。

    通过Ribbon的封装,使用客户端负载均衡调用非常简单:

    1)  服务提供者启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心

    2)  服务消费者直接通过调用@LoadBalance注解修饰过的RestTemplate来实现面向服务的接口调用。

    0c5d49793d3c963c1bced891ae9051ff.png

    注:客户端负载均衡和服务端负载均衡的区别?

    服务器端负载均衡:例如Nginx,通过Nginx进行负载均衡,通过维护一个可用的服务端清单,通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户发送请求到负载均衡设备的时候,

    该设备按某种算法(比如线性轮询、按权重负载、按流量负载等)从维护的可用服务清单中取出一台服务端的地址,然后进行转发。

    客户端负载均衡:例如spring cloud中的ribbon,最大的不同点在于上面提到的服务清单所在的位置,在客户端负载均衡中,所有客户端节点都维护着自己要访问的服务端清单,而这个清单来自于服务注册中心。

    同服务端负载均衡的架构类似,在客户端负载均衡中也需要心跳去维护服务端清单的健康性。在发送请求前通过负载均衡算法选择一个服务器,然后进行访问,这是客户端负载均衡;

    展开全文
  • Eureka服务治理

    2021-04-25 21:26:05
    Eureka服务治理服务治理服务治理的概念服务发现的两种方式客户端服务发现服务端服务发现什么是CAP?Eureka实战搭建单机服务注册中心搭建集群服务注册中心Eureka集群架构常用的HttpRest接口 服务治理 服务治理的概念 ...

    服务治理

    服务治理的概念

    1. 服务治理可以说是微服务架构中最为核心和基础的模块,它 主要用来实现各个微服务实例的自动化注册与服务发现
    2. 在传统的系统部署中,服务运行在一个固定的已知的IP和端口上,如果一个服务需要调用另一个服务,那么可以通过地 址直接调用。但是,在虚拟化或者容器化的环境中,服务实 例的启动和销毁是很频繁的,那么服务地址也是在动态变化的。因此,就产生了服务治理的概念。
    3. 如果需要将请求发送到动态变化的服务实例上,至少需要两个步骤:服务注册&服务发现

    服务发现的两种方式

    在这里插入图片描述

    客户端服务发现

    在这里插入图片描述
    优点: 客户端知道所有可用服务的实际网络地址,所以非常方便的实现负载均衡。(比如一致性哈希)
    缺点:耦合性很强。针对不同的语言,每个服务的客户端都得实现一套服务发现的功能。

    服务端服务发现

    在这里插入图片描述
    优点:服务的发现逻辑对客户端是透明的。客户端只需要向load balancer发送请求就可以了。
    缺点:必须要关心该负载均衡组件的高可用性。

    什么是CAP?

    CAP理论指的是一个分布式系统最多只能同时满足一致性(Consistency)、可用性 (Availability)和分区容错性(Partition tolerance)这三项中的两项。
    在这里插入图片描述

    • 一致性指的是数据一致性,一致性指的是所有节点在同一时间的数据完全一致。
    • 可用性指的是服务可用性,可用性指服务一直可用,而且是正常响应时间。,不管什么时候访问,都可以正常的获取数据值。而不会出现问题。好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。
    • 分区容错性指的是在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。

    Eureka实战

    搭建单机服务注册中心

    pom引入相应的包。

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    </dependency>
    

    主启动类添加注解@EnableEurekaServer。

    @EnableEurekaServer
    @SpringBootApplication
    public class EurekaServerApplication {
        public static void main(String[] args) {
            SpringApplication.run(EurekaServerApplication.class, args);
        }
    }
    

    修改application.yml 文件。

    eureka: 
      client: 
      	service-url:
      	  defaultZone: http://localhost:8800/eureka/
        register-with-eureka: false
        fetch-registry: false
    

    搭建集群服务注册中心

    cluster1的配置文件。

    # 同一个集群,应用名称保持一致
    spring:
      application:
        name: eureka-cluster
    
    server:
      port: 8001
    
    # http://cluster1:8001
    eureka:
      instance:
        hostname: cluster1
      # 注册到cluster2:8002里
      client:
        service-url:
          defaultZone: http://cluster2:8002/eureka/  
    

    cluster2的配置文件。

    # 同一个集群,应用名称保持一致
    spring:
      application:
        name: eureka-cluster
    
    server:
      port: 8002
    
    # http://cluster2:8002
    eureka:
      instance:
        hostname: cluster2
      # 注册到cluster1:8001里
      client:
        service-url:
          defaultZone: http://cluster1:8001/eureka/  
    

    Eureka集群架构

    在这里插入图片描述
    在这里插入图片描述

    服务提供者

    • 服务注册
      “服务提供者” 在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server 上,同时带上了自身服务的一些元数据信息。Eureka Server 接收到这个REST请求后,将元数据信息存储在一个双层结构Map中,其中第一层的key是服务名,第二层的key 是具体服务的实例名。
      在服务注册时,需要确认eureka.client.register-with-eureka=true参数是否正确,若为false,将不会启动注册操作。

    • 服务同步
      由于服务注册中心之间为互相注册,当服务提供者发送注册请求到一个服务注册中心时,它会将请求转发给集群中相连的其他注册中心,从而实现注册中心之间的服务同步。通过服务同步,两个服务提供者的服务信息就可以通过这两个服务注册中心中的任意一台获取到。

    • 服务续约
      在注册完服务之后,服务提供者会维护一个心跳用来持续告诉 Eureka Server :“我还活着”,以防止 Eureka Server 的 “剔除任务” 将该服务实例从服务列表中排除出去,我们称该操作为服务续约。

    服务消费者

    • 获取服务列表
      假如到这里,在服务注册中心已经注册了一个服务,并且该服务有两个实例。当我们启动服务消费者时,它会发送一个REST请求给服务注册中心,来获取上面注册的服务清单。为了性能考虑,Eureka Server 会维护一份只读的服务清单来返回给客户端,同时该缓存清单会每隔30秒更新一次。
        获取服务列表是服务消费者的基础,所以要确保 eureka-client-fetch-registery=true 参数没有被修改成false,该值默认为 true。若想修改缓存清单的更新时间,可以通过 eureka-client.registry-fetch-interval-seconds=30 参数来进行修改,该值默认为30,单位为秒。
    • 服务调用
      服务消费者在获取服务清单后,通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息,所以客户端可以根据自己的需要决定具体需要调用的实例,在Ribbon中会默认采用轮询的方式进行调用,从而实现客户端的负载均衡。
    • 服务下线
      在系统运行过程中必然会面临关闭或重启服务的某个实例的情况,在服务关闭期间,我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中,当服务实例进行正常的关闭操作时,它会触发一个服务下线的REST请求给 Eureka Server,告诉服务注册中心:“我要下线了”。服务端在接收到请求之后,将该服务状态设置为下线(DOWN),并把该下线事件传播出去。

    服务注册中心

    • 失效剔除
      当一些外部原因如内存溢出、网络故障等导致服务实例非正常下线,而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除,Eureka Server 在启动的时候会创建一个定时任务,默认每隔一段时间(默认60秒)将当前清单中超时(默认90秒)没有续约的服务剔除出去。
    • 自我保护
      我们在本地调试基于 Eureka 的程序时,基本上都会在服务注册中心的信息面板上出现红色警告信息。
      实际上,该警告就是触发了Eureka Server的自我保护机制。之前介绍过,服务注册到Eureka Server之后,会维护一个心跳连接,告诉Eureka Server 自己还活着。Eureka Server 在运行期间,会统计心跳失败的比例在15分钟之内低于85%,如果出现低于的情况,Eureka Server 会将当前的实例信息保护起来,让这些实例不会过期,尽可能保护这些注册信息。但是,在保护期间内实例若出现问题,那么客户端很容易拿到实际已经不存在的服务实例,会出现调用失败的情况,所以客户端必须要有容错机制,比如可以使用请求重试、断路器等机制。
      由于在本地调试很容易触发注册中心的保护机制,使得注册中心维护的服务实例不那么准确。可以在本地进行开发时,使用 eureka-server.enable-self-preservation=false 参数来关闭保护机制,确保注册中心将不可用的实例正确剔除。

    常用的HttpRest接口

    1. 查看所有服务的注册列表
      GET http://localhost:8800/eureka/apps
      
    2. 查看某一个服务的注册列表
      GET http://localhost:8800/eureka/apps/SERVICE-NAME
      
    3. 服务下线
      PUT http://localhost:8800/eureka/apps/SERVICE-NAME/INSTANCE-NAME/status?value=DOWN
      
    4. 服务恢复
      PUT http://localhost:8800/eureka/apps/SERVICE-NAME/INSTANCE-NAME/status?value=UP
      
    5. 服务剔除
      DELETE http://localhost:8800/eureka/apps/SERVICE-NAME/INSTANCE-NAME
      
    展开全文
  • 服务治理是主要针对分布式服务框架的微服务,处理服务调用之间的关系、服务发布和发现、故障监控与处理,服务的参数配置、服务降级和熔断、服务使用率监控等。 需要服务治理的原因: 过多的服务 URL 配置困难 ...
  • 饿了么的服务治理

    2018-01-31 16:35:22
    饿了么的服务治理 饿了么。服务治理、配置中心、负载均衡
  • 服务治理 Eureka

    2020-08-19 17:35:15
    服务治理 Eureka spring Cloud 实现服务治理是由Netflix公司开发的Eureka。Netflix公司是美国加利福利亚的一家公司,主要业务是在线影片租赁。开发了一套分布式系统组件。Eureka是SpringCloud服务治理中心。 ...
  • 理解服务治理

    千次阅读 2019-01-05 14:19:54
    为什么不是服务管理,而是服务治理? 治理意味着建立和执行工作组为了一起工作而一致同意的工作指南。 治理重在建立决策,而管理重在贯彻执行决策。   怎么理解服务治理服务治理发展过程:开始是单体服务,...
  • 服务治理工具dubbo

    2018-06-26 19:36:39
    服务治理工具dubbo,欢迎学习爱好者下载资源,共同学习。。
  • OCTO-NS是美团OCTO服务治理体系服务注册发现功能的套件, 包括SDK(Java/C++)、本地服务治理代理(SgAgent), 服务缓存(NSC), 云端健康检查(Scanner)等基础组件
  • 服务治理学习

    2018-11-19 17:48:00
    文章:分布式系统中的必备良药 —— 服务治理 文章:什么是服务治理? 转载于:https://www.cnblogs.com/Tpf386/p/9984390.html
  • Spring Cloud Eureka基于Netflix Eureka做了二次封装,是Spring Cloud Netflix微服务套件中的一部分, 负责服务治理功能。服务治理——微服务架构中最核心和基础的模块实现各个微服务实例的自动化注册与发现。静态...
  • 服务治理的简介

    2020-09-01 09:26:15
    一、服务治理需要遵守的原则 (1)高可用性 对于服务治理麾下的所有微服务节点,服务治理要保证它们的服务可用性; (2)分布式调用 微服务的节点通常散落在不同的网络环境中,大型互联网公司甚至会使用跨洲际机房...
  • 谈谈服务治理

    2017-09-15 14:50:36
    本期我们组的技术分享,打算跟大家讲讲服务治理。我在上篇文章中介绍了我们美团.点评北京总部用的OCTO框架,其实在上海点评部门用的是另一套Pigeon。这两套框架都很重。这是和我们的业务有关的,其实服务治理这个...
  • 微服务-服务治理

    2021-03-12 16:23:00
    1. 服务治理的需求 当具备服务注册中心后,服务治理设计的角色有以下三中: 注册中心:提供服务注册和发现; 服务提供者:服务提供者将自身服务注册到注册中心,从而使服务消费者能够找到; 服务消费者:服务消费者...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,725
精华内容 5,490
关键字:

服务治理