人老了就得服老，在收拾行李的时候接了个电话，于是后果就是电脑忘带了，出差到目的地后只能用同事的电脑和客户交流。于是这几天没电脑用，也就没法写文章了。今天虽然拿到电脑了，不过一路狂奔下一站出差的地点，只能翻出一篇老文章发一下了。大家见谅。
80年代中期，我国的信息化工作开始起步，到现在为止，经历了从最早的电算化、网络化到信息化、数据化、智能化的数个阶段。信息化建设之初是实现电算化，将以前手工处理的数据和台账管理起来。这个阶段的信息系统建设大多数是以采购国外先进的计算机、网络设备与应用软件来支撑我们的业务工作，同时我国的软件开发产业也开始起步，在采购的套装软件外，部分企业也开始了自己的业务系统的开发。
这个阶段的计算机系统对于现在来说还处于较为低级的水平，CPU、内存、存储的能力和容量也都比较低，1992年，当时中国能够从美国进口的最高端的小型机设备的配置为2颗90M主频的CPU，64M-128M内存。当时的应用体系架构是T/S架构（终端/服务器架构），开发的应用软件也十分简单，往往一两个开发人员开发一套业务系统，有十多个人开发的软件项目就算特别大的系统了。虽然当时的计算机系统的配置这么低，似乎不如我们十多年前的一部手机的配置。不过当时这样配置的小型机系统往往要支撑上百台甚至几百台终端的同时接入，因此如何有效的优化软件的逻辑，减少内存和CPU的使用，支撑更多的客户端接入，对于应用程序来说是十分关键的。
这个阶段的应用开发者往往都有比较好的专业背景，精于各类算法，往往都会利用自己所学尽可能优化自己的程序，减少CPU和内存的使用。和我们现在所说的码农不同的是，那个时代的软件开发者都属于精英阶层，能够编写这样大型应用系统的程序员的数量也十分少，培养周期也很长。基于此，这个阶段开发出来的应用系统的代码质量是比较高的。
T/S架构最大的瓶颈就是服务器本身，哪怕我们再怎么优化应用软件，一台服务器的处理能力也是有限的。接入终端的数量达到一定限制后，就很难继续扩展了。哪怕程序员再如何优化应用，都无法解决单机瓶颈问题。此时DEC公司的VAX CLUSTER技术出现了，VAX CLUSTER可以将几台甚至十几台VAX小型机组成一个集群，这个集群上的所有设备，甚至某个串口和每台服务器上的DAS存储都可以在集群范围内共享。终端只要连接到集群上的任何一台服务器，就可以使用整个集群的资源。集群可以部分的解决单机瓶颈问题，使得成千上万个客户端可以突破单机瓶颈，连到服务器上运行程序。当时广州邮电局的呼叫中心系统，就是利用了VAX CLUSTER技术，才实现了数百个终端同时连接服务器的。虽然VAX CLUSTER解决了部分横向扩展的问题，但是数据库集群技术仍然没有大的突破，VAX CLUSTER的优势无法得到很好的发挥。同时由于DEC公司的UNIX版的TRUCLUSTER未能达到VAX CLUSTER的水准（到目前为止，还没有任何一个UNIX CLUSTER能够达到当年VAX CLUSTER的水准），因此VAX CLUSTER技术随着OPENVMS的衰落而陨落了，VAX CLUSTER并没有拯救我们的信息系统。似乎一切都预示着T/S架构的天花板快要到达了，必须有救世主出现来拯救T/S架构。
在T/S架构这个阶段的系统优化主要还是集中在应用软件上，主要是通过算法去优化应用系统，通过批处理去加工汇总今后需要使用的数据。比如通过设置适当的缓冲区来提高文件的访问效率，通过减少单次读取数据的数量来减少表或者文件的锁定时间（那时候大多数数据库还不支持行锁，减少锁冲突时优化应用的常用方案），通过B树来缓冲常用数据，通过访问汇总数据减少汇总原始数据的开销等等。
优秀的程序员和优化专家并不能拯救T/S架构，系统架构的发展再一次拯救了IT世界，C/S架构的出现拯救了这一切。随着PC机的日渐成熟，一种新的计算架构出现了，将部分业务逻辑迁移到PC机上，而服务器端只运行部分共享式的服务，从而减轻中心的服务器的负担，这就是著名的C/S架构。C/S架构将一部分服务与数据库独立出来了，一个应用系统的业务逻辑被下移到PC端，从而不再消耗服务器的资源，只有访问共享部分的时候才需要访问服务器（共享部分主要是数据库和部分共享类的服务）。C/S架构大大解放了服务器，解决了T/S架构马上就会面临的瓶颈问题，也使PC机、工作站的发展进入了快车道。
由于业务逻辑和数据库分离了，每个客户端可以独享一台PC机，因此软件代码优化的要求比T/S架构下低得多，我们不再需要让用户去使用那种简陋的字符界面，而可以在PC机上使用视窗界面来展示用户接口。在这个阶段，大量图形化/可视化开发工具如Oracle Forms（后来到90年代末演化为Oracle developer/2000,后来演变为现在ORACLE EBS的图形开发工具）、PowerBuilder、DELPHI、C++ Builder、VB等的出现，使软件开发的门槛大幅度下降，程序员不再是高大上的工种。可视化开发工具的广泛使用使软件开发的门槛也大幅度的降低，大量的没有经过计算机专业训练的技术人员经过简单的学习就可以进入到软件开发大军的行列。这是IT发展中的巨大进步，使应用软件能够像DOS/WINDOWS一样，进入到我国国民经济的各个行业，中国迎来了软件行业的大发展。
C/S架构最早出现在九十年代初，早期的小型机的处理能力还很弱，所以当时的C/S架构的应用还是十分精细的。拿上面那个广州邮电局的呼叫中心的例子来说，这个系统是国内最早改造为C/S架构的系统之一。当时所有的用户数据都存储在VAX 小型机的RDB数据库和RMS文件系统里面，话务员通过终端来访问这些数据。随着话务员数量的增加，服务器端的处理能力达到了瓶颈，并且终端的操作十分不便，于是就考虑到将话务员的业务处理迁移到PC机上，VAX小型机上只进行数据库的操作（RDB和RMS数据库）。在90年代初，这样的改造最大的困难来自于网络，当时的话务员是分散在各个分局，甚至县局、乡镇支局的。这些地方以前和服务器是通过拨号线路连接的，如果改为C/S架构，那么网络通信是个大问题。笔者有幸以DEC专家的身份参与了那个方案的编制，当时把香港赛马会的串口通讯的方案介绍给了项目组并得到了项目组的采纳。当时的做法是在VAX服务器上外接几十台终端服务器（带有32个串口的网络设备，通过网络与服务器连接）用于接入外部的PC机，同时在服务器上编写一组数据服务，用于和客户端通讯交换数据。客户端通过远程拨号线路连接到服务器上，通过串口通讯的方式实现C/S之间的数据交换。由于C/S之间的通讯线路带宽有限，通讯质量也较差，因此数据交换的协议必须设计的十分精巧，而且能够应对各种特殊的问题，这样的系统的设计者与开发者都是需要有较高的技术水准的。
这个阶段的信息系统一般来说都有比较细致的设计，因为网络、数据库、服务器处理能力等因素的限制，这个阶段的应用系统大多数是采用分布式计算的。系统的设计者力争将UI展现、业务逻辑、数据交换与数据服务、网络通讯等分开来设计与开发。因此这个阶段的系统优化工作主要是在架构上的优化，如何优化系统的整体架构与服务器上的服务，使之满足大型应用系统高并发访问的需求。
随着C/S架构的逐步流行，软件开发也从阳春白雪变成了下里巴人，中国的软件产业终于起步了。凡事有利也有弊，软件行业的大发展，使大量没有受过系统培养的技术人员进入了软件开发的行列，应用软件的开发质量问题也日益暴露出来。随着大型数据库的大规模应用，开发人员也更习惯于将业务逻辑都使用SQL来实现。这种情况下，再也没有人会自己编写算法去处理数据了，而是把业务逻辑统统交给数据库去处理，让PC机的功能主要是处理UI界面的显示。每个客户端只需要处理本客户端的UI部分的工作，确保每个客户端的处理能力是足够的，这样的话系统的大型负载主要被集中在服务器端的数据库上。
由于集中式数据库是整个架构中的唯一的无法横向扩展的点，因此数据库往往会成为C/S架构中的瓶颈。因为服务器资源的限制，过多客户端同时连接到数据库服务器上会导致服务器的资源（特别是内存）耗尽，导致系统出现严重的问题。因此开发着被要求编写高质量的SQL，数据库表和索引的设计也有优化的需求。不过由于当时开发人员对数据库的技术掌握处于较低的水平，因此应用优化的效果往往是极为有限的。电信计费账务，银行核心交易系统等大型系统都面临着必须不断升级数据库服务器资源的困境。而这时候，小型机的发展似乎遇到了瓶颈，虽然DEC公司已经推出了64位的ALPHA服务器，但是IBM/HP等企业的64位芯片却还迟迟没有上市，而ECC内存的昂贵价格也让服务器的处理瓶颈再次凸显出来，IT世界的性能危机将再次上演。
拯救这次危机的还不是程序员和系统优化人员。当程序员无法完成这个使命的时候，应用架构再次拯救了IT世界。在90年代初，一家叫BEA的公司横空出世了，BEA的TUXEDO成为拯救大型应用系统的救世主。为了解决软件行业爆发发展后C/S架构里服务器处理能力不足的问题，BEA公司发明了一种革命性的技术架构C/S/S三层架构。在这种架构下，客户端不直接连接数据库，而是连接BEA TUXEDO中间件，由TUXEDO再去连接数据库。这种架构让客户端直接连接数据库的需求减少，通过中间件的排队机制，还可以消除应用访问的高峰，让数据库服务器能够支撑更大并发的访问。同时，TUXEDO的XA支持分布式事务，使我们在应用系统不用进行大的改造的情况下，把数据分布式存储在多个数据库里，从而打破了数据库纵向扩展的资源瓶颈。BEA TUXDEO的出现，让大型企业的大型业务系统突破了以往的瓶颈，很快被运营商、银行等在大型企业在核心业务系统中广泛使用。
当BEA在用新架构打破服务器单机瓶颈的时候，数据库厂商也在做着努力。Oracle公司在7.3.4版本的数据库产品中首先推出了一种叫做OPS的并行服务器技术，让一个OPS集群中的多台服务器可以同时打开同一个数据库，这样客户端就可以通过连接多个数据库实例来共享访问一个数据库了。到了Oracle 9i，Oracle公司的 OPS升级为真正实用的Oracle数据库集群RAC，通过RAC的数据库集群技术，将数据库能够进行一定程度的横向扩展，从而支撑超高的并发处理。
与此同时，小型机技术也获得了巨大的突破。大型并行计算技术的突破让小型机从一路、两路、四路发展到八路，每个CPU板的核数也从1颗到2颗，4颗，一直到16颗。IBM/HP等小型机领域的后来者把那些早期小型机界的霸主一一逼退，同时也把小型机的处理能力和可扩展性推向了一个新的高峰。对于绝大多数企业来说，数据库服务器的瓶颈打破了，因此我们的应用开发也变得任性起来。
另外一个发展的十分快的IT基础设施是集中式存储，最早的小型机都采用DAS方式内置存储，这种方式的磁盘是无法集中共享使用的。基于SAN(存储局域网络)的集中式存储大行其道后，存储技术发展十分迅速。高性能、高可靠的集中式存储为信息系统的大发展解决掉了最后一个瓶颈。
至此IOE全面登场，信息系统建设也进入了快车道。以IBM小型机、Oracle数据库和EMC高端存储为代表的IT基础架构甚至在阿里巴巴等互联网公司的发展早期都发挥了巨大的作用。基于这种架构的系统被阿里的工程师亲密的称为“IOE架构系统”。直到2006年左右，阿里才开始逐步转向开源的Mysql，开始了十年的去IOE之路。
在2000年以后，随着IOE架构的日渐成熟，以小型机+集中式存储+大型数据库为基础架构的应用系统逐渐流行起来。由于这些设备都比较昂贵，所以采购的时候的配置大多数都偏低，系统上线一两年后，大多数都出现了一些性能问题。性能优化的需求也就被提了出来。笔者参与系统优化工作大致上也是在2003年左右开始。比较大型的优化项目包括海尔HCSP系统优化、云南联通计费账务系统优化、北方电信BSS/CRM系统优化、华为供应链管理系统优化、华为彩铃系统优化等几个项目。这些系统里面，大多数是因为应用系统存在较多的问题，而服务器、存储等的硬件配置性能明显不足，出现了系统资源不足的情况。因此这些项目大多数都是通过优化SQL语句的方式达到了优化的目的。海尔HCSP系统和华为供应链管理系统比较特殊，海尔HCSP系统的应用软件代码优化已经遇到了瓶颈，而服务器配置过低的问题暂时没有办法解决，于是通过了一系列非常规的手段才临时性解决了当前的问题，一直支撑到系统扩容。这个阶段，对于优化理论的研究也比较粗浅，优化方法也都是采用黑盒优化的方法，找出系统存在的瓶颈，并想办法去消除瓶颈。黑盒优化法很容易找到一些比较明显的瓶颈和性能问题，所以黑盒法对于存在明显瓶颈的系统优化工作是比较有效的。
与此同时，JAVA的快速发展推动了B/S/S三层架构的发展。与C/S/S相比，B/S/S不需要笨重的客户端，应用的可移植性更强。同时，随着SOA软件架构的逐步发展，软件程序员从高大上的高端技术人员变为了码农。软件开发人员的大规模增加，也使得软件开发的质量急剧下降。数据库厂商乘机快速增加数据库的功能，使原来在中间件中的业务逻辑大多数都可以由数据库来完成，于是，只要会写SQL的人都可以快速成为JAVA 程序员。由于应用软件规模的迅速膨胀，导致了应用代码对系统资源的过度消耗，从而出现了一些性能问题。
随着服务器、数据库和存储技术的发展，IT基础架构的成本也在快速下降，大型企业有条件采购处理能力更强的硬件了，于是由于资源瓶颈导致的性能问题逐渐少了起来。虽然系统的整体资源是足够的，但是用户对应用系统的满意度并没有提升。系统慢不是资源问题，而是应用的问题了。于是前些年的解决系统瓶颈的黑盒优化方法能够发挥的作用就有限了。于是白盒+黑盒的优化方法开始被广泛的采用起来了。黑盒优化可以很容易找到系统级的瓶颈，但是不一定能找到当前系统中用户所遇到的痛点，而白盒优化可以帮我们找到用户的痛点，通过这两种方法的结合，既可以解决系统级的问题，又可以用较小的代价解决用户使用的痛点。
近些年来，IT基础架构发生了翻天覆地的变化，随着云计算、大数据、人工智能的发展，以小型机、集中式数据库、高端集中式存储为核心应用架构正在被逐渐颠覆。虽然接替小型机的X86服务器的处理能力已经超过了小型机，大多数情况下，X86服务器+大型数据库+高端存储下都能够很好的支撑企业信息系统的负载需求，但是集中式架构逐渐被分布式架构替代只是一个时间的问题了。
基于云平台、微服务、分布式/分库分表数据库的这种以往互联网企业使用较多的应用架构逐渐被大型企业所接受。在我们看来，应用架构在某些方面来说是在向二十年前回归。尽可能的分拆业务逻辑，让更小的应用单元负责专业化的工作，而不是仅仅依赖于强大的集中式数据库来处理业务逻辑，这种系统架构逐渐深入人心。
国家电网调度系统要实现国产化的最大障碍就是数据库，将Oracle换成国产数据库后，发现应用系统的稳定性出现了明显的问题，通过几年的努力，在应用软件上下苦功夫，目前的新系统完全能够克服国产数据库性能不足、稳定性不够等方面的问题。国家电网国产化的成功也是一种信息系统的回归，基础架构干基础架构的事情，应用软件干应用软件的事情。当基础设施存在不足的时候，通过软件的容错能力提高来进行弥补。一旦我们的企业级应用系统都能够回归应用软件的本质，通过在软件上多下功夫去解决自身的问题，而不过度依靠IT基础设施，那么大型企业的应用系统完全适应云平台是没有任何问题的。
云架构采用一种标准化的基础设施来支撑不同的业务应用，不管是虚拟机还是容器，云平台提供给应用系统的基础设施都是标准的，能力/容量受限的。因此，我们的传统应用系统要直接迁移到云平台上面，还是存在很多问题的。我们的传统架构应用必须进行一定的改造，来适应云平台的资源限制问题，才能够很好的在云上运行。
基于云架构开发的应用被称为云原生应用，云原生应用的优化需要从两个方面去进行优化，一个是应用体系架构的优化，各种系统瓶颈都可以通过相关组件的横向扩展去消除瓶颈，应用程序本身的问题可以被云平台的监控组件发现，并交给开发商去优化改进。云平台本身的性能瓶颈通过对云平台本身的优化来解决。这样，一个复杂的优化项目被分解为云平台本身优化、系统部署架构优化、PAAS组件优化、微服务调度优化、应用软件优化等几个层面。这些层面的优化工作相对比较专业化，并且通过分层分拆之后，工作复杂度也大大降低了，由相关的专业团队分别进行就可以了。
从上面的信息系统发展以及与之伴随的系统优化的发展历史来看，我们看到了一个轮回。随着IT基础架构能力的不断提升，开发人员不断的将本来应该由应用解决的问题交给IT基础架构去解决，从而加快应用交付的时间，降低应用交付的难度。IT基础架构厂商也乐于提升基础架构的能力，从而增加用户的粘度。而随着这种模式走到极致，替代它的是现在的分布式架构，开发人员又要开始考虑软件与数据的架构，将交给IT基础架构干的活收回来自己干，对大型的应用和数据进行逻辑的分割，降低IT基础架构所面对的复杂性，从而保证系统能够在标准的基础架构下稳定的运行。从应用适应基础设施，到基础设施容忍应用，再回归到应用适应基础设施，这一个圈走了20年，似乎现在又回到了起点。
当然，在现在的环境下，分布式架构并不是包治百病的。对于某些企业来说，继续使用IOE架构或者其简单替代的架构可能是更有利的，在这种情况下，为了分布式而分布式就没有任何意义了。我遇到过一个客户，他们上了阿里云，然后开始把一些原来运行在传统IOE架构下的系统迁移到阿里云上。当他们费尽千辛万苦，把Oracle数据库替换为阿里的DRDS的时候发现，很多应用在DRDS上跑的并不好，而这些系统的数据量并不大，不使用DRDS，简单的使用RDS效果更好，而且从ORACLE将数据库迁移到RDS的成本要比迁移到DRDS上小得多。
另外一个例子就是我在前言里说的那家国外的银行，Oracle Exadata已经能够很好的支撑他们的应用系统，那么他们就没必要再把核心数据库迁移到云上了。IT是为业务服务的，而不应该成为限制业务的借口。
