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

3.1.1 部署方案

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

3.1.2 关键节点

权限隔离 三方同学可运行线上流水线，仅运行权限，不可编辑。	KP审批 增加产品审批环节； 增加测试验收环节； 增加技术负责人审批环节；	流水线部署 可回滚 可监控 钉钉群通知

服务商视角	客户视角

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转发

Before	After

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

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

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

  当用户没有为该域名配置根路径转发策略时，将向客户端返回404错误。

• 不存在匹配该域名的转发策略，则按照方式二匹配转发策略。

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

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

步骤二：健康检查

健康检查配置

健康检查方式 目前通过HTTP HEAD请求的方式进行健康检查。 curl -Iv -X HEAD http://192.168.1.1:101/ 后端服务器组必须在同一个VPC内才可做健康检查。 七层集群中的服务器根据监听的健康检查配置，向后端服务器的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求（包含设置的【域名】）。 后端服务器收到请求后，根据相应服务的运行情况，返回HTTP状态码。 如果在【响应超时时间】之内，七层集群中的服务器没有收到后端服务器返回的信息，则认为服务无响应，判定健康检查失败。 如果在【响应超时时间】之内，七层集群中的服务器成功接收到后端服务器返回的信息，则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功，反之则判定健康检查失败。

3.2.3 治理效果

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

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

3.3.1 云上核心监控

大盘监控	ECS机器监控大盘	数据库监控大盘
钉钉群监控报警：

3.3.2 数据离线核对

1. 向各个服务商提供sFTP服务器账户密码，分配不同的文件bucket。

2. 服务商定时上传对账文件到oss文件服务器。

3. ODPS创建明细对账表、总账对账表。

4. ODPS上针对各个服务商单独创建同步任务，从oss服务器同步文件数据至对应的离线表。

5. 通过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], '服务商没有可预订的订单'

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

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

• 早值班机制：每天钉钉和三方生态伙伴同学需要发早值班日志，针对发现的问题在排期优化解决。

• 稳定性周会机制：通过稳定性周会的方式同步风险和治理进展。

• 人员地图：建立每个服务商的系统保障人员地图，发现线上非预期问题，可以快速联系到相关同学及时解决，保障1分钟发现、5分钟定位、10分钟恢复。

1. 方案无感知：纯黑盒模式下对系统细节感知弱，变更风险高。

2. 无发布管控：云上系统部署不可控，三方部署内容感知弱、部署频率不可控。

3. 无灰度能力：云上系统部署无灰度能力，部署即全量。

4. 无监控能力：云上系统监控感知弱，三方日志规范不标准，监控成本高。

5. 安稳意识弱：三方人员安稳意识薄弱，三方故障等于钉钉故障。

1. 完善公有云发布管控能力：建立完整的云上系统CI/CD能力，保障无任何由于线上变更操作失误导致的线上问题。

2. 建立发布三板斧基础能力：具备可灰度、可回滚、可监控的基础能力。在一个月的治理过程中，通过系统监控、UI自动化测试提前发现并规避了6起线上问题，通过离线核对发现并解决服务商及平台系统8例缺陷。

3. 优化高可用的运维能力：通过负载均衡健康检查路由的方案解决三方系统发布过程中，由于流量切换导致部分请求不可用的问题，治理完成后无任何由于部署过程导致用户体验中断或完全不可用的问题。

4. 建立稳定性保障机制：建立同三方的稳定性周会、早值班等机制，通过阶段性的宣讲和总结提升三方同学对于共建系统的稳定性意识。