2018-03-21 17:10

　　感谢前面几位技术分享的嘉宾，通过倾听他们的演讲，我对目前负责的云管平台产品有一些新的想法和思路，感谢几位嘉宾！

　　现在开始我的报告。在云计算产品上，我比较关注性能采集方面的问题。在苏州做云计算管理平台的过程中，也遇到了类似的问题。

　　具体性能方面的问题这里列举了几项，比如性能数据采集对象复杂，有虚拟化服务器、有物理服务器、网络设备等等；另外性能数据的指标需求很多，随着云计算的发展，客户需求越来越繁杂，甚至很多想法很超前，需要我们引导；然后性能数据稳定性过低，即以前使用的性能数据采集产品的性能数据处理流程繁杂，处理性能数据需要很多流程，比如分析、存储、展示，包括后面一些业务报警之类的。接下来是分析能力。分析能力包括趋势分析、告警关联分析之类的。最后一点，性能数据展示形式过于简单，有些性能数据展示是为了展示而展示，并不是为了提高客户的生产能力或者是按照客户的实际需求去做的，就是为了展示一张比较好看的图而已。

　　根据这些问题，我们定位想做性能方面的产品，这个产品最初主要是为了服务云管平台，因为云管平台不仅要支持运营管理，和支持异构资源池，还要支持第三方厂商的数据汇总，还要支持面向业务的告警并提供统一的服务接口，为实现自动化运维，提供必要的数据支撑。定位就是图上的这六点，实际中会随着产品迭代满足出现的新需求。

　　基于这些定位和需求，我们的系统架构方案如图所示：分为展示层、基础架构、数据处理、采集层、资源层，当时设计的基本要求是各个模块以独立服务的形式，即微服务，部署几个核心服务就可以使用，服务间松耦合。我们在客户那边做项目的时候，客户以前采购了别人的产品如性能采集的产品，不可能全部替换掉。为了实现这一点，我们在这里面加了一个数据适配，支持不同的采集器与底层的存储模块。

　　我们这个产品本来是服务云管平台的，但是我们也要求能够独立部署，提供一个标准化API。设计原则就是高性能、高可用、高可靠、可扩展，性能采集涉及到大量的数据，所以要支持大量的数据集中上报，比如一分钟几百万条的数据量。

　　还有高可用、高可靠方案，不能因为一个采集点的故障引起数据丢失的问题。

　　数据采集这边我们定义的原则就是可扩展、易定制，我们尽量采用开源的产品，使用方便，二次开发比较容易。对于一些不能满足个性化需求的，自己写一些脚本实现自定义的框架。

　　存储这边要求比较高，数据量本身比较大，数据存储如果集中，会遇到很多问题。存储这里面首先要能支持分片存储，做好备份不能让数据丢失。数据存储经常遇到数据越来越多的问题，如果能够支持数据存储灵活配置就更好。

　　另外就是输出，支持JSON或XML格式的，后续可以支持输出图片的。跟输出有关的是用户权限模块，控制不同权限的用户看到的前端有一些变化。

　　模块刚才我们提了服务化和独立部署。

　　模块设计也是跟业务相关的，所谓业务导向，就是所有采集的指标以用户的需求为导向，就是用户需要什么我们就提供什么，数据上我们要重视数据的准确性，并保证鲜活度，要面向生产能力和客户需求，而不是为了要采集而采集。

　　下面就是比较重要的一点，数据我们不是为了简单存储，一定要把数据的关联关系给展示出来。因为后面跟关联分析，数据挖掘，如果没有这些关联关系，仅仅是把数据存储起来，这些数据是没有意义的数据。

　　系统架构的原则，采集、处理、存储、展示分离、部署方便，保障数据安全性与可靠性，采集端读取端支持多重协议，不同来源数据上报都可以。我们客户因为以前的项目或者根据不同的厂商接口还有一些文件数据源，设备适配层一定要做的够强大，才能都支持。

　　存储层独立出来设计上要简单，不想太多关注业务，存储层只对数据负责，与业务无关，数据来了只管存储，不管业务关系。

　　这里面实现的特色功能，多样化的采集方案支持，数据指标灵活性控制、高性能存储等。

