在JD第一次参加了大促的备战工作,我所负责的系统也要应对618当天的流量洪峰。

这半年开发的三个实时相关的工具都上线了,binlog采集、准实时hive表数据、日志分发。

在618备战期间,我对这半年的开发有很多的思考,主要是平台运营、工具特性,性能与监控等方面。

平台型和工具型

作为一个工具,你可以只关心功能,关心配置的灵活度,水平扩展能力和性能的极限。

但是作为一个平台型的东西,这些是远远不够的。

比如平台上的任务一定是绝大多数任务压力很小,有少数任务流量压力很大。

业务上也会出现,某些任务只在一些特定的时间流量压力大,而其他时间流量很低。

数据的表现上有条数多,或者单条体积大。甚至还要考虑有一些任务所使用的网络比其他任务要差一些。

单从工具的角度来说,我们的三个tool的表现都非常优异,每种任务都可以使用3-4个性能档位配置,

工具的配置非常灵活,暴露的可调节的参数也非常多,核心逻辑采用状态机等设计模式,

非常好的兼容能力。性能上也做了诸多优化,binlog采集的性能甚至超过了正常从库同步的性能。

临时解决问题

在任务上线的初期,经历了两周的阵痛,每天都有很多细碎的问题,比如某些任务延迟了,

某些任务长时间无流量,某些任务经常报错等等。经过两周对监控的调整,大大降低了告警的次数,

并且摸索出一套简单的运营办法,可以解决绝大多数问题。但是偶尔还是会有特例,

在备战618的过程中,还是需要花非常多的时间去梳理核心任务和数据量大的任务,提前进行扩容。

甚至在618前的一两个小时里,我们还在梳理增长迅猛的任务,并适当的扩容。

这种工作无论你花多少时间,多么有耐心,还是会有遗漏的情况,因为这些都是实时数据或者

准实时数据,临时人工处理一定已经晚了。

基础准备

因为现实业务上的复杂性,所以我们的任务本身需要做一些基础的准备。

第一、做好水平扩展能力,可以通过增加一个docker副本来实现性能的水平扩展。

第二、当不能通过水平扩展提升能力时,可以通过增加资源来提供能力,比如cpu、mem。

其实很多业务系统经常是增加了资源并不能提升处理能力,或者说不满足预期。

第三、Job本身能够估算出自己的余量,这一点非常重要,能做到这一点的少之又少。

第四、能够借助像docker、k8s等方式对运行时环境进行管理。

未来

在产品端开发和运行时任务之间应该有一个运营质量管理系统,将监控和伸缩容量等结合起来,

通过规则集或者AI相关技术,来解决需要大量人力时间的工作。

在docker盛行的年代,传统运维方式发生了变化,监控也随之发生了变化,

同样运营方法也在产生着巨大的变化,接来下几个月我会投入Flink相关的开发工作中,

建设一个实时计算的平台,运营的实时化问题,会被我当成一个业务场景来对待,

希望今年年底前能够彻底拜托人工运营的现状。