简介
最近在重新思考运维平台的设计思想，前期设计的平台已经呈现出了越来越多的问题，重构已经势在必行，在后续将尽量尝试根据这个思路把平台进行一次重构。
1. Agent
作为一个提供最基本服务能力的组件，Agent将被部署在所有的服务器上，提供对服务器的操作中间能力。上一个版本对Agent的功能梳理出了这几个能力：
- 文件接收
- 脚本执行
- 数据采集
- 数据发送
总结起来，Agent的任务其实就是接收、执行、发送的能力.
其实往广了说，凡是agent都应该都包含了这几个能力。而这几个能力的实现方式决定了agent的好坏。
作为一个平台类的agent，我希望新的Agent可以实现这几个能力：
- 热更新：实现自己的ClassLoader，无需重启Agent，自动更新功能和配置。
- sink扩展能力：支持从多种数据源接收数据。包括从MQ、实现监听TCP端口等等
- source扩展能力：支持将执行结果通过多种方式返回给服务端，包括MQ，UDP协议，直接存入Mysql等等。
- 多线程任务调度：使用多个线程池支持不同种类的任务并行，并限制线程的资源使用。
- 安全：设置安全的访问控制，保证数据传输安全。
- 同步、异步任务支持：支持同步和异步的方式执行任务并将结果返回给服务端。
2. 中间件、数据库
中间件层的任务包括：任务路由、数据传输、削峰填谷等
中间层提供数据的传输和存储，包括MQ、DB两个模块，其中MQ要求可替换，也就是说通过多态的模式来支持替换多种MQ。这个思路是参考java的日志系统，像是直接使用slf4j来输出日志，上下游都可以通过一个transform4j来实现数据的传输，当替换MQ以后，只需要实现一个trans-rocketMQ或者trans-kafka的包就能对接任意MQ了。其实阿里的openmessaging就是想干这个事吧。
数据层的任务包括：元数据任务数据存储、热点数据缓存、脚本文件存放、性能数据存储。
数据库考虑使用mysql存放元数据信息，包括Agent采集到的虚拟机的基本信息和当前采集到的监控数据。使用mongodb来存放脚本信息，并实现脚本的管理。使用influxdb来存放所有的agent历史监控数据，influxdb采用双写的模式来保证数据的高可用。采用redis缓存来存放热点数据。
但是数据的存放有一个问题：不同规模的agent所需要的数据存放方式可以不一样，比如100个agent，可能只需要一个mysql就能实现所有功能，这个时候就需要通过设计模式来实现灵活的数据存储方式。也是通过接口的方式来实现。
3. 服务层
服务层的能力包括：同步/异步任务下发、任务结果数据处理、数据入库存储、前端及外部API提供
服务层目前使用的是storm+httpserver，storm负责数据处理，httpserver负责对外暴露服务接口。架构分成了两层，中间采用一层MQ来对接。这样实现以后出现了一个问题：上层和下层两层的逻辑完全不同，如果架构和我们公司不同，不需要两层这么复杂的架构，还是需要完全搭建两层才能实现平台功能。而小规模且没有地域网络限制的公司完全没有必要搭建两层模式。
所以考虑重新设计一下，将storm和httpserver合并，实现服务化的模式，使用springboot重构，对外使用nginx或者dubbo暴露RESTFUL接口，相当于实现了一个前后端分离的后端。服务层对中间件和数据库，所有对中间件和数据库的操作都经过服务层。
同时服务层要能够直连Agent的同步任务端口，调用Agent同步执行任务。
服务层要采用可扩展的方式，支持通过配置的方式来实现全部或部分功能，且支持DOCKER部署。插件化的模式。
可通过扩展服务层和中间件层并通过适当的配置来实现多层扩展。
4. 展示层
展示层主要对外暴露平台的能力，包括Agent信息展示，任务结果展示，集群状态展示，任务编排，监控告警展示等等等等。。
展示层考虑使用node.js来实现，所有的操作都通过调用后端服务层的接口来实现，不直接操作数据库。
需要整合一大堆系统了……
5. 监控
监控考虑使用prometheus来实现，在所有集群节点上部署jmx-exporter或者自定义exporter，agent的数据存放在influxdb中，数据通过grafana进行展示，并嵌入到展示层中。
同时使用alert-manager来进行监控告警。
还有很多需要详细设计和思考，今天先写到这吧。
