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

经实际测试，本改造方案基本满足集中式系统分布式改造的一般性要求，但在配套的自动化部署方面并未进行更加深入的研究。要充分发挥分布式系统的特点，基础设施建设至关重要。

面对的问题：随着业务规模增长和系统运行时间的增长，传统集中式架构应用体现出越来越多的问题，例如单位成本高、并发数受限、无法弹性部署、业务模块间可用性耦合等，而且无论是应用程序变更还是数据库临时故障，该时间窗口内整套系统均无法对外提供有效服务，系统可用性已受到较大影响。

　　解决措施：对大规模集中式应用系统进行轻量化改造，将其转变为性价比和吞吐量高、跨平台性好、可自动化弹性伸缩且便于快速响应的分布式系统，提高负载能力和可用性势在必行。

必须解决的问题

　　分布式应用系统的基本要素是在子应用充分解耦的基础上，使各应用能高效地自动发现其他应用及其提供的所有交易与服务，并根据配置、权限许可和目标子应用的负载情况进行最合适的请求分发。同时要有相应的保障体系用于分析和监控系统运行情况。业界成熟的复杂分布式系统通常还会考虑服务降级、熔断等一些高级特性，但由于这些特性对一般集中式系统来说不是必须的，在此方案中不涉及这些内容。

　　从上文可以看出，要将集中式系统拆解为分布式系统，需解决的问题主要有：必须实现拆分后各应用可用交易、服务的自动注册与发现；必须实现软负载均衡以获得最优集中式应用系统分布式改造方案研究的交易、服务流转路径；必须有易于操作的配置管理中心用于配置项管理和自动发送；必须有权限控制用以保证系统安全性；必须有统一日志收集和保障组件，用于分析和监控系统运行情况。由此得出的分布式应用系统基本架构如图1所示。

图片4.jpg
图1 分布式应用系统基本架构

　　由于原有技术限制，绝大部分现有集中式系统无法使用现有的成熟分布式应用系统框架：要么改造量太大，要么组件限制不能改造。因此自主开发一套适用于现有集中式系统的分布式处理框架成为唯一的出路。经笔者调研，最终选用ZooKeeper（以下简称zk）作为管理中心，ELK作为统一日志收集处理平台来实现改造方案。此方案的物理架构及内部交互情况如图2所示，其中单向箭头表示单向访问，双向箭头表示双向访问。

图片5.jpg
图2 物理架构及内部交互情况

统一日志收集

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

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

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

注册中心

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

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

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

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

配置管理中心

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

　　分布式改造过程中通常还涉及数据库拆分。对笔者所在系统来说，子应用数据库是否独立拆分会影响到一些公共交易的实际路由，而利用配置管理中心则可以实现交易路由的灵活动态调整。

权限管理

　　本方案需要进行权限控制的主要有两部分，一是注册节点（例如枚举节点、交易节点等）的访问权限，二是子应用的访问权限。为简化处理，一套系统的所有zk节点的加密授权信息是一致的，不同系统的授权信息不同。应用程序对注册节点的所有操作必须经过鉴权以避免非法访问。

　　本系统内部所有应用可以互相访问（如图2所示），同时各个子应用允许所有经过授权的外部系统应用直接访问其指定交易或服务。子应用在进行交易、服务注册时会同步增加相应授权节点及其监听器，然后基于监听器收到的通知信息形成允许访问IP列表。收到请求时子应用会进行IP鉴权，外部IP只有在允许访问列表中才允许访问该子应用。外部系统需要直接访问子应用时需在目标交易、服务的授权节点下注册其应用IP信息。

请求处理流程

　　为最小化改动，内部系统交互应尽量以系统现有主要请求方式为准，使用相同网络协议及报文格式。如图3所示，网关收取外部请求时，根据路由参数（例如url名称或其他特定请求参数等）从相应的本地注册信息缓存中获取目标子应用，若存在目标子应用则将请求转发，否则按照常规流程处理请求。

图片6.jpg
图3 请求处理流程

　　待分发公共交易等特殊交易由于必须进行报文解析才能拿到相应的路由参数，耗时增加较其他直接转发交易更多。在不破坏原有请求参数结构的前提下，将路由参数添加到无需解析即可获取的地方（如http请求报文头），使网关无需报文解析即可确定转发目标，提高处理效率。

压力测试及分析

　　限于篇幅笔者选取若干典型交易进行了压力测试，各个交易代表的典型场景说明如下。

　　process1、2、3：网关根据zk配置决定分发策略，本测试中不分发；process41、42、51、52：网关应用解析请求后根据策略类型A进行子应用分发，其中策略值为A1的请求由网关直接处理，策略值为A2分发到子应用SUB1上；process6：网关直接转发至SUB1子应用的普通HTTP请求；process7：网关直接转发至SUB1子应用的文件生成下载请求（该交易并发数受限）；process8：网关收到MQ消息后直接转发至SUB2子应用的Webservice请求；process9：网关收到请求后直接转发至SUB2子应用，SUB2子应用收到请求后在正常逻辑处理过程中请求SUB1子应用；process10：网关应用解析公共文件生成请求后根据策略类型B进行子应用分发，本测试中分发至子应用SUB2（该交易并发数受限，与process11组合调用）；process11：网关应用解析公共文件下载请求后根据策略类型B进行子应用分发，本测试中分发至子应用SUB2（该交易并发数受限，与process10组合调用）。

　　从测试结果可以看出：对于不分发的交易，分布式处理效率较集中式略高，原因可能是分布式网关应用的可用空闲内存较集中式多。这种效率提升对于内存占用较高的交易更加明显。单一次转发的时间损耗在绝大部分情况下在4~10ms之间浮动，偶尔会达到15ms。

　　综合场景测试内容如表1，结果如图4。可以看出：综合场景测试情况下事务的平均耗时与该事务包含的转发次数相关，同时会受单交易自身复杂程度和内存占用情况等因素影响，特定场景下分布式平均耗时甚至会低于集中式。需要网关进行报文解析后再转发的交易其平均耗时增长较直接转发交易略长，且报文越长耗时增加越多。

图片7.jpg
表1 综合场景测试内容