“国货之光” 完美日记的微服务实践和优化思路

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 今年双11,完美日记仅用28分钟就超过了2018年双11全天的销售额,成为第一个登上天猫双11彩妆榜首的国货品牌。他们是如何在 4 个月内筹建、上线电商平台的呢?本文将为您分享他们在实践微服务过程遇到的难点和优化思路。

lADPDgQ9rVfPg37NArPNBMs_1227_691_jpg_620x10000q90g

如果你是一位程序媛,你一定知道完美日记。
如果你是一位程序员,你的那个她一定知道完美日记。

今年双11,完美日记仅用28分钟就超过了2018年双11全天的销售额,成为第一个登上天猫双11彩妆榜首的国货品牌。在这个遍地都是漂亮小姐姐、号称男人(特指程序员)天堂的公司里,拥有着一支什么样的基础架构技术团队,他们是如何在 4 个月内筹建、上线电商平台的呢?本文将为您分享他们在实践微服务过程遇到的难点和优化思路。

完美日记基础架构技术团队欢迎您的加入,移步文末,了解详情。

起步

自建商城在设计之初,业务部门就提出了两个要求:不崩 & 快速上线。

在立项之后,团队还没有完全配备好,一边从其他团队里调取人手,一边大力招聘,与此同时,我们的架构师也在搭建一套分布式商城开发框架,编写 Demo,让新加入的同学能快速上手。

暴露问题

问题一:分布式事务
为什么会使用分布式事务?

这个暂且可以归因于快速上线,因为生成订单会调用到商品服务扣减库存,使用了分布式事务解决了因为跨服务调用引起库存超卖的问题,带来的问题就是性能上的消耗。

问题二:数据库压力
在大促活动期间,有个实时统计是直接从业务库上直接查询统计的,运营部门的小姐姐在不断地刷新,导致该接口上的压力山大,而且没有使用缓存,连 SQL 查询条件的时间都是动态的,导致 DB 层的缓存也使用不上,每次请求都打到 DB 上。

开发和测试环境是使用自建的 MySQL,生产环境使用的是 PolarDB,从阿里云官网上看到:

  • 集群架构,计算与存储分离
  • 读写分离

我们主观地认为,只要我们使用了集群连接地址就会自动进行读写分离,但是实际上并没有,后来发现在方法上显式的指定只读事务就有请求走到只读节点上了。
@Transactional(readOnly = true)

# 优化思路:
1)从 SQL 洞察和慢 SQL 里找调用响应时间最长和频度最高的 SQL;
2)结合代码,能用缓存代替的直接处理掉,不用能缓存的优化查询,结合阿里云提供的优化分析工具,调整索引;
3)活动高峰时段,禁止分析统计类的查询执行,临时改代码已经来不及了,幸亏 AHAS(阿里云的一款限流降级产品) 的接口限流和 SQL 限流功能;
4)TP 和 AP 分离,避免分析类直接查询到业务库(这是一个比较漫长的过程)。

问题三:缓存压力
除了前面所提到的分布式事务之后,发现还有同事写了使用 Keys 模糊查询 Redis,直接导致 Redis 的 CPU 飙升严重,通过阿里云提供的 Redis 管理工具可以很方便地查看到有哪些慢查询。

另外一个低级错误,我们相信应该不是第一个,也不会是最后一个,本来要设置一个 Key 的过期时间,结果少写了个 Unit 参数,第三个就变更偏移量了。

redisTemplate.opsForValue().set(key, value, offset)

# 为什么我们花了10分钟左右才解决?
1)惯性思维,review 代码没发现出来;
2)在错误日志里发现 Redisson 锁失败时,怀疑是 Redis 写满了;
3)使用阿里云的工具去查大 Key 时发现了 Key 很大,但是直接在网页查看值的时候只看到保存了一个字符,问题就出在这里,因为 RDS 管控台里获取到的值看起来是正确的,大概又过了2分钟左右,我觉得不太对劲,然后登录上去用 redis-cli 查看,傻眼了,里面塞满了 0x00。

lALPDgQ9rVfPg33NAiPNBDg_1080_547_png_620x10000q90g

问题四:
商城上线当月有一个促销活动,因为瞬间进来的流量过大,小程序前端埋点事件上报的接口连接数爆了,商城实时数据统计调用了流量统计服务的接口,然而服务调用超时时间设置的是60s,导致过多请求积压,CPU 突然飙升得很厉害。

