海拍：电商平台是怎么演变的？（一）

曾经经历过几家电商业务的单位，有医疗电商、快销品电商、本地服务生活电商等。为了简化，我拿交易系统和商品系统两个比较有代表性的业务，来分析下电商平台的发展过程，遇到的瓶颈，以及架构上是怎么解决的。

单体架构

一般的电商系统开始都是一个单体架构，所有的代码都打包在一个应用里，部署的时候会有多个实例，我们通过负载均衡，把用户请求分发到具体的实例中。这个时候，所有的数据表还在一个数据库里。

SOA架构

我们对系统进行拆分，把整体系统分为多个子系统。我们把系统拆分为交易系统和商户系统，通过内部的负载均衡进行相互调用，这个时候，底层数据库还没有拆分，两个系统还是访问同一个数据库。通过拆分，系统整体就变成了 SOA 架构。

问题:内部服务通过中心化的负载均衡进行访问，中心化的负载均衡增加了服务的调用时间。此外，在电商场景下，内部的服务很多，服务调用的频率很高，每秒可能有上百万次，导致了负载均衡的连接能力不够。而且负载均衡是单点，如果它出了问题，很容易引发系统整体的可用性问题。

服务调用去中心化

针对内部服务路由中心化的问题，我们去掉了内部的负载均衡，加入了服务注册中心，比如 ZooKeeper。

当服务实例启动或退出时，它们会自动在注册中心进行注册或销毁，服务的客户端和注册中心保持长连接，可以实时地获取可用的服务列表；然后在客户端，根据相应的算法选择服务实例，直接调用服务。每次调用无需经过注册中心，如果注册中心有问题，也只是新的服务实例无法注册，或者是已有的服务实例无法注销，这对客户端调用服务的影响是非常有限的。

垂直分库

对于单个数据库性能和容量瓶颈，解决的办法就是，我们对数据库进行垂直拆分，按照业务拆分为交易数据库和商品数据库，这样就可以满足它们各自的容量和性能需求，同时也避免了不同业务数据表之间的相互耦合。

海拍

跳出传统拍卖方法，创新商业模式，实现“二手货，拍才值”的消费价值新理念