【.com原创稿件】京东云作为京东集团能力对外输出的窗口，实现京东能力+云平台到赋予客户权力。其产品涵盖电子商务、物流、金融、保险等领域的IaaS层、PaaS层以及基于它们的服务和解决方案。本文主要从保证这些服务的稳定性和高效性的角度来讲解京东云自动化运维体系的构建与实现。2017年12月1-2日，由主办方主办的WOTD全球软件开发技术峰会在深圳中洲万豪酒店隆重举行。京东云高级架构师在主会场为与会嘉宾分享了《京东云自动化运维体系建设》主题演讲。以下为演讲实录。说到京东云，我们最看重的就是运维，需要一个自动化的运维平台。这方面有几个关键问题，主要围绕安全、部署变更、网络管理、监控管理……利用自动化运维来提高平台架构的稳定性和人员的开发效率。在京东云的整体环境中，除了由我们的技术团队管理和维护的云自身应用外，还启用和提供各种SaaS服务。如何维护客户业务在云端的稳定性？我们对此进行了深入的研究和探索，下面分四个部分为您讲解：京东云自动化运维基础组件京东云自动化运维部署介绍京东云自动化运维监控系统总结及展望组件针对以上问题，我们从四个方面入手：服务与资源管理任务调度管理监控平台客户端如上图所示，京东云运维平台总体建设路线图为：基础组件→客户端系统→部署系统（包括：各种发布系统、任务调度系统、监控系统），最终完善运维平台，更好地服务于我们的客户。服务与资源管理首先我们来看第一个基础组件：服务组织资源的管理，即利用CMDB实现所谓的配置管理。通过CMDB的“服务树”概念，我们可以把握以下三个方面：找到各个服务项之间的依赖关系，进而知道它们被用在什么地方，谁在使用它们，以及它们自己的用处。机状态。对于京东这样的大公司，机器数量多达10万台。我们需要知道每台机器的当前状态，具体型号，位于哪个机房，使用情况如何。对于角色管理和基于角色的访问控制，我们需要确切地知道谁、什么时候、可以执行什么操作、可以实现什么功能。因此，“服务树”主要涉及系统中服务的实时信息，包括：哪个服务在哪台机器上，有哪些实例，属于哪个App，有哪些内部逻辑流程，如何申请外部信息。权限，以及我们如何对其进行监控等。这些都需要从服务器获得。二是命名服务，可以解决服务之间的解耦关系，即服务与实例的关系，以及服务对外提供的窗口。上图右侧是“服务树”和名称服务的示意图。底部显示了应用程序到实例关系的解耦，上部是客户端的回退（解耦）。任务调度管理第二个基本组件是任务调度管理。在实际场景中，无论我们是想协作某个操作，在线发布，还是部署分发文件。这些都需要系统调度目标机器来完成相应的任务，也就是我们必须要求指定的机器按照指定的策略执行指定的命令。由于该过程的实时性、批量性和共生性，对系统的支撑能力极具挑战性。同时，我们需要通过策略来定义不同类型的并发。比如我们要发布上线一百台机器，我们不会同时部署，而是分批进行并发。因此，我们需要指定每个并发的具体任务，确定成功与失败的逻辑关系，并检查具体的完成度，还要找出那些超时的状态。由于这些都是通过底层架构构建的各种业务，所以它们的调度逻辑其实是一样的。此外，所有执行操作都需要可追溯，包括能够知道执行了谁、何时以及执行了什么操作。可见安全性和标准化是非常重要的。并且如果出现故障，我们需要及时截取输出来定位问题。以上就是任务调度系统需要基于服务树和NamingService实现的基本逻辑。监控平台的第三个基本组成部分是监控平台。监控无非就是从数据采集，到数据聚合，再到存储和处理的过程。不同于通常的数据监控，我们构建的是时序数据存储（TSDB）。由于需要查询的数据点较多，我们将每次查询和采集到的监控点信息按顺序存放。另外，我们的系统具有“读少写多”的特点，即“写”（写数据）比较均衡；而“读”（读取数据）是突发的。例如：检查监视器的状态是可以随时进行的操作。一般这类写操作以1秒、10秒或1分钟为采集间隔，是一个比较频繁的过程。读操作发生的比较突然，所以我们需要把读和写分开。因此，我们基于ES（elasticsearch）实现了TSPD，其中涉及到两种封装：对于热点数据的封装，我们将比较重要的数据和那些实时数据存储在Redis中。同样，我们会对历史数据进行ES处理，然后进行封装，从而实现读写分离。这种数据的双写过程合理的保证了数据的高可用。监控数据的另一个特点是自动采样，有时一些频繁的查询涉及的时间跨度很大。例如：一个月甚至一年。由于我们的数据采集间隔是1秒、10秒、1分钟，如果直接查询所有的数据点，需要产生海量的数据，当然很难实现。因此，我们对写操作进行自动采样。当查询超过15天的数据时，我们会每隔一分钟或每小时汇总一次数据，然后入库，然后再查询一个月的数据。通过自适应路由，我们可以找到有限的一小时数据，同时我们的数据库和业务系统也可以有比较快的速度。此外，对于那些实时数据处理，我们主要采用多位置部署和基于JNS的多调度流程，从而实现多维度的实时计算。客户端的第四个基本组件是客户端。由于所有业务都需要客户端，对于京东这样大的公司，会细分为部署（如JNS）、监控、初始化等客户端类型。.想象一下，如果我们需要加载部署或升级10万台机器，其工作量可想而知。即使只用几十万台机器维护agent，由于环境复杂，存在多个IP，单机处理“什么时候发生了什么”这样的事情，也是费时费力的。方面。所以这里介绍一下Agent资源溢出这个重要的概念。比如对Agent的监控，可能会因为占用了部分计算资源，导致当前服务宕机。那么这种在服务之外的监控，就会影响到服务本身的稳定性。可以看出，Agent客户端需要做以下工作：管理所有Agent的部署和升级。保持每个代理的生存能力。也就是当我们发现哪台机器上的Agent挂了，我们需要知道如何在线重新激活它。资源溢出保护。分级发布。具体实现上，我们使用ifrit来进行控制。即当一台机器引入某项服务时，负责管理的agent会在我们的ifrit服务器上注册，告知它当前所在的分机房和所使用的agent的版本。然后其对应的客户端就可以相应地下载这些信息包，从而掌握最新版本的Agent等信息。这导致了一个简单的客户端架构。京东云自动化运维部署介绍有了上述客户端和组件系统搭建基础，我们进一步搭建部署发布任务就相对容易了。我们先来看看应用的部署系统。除了实现应用部署，它还管理各种服务的维护和资源，以及接入流程。如上图所示：除了“前向”的编译构建，我们还实现了“后向”的流量接入。如上图所示，这里的Agent有一个核心需求：实现跨平台。由于京东整体平台环境复杂，我们有不同的虚拟机、Docker、物理机，需要整合上面提到的各种操作。因此，我们需要实现如下容错功能：不允许单次宕机导致的服务失败。在服务出现故障时，系统可以实现自我发现。面对双十一、618等重要促销场景，系统可快速扩容应对此类流量激增。针对以上功能的实现，我们有两种部署方式：基于Docker的镜像输出。基于传统物理机或虚拟机打包输出。大致流程是：编译构建自己的产品库（包含代码包和代码项）→通过部署服务和上述调度系统的部署服务（物理机和容器）发布→完成部署并启动运行→对运行维护（特别是收集镜像日志）→使用日志服务做进一步分析。同时我们在前端做好了流量接入，中间部分也提供了LB（负载均衡）网络。通过以上两种部署方式，我们可以根据服务的实际需求进行按需升级。另外，我们这里使用的是基于NS的服务自动化和资源管理。它不需要关心当前服务的具体流程是如何实现的，而只关注：当前的能力，需要什么资源，可以获得的资源。京东云自动化运维监控系统除了上面提到的部署之外，我们也非常重视监控系统。监控最重要的作用就是在出现问题时能够及时恢复。要做到这一点，必须做到以下几个方面：第一时间发现问题的能力是恢复的基础。快速定位问题，及时判断问题出在哪里，是在虚拟机上还是在硬件上。可自动使用既定算法，通过自动调度计划或人工响应快速处理和恢复。因此，面对同时存在虚拟机和Docker的复杂环境，为了保证服务器不停止运行，我们在上线过程中采用了部署挂钩的分级发布。它可以监控一个服务是在机器层、服务层、外部流量接入层，甚至是网络层。这些都是监控需要解决的问题。上图展示了监控的整体架构，展示了从底层数据抽象，到数据采集，再到数据处理，再到离线处理的全过程。数据采集??方式包括：采集Agent、外部检测和API推送。同时处理逻辑包括：如何判断异常类型，异常告警类型，运维沟通或研发沟通的方式。我们提前计划好了这些步骤。当然，这些失败本身就是事件类型。因此，我们需要考虑如何存储事件，以方便查询并进一步做出相应的决策。由于之前的事件可能会影响到后续的事件，如果你有一个好的事件库，可以让系统的下游获取到上游发生故障的时间和地点，这对于下游排查问题都是极其有帮助的。同时，我们也会对监控到的数据进行一些离线处理，通过各种高效的算法反馈给相应告警的计算。最终将各种数据以趋势图或Dashboards的形式展示出来，显示各种事件和告警。有了前面的基础，我们搭建的京东云监控系统包括以下四种监控：基础监控，针对机器级别，不需要用户配置，自动采集CPU、内存、硬盘、网络等简单信息。生存监控针对的是服务监控，包括监控进程、端口、语义等。性能监控针对的是服务层的外部性能。我们用四个核心指标来解决服务性能是否有异常。同时我们使用日志监控来收集pv、errors和volumes，并通过所谓的异常边界识别问题。业务监控类似于一个黑盒子，站在用户的角度观察服务，发现问题。例如：所有服务指标都显示OK，但是服务的外部性能不好，无法访问网站。这个问题对于京东来说其实是非常严重的，因为它会直接影响到用户流量，甚至是用户订单的流失，所以我们需要从用户层面做好黑盒检测。基础监控具体来说，在机器监控方面，我们实现了机器连接从采集、到计算、到报警的全自动化，避免人工干预。同时，我们为各种告警指标设置了默认值。例如，通过查找cpu.向其维护人员发送告警信息，通过告警信息可以大致了解相关数据，从而实现后台联动。生存监控对于生存监控，主要检查进程和端口是否存活。为了实现部署联动，我们规定了进程和端口的部署路径。有了进程的路径，我们就可以知道进程的类型和对外开放的端口，从而实现天然的监控。性能监控我们再来看看性能监控。主要关注服务的外部指标，一般来自日志。为了统一，我们事先规定、规范、约定了一种日志格式，从多个维度读取日志信息中不同的标签（label）值。例如：从宏观上看，京东的整体流量是稳定的，但我们可以通过多维聚合发现某省某机房的流量存在细微的潜在波动。当然，除了主动从日志中抓取，我们还可以从程序和用户的告警中学习。业务监控业务监控是从用户的角度检查服务是否正常。比如电商常用的通过模拟全国用户访问，按省份、运营商、机房发现访问。这是使用外网或者自定义的方式来测试业务。此外，我们还将使用模拟云运行的方法来监控云服务。例如：模拟用户登录云网站→购买主机→部署镜像→发布。让我们判断是否一切正常。这样我们就可以站在用户的角度，先于用户发现问题、处理问题、排查问题。总结与展望如上图所示，我们最终在前面的基础上搭建了京东云的自动化运维平台方舟。在接口上，它可以提供：配置管理、JNS管理和资源管理。当天的部署流程。应用程序相关的工具和组件。各种报道。监控的对外展示，包括如何做对比、报表、查询。综上所述，我们的监控自动化平台基本上是通过各种技术的应用实现服务化，实现全生命周期的DevOps。面对海量的SaaS客户，我们的解决方案保证交付效率，节约成本，为他们做好各种可能出现的问题的准备。郑永宽，京东云高级架构师，华中科技大学硕士。拥有6年自动化运维平台研发运营经验。2011-2016年任百度自动化运维平台经理，主要负责分布式任务调度系统、数据传输系统、百度部署发布系统。2016年起担任京东云运维平台负责人，主要负责京东云自动化运维体系建设。【原创稿件，合作网站转载请注明原作者和出处为.com】
