在这个人人都谈“云原生”的时代，企业在建设内部相关系统时常常会优先考虑云原生架构。那么，云原生架构的系统与传统架构系统有什么不同？又该如何建设呢？本文我们邀请京东架构师韩超老师分享了京东基于云原生架构的监控 - 日志系统的建设之路，希望能对想要建设基于云原生架构系统的读者有所助益。

云原生监控系统有什么特殊？

随着云计算的发展，我们发现很多系统都是基于云原生架构构建的，监控系统也不例外。云原生架构监控系统与传统架构监控系统到底有什么不同？这两者的本质区别是云原生架构监控系统需要以 Cloud Native 的方式来进行部署运维。

Cloud Native 是一个发展中的体系，简单来说，云原生架构需要融入 K8s 体系，让 Monitoring、Logging、Tracing 几大功能，按照 Cloud Native 的方式运作。从系统（K8s 或 PaaS）的视角来看，云原生架构的监控需要是一个标准的东西，而非把系统改得“七零八落“；从应用的视角来看，云原生架构的监控需要与系统融为一体，接入方式不能太复杂。

传统架构的监控系统与云原生架构的功能目标大致是相同的，但细节的把握不同，后者可以视为前者的“进阶”。当然，两种监控系统面临的挑战也各有不同。

传统架构的监控系统中，主要是面临多、快、好、省四个方面的挑战：

• 多系统需：监控要运作于数万主机、百万应用的环境中，而且开发、运维的负责度要做到 O(1)。

• 快：监控系统要随着主机、应用快速部署完成。一台主机交付上线，有没有监控的部署速度应该是相同的；一组应用交付上线，配套的监控应当同步具备；

• 好：监控的时效性、稳定性要强于应用。监控是应用的保障，发现问题的准确率、召回率是监控系统的关键指标。

• 省：监控系统需要省资源，监控的 CPU、Memory 开销是监控的关键指标。

而基于云原生架构的监控系统，其挑战大多是来自于 Cloud Native 模式本身，主要包括：

• Cloud Native 体系本身就有快速部署、自动扩缩等功能，既然应用具有这种特性，那么监控系统也需要具备同类特性；

• 在云原生的 PaaS 中，K8s 与应用层都是标准的，监控系统作为介于二者之间的部分，“采集端侵入”的危害会更加严重；

• 云原生秉承有标准化、自动化的核心理念，但是大型系统往往需要做“极限优化”，要满足标准化、自动化的“极限优化”，挑战就更大了。

京东如何构建监控系统？

最初，京东的应用程序全部都部署在物理机器上。这种部署方式不仅造成了物理机器资源的严重浪费，而且调度缺乏灵活性。由于物理机器的故障，应用程序迁移的时间要花数小时，无法实现自动扩展。

为了解决这些问题，京东从 2014 年开始尝试使用 Docker，并基于 OpenStack + Novadocker 架构创建了第一代容器引擎平台：JDOS1.0。此后，所有应用程序在容器里面运行，而不是在物理机器里面运行。其中，一个 OpenStack 分布式容器集群中最多有 10000 个计算节点，至少也有 4000 个计算节点。

2016 年，JDOS 1.0 的容器规模由 2000 个扩大到 100000 后，京东推出了新的容器引擎平台 JDOS 2.0，京东商城的“应用体系”从 OpenStack 切换到 K8s。

JDOS 2.0 的平台架构

京东云原生监控 - 日志系统

京东商城基础架构的 JDOS2.0 已经非常接近“云原生标准“，京东云原生监控 - 日志系统的发展和建设，与之同步。该系统的核心组成主要包括采集端、接入代理、存储模块、计算模块、服务控制中心、报警等。

• 最核心的底层是京东商场基础架构自研的存储模块；

• 中层则是其它各个核心模块，采用积木式可以进行排列组合；

• 在核心的监控 - 日志系统之上是基于 API 的扩展能力，比如业务定制扩展、AIOps 扩展等。

京东云原生监控 - 日志系统各模块之间也是以服务化的方式进行联系，看起来就像是普通的应用。其中采集端比较特殊，因为它要放到 Node 环境中，并且要求每机一个。这是所有监控 - 日志系统都绕不过去的事情，京东将其做成 K8s 的标准化组件，做到了“低侵入性”。

京东监控 - 日志系统本质上都是标准的 K8s 组件，与京东容器平台 JDOS 关系密切。

• 在 K8s 的视角，监控 - 日志系统是 DaemonSet、RS 的各个 Pod，并非改了系统。

• 在 JDOS 容器平台的视角，监控 - 日志系统可以视为 JDOS 容器平台的一个“插件”，并非强耦合。

• 从应用的视角来，监控 - 日志系统是一个“无需感知“的机制，例如上线无依赖。

建设监控 - 日志系统遇到的挑战

大型系统建设升级的挑战大多来自上线，上线类似于“在开车的过程中加零件”，需要保证各种稳定性。京东监控 - 日志系统也不例外，在上线的过程中，新、老系统采用“临时冗余化”、双写并行运行的模式，解决了平滑切换的问题。同时，小流量机制，也解决了占用 double 机器资源的问题。

另外，监控 - 日志系统上线常常会遇到由于“强侵入性”导致的上线顺序左右为难的问题。因此，京东监控 - 日志系统在设计之初就避免了这种问题。

报警在整个监控系统中是一个定制化极强、需求极强的模块，一般来说报警包括两个层面的东西，一是短信、邮件、IM 等通道，二是报警规则的设置引擎。

京东商城的 app 监控系统采用了极其灵活的报警规则机制，规则的设置在于使用者，而不在于监控系统的开发运维。这种设计给了各个业务开发“自我平衡”的机会，在运作的过程中，将报警的量、级别调整到比较合理的状态。同时，报警多了容易发生召回率高、准确率低；报警少了容易召回率高、准确率低。虽然这两点永远是矛盾的，但京东在技术层面也做了一些小的优化，比如自动合并、调整时间轴等。

目前京东商城的监控 - 日志系统最大的亮点在于：架构灵活 + 与时俱进。架构灵活是空间维度的概念，包括对标架构、拓扑关系、部署方式三个方面；与时俱进是时间维度的概念，包括维护成本、演进模式、技术发展三个方面。

当然，该系统也还有很多值得优化的地方，在韩超看来京东监控 - 日志系统应该优化的地方也是很多大型系统架构层面的固有问题。

• 多集群、多地域：整体架构超越了 K8s 集群的定义，监控 - 日志系统也需要进行应有的改变；

• 整个系统的监控对象其实既有普通 App，也有数据库、缓存、队列等中间件，这里面需要整合，才能让每个业务的开发者更能感受到 Serverless 的优势；

• 京东商城基础架构自研的 baudtime、baudlog 已经在很大程度上节省了存储资源，如果权衡读、写能力，仍有成本优化空间，查询体验也可以对标更好的 ELK。