千万级调用的电商服务架构实现总览

618相信有不少小伙伴也参加了这场促销抢购吧，但作为一个程序员，你又知道促销期千万级别访问量背后的架构及实现吗？

电商是典型的促销拉动式场景，也是价格战驱动的场景。618和双11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下，对秒杀、抢购是很热衷的玩法。

促销式的拉动对系统的挑战是什么呢？

从上图可以看到：对系统的高可用要求非常高的，需要99.99%的高可用性。快速迭代对对系统容性的要求很高，从几万单变成几十万单、百万单，架构上不能影响快速迭代，所以有空中加油或者是高速公路换轮胎的说法。

 

基础架构层

这层实际上是中间件和服务，包括MQ的消息、Job的调试中心、sso联合登陆，还有发消息的，分布式的文件存储，用户上传的一些图片等等，除此之外还有应用监控的整个体系、自动发布。

基础服务层

再上面一层就是基础服务层，这实际上是用基础架构层提供的组件和服务，加上一些业务逻辑，构建了一些公用的服务，包括OMS、运费模板、配送区域等，这些都作为最常用的基础服务。

业务服务层

业务服务层实际就是我们的接口及业务具体的实现，如首页Banner，购物车、下单+支付等。这层就是所有网站应用的核心。除此之外就是第三方平台的api对接。

最顶层的就是我们可以看到的，这些就是各个端了，如APP，PC商城、官网等。

微服务架构的设计实现

很多电子商务网站在最初都不是微服务化的，早期的项目基本都是一个单体应用。随着订单量的发展，服务压力的不断增大，大多数网站开始走上“微服务化”之路。对原来的单体应用进行拆分，拆分当然有几个维度。

拆分维度：

• 从系统的维度，最简单的拆法就是前后台拆开，实现后台与页面分离。

• 从功能的维度，从service层和表结构的拆分、独立部署，这也就是微服务的概念了。这也就我们看到的用户服务、商品服务、订单服务、支付服务的具体体现。

微服务架构搭建

微服务架构是将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责。那服务有要注意其他什么问题呢？

数据的异构

在大型电商系统里面的服务架构搭建的经验和技巧。首先是数据的异构，以订单表为例，一般订单都非常庞大，一般按照id来分表分库。这种分法对于查询用户所有订单时就要去各表捞数据，因此可以按用户维度来异构一张表。对于数据的存储，会分为热数据、冷数据和温数据，分别存在不同的地方。同时也会对数据进行聚合。在一些订单详情页，由于有很多ajax请求，由于请求数太多，也需要做一些请求合并。后台的服务也要做一个合并。以商品详情页为例，使几个接口的数据缓存合并在redis中，从redis中取得聚合好的数据，称为数据闭环。这是优化网络请求的通常做法。

缓存

缓存在大型电商系统中是常用的优化技巧。浏览器级别的缓存通过响应头进行设置。还会用到app客户端的缓存，把H5/CSS/JS/图片打包，提前拉到客户端，在客户端做一个代理服务器，但是不会读取数据。可以提升用户体验。缓存的使用在网络上还有常用的cdn。进到接入层后，如果使用软负载，也可以使用内存级别的缓存，如：Redis，MongoDB。

消息队列的应用

应用消息队列是做服务解耦的好方法。但也要考虑消息失败和重试的场景，需要来做一些补偿处理。一般很多的场景能做到的是最终一致性，大型的电商系统和金融系统场景非常不一样，在设计分布式系统时，这是常用的方式。

高可用的架构设计

高可用的架构设计，对于电商来说，已经是最基本的要求了。否则，在促销期间，如果千万级别的用户请求造成宕机，那损失不可预估。

服务的降级及故障隔离

基于微服务架构的电商系统，高可用的方案有以下几个部分，首先要支持服务的降级。要做降级的开关，写在配置中心里面。比如在大促时，先把订单放在缓存时，再进行落库等操作。同时还要有服务分组和故障的隔离。比如秒杀时，对秒杀的应用单独部署，当秒杀的应用挂了之后，不会影响其他服务，因为有服务的隔离。同时要有限流机制，很多的框架都有支持。

动态路由

国内的网络环境很复杂，比如南北互联等。要提高服务效率，需要在应用端（如App）做智能动态路由。可以上一些cdn，对动态的内容也做链路优化。

埋点和网关

移动电商里对app来说还有一个很重要的是埋点，指的是全链路埋点。从app里用户的每一个操作，这个操作经过网络、服务层、中间件，整个链路要可以监控。对于快速的定位问题是非常有帮助的，尤其是移动电商性能的优化，第一步就是埋点。