无论是互联网软件还是传统的企业信息系统管理软件，随着软件系统在线用户的不断增加、系统重要性的不断提升（现在很多重要的软件系统也要求7＊24不中断），对系统的可用性也不断提出新的需求。由于个人能力的限制，本系列文章梳理了个人所经历的系统架构历史，重点讨论Java体系下不断提升性能、可用性、可扩展性的架构思路及实施方法。

        系统可用性的演进是逐步的，伴随着软件的成长经历了很多的阶段：

        阶段一：单应用服务器＋单数据库服务器阶段。在Java EE还叫J2EE的那个年代，为了首先解决软件系统有无的问题，诸多MIS系统实施的时候客户对软件的可用性要求并不高，为了实施与运维的简单（高可用往往也会带来高昂的实施与运维代价），大量项目中都适用单应用服务器＋单数据库服务器的模式；

        阶段二：有钱任性的单应用服务器＋单数据库服务器阶段。为了提升系统的性能及可用性，同时由于信息化建设费用的充裕，很多的企业在实施项目的时候，选择WebLogic或者WebSphere这样的商用应用服务器，数据库采用IOE（IBM的小型机、Oracle的数据库、EMC的存储）体系，在有钱任性的状态下，这阶段的性能与可用性都得到了充分的保障；

        阶段三：应用服务器集群＋数据库集群阶段。系统越来越多、在线人数越来越多，同时由于对系统的依赖度提高，一旦软件出现问题，往往出现工作人员完全无法正常进行工作的情况，阶段二中采用的模式完全开始出现应用服务器Down机或者无法满足性能诉求的情况。为了让软件运行更高效稳定，应用服务器集群+数据库集群的模式开始出现。WebServer（Apache/Nginx做负载均衡）＋应用服务器集群（WebLogic/WebSphere/Tomcat/JBOSS等）＋Oracle（RAC）开始在越来越多的项目中出现；

        阶段四：WebServer负载均衡 + 应用服务器负载均衡 + 关系型数据库分库分表、读写分离阶段、NoSQL数据库开始应用。高并发来了，7*24小时的应用来了，这种应用场景下，阶段三的模式中WebServer的单点故障风险开始暴露、数据库性能瓶颈开始出现、系统实施部署过程中需要停机的缺陷开始变得严重，为了提升系统的可靠性以及保证系统在升级部署过程中系统的可用，新的架构体系开始出现（特别是在对高性能、高可用、可扩展要求都非常高的互联网领域中）。通过使用商用的F5等负载均衡硬件或keepalived、HAProxy、LVS等负载均衡软件针对WebServer做负载均衡，解决单点故障的可能风险，应用服务器中大量使用Memecached等缓存技术提升应用服务器的性能，数据库根据业务做分库分表、读写分离以及在合适的场景中使用NoSQL等相关技术提升系统的性能与可用性。

        其实，还有更多的技术（如CDN、Hadoop等）与架构方式在各种业务系统中应用，但是从个人所经历的系统架构来看，目前我们所遇到的大多数问题通过阶段四中所使用的模式，合理使用各种技术，足以满足90%以上的应用场景（当然，淘宝双11等极端情况下，所要应用的架构模式远超过本文所讨论的技术范畴）。