如何从0-1的建设云上稳定性？

一、系统架构

整个系统包含了私有云和公有云两个节点。前端和服务端存在私有云和公有云两套系统交互，公有云上的系统为三方黑盒系统。

带着上面的五点风险和挑战，我们从前后端的视角整体制定优化策略和方案。

二、前端策略

作为钉钉的合作产品，必然也是需要保障钉钉的体验的，这就涉及到如何将三方前端子页面进行一方化了，我们考虑了以下几套方案。

基于稳定性优先的原则，为了能够使得三方预订页面具备可监控、可灰度、可回滚的能力，我们采用方案二：前端微应用的方式进行接入。

2.1 微前端架构

在微前端的架构下，我们将三方前端子应用的打包资源地址配置到钉钉合作域名应用下，当用户访问n.dingtalk的域名链接时就会走到云上系统，进而访问三方前端打包资源，这样的话预订子应用就具备了一方应用的基础能力。

2.2 微前端效果

域名统一化：可以通过DBase平台进行灰度放量，保障可灰度、可回滚的基础能力。
隔离性：三方H5页面资源部署在公有云的独立环境中运行，避免其CSS或JS影响到主应用。
异常监控：接入Arms监控，建立异常监控机制，可以快速定位和解决接入过程中可能出现的问题，进而实现前端页面的error监控。
版本控制：第三方H5的更新应与主应用保持良好的版本控制，避免因版本不一致带来的问题，通过版本化的构建也可以更好的做到回滚管控。
Jsapi调用：域名统一化后，可以使得三方预订子页面丝滑调用钉钉的Jsapi。

三、服务端策略

稳定性的容量预估也是遵循木桶理论的，构成整个系统的各个模块都有各自的系统吞吐量，而系统最低的那块木板，很可能就是整个系统的最终吞吐量。我们需要基于线上事件来真实评估最薄弱的一环，通过各模块各节点的完整评估，我们决定从四个方向（发布前管控、发布中可用、发布后保障、机制&人员保障）挑选最重要的TOP事项快速落地，进而快速提升整个系统的稳定性。

节点	事项
发布前管控	三方系分标准规范化。三方发布变更强管控。
发布中可用	云上系统发布过程中系统100%可用。
发布后保障	云上系统监控100%覆盖。三方页面白屏感知，自动化UI测试100%覆盖。核心链路异常降级&预案演练。多方系统数据一致性保障。
机制&人员保障	早值班机制稳定性周会机制保障机制

3.1 发布前管控

3.1.1 部署方案

我们采用公有云上的CI/CD能力，通过云效平台搭建了一套构建部署的解决方案。

创建存储Bucket：创建一个OSS bucket用来存储部署物。
上传部署物：将本地构建出的部署物（比如jar包、war包等）上传到指定的OSS bucket，构建出的部署物文件名称尽可能体现出部署物版本（比如加上版本号、代码分支信息、commit id等）。
部署流水线：设定发布审批人，可以选择或签、会签。整个审批环节包含，测试、产品、主管三个审批节点，保障发布环节可控流程化。
部署物下载：在云效里创建一条发布流水线，将源代码编译的环节替换为从OSS下载构建部署物（JAR、WAR等）。
ECS分组部署：可以在ECS分组部署阶段添加部署脚本、分组、部署方式等信息。
钉钉部署通知：部署完成后通过调用云效流水线的web hook自动触发部署结果通知。

3.1.2 关键节点

通过云效的流水线能力，将整个系统的发布在线化，关键KP审核，将发布流程强管控，杜绝随意变更引起的稳定性问题。

权限隔离

三方同学可运行线上流水线，仅运行权限，不可编辑。

KP审批

增加产品审批环节；
增加测试验收环节；
增加技术负责人审批环节；

流水线部署

可回滚
可监控
钉钉群通知

3.2 发布中可用

云上系统存在发布过程中的不可用问题，比如系统在发布过程中，会导致用户以及服务商的系统页面不可用，是最为急迫解决的问题。

服务商视角

客户视角

目前的部署阶段不可用问题是由于nginx不具备高可用能力引起的，云上系统的后端服务器是采用轮询方式来进行通信的，在发布阶段由于轮询到部署机器导致系统异常。所以根本原因在于nginx不具备健康检查的能力，导致系统发布阶段的不可用问题。

