滴滴异构场景下的微服务治理实践
熵增定律
如果没有外部能量输入，封闭系统趋向越来越混乱（熵越来越大）
如果要让一个系统变得更有序，必须有外部能量的输入
无序
接口不统一导致联调效率低
节假日高峰导致雪崩
最基本的通信监控缺失
有序
服务治理打通
研发 - 测试 - 部署 - 运维
规模化的服务治理
统一的标准和实践指引，所有人尽可能靠拢
-
平台体系化支撑标准
一个标准的服务（关键点）
开发：标准化接口（我有哪些功能）
部署：标准化节点，注册发现（我在哪）
监控：标准日志、标准metrics（我的状态）
止损：标准预案（自我保护）
多级缓存：保证100%兜底可用性
最终兜底配置
自动注入部署包，随服务部署一起上线。这意味着即使在极端情况下，服务也能依赖于部署包中的配置继续运行，确保系统的可用性。
配置缺失场景
在配置缺失的情况下，阻止服务上线，并提示用户介入处理。通过在上线前拦截这些问题，可以防止配置错误导致的服务中断，提升系统的可靠性。
多机房互备：注册中心出现问题一键切换
通路多活（active-active）
多个数据中心同时在线，互为备份。当一个数据中心出现问题时，其他数据中心可以继续提供服务，确保系统的高可用性。
数据冷备（active-standby）
一个数据中心在线提供服务，另一个数据中心作为冷备份。当主数据中心出现问题时，冷备份数据中心可以迅速接管，确保服务不中断。
变更可感可控：降低操作出错概率
分级发布
对于扩缩容、流量切换等高风险操作，进行分级发布和灰度发布，逐步推广变更，降低对整体系统的影响。这种方式能够有效控制风险，减少因变更引起的故障。
到达监控
通过监控系统，实时跟踪变更状态，让用户能够感知到系统的变化。这有助于快速发现和处理变更过程中出现的问题，确保系统稳定运行。
标准+工具：有壁垒的“治理内核”
-开发
痛点
上下游联调细节多：<字段、接口、SLA>
标准
唯一服务名
服务IDL
抓手
服务发现、IDL生成多语言SDK
-测试
痛点
线下环境搭建难
标准
线下节点名标准
抓手
服务发现支持多永道环境隔离
-部署
痛点
复杂多变的环境重启时大量报警
标准
节点名标准
部署启停
抓手
服务发现支持路由、优雅重启
-运维
痛点
持续的监控
弱依赖一键降级
快速切流止损
标准
链路层监控标准
预案名称
抓手
RPC内置监控、降级
服务发现支持切流
运营思路
标准先行，开放共建
关注痛点，创造价值：新体验=旧体验>切换成本
一揽子方案：提供建议，让用户决策
组织支撑
前期孵化：先把握住大业务线，落地到别的业务线会更容易，否则会更难
纵向：平台技术部内部（覆盖快车，专车等核心业务）
横向：服务治理FT（联合多部门的虚拟组织）
核心抓手
自身能力建设：稳定、易用
树立标杆：重点抓新业务线，通过标杆的影响力辐射其它业务线
围绕公共服务：对外辐射范围广
演进路径
五层治理：分层独立演进
关注服务全生命周期，平台化整合
探索云上service mesh方案
原文作者：二进制跳动；如有侵权，请联系管理员删除。