　　刚刚讲的数据处理流程，数据上报、数据适配、数据存储、数据查询、数据分析，下面从这几方面讲系统一步步实现的过程。这块上报系统开始遇到的最直接的问题就是下面列的四个：终端多样性、异构资源池，多样性网络设备、主机设备、虚拟化设备、中间件。数据端有第三方接口和文件数据源，比如有一些用户存量的一些系统，要有接口支持。刚才异构资源池，要做适配和对接。开发语言要多种，这个影响稍微小一点。Openmelric，这里面对性能数据列了五个方面：第一个就是从上报过来的数据要经过数据处理子系统，再经过数据存储子系统、数据读取、数据分析、数据呈现。数据处理子系统就是刚才我讲的数据适配层，就是Data Adapter，比如数据格式化、数据清理、指标名称标准化、数据简单聚合等必须具备的功能。数据通过适配以后转入数据存储层。这里列了四点：高性能、高可用、高可靠、扩充，这几点都要考虑。

　　适配层考虑比较多的是大数据量，高并发网络我们要解决，比如说网卡，一下子来了几百兆数据你这个网卡就撑不住了。

　　数据缓存，这里是为了解决数据转化读取的问题。

　　支持高可用，单节点故障不会导致系统问题这些方面都有处理。

　　右边这个图主要是说我们从各个客户端，就是刚刚列举的那些各种服务、各种中间件，包括各种应用以及网络，远程的一些第三方应用，通过各种协议，UDP等等协议上报数据适配层，在数据适配层进行数据的一些清理、数据的一些格式化、数据的那些简单的聚合。这里聚合举个例子，采集的时候，各个客户端上报的数据并不是统一的，有些数据上报的，比如拿CPU举个例子，比如说CPU0到CPU31都可以上报，有的只是给你上报CPU利用率，但是按照需求的话，需要把CPU利用率做一个简单的聚合，适配层的工作就得做掉。

　　经过适配层之后数据转到存储层，关注的点就是数据分片，提高写性能。还有冗余，一份数据来了支持冗余处理，可以做一个备份，保证数据的可靠性。第三点就是读取场景优化分级，根据用户的需求不同，今天一天我对数据要求比较高，5秒钟展示一条，过去可能一个小时展示一条或者是一天展示一条，本身存储系统有这种支持的，数据经过一定的算法自动地降低精度存储。

　　上面这张图是经过两层适配，原因就是因为我刚才说的，他们上报的时候可能会有一层数据转发，到哪一个节点并不能控制，所以要经过第二层去把数据做一个汇聚，汇聚的时候CPU1到CPU16在一个节点上这种情况是适配不了的。先做一层缓存，每一次写上几千条数据，这样提高磁盘的利用效率。

　　存储有两方面，一方面是磁盘存储，一方面是内存存储，要求短时间的读取比较频繁的数据存在内存比较好一点，这是根据业务场景按照自己的需求自己去定就好了。

　　下面这个图就是本身的存储层支持，比如说CPU采集指标开始是10秒钟一条，过了一段时间自动变成了30秒钟一条，像这种很多开源工具都支持的。

　　数据读取，这里面对数据存储那一层的读取，当时定义的要求就是提供统一的API，这是毋庸置疑的，不可能底层不同存储调不同的API，这样的话对那种外部系统调用可能就增加开发量，不能说换个系统做一套API，这一层一定要在系统本身处理掉。另外提供性能数据查询接口及数据冗余处理，比如说我刚才举了个例子，同一份数据在不同的节点做不同的备份，你同时给我是不行的，比如说在不同的节点存不同的数据，这个节点是两到三点，另外一个是三点到四点，需要把数据合并在一起反馈给我，这是数据读取所要做的事情。还有支持一些基本的函数功能，平滑功能函数都要支持。

　　另外预测及趋势分析功能，举个例子，比如根据磁盘近一到半年的趋势分析你的磁盘将在明年某个时间达到90%，这时候发一些预告警，这边的功能就是比较高级的功能。

　　支持标签数据，这里面跟存储有关的，因为存储只对数据负责，不管业务，有时候往往业务查询的时候需要根据不同的业务系统或者根据不同的标签分类做一个归总，所以这里面数据存储层的标签查询的时候一定要支持，这里面就是我的数据读取的子系统。

