hello，咱们好呀，我是小楼。
前段时刻不是在忙么，忙的内容之一就是花了点时刻重构了一个服务的健康查看组件，现在现已渐渐在灰度线上，本文就来共享下这次重构之旅，也算作个总结吧。
布景
服务健康查看简介
服务健康查看是应对分布式运用下某些服务节点不健康问题的一种解法。如下图，顾客调用提供方集群，通常经过注册中心获取提供方的地址，依据负载均衡算法选取某台具体机器建议调用。
假定某台机器意外宕机，服务消费方不能感知，就会导致流量有损，假如此刻有一种检测服务节点健康状况并及时除掉的机制，就能大大添加线上服务的稳定性。
原服务健康查看完结原理
咱们是自研的注册中心，健康查看也算注册中心的一部分，其原理很简略，可分为三个阶段：
- 从注册中心获取需求探活的实例（ip、port）
- 对每个地址进行端口检测，也就是对 ip + port 建议 TCP 建链请求，建链成功视为健康
- 对断定为不健康的实例进行去除，对原断定不健康现在健康的实例进行恢复，去除恢复经过调用注册中心提供的接口完结
当然这是大致流程，还有不少细节，例如获取探活实例时一些不需求探活的服务会被排除（如一些基础服务如MySQL、Redis）；为了避免网络抖动导致健康状况的断定有误，会添加一些断定策略，如接连 N 次建连失利视为不健康；对不健康实例去除时也计算了去除阈值，如一个集群的机器都被断定为不健康，那也不能把它们全摘了，因为此刻全摘和不摘差别不大（请求都会报错），乃至全摘还要承担风险，考虑集群容量问题，能够设个阈值，如最多只能摘三分之一的机器。
原服务健康查看存在的问题
1. 容量问题
原组件物理机年代的产物，其时实例数量并不多，所以开始是单机规划，只布置在一台物理机上，跟着公司事务开展，实例数量增多，单机到达瓶颈，所以做了一次升级，经过装备文件来指定每个节点的健康查看使命分片。
2. 容灾问题
单机就必定存在宕机风险，即使查看使命现已做了分片，但是写在装备中，无法动态调配，当某个节点宕机，则它担任的实例健康查看就会失效。
3.布置功率问题
布置在物理机且分片是写在装备中，无论是扩容仍是机器过保置换，都要修正装备，人为操作功率太低，并且简略犯错。
4. 新需求支持功率问题
跟着云原生年代的迈进，对健康查看提出了一些新的需求，例如只探端口的联通性或许不能代表服务的健康程度，乃至公司内还有一些其他服务也想复用这个健康查看组件的能力，日益增长的需求同原组件紊乱的代码之间存在着不可调和的矛盾。
5. 迭代过程中的稳定性问题
原组件没有灰度机制，开发了新功能上线是一把梭，假如出问题，就是个大毛病，影响面十分广。
需求处理这么多问题，假如在原基础上改，稳定性和功率都十分令人头疼，所以一个念头油然而生：重构！
技能计划调研
业界常见服务健康查看计划
在规划新计划前，咱们看看业界关于健康查看都是怎样做的，从两个视点打开调研，注册中心的健康查看和非注册中心的健康查看
注册中心健康查看
| 计划 | 代表产品 | 长处 | 缺点 |
|---|---|---|---|
| SDK 心跳上报 | Nacos 1.x 临时实例 | 处理心跳耗费资源过多 | |
| SDK 长衔接 + 心跳坚持 | Nacox 2.x 临时实例、SofaRegistry、Zookeeper | 感知快 | SDK 完结复杂 |
| 集中式主动健康查看 | Nacos 永久实例 | 无需SDK参与，可完结语义探活 | 集中式压力大时，时延增大 |
非注册中心健康查看
K8S 健康查看 — LivenessProbe
与集中式健康查看做对比
| LivenessProbe | 原健康查看组件 | |
|---|---|---|
| 完结方法 | k8s原生，分布式（sidecar形式） | 自研，集中式 |
| 查看建议者 | kubelet，与事务容器在同一物理机 | 集中布置的服务 |
| 适用范围 | k8s容器（弹性云） | 容器、物理机、虚拟机等 |
| 支持的查看方法 | tcp、http、exec、grpc | tcp、http |
| 探活基本装备 | 容器发动延时探活时刻、探活间隔时刻、探活超时时刻、最小接连成功数、最小接连失利数 | 探活超时时刻、接连失利次数、最大去除份额 |
| 检测不健康时动作 | 杀死容器，容器再依据重启策略决定是否重启 | 从注册中心上去除 |
| 兜底 | 无 | 有，可配去除份额 |
结合公司布景进行选型
咱们的大布景是技能栈不一致，编程言语有 Java、Go、PHP、C++等，依据成本考虑，咱们更倾向瘦SDK的计划。
所以注册中心常见的 SDK 长衔接+心跳坚持计划被排除，SDK主动上报心跳也不考虑。
而 K8S 的健康查看计划只是运用于 K8S 体系，咱们还有物理机，并且 K8S 的 LivenessProbe 并不能做到开箱即用，至少咱们不想让节点不健康时被杀死，兜底策略也需求从头开发。
所以最终咱们仍是挑选了与原健康查看组件相同的计划 — 集中式主动健康查看。
抱负态
依据原健康查看组件在运用中的种种问题，咱们总结出一个好的健康查看组件该有的姿态：
- 毛病主动转移
- 可水平扩容
- 快速支持丰厚灵敏的需求
- 新需求迭代，自身的稳定性需求有确保
规划开发
总体规划
组件由四大模块组成：
- Dispatcher：担任从数据源获取数据，生成并派发使命
- Prober：担任健康查看使命的履行
- Decider：依据健康查看成果决议计划是否需求变更健康状况
- Performer：依据决议计划成果履行相应动作
各模块对外暴露接口，躲藏内部完结。数据源面向接口编程，可替换。
服务发现模型
在具体介绍各个模块的规划之前，先简略介绍一下咱们的服务发现模型，有助于后续的表述和了解。
一个服务名在公司内是唯一的，调用时需指定服务名，获取对应的地址。
一个服务又能够包含多个集群，集群可所以物理上的阻隔集群，也可所以逻辑上的阻隔集群，集群下再包含地址。
协程模型规划
编程言语咱们挑选的是 Go，原因有二：第一是健康查看这种 IO 密集型使命与 Go 的协程调度比较符合，开发速度，资源占用都还能够；第二是咱们组一直用 Go，经验丰厚，所以言语挑选咱们没有太多的考虑。
但在协程模型的规划上，咱们做了一些考虑。
数据源的获取，因为服务、集群信息不经常改变，所以缓存在内存中，每分钟进行一次同步，地址数据需求实时拉取。
Dispatcher 先获取一切的服务，然后依据服务获取集群，到这儿都是在一个协程内完结，接下来获取地址有网络开支，所以开 N 个协程，每个协程担任一部分集群地址，每个地址都生成一个单独的使命，派发给 Prober。
Prober 担任健康查看，完全是 IO 操作，内部用一个行列存放派发来的使命，然后开许多协程从行列中取使命去做健康查看，查看完结后将成果交给 Decider 做决议计划。
Decider 决议计划时比较重要的是需求算出是否会被兜底，这儿有两点需求考虑：
一是开始获取的实例状况或许不是最新了，需求从头获取一次；
二是关于同一个集群不能并发地去决议计划，决议计划应该串行才不会导致决议计划紊乱，举个反例，假如一个集群3台机器，最多去除1台，假如2台同时挂掉，并发决议计划时，2个协程各自认为能摘，最终成果是去除了2台，和预期只摘1台不符。这个怎么处理？咱们最终搞了 N 个行列存放健康查看成果，按服务+集群的哈希值路由到行列，确保每个集群的检测成果都路由到同一个行列，再开 N 个协程，每个协程消费一个行列，这样就做到了次序履行。
决议计划之后的动作履行就是调用更新接口，所以直接共用决议计划的协程。用一张大图来总结：
水平扩容 & 毛病主动转移
水平扩容与毛病主动转移只要能做到动态地数据分片即可，每个健康查看组件在发动时将自己注册到一个中心的和谐器（可所以 etcd），并且监听其他节点的在线状况，派发使命时，按服务名哈希，判别该使命是否应该由自己调度，是则履行，不然丢弃。
当某个节点挂掉或许扩容时，每个节点都能感知到其时集群的改变，主动进行数据分片的从头区分。
小流量机制
小流量的完结采纳布置两个集群的方法，一个正常集群，一个小流量集群，小流量集群担任部分不重要的服务，作为灰度，正常集群担任其他服务的健康查看使命。
只需求同享一个小流量的装备即可，咱们按安排、服务、集群、环境等维度去规划这个装备，基本能够任意粒度装备。
可扩展性
可扩展性也是规划里十分重要的一环，可从数据源、查看方法扩展、过滤器等方面略微一些。
数据源可插拔
面向接口编程，咱们将数据源笼统为读数据源与写数据源，只要符合这两个接口的数据源，就能无缝对接。
查看方法易扩展
健康查看其实就是给定一个地址，再加一堆装备去进行查看，至于怎样查看能够自己完结，现在已完结的有TCP、HTTP方法，未来还或许会完结诸如Dubbo、gRPC、thrift等的语义级别的查看方法。
过滤器
在派发使命时，有一个或许会随时修正的逻辑是过滤掉一些不需求探活的服务、集群、实例，这块用职责链的形式就能很好地完结，后期想增删就只需求插拔链中的一环即可。
可扩展性是代码层面的内容，所以这儿只列举了部分比较典型的比如。
灰度上线
因为咱们是重写了一个组件来替代原组件，所以上线还挺费事，为此咱们做了2方面的作业：
- 规划了一个可按安排、服务、集群、环境等维度的降级开关，降级分为3档，不降级、半降级、全降级。不降级很好了解，就是啥也不做，全降级就是不作业，相当于一键关停健康查看组件，半降级是只恢复健康但不去除的一个作业形式。试想假如健康查看在上线过程中，误去除，此刻降级，岂不是无法恢复健康？所以咱们让它保存恢复能力。
- 咱们使用上述的小流量规划来逐步将服务迁移到新组件上来，灰度的服务新组件担任，非灰度的服务老组件担任，等悉数灰度完结，停掉老组件，新组件的灰度集群再切换为正常集群。
踩坑调优
在灰度过程中，咱们发现了一个问题，有的一个集群机器十分多，超过了1000台，而咱们的决议计划是次序履行，并且决议计划时还会去实时查询实例状况，假定每次查询10ms（现已很快了），1000台次序决议计划完也得10s，咱们期望每轮的检测要在3秒左右完结，光这一个集群就得10秒，显然不能承受。
为了咱们做了第一次的优化：
咱们其时在线上环境测验，一个集群有2000多台机器，但大部分机器是禁用的状况，也就是这部分机器其实做健康查看是个无用功，禁用的机器，无论是否健康都不会被消费，所以咱们的第一个优化就是在派发使命时过滤掉禁用的机器，这样就处理了线下环境的问题。
但咱们上到出产环境时依然发现决议计划很慢，线上一个集群只要少数的机器被禁用，第一次的优化基本就没什么作用了，并且线上机器数量或许更多，使命堆积会很严重，咱们发现其他的行列或许比较空闲，只要大集群所在的行列很忙。
所以咱们进行了第二次优化：
从事务视角动身，其实需求次序决议计划的只要不健康的实例，关于健康的实例决议计划时不需求考虑兜底，所以咱们将按查看成果进行分类，健康的查看成果随机派发到任意行列处理，不健康的查看成果严厉按服务+集群路由到特定行列处理，这样既确保了兜底决议计划时的次序，也处理了行列负载不均衡的状况。
总结
本文从健康查看的布景，原组件存在的问题，以及咱们的抱负态动身，调研了业界的计划，结合实际情况，挑选了合适的计划，并总结之前体系的问题，规划一个愈加合理的新体系，从开发闭环到上线。
我觉得体系规划是一个取舍的过程，他人的计划不见得是最优的，合适的才是最好的，并且有时并不是纯技能处理问题，或许从事务视点去考虑，或许愈加豁然开朗。
引荐阅览
与本文相关的文章也趁便引荐给你，假如觉得还不错，记得重视、点赞、在看
- 《怎么给注册中心锦上添花？》
- 《怎么组装一个注册中心？》
- 《服务探活的五种方法》
- 《4个试验，彻底搞懂TCP衔接的断开》
- 搜索重视微信公众号”捉虫大师”，后端技能共享，架构规划、功能优化、源码阅览、问题排查、踩坑实践。
- 本文正在参与「金石计划 . 瓜分6万现金大奖」
