如何从0-1的建设云上稳定性?
阿里妹导读
本文将从前后端的视角整体看下我们在云上稳定性治理的一些路径和经验。首先从平台的系统架构模型出发,站在全局视角看下整个平台的风险。
一、系统架构
二、前端策略
2.1 微前端架构
2.2 微前端效果
域名统一化:可以通过DBase平台进行灰度放量,保障可灰度、可回滚的基础能力。 隔离性:三方H5页面资源部署在公有云的独立环境中运行,避免其CSS或JS影响到主应用。 异常监控:接入Arms监控,建立异常监控机制,可以快速定位和解决接入过程中可能出现的问题,进而实现前端页面的error监控。 版本控制:第三方H5的更新应与主应用保持良好的版本控制,避免因版本不一致带来的问题,通过版本化的构建也可以更好的做到回滚管控。 Jsapi调用:域名统一化后,可以使得三方预订子页面丝滑调用钉钉的Jsapi。
三、服务端策略
3.1 发布前管控
3.1.1 部署方案
创建存储Bucket:创建一个OSS bucket用来存储部署物。 上传部署物:将本地构建出的部署物(比如jar包、war包等)上传到指定的OSS bucket,构建出的部署物文件名称尽可能体现出部署物版本(比如加上版本号、代码分支信息、commit id等)。 部署流水线:设定发布审批人,可以选择或签、会签。整个审批环节包含,测试、产品、主管三个审批节点,保障发布环节可控流程化。 部署物下载:在云效里创建一条发布流水线,将源代码编译的环节替换为从OSS下载构建部署物(JAR、WAR等)。 ECS分组部署:可以在ECS分组部署阶段添加部署脚本、分组、部署方式等信息。 钉钉部署通知:部署完成后通过调用云效流水线的web hook自动触发部署结果通知。
3.1.2 关键节点
|
|
|
3.2 发布中可用
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转发
After:HTTP请求之所以强制转发到HTTPS,原因是期望用户侧的访问都通过HTTPS的方式进行访问,安全性更高一些。
方式一:前端请求中存在域名,则根据域名匹配转发策略。
存在匹配该域名的转发策略,则继续匹配URL路径部分。若URL路径部分也能匹配,则将请求转发至对应的虚拟服务器组;若URL路径部分未能命中该域名下的任何规则,则将请求转发给域名根路径转发策略(转发策略中只配置了域名,没有配置URL路径)。
当用户没有为该域名配置根路径转发策略时,将向客户端返回404错误。
不存在匹配该域名的转发策略,则按照方式二匹配转发策略。
方式二:前端请求中不存在域名或者转发策略中不存在与之相匹配的域名,则直接匹配无域名转发策略(转发策略中只配置了URL,没有配置域名)。
成功匹配到转发策略时,将请求转发至对应的虚拟服务器组;未能匹配到任何转发策略时,将请求转发至此监听配置的服务器组。
步骤二:健康检查
3.2.3 治理效果
3.3 发布后保障
3.3.1 云上核心监控
3.3.2 数据离线核对
向各个服务商提供sFTP服务器账户密码,分配不同的文件bucket。
服务商定时上传对账文件到oss文件服务器。
ODPS创建明细对账表、总账对账表。
ODPS上针对各个服务商单独创建同步任务,从oss服务器同步文件数据至对应的离线表。
通过MAC核对平台,针对各个服务商部署单独的核对任务。
3.3.3 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], '服务商没有可预订的订单'
当预期的断言失败后就会推送到群内报警,并可以通过详情查看到具体的异常页面,如下所示:
3.4 机制保障
早值班机制:每天钉钉和三方生态伙伴同学需要发早值班日志,针对发现的问题在排期优化解决。
稳定性周会机制:通过稳定性周会的方式同步风险和治理进展。
人员地图:建立每个服务商的系统保障人员地图,发现线上非预期问题,可以快速联系到相关同学及时解决,保障1分钟发现、5分钟定位、10分钟恢复。
四、治理成果
方案无感知:纯黑盒模式下对系统细节感知弱,变更风险高。
无发布管控:云上系统部署不可控,三方部署内容感知弱、部署频率不可控。
无灰度能力:云上系统部署无灰度能力,部署即全量。
无监控能力:云上系统监控感知弱,三方日志规范不标准,监控成本高。
安稳意识弱:三方人员安稳意识薄弱,三方故障等于钉钉故障。
完善公有云发布管控能力:建立完整的云上系统CI/CD能力,保障无任何由于线上变更操作失误导致的线上问题。
建立发布三板斧基础能力:具备可灰度、可回滚、可监控的基础能力。在一个月的治理过程中,通过系统监控、UI自动化测试提前发现并规避了6起线上问题,通过离线核对发现并解决服务商及平台系统8例缺陷。
优化高可用的运维能力:通过负载均衡健康检查路由的方案解决三方系统发布过程中,由于流量切换导致部分请求不可用的问题,治理完成后无任何由于部署过程导致用户体验中断或完全不可用的问题。
建立稳定性保障机制:建立同三方的稳定性周会、早值班等机制,通过阶段性的宣讲和总结提升三方同学对于共建系统的稳定性意识。
五、未来展望
微信扫码关注该文公众号作者