server {        location / {            proxy_set_header Host $host;            proxy_set_header   X-Real-IP        $remote_addr;            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;            proxy_set_header X-Forwarded-Proto $scheme;            proxy_pass http://proxy-pro;  // `proxy_pass` 用于指定一个反向代理的后端服务器        }}
// 对于location指定的后端服务器配置，nginx的默认配置，默认为轮询通信。upstream api-pro{        server xxx.xx.xx.x:001;}

3.2.1 解决方案

在看清楚问题背后的原因后，理论上是有以下两种解决方案的。

基于扩展性及系统高可用的考虑，决定采用方案二。

3.2.2 关键节点

步骤一：SLB转发

首先需要做SLB层的域名路由转发，需要调整SLB层的监听配置：

Before

After

After：HTTP请求之所以强制转发到HTTPS，原因是期望用户侧的访问都通过HTTPS的方式进行访问，安全性更高一些。

基于SLB的转发策略，对于云上系统进行分发配置，如下：

域名	路径	端口	服务器
A-test.com	/	10201	192.168.1.1
B-test.com	/	10204	192.168.1.2
C-test.com	/	10202	192.168.1.3

域名路径转发逻辑，如下图所示：

方式一：前端请求中存在域名，则根据域名匹配转发策略。

存在匹配该域名的转发策略，则继续匹配URL路径部分。若URL路径部分也能匹配，则将请求转发至对应的虚拟服务器组；若URL路径部分未能命中该域名下的任何规则，则将请求转发给域名根路径转发策略（转发策略中只配置了域名，没有配置URL路径）。

当用户没有为该域名配置根路径转发策略时，将向客户端返回404错误。
不存在匹配该域名的转发策略，则按照方式二匹配转发策略。

方式二：前端请求中不存在域名或者转发策略中不存在与之相匹配的域名，则直接匹配无域名转发策略（转发策略中只配置了URL，没有配置域名）。

成功匹配到转发策略时，将请求转发至对应的虚拟服务器组；未能匹配到任何转发策略时，将请求转发至此监听配置的服务器组。

步骤二：健康检查

目前SLB转发为后端服务器后，可以配置健康检查策略，如下：

健康检查配置

健康检查方式

目前通过HTTP HEAD请求的方式进行健康检查。
curl -Iv -X HEAD http://192.168.1.1:101/
后端服务器组必须在同一个VPC内才可做健康检查。

七层集群中的服务器根据监听的健康检查配置，向后端服务器的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求（包含设置的【域名】）。
后端服务器收到请求后，根据相应服务的运行情况，返回HTTP状态码。
如果在【响应超时时间】之内，七层集群中的服务器没有收到后端服务器返回的信息，则认为服务无响应，判定健康检查失败。
如果在【响应超时时间】之内，七层集群中的服务器成功接收到后端服务器返回的信息，则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功，反之则判定健康检查失败。

3.2.3 治理效果

基于super后台做了一轮测试验证，结果符合预期。

Before

通过nginx进行路由且无健康检查时，部署过程中会有页面访问失败的情况。

After

部署过程中可以根据健康检查情况路由分发流量，保障部署阶段的可用性。

3.3 发布后保障

3.3.1 云上核心监控

大盘监控

ECS机器监控大盘

数据库监控大盘

钉钉群监控报警：

3.3.2 数据离线核对

由于平台涉及到和三方的数据流入流出，如果数据不一致会导致用户月度结算、购票等链路的使用及体验问题，所以我们建立了和三方的对账能力，通过该基础能力可以在T+1的时效内发现三方的系统问题，进而规避系统风险。

向各个服务商提供sFTP服务器账户密码，分配不同的文件bucket。
服务商定时上传对账文件到oss文件服务器。
ODPS创建明细对账表、总账对账表。
ODPS上针对各个服务商单独创建同步任务，从oss服务器同步文件数据至对应的离线表。
通过MAC核对平台，针对各个服务商部署单独的核对任务。

3.3.3 UI自动化测试

平台接入了10余家专业的行业头部ISV，这更加剧了平台可用性的隐患，在三方页面不可用的情况下，便会导致用户投诉反馈。

基础监控

在梳理了核心场景之后，我们通过UI自动化测试每天定时扫描三方页面的可用性，通过断言的方式发现核对三方页面的有效性。

def test_Platform_model_trip_business_travel_ticket_booking(self):        # 轮询是否有判断页面是否加载完成        mobile.loop_exist_pic("xx_xxx",subfolder="smart_pic/platform_mode/isv")        # 点击选择第一个票务        x = mobile.get_screenshot_resolution()[0] / 2.0 / mobile.get_scale()        y = mobile.get_screenshot_resolution()[1] / 5.0 * 2 / mobile.get_scale()        mobile.get_driver().click(x, y)        #  断言查询是否有预定按钮，否则就提示服务商没有可预订的订单        assert mobile.loop_exist_text('预订')[0], '服务商没有可预订的订单'

当预期的断言失败后就会推送到群内报警，并可以通过详情查看到具体的异常页面，如下所示：

针对异常的case，可以通过查看详情明确具体的异常节点，对于快速定位问题很有帮助。

3.4 机制保障

早值班机制：每天钉钉和三方生态伙伴同学需要发早值班日志，针对发现的问题在排期优化解决。
稳定性周会机制：通过稳定性周会的方式同步风险和治理进展。
人员地图：建立每个服务商的系统保障人员地图，发现线上非预期问题，可以快速联系到相关同学及时解决，保障1分钟发现、5分钟定位、10分钟恢复。

四、治理成果

总体来说合作产品模式遇到了以下几个风险和挑战：

方案无感知：纯黑盒模式下对系统细节感知弱，变更风险高。
无发布管控：云上系统部署不可控，三方部署内容感知弱、部署频率不可控。
无灰度能力：云上系统部署无灰度能力，部署即全量。
无监控能力：云上系统监控感知弱，三方日志规范不标准，监控成本高。
安稳意识弱：三方人员安稳意识薄弱，三方故障等于钉钉故障。

整个治理过程，沉淀了通用的公有云CI/CD能力，实现了公有云发布三板斧的能力建设，并建立了平台持续、稳定、可靠的稳定性保障机制。

完善公有云发布管控能力：建立完整的云上系统CI/CD能力，保障无任何由于线上变更操作失误导致的线上问题。
建立发布三板斧基础能力：具备可灰度、可回滚、可监控的基础能力。在一个月的治理过程中，通过系统监控、UI自动化测试提前发现并规避了6起线上问题，通过离线核对发现并解决服务商及平台系统8例缺陷。
优化高可用的运维能力：通过负载均衡健康检查路由的方案解决三方系统发布过程中，由于流量切换导致部分请求不可用的问题，治理完成后无任何由于部署过程导致用户体验中断或完全不可用的问题。
建立稳定性保障机制：建立同三方的稳定性周会、早值班等机制，通过阶段性的宣讲和总结提升三方同学对于共建系统的稳定性意识。