Valen Won

Scalability，可伸缩性。
我们在评价一个软件系统的优劣的时候，往往会从稳定性、可用性、可扩展性、易维护性以及可伸缩
性等方面来进行评估。一个系统从开发到上线，运行了一段时间以后，通常对稳定性、可用性、易维护性都有了大致的了解，但可伸缩性却不能在最短的时间内体现出来。
那么什么是可伸缩性呢？
理论上，可以称为软件系统的工作负载能力和硬件资源的投入成比例。换句话说，在一个具有良好伸
缩性的系统中，如果你加大工作量两倍，那么软件系统将使用两倍系统资源（假设足够的化），同时获得两倍的工作能力，当然也不可能无限制的和硬件增加成比例。反过来说，一个可伸缩性差的系统，在一个低端的PC server和高配的小机上的性能是没有很大的区别的。
某大型企业的一个网络管理系统是于5年前上线的，时至今日已经不堪重负，不能满足公司日常业务
需求。公司先后投入很多人员进行优化，但始终没有解决问题。我曾经问起一个负责该系统的人员，服务器的CPU有几个？他肯定：这个系统的速度和CPU无关。如果肯定了系统的能力和硬件无关，那么这个系统的可伸缩性差劲可见一般。不知道是这个产品的开发商（国内某著名通讯企业）的问题，还是我们的二次开发人员没有理解到可伸缩性的含义，无法提出真正解决方案。在系统硬件利用率100％的情况下，无论你做什么优化和修改，对性能的影响是微乎其微的。而通过增加了硬件资源，仍然没有带来性能显著的提升，就是系统本身有问题，不具备可伸缩性。
最近几年，硬件技术的高速发展，多核多CPU技术、高速硬盘、光纤普及，使得我们在硬件资源的使用已经不再捉襟见肘。但很多开发人员，始终把硬件资源以及系统资源（OS）看作是黑盒，这样往往就不会考虑到系统对硬件的利用和工作负载的关系。当我们开始设计一个软件系统的时候，应该把可伸缩性的做为一个重要的考虑部分，而合理的采用并发技术是解决可伸缩性问题的一个重点。
最近我参加过一次成功的软件系统的优化。该系统是四川电信的一个网元激活系统，应用服务器和数
据库服务器负载均很低，每台CPU负载30％，4核，内存利用率也很低，总共8G,采用的java技术和
oracle集群。但是该系统的性能达不到要求。我在仔细分析了系统的结构后，发现该系统的2个高负载的核心处理模块，一个是采用的单线程处理模式，一个是开发人员写死的双线程，每当工作量加大的时候，这两个模块就是瓶颈所在。找到问题之后，就把该模块改为线程池和可配置多线程。系统可根据工作量的负载，动态增加/回收/或者配置多个处理线程。改造完毕后，压力测试中，性能提升至少3倍以上，而硬件消耗也达到了60％左右，在一段时间以内可以满足业务的需求。这个时候，我可以说这个系统具有一定的可伸缩性了。最后我建议，把一些业务逻辑转移到PL/SQL，因为Oracle是一个具有良好伸缩性的软件产品，简单的讲它可以自动根据硬件资源的情况，来制定合理的执行计划。
影响可伸缩性的关键因素，我认为是多CPU技术和软件的并发技术。当然任何一个系统，也总可以从更高CPU频率，更多的磁盘I/O,更快总线、内存的速度，获得一定性能提升。但是如果融入了可伸缩性的设计，系统的性能会更加充分的使用硬件资源，从而带来显著性能提升。
我口号是：Multiple CPU and Multiple Thread...