微服务架构在千万级别日调用量亿级别海量数据场景下的应用实践

Posted 51CTO技术栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务架构在千万级别日调用量亿级别海量数据场景下的应用实践相关的知识,希望对你有一定的参考价值。

本文作者结合大型移动电商系统等应用案例,从领域驱动设计、服务依赖治理、服务高可用、故障熔断降级快速恢复等方面全面剖析微服务的应用。


前 1 号店技术总监、海尔农业电商CTO,《技术管理之巅》作者黄哲铿近日带来了一场关于微服务架构的分享,包含了微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践。


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


微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践

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


促销式的拉动对系统的挑战


可以从上图里看到:对高可用性的要求是非常高的,需要 99.99% 的高可用性。


快速迭代对系统容性的要求很高,从几万单变成几十万单、百万单,架构上不能影响快速迭代,所以有空中加油或者是高速公路换轮胎的说法。


另外,为了应对瞬间的海量访问(尤其是秒杀场景),系统需要高可伸缩(快速扩容和缩容),这些都是对系统的要求。


大型电商系统的架构


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

微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践

基础架构层


这层实际上是中间件和服务,包括 MQ 的消息、job 的调试中心、sso 联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等。


除此之外还有应用监控的整个体系、自动发布的框架,支持到 AB 测试。


基础服务层


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


业务服务层


业务服务层我们可以看到的是,比如用户在前台能看到的界面,比如购物车、订单、首页,不管是不是微服务,至少是服务化的。


这层就是所有网站应用的核心。除此之外就是第三方平台的 API 对接。


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


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


微服务架构的设计


应用的无状态化


很多网站一开始可能不是微服务化的,在早期的一些项目里,我们为了快速上线交付,会做一些单体的应用。


随着订单量的发展,我们就开始做所谓的“微服务化”,第一步是把所谓的单体应用,变成应用的无状态化,以登录 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 里用户的每一个操作,这个操作经过网络、服务层、中间件,整个链路要可以监控。


对于快速的定位问题是非常有帮助的,尤其是移动电商性能的优化,第一步就是埋点。


在网络这一层,还有网关的接入,比如限流,动态负载。在网关里没有加太多逻辑,也有不同的做法。


对于服务来说,最复杂的是服务的依赖和治理。服务之间调用的优化要基于业务场景,比如说购物车的服务,调用到价格、库存、促销等。


当依赖的服务不可用的时候,比如价格不可用,设计依赖的时候,要在购物车服务中做一个缓存,来对缓存调用,最后再对最终一致性进行验证。


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


更多技术干货分享

以上是关于微服务架构在千万级别日调用量亿级别海量数据场景下的应用实践的主要内容,如果未能解决你的问题,请参考以下文章

前 1 号店 CTO 黄哲铿揭秘:微服务架构在超大场景下的应用

高并发高性能场景(抢购秒杀抢票限时竞答)解决方案

高并发场景下的httpClient优化使用

高并发场景下的 HttpClient 优化,QPS 大大提升!

HttpClient在高并发场景下的优化实战

Redis 实战篇:巧用Bitmap 实现亿级海量数据统计