集中式应用系统分布式改造方案研究

图2 物理架构及内部交互情况

统一日志收集

　　各子应用分布部署带来的必然问题之一就是日志文件分散，给故障分析与排查带来困难。为解决此问题且保证系统可用性，本改造方案采用ELK作为日志统一收集处理平台。按照侵入性不同，以下两种处理方案可供选择。

　　（1）基于logbackAppender的实时日志发送。此方案使用定制化的logbackAppender实现日志实时发送。缺点是如果kafka集群运行不够稳定会对自身应用有影响，而且要实现日志的多种格式输出需修改代码。

　　（2）基于logstash的外挂式准实时日志收集。此方案是在日志输出方部署logstash客户端，自动扫描日志路径下的日志变化，读取日志并通过正则匹配格式化后发送到kafka集群。实时性较前一种方案略差，但是对应用本身几乎没有影响，而且灵活性较前一种高。需要注意的是由于正则匹配比较消耗CPU资源，日志输出较多较快或计算密集型的应用不推荐使用这种接入方式。

注册中心

　　注册中心主要有三部分，第一部分是应用注册中心，第二部分是交易、服务注册中心，第三部分是其他注册中心。

　　基于应用注册中心收集到的实时负载信息（包括当前请求总数、虚拟机空闲内存大小等）和zk的Watcher机制，可以轻松实现应用自动注册发现；同时可以根据较复杂的均衡策略在网关应用本地生成当前最优服务器列表。

　　各应用在启动时需要将自身交易、服务信息以临时节点的方式写入服务注册中心，网关应用利用交易、服务注册中心收集到归属系统名称和本地的当前最优服务器列表即可快速获取指定交易、服务的实际URL。

　　在集中式系统中，某些公共交易、服务会采用“统一入口+策略分发”的方式来进行请求分流（以下称为待分发公共交易），而在分布式拆分时这种处理方式会导致网关应用无法仅通过交易、服务名称来确定其实际目标应用。为避免大规模的前后台重构，必须要有一个其他注册中心来统一注册各应用中能够作为路由参数的策略类型和策略值，以便网关收到待分发公共交易时进行路由选择。

配置管理中心

　　在集中式系统中通常存在一些可以动态调整的配置性信息，例如最大消息队列深度，某些多线程操作的并发线程数量等。在应用较少时以http方式逐台调整所有应用的配置是可以接受的，但在分布式场景下这种方式就不再可行，必须要有一个配置管理中心来负责下发这些动态参数的变更，减少运维人员工作负担。在特定场景下某些公共交易也可以利用该配置管理中心实现交易的异步广播分发。

 2/4   首页 上一页 1 2 3 4 下一页 尾页

BPO网版权及免责声明

1、凡本网注明：“BPO网”或者“原创”的所有作品，版权均属于BPO网所有，其他媒体、网站或个人转载使用时必须注明：“文章来源：BPO网”。违反上述声明者，本网将追究其法律责任。

2、凡本网注明“来源：XXX（非BPO网）”的作品，均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其产生的任何结果负责。