微服务架构之千万级调用量架构实践

随着微服务的兴起，微服务的应用越来越广，要求也越来越高，当然系统复杂度也是逐渐递增

微服务架构在大型电商中的运用

1、传统电商业务困境

• 高可用性
• 高可伸缩
• 架构柔性
• 数据实时
• 平台开放

如图：

2、传统大型电商系统的架构

数据层，埋点数据把用户行为数据，实时数据存储在NoSQL、关系型数据库、大数据平台 。

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

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

业务服务层
业务服务层我们可以看到的是，比如用户在前台能看到的界面，比如购物车、订单、首页，不管是不是微服务，至少是服务化的。这层就是所有网站应用的核心。除此之外就是第三方平台的api对接。

虚拟类目相当于“标签”，比如我们正常的类目叫做“生鲜”、“服装”，还有一些虚拟的类目叫做“618特卖”，里面会聚合很多的商品，可以理解为一个标签，作为展示用。

暴露在最顶层的我们可以看到，这些就是各个端，比如H5、PC、官网，这就是最终可见的端。

3、微服务架构的设计

应用的无状态化
很多网站一开始可能不是微服务化的，在早期的一些项目里，我们为了快速上线交付，会做一些单体的应用。随着订单量的发展，我们就开始做所谓的“微服务化”，第一步是把所谓的单体应用，变成应用的无状态化，以登录SSO来看，就是一种解决去状态化的方法。我们会拿到一个token，每次访问都会带着token，这就是所谓的去状态化。之后每一个应用都有横向可扩的能力。当访问量大的时候，就可以通过加服务器来增强水平扩展的能力。

这种应用无状态，其实配置文件还是有状态的。比如访问的数据库和节点，这些是通过配置文件来完成。我说到的案例基本都是基于spring boot来做微服务化，相关技术框架包括：dubbo、zk、hystrix、rocketmq、elasticsearch、redis等等。

单体应用的拆分
在做了应用的无状态之后，就是对单体应用的拆分。拆分有几个维度，一个是从系统的维度，最简单的拆法就是前后台拆开。比如购物车、商品、搜索、首页等属于前端，而后端给网站运营人员用。

还可以按功能的维度来拆分，对于用户服务，从service层到表结构，其实是可以独立部署的，这就是微服务的概念。技术架构反应的就是组织架构，在这种架构下开发团队分为用户服务开发组，价格开发组，商品开发组等。

还可以根据读写维度进行拆分。比如搜索和商城的索引肯定是独立的两个服务。用户注册下单支付是一个完整的业务流程。这些是由若干个微服务构成。

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

以商品详情页为例，使几个接口的数据缓存合并在redis中，从redis中取得聚合好的数据，称为数据闭环。这是优化网络请求的通常做法。

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

消息队列的应用
消息队列的应用，是做服务解耦的好方法。也要考虑消息失败和重试的场景，需要来做一些额外补偿来防止数据丢失。还有一个机制是数据的校验和补偿。很多的场景能做到的是最终一致性，大型的电商系统和金融系统场景非常不一样，在设计分布式系统时，这是常用的方式。在电商中大多数情况只要实现最终一致性就可以了。

高可用的架构设计
高可用的架构设计，对于电商来说，其实高可用是最基本的要求。如果在促销时，引来千万级别的用户，宕机会损失很大。

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

流量治理
在极限的场景下， 对流量的治理要从多层面进行。比如在促销当天，会开启对于爬虫和机器人的流量进行限流。一般会在大促前进行封板，如果出现问题，就进行回滚，比如数据版本的回滚，在设置数据结构的时候，要做支持带数据版本号的回滚。

业务设计
业务设计方面的思考。从图中可以看到订单支付的流程。在设计的时候要考虑防重设计，可以采用防重key或者防重表的方案，但是耗费和代价很高，会在某些场景使用，比如积分，扣费等和金钱相关的场景下用。

业务设计要考虑状态机。尤其是订单的流转状态里，要做状态机的应用，包括正向和逆向流程，及其产生的结果。

动态路由
最后来回顾一下大型移动电商的架构。下图是一个移动电商的完整架构。从app端，主要做的是静态文件的缓存和智能的动态路由。中国的网络环境很复杂，需要在app端做智能动态路由。可以上一些cdn，对动态的内容也做链路优化。会有一些对网络环境检测的机制，可以是cdn，或者是走域名，也可以暴露ip。

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

在网络这一层，还有网关的接入。比如限流，动态负载。在网关里没有加太多逻辑，也有不同的做法。对于服务来说，最复杂的是服务的依赖和治理。服务之间调用的优化要基于业务场景，比如说购物车的服务，调用到价格、库存、促销等。当依赖的服务不可用的时候，比如价格不可用，设计依赖的时候，要在购物车服务中做一个缓存，来对缓存调用，最后再对最终一致性进行验证。

全链路监控的做法，需要做到预警，这就是一个基础。通过对数据的监控请求来后，根据场景来做预警方案。