架构实战案例解析_05_04_可扩展架构案例一电商平台架构是如何演变的
你好，我是王庆友。
上一讲中呢，我们介绍了如何打造一个可扩展的架构。
那今天我就针对最近十几年电商平台的架构变化过程来具体说明一下，为了支持业务的快速发展架构，它是如何一步步演进的那从零三年淘宝上线开始，国内电商平台经历了一个快速发展的时期。
在这个过程中呢，系统也遇到了很多的过程。
比如说如何针对当前的业务现状，选择合适的架构呢？还有啊如何在业务发展过程中升级和改造架构并保证系统的平滑过渡呢？那接下来我会结合自己的工作实践，和你一起探讨架构的这个演变过程。
从中呢你可以了解到各种架构，它的优劣点和适用性，然后在实际工作中可以选择合适的架构去落地。
这里我大致总结了国内电商平台架构发展的落程。
你可以结合文稿中的图片参考一下，从两千年开始到零六年，大致是个单体的架构。
那么从零六年到零九年，主要是分布式的架构。
那么从零九年到一四年，主要是SOA的架构。
那么从一四年到一八年呢，又是个微服务的架构。
那么从一八年开始呢，我们也进入了一个中台架构的时代。
我们可以看到，从最初的单体架构到最新的中台架构，架构的扩展性呢它是越来越强。
这些呢都是系统不断适应业务复杂化的结果。
下面我就结合电商业务的变化，按照顺序和你介绍一下各个架构。
那因为篇幅的原因，对中台架构我会放在下一篇文章里重点介绍。
先来说一下单体架构在单体架构中只有一个应用。
那所有的代码呢它跑在一个进程里面，所有的表呢也放在一个数据库里面。
第一代电商平台都是单体架构。
比如说淘宝，它在最初的三年，它的系统啊就是一个巨大的单体应用。
单体应用内部呢它一般采用分层的结构，从上到下一般分为表示层、业务层、数据访问层和DB层。
那表示层呢它负责用户的体验，业务层，负责业务逻辑，数据访问层，负责DB的单据存取。
那这里呢有张张图，你可以到文稿中去一下。
这里我们可以看到各层的职责呢正好对应业务处理的不同阶段。
所以单体架构啊它在水平方向上，通过层次化的划分，降低了业务上深度复杂性。
不过在垂直方向上，单体应用呢它缺乏清晰的边界。
那上下层模块之间呢是多对多的网上依赖关系。
比如说业务层的某个模块，它可能调用数据访问层的所有模块。
同样的道理呢，数据访问层的某个模块也可能被业务层的所有业务模块调用。
所以说单体架构中的模块，它只是在逻辑上相互独立，并没有在逻理上严格的区分开。
那导致系统在落地时呢，模块的职责和边界划分往往比较随意，相应的模块之间的依赖关系也比较模糊。
所以，在单体架构中，模块结构是否合理，很大程度上依赖开发的个人水平。
那在电商发展的初期，业务并不复杂，比如前台的首页、搜索页、详情页和结算页等等。
页面的功能呢都比较简单，我们可以放在一个应用里进行处理，这样是用单体架构可以快速的落地系统。
但是当业务开始变得复杂时，每个页面都发展为一个独立的业务体系。
比如说首页，它原先呢只展示相对固定内容，现在呢发展成为一个动态的千人千面系统。
这样子一来，业务的复杂度急剧的上升，模块的数量呢也大幅度增加了。
我们就很难在代替架构里，通过构建一个清晰的模块体系来支持系统的扩展。
而且啊所有代码放在一个代码库里管理，如果多团队并行开发的话，很容易发生代码冲突，这样呢也难以满足系统的快速扩展。
这里举个例子，在零七年的时候，单备网站总体上也是个单体应用，它的核心工程包含了数百万行代码。
那由于代码合并和编译非常复杂，他们甚至有专门的团队负责代码合并，有专门的团队负责编译脚本的开发。
另外呢还有一套复杂的火车模型来协调不同团队之间进行并行开发和上线。
所以说当业务系统体量变大时，单体架构它的弊端就充分的暴露出来了。
我们这时候呢就需要对系统进行有效的拆分，比如把首页搜索页、详情页结算页等等拆成一个独立的应用，分别对他们进行应理。
于是分布式架构就出现了分布式架构。
简单来讲说就是系统有多个独立的应用组成，它们之间互相协作成为一个整体。
那在分布式架构里面呢，包含了多个应用，每个应用它分别负责不同的业务线。
那当一个应用需要另外一个应用的功能时，怎么办呢？他们会通过APR接口进行相互调用。
那在分布式架构中呢，APR接口往往属于应用的复杂分，从和表示成共享底层的一个业务逻辑。
所以啊你可以认为APR相当于应用在实现自身业务的基础上，对外呢开了一个小窗口，提供给外部应用使用。
那关于分布式的具体架构，我这里呢也放了一张图，你可以到文稿中去看一下。
这里你可以看到，分布式架构在单体应用的基础上，进一步对系统按照业务线进行了业务广度上的一个切分。
这样就把一个大系统的业务复杂度分割成多个小业务的复杂度，从而降低了整体的复杂度。
这么拆分后，各应用是之间呢它的耦合度很低，可以很好的支持多团队之间的并行开发，但分布式架构也有它的局限性。
作为应用的开发者，我们除了要满足自身业务的需求之外，同时还需要考虑外部业务的需求。
这两部分呢经常会打架。
比如说由于自身业务的需求引起了底层的业务逻辑修改，这个时候呢会影响API接口功能，导致其他业务也受影响。
那同样的道理，一个外部业务的需求之外，我们需要对api结构做调整。
即使这个时候不影响底层业务逻辑，这个呢也会调整整个应用，重新打包和部署，影响了自身业务的稳定性。
另外呢在分布式架构下，每个应用都是从头到尾自搭一套完整的体系，这样导致业务之间重复造轮子，造成资源浪费。
那举个例子，在零八年的时候，淘宝还没有开始服务化改造之前。
那不同业务线之间的用户商品订单，他们的逻辑非常类似，导致了整个系统有超过三分之一的核心代码重复。
所以你可以发现分布式架构，它是用业务相关性比较低耦合比较少的业务系统。
那举个例子，企业内部的管理系统它分别服务于不同的职能部门，比如说财务系统和HR系统。
这样的系统就比较是按照分布式架构去落地。
但是在电商场景下，业务都是围绕交易展开的，各个页面都需要和商品用户订单库存打交道。
对这样一个业务相互依赖、应用之间需要紧密协助的场景。
在系统架构层面，我们是否有更好的手段可以更高效的集成这些应用呢？那答案是有的，SOA架构就可以有效的解决这个问题。
那接下来我们就具体了解一下SOA架构，它是一种面向服务的架构。
它的发展呢经历了两个阶段，一个是传统的SOA架构阶段，它解决的是企业内部大量异构系统集成的问题。
还有一个就是新的SOA架构阶段，它解决的是系统重复建设的问题。
下面呢我就展开和你详细的高潮。
那从两千年开始，很多传统企业进入了信息化建设的高潮。
那后采购了很多系统，比如说ERPOACIM等等。
这些系统呢都是由不同的供应商提供。
落地后呢，他们形成很多的信息孤岛。
但是随着业务的发展，企业需要打通这些不同的系统。
那么问题来了，这些系统使用不同的技术，事先呢也没有提供开放接口给外部使用。
那我们如何才能有效的集成这些系统呢？那这里的解决办法是，每个系统首先把外部需要的能力分装为一个个粗力度的接口，打包成一个独立的服务。
然后啊外部系统通过这个服务来访问系统内部，这样子呢解决不同系统相互之间集成的问题。
经过这样子的改造系统，最后就变成了一个面向服务的SOA架构。
这里我放了一张传统的SV架构图，你可以到文稿中去看一下。
你可以看到在SOV架构中，每个服务它都对应了一个现有的系统。
所有这些服务又都部署在一个中心化的平台上，我们称之为企业服务总线ESB.那这个ESB呢它负责管理所有调用过程的技术复杂性，包括服务的注册和路由，各种通信协议的支持等等。
那比如说在零九年的时候，易贝就基于access to开发了自己的所有框架，让各个系统可以通过提供标准的服务来满足外部调用需求。
比如说一个后台的搜索系统，它本身是c加加开发的。
但是它通过提供一个java服务分装常见的搜索功能。
那么其他系统大都是java开发的，就可以和搜索系统进行集成。
那以上讲的呢是传统的SOA架构，它主要用于解决遗留系统的集层问题。
啊，新的SOA架构呢，它利用服务共享的思想，很好的解决系统的重复开发问题。
那举个淘宝的例子，淘宝的系统基本上是自建的系统，相互之间打通的问题不大。
经经过段段间间的自生生长系统用的逻辑的问题很突出啊，前面我们也提到了有超过三分之一的核心代码重复。
那针对这种情况，我们就可以通过服务化手段，把通用的逻辑和数据从各个业务系统里抽取出来，分装种独立的服务，提供给所有业务线进行共享。
那基于这个思路呢，淘宝花了两到三年的时间，先后落地了用户商品订单、库存、店铺营销等服务，搭建了一个共享服务体系。
通过共享淘宝，不仅提升了开发效率和质量，也加强了系统的扩展能力。
这里呢我也放了一张新的SOA架构的图，你可以到文稿中去看一下。
那我们看到相对于分布式架构，SOA架构给系统的扩展带来了一系列好处。
首先它通过服务化的思想提供更好的业务分装性，并且通过标准的技术更友好的对外输出这些业务能力。
其次呢SOV服务它不依附，具体某个应用，它可以独立的部署和扩展，这样避免了直接影响现有系统。
最后，服务通过分装通用的业务逻辑可以供所有应用共享，解决了重复造轮子的问题。
不过呢虽然SOA服务化的思想很好，但在系统实现上它比较重，落地比较困难。
那有没有更轻量级的架构，使得系统各个部分更容易构建和相互协作呢？这个时候啊微服务的架构便悄悄的来了。
关于微服务大家都不陌生，但究竟什么是微服务，每个人理解可能都不一样。
接下来我就基于自己的服务化大实现和你分享我自己的看法。
首先微服务概念的提出，一开始它是用来和单体架构做区分的那我们知道单体架构和分布式架构实际上都是围绕一个大的业务线来构建应用它。
当业务变得复杂时呢，就无法做到模块边界和依赖关系的一个清晰划分。
那模块局部的调整往往会导致系统整体的调整，使得系统呢很难扩展。
而微服务啊它围绕的是更小的业务单元来构建独立的应用。
比如说一个飞机航班的预定系统，我们可以把它划分为预定航班、时间表、查询、计算、票价、分配、座位等几个小的应用呢来落地。
那么经过划分后，每个小应用都比较简单，只关注一个业务功能就可以了。
那这里需要注意的是，每个微服务它都负责端到端的业务，包括了前端的UI展现部分和后端的业务逻辑。
那微服务的团队成员呢也可能包含产品开发、测试、运维等人员，有这个小团队负责应用的整个生命周期管理。
因此，从一定程度上说，微服务叫做微应用，或者说微产品更加合适。
你也可以认为微服务架构它是拆分的更细的分布式架构。
那另外呢微服务强调围绕业务进行清晰的业务和数据边界划分，并且通过良好定义的接口输出业务能力。
这个呢和SOA架构的服务非常类似，但两者不同的地方在于微服务，它是去中心化的，不需要SOV架构中ESB的集中管理方式。
一方面，微服务强调所谓的亚管道，也就是说客户端通过HTP等简单的技术手段来访问微服务，避免重的通信协议和数据编码格式的分章。
另外一方面呢，微服务强调智能终端，也就是说所有的业务逻辑它就包含在微服务内部。
我们不需要额外的中间层提供业务规则的处理。
这样子微服务提供方可以自由的选择，语言和工具落地，微服务，微服务的部署维护上也更加灵活。
那从这个意义上说，你也可以认为微服务它是轻量级的SOV服务。
所以说微服务同样有应用和服务的特征。
你可以微服服理解为微服务等于小应用加小服务。
这个呢就是微服务架构设计。
它的初衷中是在实践中我们更多的把微服务当做一个小服务来实现，而不是一个端到端的小应用。
那为什么会这样子呢？这里有几个原因。
首先啊我们很难把一个大系统按照端到端业务的方式拆分为一个个应用，而拆分为服务呢是比较灵活的。
我们可以把系统核心的业务逻辑和数据分装成服务，那系统其他部分还是可以以应用的方式去落地。
另外一方面，微服务它要求团队人员跨多个职能，构建独立的小团队去负责服务完整的生命周期。
这个就需要我们把现有的职能团队这种方式打散后进行人员重组。
这种人员组织的调整实际上也很难落组。
所以微服务强调围绕端到端的小业务功能，通过逐渐跨职能的团队进行落地。
这个呢是个比较理想化的做法。
在实践中，我们往往弱化微服务的小应用的定位，然后呢扩大化微服务小服务的定位。
我们不再强调端到端的业务分装，而是可以有各种类型的微服务。
比如说分装底层基础业务的是共享微服务，分装流程的是聚合微服务。
分装一个具体业务场景的服务端，它就是应用微服务。
分装基础中间界能比如说RDIS缓存的消息推送，这些呢是系统微服务。
当然这些服务在落地地，我们还是采取取去心心的的机制，使用轻量级的通讯系统。
最后呢把它们打造成一个个技术上轻量级的功能，知识上细分的微服务。
所以据这样子的输入，微服务就很容易构建。
同时呢像水电煤一样容易被我们使用。
然后我们在这个基础上组装微服务，像搭积木一样的去构造系统，这样的系统就非常具有弹性，更容易扩展。
那值得注意的是，我们需要对服务的依赖关系进行有效的管理，打造一个有序的微服务体系。
否则的话，东一个服务西一个服务，这样会让系统变成碎片化，难以维护和扩展。
所以我这里也放了一张图，来帮助你理解一个有序的城市化微服务体系。
大致什什么子子的，你可以在文化中去看一下。
最后我们做要总结。
今天我和你分享了电商平台架构的发展过程，从单体架构到分布式架构，再到SOA架构和微服务架构。
每种架构啊，它都是针对前一种架构的缺点，做了改进，架构的扩展性也变得越来越好，可以满足更高的业务复杂性要求。
也值得注意的是，每种架构都有两面性，既有优点，又有缺点。
在实际系统中呢，这些架构也都是并存的。
所以说架构没有最好，只有最合适的。
那么在做架构设计的时候，一定要根据当前业务的特点，选择合适的架构去落地。
那么通过今天的分享，相信你对架构的扩展性有了更深入的理解。
也能够根据公司的业务现状进行更合理的架构选型了。
那最后给你留个思考题，那么我们人人都在落地微服务，你在这方面有什么经验和教训吗？欢迎你在留言区和大家分享你的答案。
如果你在学习架构，实践过程中有什么问题或者思考，也欢迎给我留言，我们一起讨论，感谢收听，我们下一期再见。