# 优化思路:
1)充分利用 Nginx 的并发处理能力,Lua 脚本提供了强大的处理能力,将 Java 处理请求改为使用 OpenResty 接收;
2)接收到请求之后做好基本的校验之后,使用 lua-resty-kafka 模块异步发送到 Kafka;
3)Kafka 落盘到 HDFS 后,由 Spark 离线计算日志数据;
4)后端接口独立部署,实时数据统计调用接口设置更短的超时时间;

经过以上改造之后,前端日志上报服务单机处理能力由原来的 1K 提升 40K,那种如丝般顺滑的体验实在是太好了。

迭代

从当时的情形来看,针对双11的活动做大动作调整代码优化基本上是来不及了,离活动还有不到两个星期的时间,即便改了,风险也很高。

1、压测
作为一个新上线的项目,数据量还比较小,使用云服务来搭建一套1比1的压测环境还是比较容易的,在这个时间节点上,我们需要模拟真实的场景摸清楚目前的系统能承受多大的压力,需要多少机器。

阿里云上有个 PTS 的压测工具,可以直接导入 Jmeter 脚本,使用起来很方便,接下来说说我们的使用步骤:

1)先是按过往一个月的用户行为日志里,找出用户的路径和每个行为的思考时间,做了一个大概的模型;
2)按照双十一活动的运营节奏,定义了两到三个场景;
3)使用 ECS 搭建 Jmeter 集群,内网对接口进行施压,目的是减少网络开销,让请求都能打到后端服务器上;
4)观察服务器的压力,调节应用内存分配,再通过 PolarDB 性能分析,找出有性能瓶颈的 SQL 尽可能地优化掉;
5)将 Jmeter 脚本导入到 PTS,关联上数据库和 ECS 机器的云监控,设置好思考时间等相关的参数后施压,可以动态秒级调整压力,生成的压测报告就是我们想要的结果,需要拿这个结果来进行下一步的限流控制。

2、限流
1)在接入 AHAS 过程中,由于微商城项目当前版本接入的是spring-cloud-alibaba-dependencies-0.9.0.RELEASE版本来使用阿里云的 OSS 与 SMS,在接入 AHAS 后,需要对依赖 Alibaba 版本的升级,涉及包括 Nacos 配置中心与服务发现的升级和包路径的命名变更修改;
2)在接入 AHAS 的 gateway 网关路由限流,采用的是 SDK 接入方式,AHAS 采用了符合 springboot-starter 特性的 SDK 开发,这样在我们微商城接入 gateway 时只需要在项目 POM 中加入 spring-cloud-gateway-starter-ahas-sentinel,在接入 gateway 的时候发现,网关路由限流采集上传的 API 出现了没有兼容 Restfull 风格 API 的问题,导致 URL 上出现参数时多个url没有合并一起的情况,阿里云 AHAS 支持团队立即发布 Fix 版本,提供新的 SentinelWebInterceptor 拦截器进行清洗 Restful 风格 API 处理;
3)在接入 AHAS 的应用模块限流,采用的也是 SDK 接入方式,在按官网文档进行接入的时候,发现我们微商城采用的是最新版本的 Mybatis Plus 版本,在接入 SQL 限流分析功能时发现出现ahas报错,在将此反馈到ahas钉钉团队支援群后,当时已经差不多凌晨一点了,ahas团队的及时响应以及第二天早上就发布了兼容 Mybatis Plus 版本的SQL 限流分析版本给到我们微商城,在我们接入新版本后,SQL 分析和限流功能也能正常使用了;
4)在使用 AHAS 接入的时候,发现 AHAS 除了接口的 API 限流功能外,还提供了CPU/Load 的限流,对服务器性能情况的监控和保护做了很好的护航,在微商城服务器压力过高时能够很好的保护服务器不被高并发压垮,保证了服务的高可用,同时在服务器压力大的时候,做到了实时 QPS 日志上传的隔离,避免上传抢占服务器资源,保证了服务器在接入 AHAS 后也能保持良好的性能。

未来

未来计划要做的事情:
1)按服务拆分 Redis;
2)数据库读写分离、分库分表、TP/AP 分离;
3)业务中台化:建立业务中台,打通商品中心、库存中心、用户中心和交易中心;

为了更好的应对源源不断的挑战,以下岗位持续招聘中:

  • Java开发工程师
  • 前端开发工程师
  • 测试工程师

**有意请发送简历至邮箱:
Lynn.Guo@yatsenglobal.com**

作者信息:
庄工:逸仙电商架构师&技术委员会负责人,负责完美日记商城基础架构和微服务体系建设。
关工:逸仙电商后端技术专家,现主要参与微商城后端框架集成方案、以及性能调优和微商城技术规范管理。
唐工:逸仙电商技术经理,曾先后就职于中国航信和唯品会,现主要负责前后端技术统筹等打杂工作。

