1）     个人还不是特别确切了解目前项目开发人员调试项目开发过程中，对日志问题真正迫切的本质原因，也没深刻体验（一直开发以来没有遇到问题难调试的问题，可能现有公司项目架构方式关系密切），所以不知道是否能够解决。

2）     目前分布式监控平台是在原有公司开发的简化版本，为了实现整体项目架构的监控那块的抽象和布局而研发的。性能和功能上还有很多的优化和改进空间。（当然支持公司的现状还是绰绰有余）

未来方向：

1）     根据公司的业务对监控的需求，还需要不断的改进和完善监控平台。

2）     监控平台的功能和性能需要完善，底层将使用nosql来存储实现。

6）     配置中心（个人开源地址：）

公司现状：

1）     目前公司有类似配置中心的功能，用于基本的业务配置的使用，比较简单。

2）     云这块业务尚处于简单的业务模型和业务状态，未遇到真正线上复杂的业务和业务剥离的需求，及异步化的功能点，统计类的功能等等，对分布式配置中心的本质需求和问题还没有真正暴露出来。

采用方案：

依旧使用原有的配置中心功能，同时分布式的配置中心也会搭建。原有的配置中心适合业务配置的存储，现有的配置中心可以用于业务配置的存储，也可以用于分布式架构的环境配置协调问题。

方案弊端：

会维持两套配置中心的运维，在业务架构上比较难以区别，业务上容易混乱。

未来方向：

1）     两块配置中心将根据业务的需求和方向，在一定程度上进行融合。但就目前的公司精力不会着重这块。

2）     配置中心将根据公司的业务发展，也会继续演变出更多的功能，不过暂时不明朗。

7）     消息队列（个人开源地址：）

公司现状：

1）     目前公司在云平台端与工作站异步通信是通过ActiveMQ进行的。

2）     云平台项目还处于前期研发起步阶段，业务复杂度还不够，对性能的要求不高，也未涉及同一业务异步化拆分和解耦。

3）     公司的采集方面的业务还未做到真正的大规模分析，大规模采集的场景。

采用方案：

出于公司架构统一的现状考虑，暂时采用ActiveMQ，也方便java，C#等跨语言的异步通信。当然也仅仅能应用与异步化的简单的即时通信效果。

方案弊端：

ActiveMQ 只能作为异步的即时通信暂时使用，就目前的性能和稳定性来说，并不是长远之计。

1）     若是为了持久化的Tcp通信，未来自己会有TCP服务的搭建来确保。

2）     若是为了消息队列的通信，未来更多考虑消息的堆积性能，消息的高稳定性和高可靠性（不能丢失消息）。

3）     若是考虑消息队列收集消息便于后续采集分析，未来更多考虑类似kafka的方案。

未来发展：

消息队列有众多的解决方案，也有众多的一些特性适用于不同的业务场景。针对这些不同的场景和方案，个人会做如下考虑：

1）     自建的一套消息队列平台，自建的消息队列可以剥离底层的存储引擎，通过不同的存储引擎的特性，达到适用不同场景和方案的目的。（如存储引擎为redis，ssdb，数据库等，即便实现逻辑相同，但是性能不同，可靠性表现也不同）

2）     自建的一套消息队列中间件，可以剥离具体的消息队列实现，抽象出常规消息队列的使用方式。仅通过修改连接字符串或者配置类，就能实现不同消息平台的切换。（如底层消息服务可能是activemq，rabbitmq，redis，kafka，对上层业务可以是透明，甚至无缝切换）

8）     任务调度平台（个人开源地址：）

公司现状：

1）     公司目前业务尚处于前期，未有业务需求有类似后台任务统计，后台任务消费之类的业务需求。

2）     任务调度平台是所有基础服务的一个基础环节，目前也仅在基础服务部署中使用。

采用方案：

个人开源的分布式任务调度平台。

方案弊端：

分布式任务调度平台目前仅属于一个简单的任务调度平台，未来的发展方向还有很大的空间。

未来发展：

1）     所有公司的业务都被视为一个业务任务，所有的业务任务都将被挂载到任务调度平台，任务调度平台会根据分布式集群的负载情况，自动分配集群服务器用于业务的负载均衡和故障转移等资源的调度和协调。（如所有的接口服务，所有的后台任务，所有的消息消费任务等等）