如图所示，系统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架构中的相关系统中，导致所有的服务请求受到影响。
| 共3页: 上一页 [1] 2 [3] 下一页 |
| 【内容导航】 | |||
|
服 务 CIO 推 进 信 息 化
|
|