　　下面就是分析子系统，分析子系统在我们这里对接的并不是存储层，而是直接对接的读取，因为读取层面的数据对于我们来说应该是比较基本的数据，就是一些没有经过处理的数据，没有经过二次加工，我前面说了有一些简单的指标，标准化、数据清理包括数据的聚合之类的，那些对于我们来说，聚合之后的数据还是我们最需要的原始数据。在数据分析层我们直接对接API。

　　数据分析层要紧跟业务和需求，面向他们的运维需求或者是面向生产能力做这个分析，里面分析功能，当时根据我们平常遇到的问题或者是客户反馈回来的需求做了很多的分析功能，这些分析功能并不是所有客户都需要，我们做到了分析功能可配置，因为可以节省系统资源。支持任务调度形式启动任务，这里面有一点微服务的思想在里面，因为云管平台把配置中心的概念也弄到这里面来，我们所有配置都在配置中心，从配置中心里面拿数据，当然拿数据的方式有主动推送和自己请求之类的。配置中心在数据处理层关系最大的是调度中心，就是中间这个图，调度中心从配置中心来读取我们的各种任务或者说一些新加的任务，根据预先预知的新加的任务，调度中心读取到任务，把任务分发到各个处理点。因为各个资源池的性能数据量比较大，所以如果是直接把一个性能数据交给一个点去处理，在规定时间内根本处理不完，所以把数据切片分发到各个数据点去处理，然后完成这个处理。

　　右边这个图，数据分析子系统处理完数据之后，在右边这些图是对接Web系统，第三方根据业务方式、用户需求不同提供不同的接口。这里面提供最基本的就是消息队列和REST接口，我们发布了消息队列，第三方怎么用可以自己去定义，但是我们的设计是为了满足用户的需求的，具体项目要做适配。下面还有告警之类的。

　　后面是数据呈现子系统，这个是主要对接API，对原始数据做一些处理，也有一些根据业务层面呈现，一个是对接的大屏，另外一个是数据原始数据的展现（见图）。数据承接子系统要关心用户的权限，并不是所有用户都可以访问的。我们有各个分类，比如说运维部署，可以查询数据指标是否正常，各个虚拟机的磁盘读写、I/O是否达到瓶颈了，这要看部署的节点，服务端的数据。

　　下面介绍一下我们这个系统本身的交付与运维。系统本身我们是Git管理代码，Git每个模块上面都有一些脚本，可以将完成的功能模块直接打包镜像上传到本地的镜像库。根据资源池的规模来部署我们的系统，有时候配置信息比较简单，有时候比较复杂，比如说有6个节点和有2个节点就不一样。这些配置信息有一个配置模板，把模板的关键参数填好后就自动生成配置文件，这跟叶哥说的配置模板有点像。

　　部署交付人员都使用容器镜像交付，在现场部署、上线系统的时候并不关心各种配置的开发和怎么做镜像。他们只需要把各个关键节点的IP等等配置参数写进去，生成配置文件，然后启动就可以了。

　　最后一点是一些产品优势，在网络方面我们做的比较多。举个例子，我们可以根据系统的网卡信息以及Bond检测各个流量、流速都可以做到，这些方面一直在做。因为在做云管平台都知道，如果我们只是根据IP做一些东西往往是不准的。另外信息提取方面，纳管对象的属性和相互关系在这个系统里面做的比较多。

　　扩展能力就是部署节点，部署人员其实并不需要改动东西，只需要告诉节点、配置，自动生成配置文件自己去部署就可以了。

　　部署模式的话，就是各种灵活的部署模式主要是为了实现不同的需求产生的。

　　成熟的数据采集（这里面有一点自我安慰），要支持Iaas和Paas数据采集，我们在Paas层根据性能数据做一些Paas容器扩容，或者这里的容器扩容不是单独的容器扩容，而是底层的依赖资源的扩容，比如依赖物理机之类的。

　　这里面是我们近期做了一些项目的实践，当然是部分，中国移动一级私有云项目，6000多个节点，浙江移动私有云1400个节点，工商银行1300个节点，还有上海咪咕项目，右边的图是近两年做的项目，上海、南京等。

　　我的演讲就到这里，谢谢大家。

　　主持人董伟：再次感谢师忠涛带来的精彩分享。大家坚持到最后相信都是真爱，相信大家从一下午的演讲当中，从京东、腾讯到有一些不太大的公司都可以学到非常非常多的经验带回去为我们的团队带来更多的进步和成长。

　　下午感谢大家，再次感谢。会议到此结束。