我们是如何建设5个9的服务化网关
核心基础设施部约 6 分钟作者：neal曹威
LApiGateway简介
LApiGateway是货拉拉内部的微服务网关，负责流量转发，并为研发提供诸如鉴权，限流，参数修改，参数校验等一系列功能，以此帮助研发提升开发效率。
LApiGateway的架构
LApi控制面主要包括：
服务配置，由LApi管理平台和Apollo配置中心组成，用户能够通过LApi管理平台修改服务的配置
服务发现，LApi通过Consul获取后端服务的节点注册信息，比如节点的IP地址，分组标识，灰度版本等
监控，主要由Trace服务和HLL Monitor两大组件构成，能够进行请求监控和错误告警
LApi数据面，请求经过入口处的负载均衡（KONG、SLB）到达LApi节点，在LApi内部经过一系列的插件处理后，被转发到下游服务节点。
LApi同时提供一些依赖第三方服务的插件，比如账号鉴权插件依赖账号服务，SSO鉴权插件依赖SSO服务。
目前在数据处理过程中，LApi可能会依赖以下组件的处理结果：
账号服务，负责用户账号鉴权
Kafka，负责保存请求产生的消息数据
Lone，负责发布窗口和服务权限管理等
SSO服务，负责员工账号鉴权
LApiGateway SLA定义
在阐述具体保障方案之前，我们需要先了解LApi关于SLA的定义:
名词解释：
“可用性百分比” 是指在一个可用性计算周期内，代理服务请求的成功率，即排除掉因lapi本身导致的请求失败
“代理服务”是指接入到lapi的后端服务
“可用性计算周期” 5min计算一次
“可用性计算周期数” 即一年内所包含的可用性计算周期数量：365 * 24 * 12 = 105120
因此SLA达成5个9，则意味着LApi全年的完全不可用时间（即请求的成功率为0）必须小于5min。
我们面临哪些挑战以及对应的解决方案
通常来讲，我们可以对系统面临的稳定性风险，做以下两个分类：
外部风险，比如ECS实例宕机，网络抖动，异常流量攻击等，属于不可控因素，无法事前防御，需要通过快速恢复的手段来提升可用性计算周期内的请求成功率
自身风险，比如代码bug，第三方组件异常等，需要结合多种手段进行针对性防御
外部风险
外部风险不可完全避免，因此我们的思路就是当发生不可控的外部风险时，尽量缩短系统的不可用时间。
单节点故障
当集群内的节点出现故障（网络不可达，机器宕机等），我们通过心跳检查机制自动剔除故障节点，从而提高了请求的成功率。
目前Lapi节点的心跳检查分为两种：
KONG TCP连接心跳检查，可以在9s左右剔除故障节点
Consul心跳检查，可以在6s左右剔除故障节点注册信息
因此当LApi节点发生故障时，以一个4节点规模的集群为例，对比不采用心跳检查，5min内的可用性百分比从75%提升至 99.25%（KONG转发流量）和99.50%（SOA流量）。
目前LApi部署在阿里云ECS实例上，ECS单实例SLA为：99.975%，因此全年累计的不可用分钟数为131.4，仍然以4节点的集群为例（LApi的最小集群规模），并假设ECS不可用时间刚好分布在每个LApi可用性计算周期内，因此LApi的SLA可以做如下推算：
1、KONG流量
2、SOA流量
通过以上计算可以看出来，4节点的LApi集群，通过心跳检查的机制能够在ECS实例故障时，保障LApi集群的5个9的高可用性。
同时当集群规模变大时，单实例对SLA的负面影响会更小。
因此设置一个合理的健康检查时间能有效提高请求的成功率。
集群故障
集群故障指的是集群内部有超过一半的节点出现宕机或者网络故障，此时单纯依靠剔除故障节点，反而会加速整个集群的负载上升从而导致请求成功率快速降低至0。
目前对于集群故障的出现概率并没有比较权威的研究，反而更依赖于现实世界的事故对工程师的造成的直觉刺激。经过最近两年的国内各种云上事故，这样的故障率显然远远谈不上万中无一。
而要达成五个九，显然不能允许有超过一个可用性计算周期的请求成功率为0。
因此故障集群流量迁移的目标就是在极短的时间内将流量迁移到正常集群，从而保证5个9的SLA。
流量迁移要点：
故障发现，通过LApi管理平台为每个集群维护一个集群规模配置，同时基于consul的服务注册信息，则可以快速探测当前的集群节点数量是否已经低于预警值（总数的一半）
流量迁移
指定容量有富余的多个集群，组成容灾集群分组
当收到告警时，通过lplan平台将流量迁移到容灾集群分组
相比于不可控的等待云商故障恢复，我们能够在2到3min内完成流量迁移。
下一步我们会继续推进完全自动化的流量迁移，预计能将故障恢复时间缩短到30s以内。
自身风险
我们通过以下三个手段来规避自身风险带来的稳定性隐患：
异常case防护
对于一款自研的api网关产品而言，造成请求处理失败的情况是多种多样的，下面将从系统层面，应用层面和第三方组件层面罗列可能得异常case，以及对应的解决方案。
变更规范
作为一款仍在持续迭代的产品，严格遵守变更规范能够有效的降低线上风险。
LApi的变更分为两类:
LApi代码变更：代码review -> 回归测试验证 -> 测试环境发布验证一周 -> prd多集群灰度一个节点验证一周 -> 全量发布
线上灰度验证期间，除了观测是否有请求错误，还需要观测节点负载是否符合预期
服务接入变更
新服务接入，需在测试环境完成验证，再接入prd
老服务接入，需在测试环境完成接口回归测试，prd环境通过KONG切流插件进行灰度放量验证
日常运维
日常运维是保持关注服务健康状态最直接最重要的手段，因此除了关注常规的每日巡检面板之外，还需要关注研发对自己服务配置的变更。
通过LApi管理平台的路由变更通知，我们能够及时获知，研发在变更日变更了那些服务的配置，涉及到哪些LApi集群，在隔日就需要对这些集群做特别的观测，以比对变更前和变更后，系统负载的变化，如果变化超出预期，则需要找到原因。
LApiGateway故障演练
通过对系统可能存在的风险进行定期演练，既能起到系统防腐的效果，又能帮助我们提前发现潜在的问题。
以下是我们过往的演练记录：
对应的演练报告：
结语
通过对稳定性建设的持续投入，在LApiGateway上线的两年多时间里，我们成功达成了5个9的高可用性指标。然而，我们深知稳定性建设是一个持续不断的过程，未来我们将继续致力于优化和改进，以确保我们的平台始终保持在最高水准，为用户提供高可靠的服务体验。