网银系统拥堵 SOA从治病良方到罪魁祸首

申请免费试用、咨询电话：400-8352-114

网银系统拥堵 SOA从治病良方到罪魁祸首

IT管理者本来寄希望于SOA解决系统运维中的一些问题，而这个治病的良药，偏偏又可能带来新的疾病，如网银因系统拥堵而变慢。如何克服SOA架构下的新问题，也就成了IT管理者所要面临的首要任务。

系统运行维护一直是企业IT部门的重头戏，而在银行这样拥有众多应用系统的大型企业，运维问题显得更加突出。当SOA架构出现时，银行的科技部又不得不去面临一些崭新的难题。他们本来寄希望SOA解决系统运维中的一些问题，而这个治病的良药，偏偏又会带来了副作用，如何在SOA架构下克服这些不良反应，也就成了IT管理者所要面临的首要任务。

业务高峰期的拥堵

系统拥堵是经常会看到的场景。以网银系统为例，上午10点钟左右，是一天中最为集中的业务高峰，网银系统发生了拥堵，造成的问题是客户不能正常访问和登录。在实际工作中，首先能够发现问题的往往不是IT运维部门，而是客户服务部门，因为他们接到了大量的客户投诉以及抱怨，当问题不断发现和积累之后才逐步上报到IT管理者手中，然后运维部门才能予以解决。

这时，系统堵塞已发生半个小时之久，并造成了较为广泛的不良影响。为什么运维人员没能及时发现问题呢？其实，这不是他们工作不负责任，也不是领导的玩忽职守。网银系统拥堵的原因并非出现在某个系统上，而是出现在SOA整合之后，多个系统并行和协同的处理引起了系统拥堵。

通过一个服务链路的示意图，网银系统拥堵的原因更容易被理解。A、B、C、D是银行的客户服务渠道，E、F、G、H都是后台应用系统。假设A是网银渠道，银行客户在A渠道上提交的服务请求被发送到ESB上，服务总线将请求进行处理和转换之后，再发送到其他的后台应用系统E和G，可能是一个，也可能是多个，而且其中要保证整个服务和事务的一致性，最后再将应答返回给渠道系统A。

经分析，笔者发现每个应用系统都会存在自己的流量控制、超时控制、安全控制和用户访问控制。因为经过了上线前的集成测试和压力测试，所以点对点地去访问某一个系统是不会有任何问题的。可是当通过SOA进行系统整合之后，却发现各个系统之间的控制参数设置，并不是最优的，甚至会造成互相矛盾和制约。

系统A、B、C、D、E、F、G、H所设定的流量控制值分别是 60、5、40、10、80、50、30、60，ESB的流量控制值是200。如果现在A系统流量值达到了60的峰值，执行1～4步骤时，整个系统的服务都是正常的，但是由于G系统的设定值有限，大于30的并发服务请求被G系统拒绝，从而导致E系统需要做回滚处理、A系统的用户服务请求造成堵塞。这样来看，A系统设定的60并发流量是存在风险隐患的，在目前G系统不能提升处理能力的情况下，只能设定为30，这就是所谓的木桶短板效应。

参数设置难题

前面列举的只是最为简单的例子，其实在实际工作中所面临的问题更为复杂、困难。针对SOA架构所带来的改变，运维管理上带来的困扰主要体现在参数设置和系统监控两个方面。

系统参数的设置不尽合理的原因主要有六个方面。

第一，各系统建设和运行维护都是靠独立的项目组来完成，各自形成了一套自成体系的流量和超时控制方法，可是当多个系统并行运行在SOA架构下的时候，没有一个统一的规则和机制来进行管理，必然会造成系统的整体运行不够协调和匹配。

第二，各系统的控制参数都是根据当初自身的处理能力评估值来设定的，可是这些评估值与实际系统运行态的访问压力相比来说相去甚远，这也是导致系统运行效率低下的原因之一。

第三，在正常交易状况下，系统整体是稳定运行的，可是当访问量增大系统拥堵发生时，服务一旦被拒绝，必然会产生大量的冲正服务来占用通道流量，影响了其他正常服务请求。

第四，各个系统过于强调自我保护机制，运维人员希望能够把系统安全风险降到最低，所以在设定系统参数时，会尽量考虑配置到系统承载能力的下限。可是从整体应用上来讲，保守的参数设置并不足以满足系统的访问压力，从而降低了整体SOA架构的系统资源利用率。

第五，从SOA架构整体运行来看，并不能在拥堵发生时，发现在某个系统内发生的是系统故障还是系统过载，而对于这两种情况，运维人员完全会采取不同的处理方式。对于系统故障，应该采用系统隔离和故障修复的方式，而对于系统过载，是可以采用降低压力和过载分流来进行处理。而在目前状况下，这两种情况是难以区分的。

第六，没有结合故障隔离机制，也就是在系统故障发生时，需要将堵塞的服务请求进行隔离，避免影响正常的用户访问，而且单点所造成的系统堵塞很容易扩散到整个SOA架构中的相关系统中，导致所有的服务请求受到影响。