相关文章
|
1天前
|
设计模式 负载均衡 Kubernetes
解密微服务架构:从理论到实践
在这篇文章中,我们将深入探讨微服务架构的核心概念,并通过一个实际案例来展示如何在现实世界中构建和部署一个微服务系统。文章将从微服务的定义开始,逐步介绍其优势、挑战、设计模式、以及如何使用现代技术栈来实现微服务架构。
|
1天前
|
Cloud Native Go API
Go语言在微服务架构中的创新应用与实践
本文深入探讨了Go语言在构建高效、可扩展的微服务架构中的应用。Go语言以其轻量级协程(goroutine)和强大的并发处理能力,成为微服务开发的首选语言之一。通过实际案例分析,本文展示了如何利用Go语言的特性优化微服务的设计与实现,提高系统的响应速度和稳定性。文章还讨论了Go语言在微服务生态中的角色,以及面临的挑战和未来发展趋势。
|
2天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型加速的今天,云原生技术以其高效、灵活、可扩展的特性成为企业IT架构转型的首选。本文深入探讨了云原生环境下微服务治理的策略与实践路径,旨在为读者提供一个系统性的微服务治理框架,涵盖从服务设计、部署、监控到运维的全生命周期管理,助力企业在云端构建更加稳定、高效的业务系统。 ####
|
1天前
|
Java 持续交付 微服务
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,通过具体案例分析,揭示了其如何助力企业应对业务复杂性、提升系统可维护性和可扩展性。文章首先概述了微服务的核心概念及其优势,随后详细阐述了实施微服务过程中的关键技术选型、服务拆分策略、容错机制以及持续集成/持续部署(CI/CD)的最佳实践。最后,通过一个真实世界的应用实例,展示了微服务架构在实际项目中的成功应用及其带来的显著成效。 ####
|
2天前
|
负载均衡 监控 API
后端开发中的微服务架构实践
【10月更文挑战第15天】 在当今的软件开发领域,微服务架构已成为一种流行的技术趋势。本文将探讨微服务架构的基本概念、优势以及在实际后端开发中的应用。我们将通过具体案例分析,了解如何设计和实现一个高效的微服务系统,以及如何应对在实施过程中可能遇到的挑战。
13 1
|
3天前
|
Cloud Native API 持续交付
利用云原生技术优化微服务架构
【10月更文挑战第13天】云原生技术通过容器化、动态编排、服务网格和声明式API,优化了微服务架构的可伸缩性、可靠性和灵活性。本文介绍了云原生技术的核心概念、优势及实施步骤,探讨了其在自动扩展、CI/CD、服务发现和弹性设计等方面的应用,并提供了实战技巧。
|
3天前
|
消息中间件 监控 Kubernetes
后端开发中的微服务架构实践与挑战####
本文将深入探讨微服务架构在后端开发中的应用,通过实际案例分析其优势与面临的挑战。我们将从微服务的基本概念入手,逐步剖析其在现代软件开发中的重要性及实施过程中需注意的关键因素。无论你是后端开发的新手还是资深工程师,这篇文章都将为你提供有价值的见解和启发。 ####
|
3天前
|
运维 监控 Cloud Native
云原生架构下,微服务治理的艺术与实践####
【10月更文挑战第14天】 在数字化转型的大潮中,云原生技术以其高效、灵活与可扩展性成为企业IT架构的首选。本文深入探讨了云原生架构的核心理念,聚焦于微服务治理的策略与实践,揭示了如何通过精细化管理提升系统的响应速度、稳定性和可维护性。不同于传统的摘要概述,本文摘要旨在直接触及读者关注的核心——即如何在复杂多变的云环境中,实现微服务的高效协同与治理,为读者提供一个清晰的行动指南。 ####
11 1
|
3天前
|
监控 安全 开发者
后端开发中的微服务架构实践与挑战
在当今的软件开发领域,微服务架构因其灵活性和可扩展性而受到广泛关注。本文将探讨微服务架构的基本概念、优势以及在后端开发中的具体实施方法。通过分析实际案例,我们将深入了解如何克服微服务实施过程中的挑战,包括服务划分、数据管理、通信协议选择等关键问题。此外,文章还将讨论微服务架构下的性能优化和安全性考虑,为开发者提供实用的指导和建议。
|
7天前
|
消息中间件 监控 Go
Go语言在微服务架构中的优势与实践
【10月更文挑战第10天】Go语言在微服务架构中的优势与实践