首届阿里巴巴中间件技术峰会上，阿里巴巴中间件技术部专家唐三带来“阿里电商架构演变之”的，本文从阿里业务和技术架构开始引入，分别分享了阿里电商从1.0到4.0架构的演变之，着重分析了分布式和异地多活的改变之。 阿里已经不单单有电商业务，今天我们涉猎的非常广泛，布局也非常多。阿里从一家电商公司开始，如果业务已经覆盖到了各个行业，图为2015年的布局。按照这样的业务发展速度，如果没有一套完整的技术体系支撑，势必会影响整个业务的发展。
可以看到我们的技术是分层的,在最上的是业务，中间部分是中间件、搜索和大数据等中台系统。整个的大中台体系就是中中间这层通用的技术能够快速支持上层业务的快速发展。只要是用发中台的技术体系，都能够在快速的搭建自己的业务。
整个中台包括部分如图，除了中间件、搜索，还有一些数据分析。中间件在业务研发的过程中起到非常重要的作用。这是在我们整个技术架构演变过程中，逐渐形成的一套体系。 整个淘宝网从开始想去创建，到真正上线，总共经历了一个多月的时间。那这一个多月的时间都做了些什么呢？
第一件事情，我们开始做技术选型，决定我们后续怎么发展；第二件事情，如何在一个多月的时间，让我们的网站上线我们购买了一套基于LAMP架构的电商网站，并且拿到源代码，我们对其进行二次开发，比如界面的UI改动，上下title的改动，其中最大的改动就是我们对它的数据库做了读写分离。
随着业务量的增长，就会发现一些瓶颈，主要来自于数据库。当时的数据库是MySQL4，还不够稳定，数据库经常会出现死机。因此，我们直接把数据库换成oracle，通过PHP和oracle直接去连接进行操作，但PHP不支持连接池，即使使用一些开源的PHP中间件，让PHP去连接oracle，还常不稳定，连接池的中间件经常卡死。 然后我们开始考虑将技术体系转成Java，因为Java在企业级的应用中，有着比较成熟的生态。的过程中也还是很坎坷的：第一，我们是一个线上正在运行的系统；第二，系统当时正在大规模的增长。所以说把系统替换成Java，最好的方法就是分块替换。同时发现，oracle的写入量还是比较大的，当时还做了一个search，把产品搜索和店铺搜索放到search里面，这样每一次的请求都打到数据库里面了，这样我们就完成了1.0架构到2.0架构的演进。 随着整个业务的发展，我们又迎来了新问题，洪峰流量给我们带来了巨大的挑战，电商行业在国内已经逐步开始盛行，我们的流量直线上涨，电商的人口红利也开始上涨。随着流量的上涨，我们面临着服务器和数据库的压力。 首先是淘宝上描述商品的图片特别多，图片问题非常严重，主要取决于我们采用的是商用存储，成本非常高，最高级别版本也很难存储下我们所有的图片； 第三，虽然数据库替换成了oracle，随着数据量的增大，我们所有的请求都打到数据库，这时数据库的存储也快达到了极限，压力也非常大。
所以我们开始对架构升级。第一，我们增加了内存cache，cache主要是解决数据库压力过大的问题，我们自己研制了一套Key/Value 分布式缓存（TAIR），就是在数据库前端加了一个内存cache，缓解了我们数据库的压力。第二，我们增加了分布式文件系统（TFS），之前的文件系统在商用的时候，成本太高，服务器的量非常大，所以我们研发了自己的一套文件系统。
随着我们的业务量逐渐增大，人也越来越多，这就导致开发成本特别高，当时我们是all-in-one系统，所有人改所有的代码都是在这一个系统里面，就会出现以下问题： 还有性能问题。随着前端业务量的增大，服务器逐渐增多的时候，oracle也出现了连接数的瓶颈。所以我们必须开始做新的架构，让整个架构往前走一步。
第一类是c类，是中心类，比如说会员、商品、店铺等等，基于这些中心开发各自的系统。比如说商品详情、交易下单； 还有一些公共的类，是p类，比如交易平台，这是从业务上进行拆分。几个比较知名的项目，比如千岛湖项目（拆分出交易中心、类目属性中心）、五彩石项目（拆分出店铺中心、商品中心、评价中心）。 伴随着技术架构的改动，我们的业务结构也开始进行改动，开始成立了相应的团队。上图的下半部分就介绍了我们架构的演变过程。开始时，是all in one，1~10在一个项目。第二个阶段是10~1000人的MVC架构，实现了前后端分离，各司其职。第三个阶段是RPC，就是把各个系统进行拆分，然后各个系统之间进行通信。第四个阶段就是SOA这样一个模式。
重点分享RPC的发展历程。我们把应用拆成才c类、p类、垂直团队类。这些应用本来就是在一个大应用里面，他们之间可以很自然地进行通信，可以直接进行相互调用。但是拆分之后，我们的应用如何进行相互调用？ 我们开发了轻量级的HSF框架，它是基于Java intece 的RPC框架，使得开发系统时就像开发本地应用一样去正常的调用Java。使用这个框架可以真正远程的调用到其他的系统。 随着应用逐渐发展，我们会依赖中间件或者各个产品之间相互依赖。为了解决Jar包冲突的问题，我们研究出了Pandora容器。这个容器能把所有的加包做隔离，当发生Jar包冲突的时候，它知道优先加载哪个，这样，我们就把Jar包冲突的问题解决了，那服务发现怎么办呢？比如：一个应用A如何知道应用B里面有多少台机器呢，你的ip又是什么？最简单的方式就是静态列表，记录下ip，做轮询策略，先调用A的1号机，再调用2号机。这样就没法实现一个动态的发现。所以在这个过程中，我们有一个动态的配置中心（configserver），在你服务上线的时候，作为provider把服务放到configserver上去，当需要消费这个服务的时候，会看哪些服务可以调用，然后把这个列表拿到。 Configserver会自动把相应的provider的ip推送到consumer。然后consumer会自动发现provider的服务，然后彼此会发生一个相互调用关系。如果configserver挂掉之后，你的provider是挂不上去的，但是已经发上去的服务是不受影响的，因为configserver已经把相应的服务推送到consumer。当我们把分布式系统变得庞大之后，其实各个系统各司己职就好了。
Oracle其实也产生了性能瓶颈，而MySQL经过了多年发展，已经非常的成熟和稳定了。我们考虑把数据库做拆分，也就是去IOE。对MySQL进行拆分，其实就是按照一定的规则去分库分表。拆分首先就是读写分离，然后做垂直拆分，还有水平拆分。垂直拆分主要是按业务来拆分，当垂直拆分到一定程度之后，有一些大业务还是不能承担这样的数据量，我们只能水平做分库分表，做sharding的拆分。分库分表就基于某一些主键算，如果主键符合什么样的条件，就Sharding到什么服务器。但是让每一个业务系统去做的成本常高的，一定要有一个中间通用的东西，能够解决数据库水平拆分的问题。 推荐：
|
