技术成为世界进步的源动力，而新旧技术的更替越来越快速，特别对于无处不互联网的时代，作为互联网时代下的开发者，如何更快的感知到“新技术”“新趋势”“新实践”，并且应用于软件开发中，将成为一项能力。         12月1日-2日，WOTD全球软件开发技术峰会在深圳开幕。50+海内外人工智能技术领袖、创新开拓者围绕当前最热点的话题进行交流与探讨，分享架构设计、机器学习、移动开发、智能硬件等主题最佳技术实践。

大家了解的京东可能是京东电商，事实上在京东有四个最主要的平台：电商、物流、金融和保险。京东有技术设施、主机网络，上面还有一些中间件和PaaS服务，而最主要是我们的电商和物流。
说到京东云，我们最看重是运维，需要自动化运维平台。对此有几个关键问题，主要是围绕安全、部署变更、网络管理、监控管理......利用自动化运维提高平台架构稳定性和人员的开发效率。
京东云自动化运维基础组件
京东云运维的挑战是什么？其实京东云不单是提供PaaS服务，而且还提供一些SaaS服务。客户的业务如何保持稳定？其实是非常富有挑战的问题。在这个过程中，我们大概的经历是，首先从运维技术手，比如服务署、调度系统、客户端管理系统等等，在这个基础上把客户端搭建起来，有了客户端体系和技术理念才能构建刚才说的这些部署系统，还有发布系统和任务调度系统，以及监控系统等等。最终，我们把这些能力SaaS化，从而支撑更多的人做这些事情，从而更好地服务京东云客户。
实现自动化运维的第一件事就是配置管理。对于服务树来说我们要解决什么问题呢？一是服务的组织架构的问题，因为我们所有的服务是要有它的依赖，我们要知道它在哪里用，谁在用，可能有什么用。二是我们所有的技术管理，对大公司或者京东这种体量的公司来说，机器的量是在十万，十万量级如何知道一台机器在当前是怎么样的状态？怎么用？我们需要很多组织。三是角色管理与基于角色的权限控制。还有其他的大数据，比如机型、在哪个机房、当前是什么状态。最主要的东西其实在于我们的服务在系统中是同步的，我们知道这个服务在哪个机器上，有哪些实例，属于哪个APP，中间的逻辑过程又是什么样，对外提供服务的时候，它怎么样告诉别人我需要什么样的权限，以及我需要什么样的监控。我们所有的东西都是构建在服务器上。
Naming Service是解决服务之间的解耦关系和服务关联关系，还有服务对外提供的窗口。右边的图展示服务树与名字服务示意图，最底层展示了从应用到实例关系的解耦，这里面还有它的客户端需要的。最主要的文件就是任务调度，不管做什么事情，比如我们一起做一个操作或者做上线、部署或者文件分发，这些系统都需要调度目标机器做相应的事情，也就是说需要对指定的机器按照指定的策略做指定的命令，这个过程其实是需要比较大的挑战。因为这是实时的，同时又是大批量的，又是同时存在的，所以它需要比较好的系统支撑，同样能批量使用。还有策略，你需要什么样的并发度，比如我需要一百个机器，一百个机器都不一定是同时的。最简单的就是上线，我不会把一百个机器都上线，可能一批一批，这属于并发，以及每次并发是怎么做的。我做上线或者做任务调度，我当前需要做几个，成功还是失败，如果成功或者失败，下面的逻辑是什么样的，以及我做到什么程度业务算是成功或者超时。因为这个底层架构上，它构建了很多业务，它的调度逻辑是一样的。
同时所有的执行需要可追诉，即需要知道什么人什么时候做什么操作，这对安全性或者规范性来讲是非常重要的。而且单机输出怎么样，我需要定位什么问题，如果出现故障，这是任务调度系统，这个基础上可以做很多事。调度的逻辑则是基于服务树和Naming Service。
第三个是做监控，监控无非是从数据采集到数据的汇聚到存储处理的过程。这里面有一个很重要的概念是监控的数据层，不同于我们平时见的，它是时序性的。这里面需要构建时序存储。意思是收集的监控点存储起来，同时我们需要每次查询，要查询大量的、很多的数据点。还有很重要的是“读少写多”的过程，而且它的“写”（写入数据）相对比较均衡，而“读”（读取数据）是有突发性的。比如看一个监控，或者看监控状态，是随时做的。写是10秒或者1秒或者1分钟做采集，它是写比较频发的过程，读比较突兀的过程，所以需要做读写分离。
我们基于ES做了TSPD，封装两个东西，一个是对热点数据，比较重要的数据或者实时的数据存在redis，对这种历史数据会有ES，然后再封装，从而做到这种所谓的读写分离。我们的数据是双写的过程，保证数据的高可用。自动抽样，监控数据还有一个特点，有时候查他是频发，但是查询会有很大的跨度，比如一年的跨度或者一个月的跨度，因为我们采集的数据点是10秒或者1秒或者1分钟，如果查一个月或者一年甚至更长时间，我肯定不会把所有数据点查出来，如果都查出来，这个查询数据量太庞大，不易实现。所以我们写的时候就自动做了抽样，我们查15天以上的数据，把这些数据点会每分钟或者每小时做聚合，然后再放在里面，再查一个月的数据，通过自适应的路由，可以查到一小时的数据，这样检测有限，你的数据库或者业务系统速度就会比较快。第二是我们的数据实时处理，这里面比较重要的特性是多级化部署，是基于JNS调度的过程，就是我们讲的多维度实时计算。
以上这些技术组件还有客户端，所有的业务都需要客户端，对于京东这种体量的公司来说，我们的监控、初始化等都是全网部署。大家想象一下，十万量机器加载的部署，如果每次的升级或者每次的上线都需要操作这十几万台机器，这个事情简直是不可想象的事情。还有另外一个问题，如果是维护十几万机器的Agent，环境比较复杂，多个IP，什么时候出现什么问题没有办法处理，按照单一维度处理，这个东西就没有办法做了。Agent有一个很重要的事就是资源超限，比如监控Agent，它做了一些计算，把当前的计算打死了，而监控又是服务外的东西，这时候因为监控这个事情影响了本身服务的稳定，这也是有可能的。Agent做的事情，一是我们负责所有的Agent的部署和升级。第二个事情是维护这些Agent的存活，它挂的时候我知道哪台机器上的Agent什么时候挂了，我需要做什么动作把它拉起来。第三个是资源超限守护。四则是分级发布，讲一下它的实现。我们装技术的时候会把Agent装起来，一台机器进入一个服务，管理的Agent会在我们的服务器注册，告诉它当前在某个分机房，某个Agent的版本是什么样的，这样他自然就会知道：你在加入服务的时候，它知道你属于哪个机房、属于哪个服务，我就告诉你Agent期望的版本是什么样的。这时候他自然把包下下来，这时候你的Agent就知道最新的版本是什么，这时候我们就可以实现个过程。这是另外一个客户端体系。
我们构建完这些客户端体系或者组件，再构建我们的部署和发布任务就比较简单。大概介绍一下我们应用的部署系统，应用的部署系统不单单只是做应用部署，也做了一些服务的维护和资源的管理，甚至还有接入的过程。我们做了几个事情：一是往前做了编译构建，往后做了浏览接入。这个Agent有一个核心的诉求，是需要跨平台。京东面临的环境比较复杂，我们有虚机、Docker、物理机，那我们的调度需要支持所谓的物理机和虚拟机和Docker。第二个是我们需要把之前说的很多操作融合到一起，同时我们能够做到容错，这里面是不允许一台或者单台出现故障，从而引起服务故障，同时这些服务有问题的时候，他们自发现。而且京东很重要的场景是促销，比如双十一。你能快速扩容，从而能够去应对这种比较大的流量高峰或者下降。
京东云自动化运维部署介绍
部署分两种，一是所谓的基于Docker的镜像输出，二是基于传统部署的物理机或者虚机的包输出。从编译构建到自身做的产品库，这里面有代码包和代码项，通过部署服务和构建刚才调度系统上的部署服务做发布，然后在物理机和容器上都可以做。部署完之后是运行，维护运行之后，尤其对镜像日志需要收集起来，然后做分析，做了日志服务。前台做流量接入，中间做了一个LB网络，最主要的一个点是这个部署分两种，根据你的服务需要做它事实的升级。这里面所有的服务又是基于服务，它其实不需要关心当前的服务是怎么样的过程，以及它这个过程是怎样实现的，因为我们只需要当前需要什么东西以及容量是什么样，以及我们给你分配了什么样的资源。
京东云自动化运维监控系统
讲完部署讲一下监控系统，监控最主要大家比较明白，刚才我们的例子，大家迫切需求是恢复：什么时候恢复？第一个事情要做的是什么时候发现，即能够在第一时间发现问题，这是恢复很重要的一套。第二个是能怎么样快速定位这个问题，然后知道在哪里。第三步我们能够去自动调度一些或者提前准备好的预案或者自动准备一些之前所谓通过的算法，然后把这个故障给它自动调度恢复或者人工能够快速出一些预案。他面临的环境应该说是一样的，它是比较复杂的环境，需要面临虚机、Docker，最主要的事情是需要部署联动，我们在上线过程中，有些东西是分级发布的，对于分级发布的过程中，不能停服。
其实这些故障本身又是一个事件，你怎么把这个事件存储起来，以及方便查询，从而提供给别人决策的依据。上一个事件影响下一步，你有很好的事件库，让上游知道下游什么时候出现故障，这对监控很有帮助。然后做离线处理，得到比较好的办法，反过来反馈计算和报警。
我们能有什么样的数据展示，可能需要趋势图或者仪表盘或者Dashbord，这是我们需要研究的。这些事件或者报警或者上线有什么比较好的方式展现给外部看，这也是很重要的。我们采集，从Agent采集到自定义的日志，以及日志的外部、外网在全国的CDN的点接受探测，这些方式从而决定我们上层构建起很多的监控模式在。
在这个基础上我们构建了京东云监控体系，我们把监控分为四个层次，或者说四个类型：一是基础监控，就是我们所谓的机器层面，CPU、内存、磁盘等，比较简单，不需要用户去配置的，它会自采集。在机器上，机器是好的时候就解决服务的监控，这个解决方案比较多一些，大家做得比较多。第二个是怎么解决服务的监控，我们需要存活监控，比如进程和端口监控，还有语义监控。
存活监控基础上就是服务层面对外的表现是什么，我们的四大核心指标，解决服务性能或者有异常，确定所谓的边境问题，这里面通过日志来解决性能的监控。再类似黑盒，从用户侧看服务，发现问题。从用户的角度，因为很多时候我们看服务是好的，但是服务对外表现不好。很简单的例子，所有服务指标OK，但是网站不能访问，这是一个问题，对京东来说这是非常严重的，这时候最终你会发现你的流量在掉，或者你的订单在掉，这也是很严重的问题，就是说我们从业务的角度，从用户层面做黑盒的检测。技术监控的机器，从采集到计算到报警到机器连通性都是自动的，这些是不需要用户做任何事情的，就可以把这些东西采集。这些报警会给一些默认，比如我大概发现一台机器cpu.idle小于10%，我们看它属于哪个服务，从服务知道这个是谁维护，谁维护就知道给谁报警，给谁报警之后，我大概需要做什么样的数据。我们做这个联动。上线过程中，这个机器的报警需要做什么评比，这是技术层面的。存活监控主要是看基础日志是不是存活，当前的技术消耗是什么样。再就是看端口是不是OK的。
性能监控方面，主要关注服务对外的指标，这个指标怎么来的呢？一般是日志。这个格式比较统一，我们去规定和规范或者约定一个所谓的日志格式，这时候很容易把这些值分出来，其实本身是多维度的，可以发现京东的流量是平稳的过程，但是底下可能比较波动，我们可能发现总体流量平衡，但是某个时段，比如山东联通的流量不OK，多维度的聚合你可能发现这些所谓比较细微的问题。这个采集方式是从日志里抓，还有一种方式是存续或者用户自己对我们暴露，然后通过一些方式把这些值输出出来。
业务监控，从用户侧看服务是否OK，用户侧看服务最主要，能模拟全国各地用户做访问，发现非运营商或者分机房访问的情况，这是用外网或者自定义的方式，我们用各种方式模拟云操作，监控云，模拟一个用户登录监控云网站，然后购买一个主机，部署一个镜像，然后做一个发布，这些过程都是OK的，如果监控层OK，理论上用户也是OK，从用户的角度可以发现一些问题，先于用户发现问题很重要，先于他发现，就可以提前处理，这就不是故障，只是小case。
总结一下，我们做京东的监控自动化的平台，接下来是将技术实现服务化，做全生命周期的DevOps，尤其我们有这么多的SaaS客户，帮他们保证效率，节约成本，提供解决方案，帮助用户解决问题。
谢谢！