电商平台架构演变

大家好，我是易安！

今天，我以国内这些年来电商平台的架构的角度，来具体说明下，电商架构是如何一步步演进的。

从2003年淘宝上线开始，国内电商平台经历了高速的发展，在这个过程中，系统遇到了很多的挑战，比如说:

• 如何针对当前的业务现状，选择合适的架构呢？
• 如何在业务发展过程中，升级改造架构，并保证系统的平滑过渡呢？

这里，我总结了国内电商平台架构发展的大致过程，你可以结合图片参考下。

我们可以看到，从最初的单体架构到最新的中台架构，架构的可扩展性越来越强，这些都是系统不断适应业务复杂化的结果。下面，我就结合电商业务的变化，按照顺序和你介绍下各个架构。因为篇幅的原因，对于中台架构，我会放在后面的文章里重点介绍。

单体架构

单体架构其实是在微服务时代才给出的定义，在单体架构中，只有一个应用，所有代码跑在一个进程，所有的表放在一个DB里。第一代电商平台都是单体架构，比如说淘宝，在最初的3年，它的系统就是一个巨大的单体应用。

单体应用内部一般采用分层结构，从上到下，一般分为表示层、业务层、数据访问层、DB层。表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB的数据存取。

我们可以看到，各个层的职责，正好对应业务处理的不同阶段，所以，单体架构在水平方向上，通过层次化的划分，降低了业务的深度复杂性（所谓的业务深度，指的是业务流程从开始到结束的长度）。

不过在垂直方向上，单体应用缺乏清晰的边界，上下层模块之间是多对多的网状依赖关系，比如业务层的某个模块（上图中BO1），可能调用数据访问层的所有模块（DAO1~3）， 同样的道理，数据访问层的某个模块，也可能被业务层的所有业务模块给调用。

所以，单体架构中的模块只是在逻辑上独立，并没有在物理上严格分开，导致系统在落地时，模块的职责和边界划分比较随意，相应地，模块之间的依赖关系也比较模糊。所以，