完美日记是国货网红美妆品牌（“国货之光”完美日记的微服务实践

哔哩哔哩 ；；的加班时间是多少？服务 ？完美日记的微服务实践与优化思路。中国商品之光。

如果你是程序员，你一定知道完美日记。

如果你是程序员，你的姑娘一定知道完美日记。

今年双11，完美日记仅用28分钟就超越2018年双11销售额，成为首个登上天猫双11彩妆榜榜首的国产品牌。在这家美女如云，被称为男人(尤其是程序员)天堂的公司，你们有什么样的基础设施技术团队？他们是如何在四个月内搭建并推出一个电商平台的？本文将分享他们在微服务实践中的难点和优化思路。

完美日记基础设施技术团队欢迎您的加入。详见文末。

起步

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

项目成立后，团队还没有完全配备，一边从其他团队 。，我们的架构师也在搭建分布式商城的开发框架，编写Demo，让新学员快速上手。

暴露问题

问题一分布式事务

为什么要使用分布式事务？

暂时这可以归结为快手在线，因为生成的订单会被调用从商品和服务中扣除库存，分布式交易用于解决跨服务调用带来的库存超售问题，带来了性能消耗问题。

问题二数据库压力

促销活动时有直接从业务库实时统计查询，运营部 姐不断刷新，对界面造成很大压力，而且缓存没有使用，连SQL查询条件的时间都是动态的，导致DB层的缓存没有使用，每个请求都打在DB上。

开发测试环境使用自建MySQL，生产环境使用PolarDB，从阿里云官网看到

集群架构，计算和存储是读写分开的。主观上我们以为只要使用集群连接地址，读写就会自动分离，其实不然。后来我们发现，在 中显式指定只读事务会导致请求转到只读节点。

@Transactional(只读=真)

# 优化思路

1)从SQL insight和slow SQL中找到响应时间最长、频率更高的SQL；2)结合代码，可以直接处理缓存而不是可以缓存的优化查询，结合阿里云提供的优化分析工具调整索引；3)活动高峰期禁止执行分析统计的查询，临时改代码来不及，得益于AHAS(阿里云的限流降级产品)的接口限流和SQL限流功能；4)TP和AP分开，避免分析类直接查询业务库(这是一个漫长的过程)。

问题三缓存压力

除了上面提到的分布式事务，发现有同事用key写了一个关于Redis的模糊查询，直接导致Redis的CPU严重增加。通过阿里云提供的Redis管理工具，我们很容易看到有哪些查询速度慢的地方。

另一个低级错误，我们认为，不应该是之一个，也不会是一个。它应该设置一个密钥的过期时间，但结果是缺少了一个单元参数，第三个参数更改了偏移量。

redisTemplate.opsForValue()。 (键、值、偏移量)

# 为什么我们花了10分钟左右才解决？

1)惯性思维，复习代码没找到；2)当错误日志中Redisson锁失效时，怀疑Redis已满；3)使用阿里云 s工具查大键，发现键很大，直接在网页上看数值，只看到保存了一个字符。那个 这就是问题所在，因为在RDS控制台中获得的值看起来是正确的。大概过了2分钟，感觉不对劲，然后登录用redis-cli查了一下。我傻眼了，里面全是0x00。

问题四

商城上线当月有一个促销活动。因为瞬时流量太大，小程序前端掩埋事件上报的接口连接数爆炸，商城实时数据统计调用流量统计服务的接口。服务调用超时设置为60s，导致请求太多，CPU突然飙升。

# 优化思路

1)充分利用Nginx 的并发处理能力，Lua脚本提供强大的处理能力，将Java处理请求改为OpenResty接收；2)收到请求后，做一个基本的检查，用lua-resty-kafka模块异步发送给Kafka；3)3)卡夫卡登陆HDFS后，Spark离线计算日志数据；4)后端接口独立部署，实时数据统计调用接口设置更短的超时；

经过以上改造，前端日志上报服务的单次处理能力从原来的1K提升到了40K，丝滑的体验真的很棒。

迭代

从当时的情况来看，为了双11 美国的活动，还有不到两个星期的活动。即使换了，风险也很高。

1、压测

作为一个新上线的项目，数据量还是比较少的，所以使用云服务搭建1: 1的压力测量环境相对容易。在这个时间节点，我们需要模拟现实。

的场景摸清楚目前的系统能承受多大的压力，需要多少机器。

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

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

2、限流

在接入 AHAS 过程中，由于微商城项目当前版本接入的是spring-cloud-alibaba-dependencies-0.9.0.RELEASE版本来使用阿里云的 OSS 与 S，在接入 AHAS 后，需要对依赖 Alibaba 版本的升级，涉及包括 Nacos 配置中心与服务发现的升级和包路径的命名变更修改；在接入 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 处理；在接入 AHAS 的应用模块限流，采用的也是 SDK 接入方式，在按官网文档进行接入的时候，发现我们微商城采用的是最新版本的 Mybatis Plus 版本，在接入 SQL 限流分析功能时发现出现ahas报错，在将此反馈到ahas钉钉团队支援群后，当时已经差不多凌晨一点了，ahas团队的及时响应以及第二天早上就发布了兼容 Mybatis Plus 版本的SQL 限流分析版本给到我们微商城，在我们接入新版本后，SQL 分析和限流功能也能正常使用了；在使用 AHAS 接入的时候，发现 AHAS 除了接口的 API 限流功能外，还提供了CPU/Load 的限流，对服务器性能情况的监控和保护做了很好的护航，在微商城服务器压力过高时能够很好的保护服务器不被高并发压垮，保证了服务的高可用，在服务器压力大的时候，做到了实时 QPS 日志上传的隔离，避免上传抢占服务器资源，保证了服务器在接入 AHAS 后也能保持良好的性能。

未来

未来计划要做的事情

1）按服务拆分 Redis；2）数据库读写分离、分库分表、TP/AP 分离；3）业务中台化建立业务中台，打通商品中心、库存中心、用户中心和交易中心；

作者庄工、关工、唐工

本文为阿里云原创内容，未经允许不得转载。

兰蔻和完美日记哪个是国货 完美日记是国货吗