IT架构演进之路
我一直认为IT架构是逐步演进出来的，而不是设计出来的，设计的再完美的架构在实施的过程中也会有变化，影响因素太多了，变是正常的，不变才是有问题的。一个大型信息系统都是从小到大一步步走过来的，在每个阶段都会遇到各类系统问题，然后在不断的解决这些问题，所以架构是由业务规模驱动而演进的，当然IT架构也是为业务提供其所需要的功能不应过度设计而舍本逐末，接下来回顾一下IT架构的发展过程：
单体应用
我接触过这样一个公司，最早是做大学校园食堂饭卡系统的，功能很简单，开卡、充值，刷卡吃饭，初期购买一台服务器部署应用就可以承载所有的需求，在服务器上部署了应用程序服务、数据库服务、文件服务，此时的业务目标是尽快上线给用户提供服务，验证系统的能用性，业内称之为ALL in ONE，架构如下图：
（该图可以理解为一台服务器就是一个饭馆，只有一个老板干所有事，既当服务员又当厨师还当采购员）
运行了一段时间基本都没问题，但是当学校有重大活动时，比如召开运动会那几天食堂吃饭刷卡非常慢，学生吃不了饭现场大混乱，排查原因发现是这台服务器的CPU和内存那段时间 使用率已经100%了，应该是大量学生吃饭集中到同一时间段系统的访问量突然比平时增多了很多，一台服务器扛不住了。
数据与应用分离
为解决上面的问题，又购买了两台服务器，他们把原来服务器里的数据库分离出来，部署到新购的数据库服务器（硬盘更大速度更快），将应用服务部署到另一台新购的应用服务器（CUP、内存更大更快），将原来的服务器作为文件服务器使用，用来存取学生的照片文件。
（老板忙不过来请了一个服务员和一个厨师，自己干采购员）
这样分流后三个服务器各干各的，极大减轻了系统的压力。过了两年大学扩招学校里的学生多了很多，吃饭经常卡住刷不了，应用服务器的处理能力成为了系统的瓶颈，虽然运维人员对服务器的内存进行了升级，但问题时不时的出现，而且还出现了工作人员不小心把应用服务器电源用脚踢开的事故。
应用服务器集群
单一的应用服务器再高的配置资源也是有限的，高并发访问情况下连接很快就会超限，他们马上又购买了两台应用服务器，和原来的一台应用服务器组成了三台应用服务器集群，利用负载均衡器将学生刷卡扣费请求分散到三台服务器分别处理，减少单台服务器的压力，另外如果有一台服务器发生故障，其它两台也可以继续提供服务，不会影响正常的业务。
（一个服务员忙不过来，又请了两个服务员）
缓存服务器
学校发展的很快，经营范围也扩大了还开了超市，学校决定将食堂的饭卡系统进行业务扩展，升级为学校的一卡通系统，不仅可以吃饭，还可以在校园内进行所有的刷卡消费。这对刚刚架构升级后的系统又提出了更高的要求。该系统负责人找到我征求方案，我查看了他们五台服务器的系统负载情况，发现问题出在了数据库服务器的cpu和内存使用率一直在高位，然后又找了他们一天的访问日志进行了认真的分析，又发现学生一次刷卡消费需要请求服务器五次，分别是查询学生信息、卡余额信息、商户信息（包含食堂）、商品信息（包含菜品）和扣费。我发现只有查询卡余额和扣费两个数据是一直变化的，其它像学生、商户和商品信息基本变化的不频繁，基于以上分析我建议他们在应用服务器和数据库服务器之间加一台缓存服务器，将这些变化不频繁的信息存放到这台缓存服务器的内存里，这样处理请求的方式变为应用服务器收到请求先去缓存服务器的内存里找，如果找到了就直接返回数据，如果没有找到再去数据库服务器查询，并将结果存到缓存服务器，下次相同的请求通过缓存服务器即可得到数据。用缓存服务器的原因是读取内存的速度是读取数据库硬盘快的多的多。
（每天开门前把客人点的最多的菜先准备好，客人点了热一下直接上，没有了再通过后厨）
数据库读写分离
实施一卡通项目后学校的商业发展的很好，现在的学生都有钱了也愿意消费，学校的经营部门提出要对一卡通系统的经营数据进行统计分析，该系统又增加了一个报表功能，可能是数据量太大，只要查询一些大的数据报表，整个一卡通系统就非常慢，甚至不可用，导致经营部的人员只有在晚上8点后才敢进行报表查询，这种问题对于IT架构师都无法容忍，更别说业务部门了，架构师马上就发现了问题所在，操作数据库包含增、删、改、查，其中70%~80%属于查询功能，尤其是报表全是查询，我们完全可以把数据库进行分离，一个主库进行写操作，也就是增、删、改操作，一个从库只负责读操作，也就是查询操作，然后将主库的写操作实时同步到从库中，保证从库读到的数据和主库写入的数据是一致即可。
（一个厨师也忙不过来，又请来一个做配菜单的，原来的厨师只负责炒菜）
分库分表
该学校是80年代修建的面积有限，教学和日常 生活已经完全不能承载这么多学生和教职工，学校后来又在南边的大学城新建了新校区，面积大，环境又好，而且该大学作为示范，校园没有围墙完全是开放式的，甚至他们的一卡通可以让整个大学城里的学生都可以使用，不限制为本校区，本人上的大学也在这个大学城有分校，为了让学弟学妹吃好喝好，免费帮他们设计了新的架构，上次是对数据库进行主从分离和读写分离，但本质是这两个数据库是一个数据库，数据完成一样，当写的操作增多时还是单节点满足不了并发的需求。
解决方案也比较明确，减轻对单数据库访问压力，所以再次对数据库进行分库分表的拆分，该系统负责人建议将数据库按业务拆分为三个数据库，分别是食堂数据库、超市数据库和其它数据库，本人当时极力反对这样的横向业务拆分，因为这样改动太大，几乎所有的业务代码都需要修改，开发量大，而且最熟悉这个系统的几位程序员都已经离职了，所以这样干风险太大了，我给他们的建议是纵向拆分，也就是按地域进行拆分，老校区一个数据库，新校区一个数据库，这样底层代码和数据库结构基本不需要进行修改，只需要应用在请求数据库时带上标识是请求老校区的数据库还是新校区的数据库即可，改动很小，也解决了他们碰到的问题。
（将厨房进行拆分，做面的一个厨房两个厨师、炒菜的一个厨房两个厨师）
微服务化
该学校进行第三产业分离，将学校食堂也组建为独立的市场化服务公司，他们想到了一个点子很有意思，可以将学校食堂里的餐食进行外卖服务，一方面很多学生懒得都不出宿舍和下楼，但他们需要吃饭，外面的外卖又不能送进来，另一方面学校食堂的饭菜量大、干净卫生还便宜，而且还有很多剩余人员没有地方安排，可不可以将食堂饭菜对外配送，老校区地理位置好周围全是写字楼，说干就干，前端开发了送外卖的app和食堂档口接单的app，后台进行了微服务架构重构，支撑互联网化的大流量和高并发需求。
.（将餐厅进行了专业化拆分，客人可以在一家餐厅吃到整条街的美食）
该公司微服务化后，发展非常快，很快完成了资本化进行了多轮融资，业态已经涉及到老百姓的方方面面，并购了几个大公司，IT系统架构一下子变的复杂了很多，系统层面各子公司都有自己的业务系统来处理会员、订单、商品和交易，但他们之间交互很困难，协调起来也很费劲，比如某一方都想使用其它方的会员信息进行业务扩展，大家都提出集团能不能做一个共享的会员中心让各业务公司使用，各业务公司就不要建设自己的会员体系了，这个思路正是阿里提出的IT中台架构，我们看看能不能解决以上的问题？
服务中台化
中台化是将软件中有共性的、可复用的部分提炼出来，作为一个独立的、中心化的个体，快速满足多业务场景的需求和发展。上面的微服务架构只是实现中台架构的一种技术方案，看如下的中台架构图：
上图中有三个业务中心：订单中心、商品中心和会员中心，由它们实现了业务中台架构，每个中心都有自己的应用服务器（集群）、缓存服务器、文件服务器和数据库，业务中心之间是相互独立的，现实中也是由不同的研发团队负责开发和运维，更重要的是各业务中心是独立运营的。业务中心左边是小前端也就是业务应用，比如一卡通应用、外卖应用和自助洗车应用，它们不需要再去实现订单、商品的功能了，只需要使用业务中心提供的能力即可，基于业务中心的能力去实现自己的业务场景服务用户。
从应用到中台看（从左到右），一卡通应用对于自己下订单流程非常精通，但它不知道外卖点餐应用的下单流程是什么样的，它也不需要知道，外卖点餐应用也不清楚一卡通的订单流程，而在右边的订单中心需要给所有需要订单流程的业务应用提供订单服务，那么开发和运营订单中心的人员能从订单的维度全面掌握企业的业务流程，甚至是这一方面的业务专家，这样更容易发现问题的本质，在各业务中心去解决问题，更容易找到关键点创新业务价值。
后面我们将用中台思想进行企业IT架构的设计讲解。