随着出行业务的发展与行业技术的革新,滴滴在业务上和技术上都在与时俱进,这个过程中呈现了其独有的特点与难点。
在业务上,滴滴既要有严谨的交易逻辑和计算复杂的业务系统,又要有强一致性事务等特性的在线系统,要保证这类系统的稳定是最有挑战的。在交易中,每一笔订单的完整性、每一个状态的正确性、每一次支付的准确性都不能有毫末之差 。除了在业务完备性上的挑战,滴滴出行业务还具有典型的早、晚高峰期和平峰期的潮汐现象, 以及大、中、小城市的不同业务规模的业务特点,此外,还面临像元旦、端午、中秋、十一等节假日带来的瞬时或持续的大流量冲击。
在技术上,随着滴滴核心业务完成微服务化改造、服务全面上云,以及应对重大故障的同城多活、异地多活的架构积极演进,这无疑给服务通信的可靠性、服务治理、容错与止损、分布式追踪、日志管理、指标集成与观测都带来不小的挑战,与此同时,服务的可观测性自然也极其困难。
总之,滴滴业务是一种典型的具有交易特征的复杂业务逻辑,同时面临着大流量、海量数据,并且正在不断进行技术动态演进的技术模型。随着业务的不断发展,业务的熵增以及系统的架构复杂度也越来越高,多系统交叉影响的可能性越来越大,如何快速发现故障、定位、止损,以及避免类似的故障再次发生都成为了新的挑战与难题。
可观测性
开始之前,我们先聊聊业界热门词:可观测性。它起源于几十年前的控制理论,可观测性通常指通过观测系统的输出来衡量系统内部的状态的能力。如果可以仅使用输出信息(即遥测器数据)来衡量当前状态,则被认为系统是“可观测的”。
日志、追踪、度量的目标与结合
图片来源:https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
如今在业界,它被应用于提高分布式系统的性能与稳定性。通过依靠可观测性系统生成的数据(例如日志、指标和跟踪)测量系统当前状态的能力,来保持 IT 环境中的系统正常运行。
业务可观测性现状
滴滴业务场景特点与复杂度如前言,这里重点说下滴滴出行业务的可观测性实践的现状。
稳定性研发
在研发方向,我们紧紧依托业务特点,为业务提供例如NUWA业务框架、DiPRC组件、日志、Metric指标、Trace等标准业务组件,同时我们也把稳定性相关抓手预埋进组件里,比如超时治理、自动降级、业务放火能力,机器人依赖指标等。以及在架构上的全面云化、同城双活、异地多活、服务化改造与治理等,更详细见👉基于Go语言的滴滴DevOps重塑之路。
稳定性建设
在稳定性建设上滴滴一直在坚定不移的投入:为了应对系统的流量冲击而做的定期全链路压测、子链路压测等容量摸底与优化,在研发环节为了应对变更带来的风险而做的部署规范、分级发布、配置变更等。在运维环节通过告警自动化、告警管理平台、精准化提高故障的感知能力。以及在平时的巡检、重大节假日的“护堤”(滴滴内部重大节日的稳定性专项)等建设项。
稳定性运营
在建立好基础的研发与稳定性等能力后,如果没有很好的执行,就如同马其诺防线一样,看似坚不可摧,实则很容易被突破,因此我们在稳定性文化建设上也颇费心思,通过周会、海报、技术运营活动等手段,定期宣导稳定性红线、推广框架、工具的使用。在各个业务团队