第四章:服务治理

Posted 魔都码农

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第四章:服务治理相关的知识,希望对你有一定的参考价值。

服务治理

服务发现

最早的服务发现是通过DNS完成的,通过域名访问,访问者不关心主机IP端口和数量,DNS适合在单体中,且变化不频繁的场景中使用。

  • 服务发现是指使用注册中心来记录分布式系统中全部服务信息,以便让其他服务能快速找到已注册的服务,从服务配置的角度实现应用无状态。服务化需具备高可用,可自愈,服务注册,服务查找,服务监控检查,服务变更通知(服务下线时通知)等功能。
    • 服务提供者启动时,将服务名称IP地址端口以及其他的元数据服务信息注册到注册中心。
    • 注册中心于服务提供者无法维持心跳时则将服务从注册中心剔除。
    • 服务消费者从服务注册中心获取最新信息时通过通知推送或主动拉取完成。

主流注册中心

  • 铁律:注册中心不能因为自身的任何原因而破坏服务之间的连通性。注册中心各个节点的数据只需要满足最终一致性即可,流量最终达到统计学意义上的一致。属于AP要求。

zk

zk节点分临时节点持久化节点,顺序和非顺序。服务提供者将服务信息写入zk到临时节点。当服务X宕机时,服务X与zk的会话超时则服务X会失效,服务消费方通过watcher机制感知下下,并从服务列表踢除。

  • 并非注册中心最佳方案,其偏中心化,写入只能通过主节点完成,导致了无法通过添加节点水平扩展写的能力。优势在于选举机制,协调机制和分布式锁等一致性场景。

eureka

  • 去中心化:erureka中没有主节点,整个集群服务由对等节点组成。
  • 失效转移:某个节点失效不会影响服务的注册和查询,会切换至其他节点,只要有一台节点能正常工作,就无需担心可用性。保证了可用性,缺失一致性,最终会达成一致性,符合统计学的一致性。
  • 租约且互联,客户端与服务端存在租约时间,且客户端随机链接某一台,从长远看并不影响服务的整体使用情况。服务端是相互联通的,各个服务端会相互同步数据。

consul

  • 功能强大:不仅有注册中心的功能,还提供了内存磁盘等细粒度的服务状态检查功能,以及用于服务配置的建值对存储功能,支持多数据中心,一个数据中心可以理解为一套zk集群,多个数据中心可以做数据同步,可以通过本地数据中心远程数据中心,这种多数据中心同步概念上类似eureka。

负载均衡

  • 本质:通过合理的算法将服务分摊到多个服务节点。

分类

服务端负载

  • 优势:业务代码侵入,无感知
  • 劣势:负载均衡器为系统瓶颈,存在二次转发传输效率变慢
  • 使用场景:前后端交互,服务与数据库交互等偏静态场景(地址变化不大场景)
  • 服务端负载
    • 1:硬负载:基于硬件完成,如F5,A10
    • 2:软负载:LVS,NG

四层负载均衡(F5,LVS)

  • 四层负载讲的是OSI七层模型中处于传输层,基于IP+port,通过修改报文中的目标地址和端口,将请求转发至真实服务端。负载均衡器收到第一个SYN请求后,通过负载均衡算法选择合适的服务器,然后将报文的IP地址修改为真实服务器的IP地址,并将请求转发至服务端,TCP通过三次握手建立的链接是客户端与真实的服务端。负载均衡器做了路由转发功能。

七层负载均衡(NG)

  • 七层负载讲的是OSI七层中的应用层,七层负载通过解析报文中应用层的内容,将请求转发至合适的应用服务器。客户端与代理完成TCP链接,代理解析客户端应用层报文,根据应用层报文选择合适服务器。比如根据区域选择不同的机房链接。
  • 四层与七层的区别与是否创建了两次TCP链接,七层有中间代理过程,四层没有代理直接转发。

客户端负载均衡(dubbo,feign)

客户端拿到一堆list,自己选择合适的服务器发起调用。

  • 优势:
    • 1:无需额外负载均衡器且无二次网络转发
    • 2:客户端与服务端直连,绕过了中心化的代理节点,无需考虑代理节点高可用。
  • 劣势:负载均衡算法和服务发现能力需要自行控制。
  • 使用场景:服务与服务之间
  • 算法:
    • 1:最小并发数
    • 2:权重(固定与动态(成功率))
    • 3:随机 加权随机(加权一般做法是map转list,权重为2则list中放两个即可)
    • 4:轮训 加权轮训
    • 5:hash

限流

限流属于事前行为,保护自己不被打垮。

  • 客户端限流:避免自己调下游太频繁,避免被下游拖死
  • 服务端限流:避免上游对自己访问频繁,把自己打垮。
  • 接入端限流:客户端,服务端都是针对某个接口实例,接入层是从最原头开始限流。保证进来的用户整个流程都可以走完。而不是走到下单结算被限流住了。通常基于F5 NG 在前面挡住一部分流量,
  • 常用算法
    • 计数器:一秒只能访问几次,通过过期时间加自增计数完成,可能形成突刺(在10ms前已达到固定次数,后面990ms无流量处理)。
    • 漏桶:接收外部流量,队列缓存,按一定速率处理队列请求,一边放,一边取,流量整形。hystrix的线程池就类似漏桶的思路。
    • 令牌桶:设定令牌数,拿到令牌则可以执行,主要用于控制最大并发数,如:最大允许并发10。guava里有现成的基于令牌桶的限流实现。

熔断

熔断属于事后行为,当自己扛不住的时候不能拖垮别人,防止连锁失效。

  • 熔断状态
  • 1:关闭:应用程序对请求无需任何干涉,只是记录调用失败阀值
  • 2:开启:请求会直接返回错误响应,不做任何业务逻辑操作。
  • 3:半开:容许少量请求过来,用来自愈,观察程序是否自动恢复和留给开发人员看日志排查问题。


以上是关于第四章:服务治理的主要内容,如果未能解决你的问题,请参考以下文章

对于服务治理概念的一些总结和理解,我们应该如何实践服务治理

对于服务治理概念的一些总结和理解,我们应该如何实践服务治理

关于服务治理的一点理解

SpringCloud:如何使用Eureka进行服务治理?

【知识总结】4.微服务的治理去中心化,服务发现,安全,部署

.NETCore微服务之:基于Consul实现服务治理