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