以淘宝为例，解析大型电商服务端架构！ _架构

若汐缘
https://www.jianshu.com/p/796f488fd134

前言以淘宝网为例，简单了解一下大型电商的服务端架构是怎样的。如图所示最上面的就是安全体系系统，中间的就是业务运营系统，包含各个不同的业务服务，下面是一些共享服务，然后还有一些中间件，其中 ECS 就是云服务器，MQS 是队列服务，OCS 是缓存等等，右侧是一些支撑体系服务。

文章插图

除图中所示之外还包含一些我们看不到的，比如高可用的体现。淘宝目前已经实现多机房容灾和异地机房单元化部署，为淘宝的业务也提供了稳定、高效和易于维护的基础架构支撑。
这是一个含金量非常高的架构，也是一个非常复杂而庞大的架构，当然这个架构不是一天两天演进成这样的，也不是一开始就设计并开发成这样的，对于初创公司而言，很难在初期就预估到未来流量千倍、万倍的网站架构会是怎样的状况，同时如果初期就设计成千万级并发的流量架构，也很难去支撑这个成本。
【以淘宝为例，解析大型电商服务端架构！】因此一个大型服务系统，都是从小一步一步走过来的，在每个阶段找到对应该阶段网站架构所面临的问题，然后不断解决这些问题，在这个过程中，整个架构会一直演进，同时内含的代码也就会演进，大到架构、小到代码都是在不断演进和优化的。所以说高大上的项目技术架构和开发设计实现不是一蹴而就的，这是所谓的万丈高楼平地起。

文章插图

单机架构从一个小网站说起，一般来说初始一台服务器就够了，文件服务器、数据库以及应用都部署在一台机器上。也就是俗称的 allinone 架构。

文章插图

多机部署随着网站用户逐渐增多，访问量越来越大，硬盘、cpu、内存等开始吃紧，一台服务器难以支撑。看一下演进过程，我们将数据服务和应用服务进行分离，给应用服务器配置更好的 cpu、内存等等，而给数据服务器配置更好、更快的大的硬盘，如图所示用了三台服务器进行部署，能提高一定的性能和可用性。

文章插图

分布式缓存随着访问的并发越来越高，为了降低接口的访问时间提高服务性能，继续对架构进行演进。
我们发现有很多业务数据不需要每次都从数据库中获取，于是我们使用了缓存，因为 80% 的业务访问都集中在 20% 的数据上 (二八原则)，如果能将这部分数据缓存下来，性能就能提高很多，缓存又分两种，一种是 Application 中的本地缓存，还有远程缓存，远程缓存又分为远程的单机式缓存和分布式缓存 (图所示的是分布式缓存集群) 。
我们需要思考几点，具有哪种业务特点的数据使用缓存，具有哪种业务特点的数据使用本地缓存，具有哪种业务特点的数据使用远程缓存。分布式缓存在扩容时会遇上什么问题，如何解决，分布式缓存的算法都有哪几种，都有什么优缺点。这些问题都是我们在使用这个架构时需要思考并解决的问题。

文章插图

服务器集群这个时候随着访问的 qps 不断提高，假设我们使用的 Application Server 是 Tomcat，那么 tomcat 服务器的处理能力就会成为一个瓶颈，虽然我们也可以通过购买更强大的硬件但总会有上限，并且这个成本到后期是呈指数级的增长。
这时候就可以对服务器做一个集群 (cluster)，然后添加负载均衡调度器 (LoadBalancer)，服务器集群后我们就可以横向扩展我们的服务器了，解决了服务器处理能力的瓶颈。
此时我们又需要思考几个问题，负载均衡的调度策略都有哪些，各有什么优缺点，各适合什么场景，比如轮询、权重、地址散列，地址散列又分为原 IP 地址散列、目标 IP 地址散列、最小连接、加权最小连接等等。

文章插图

服务器集群后，假设我们登陆了 A 服务器，session 信息存放在 A 服务器上了，如果我们的负载均衡策略是轮询或者最小连接等，下次是有可能访问到 B 服务器，这时候存储在 A 服务器上的 session 信息我们在 B 服务器是读取不到的，所以我们需要解决 session 管理的问题。