当前位置：首页 > 编程日记 > 正文

苏宁零售云 App 稳定保障实践

编程日记 2024-10-21 02:40:00

1. 背景

苏宁零售云目标T4-T6级市场的业务，定位更靠谱的智慧零售解决方案和零售服务集成商，实战式跨界赋能。苏宁易购TO C的经验丰富，相关的方案很完善，但是零售云TO B相关业务启动后，业务增长迅速，App相关的稳定保障方案缺失。

2. 零售云业务的特殊性

零售云主要是TO B的业务，目标T4-T6级市场的加盟店，授权店，跟TO C业务相比，有以下有个不同点：

1）用户量不多，但是每个用户强依赖零售云相关App。
2）每笔订单金额巨大。
3）需要系统稳定。

零售云的每个用户都是一家门店的一个角色人员（老板，店长，收银员…），每家门店每天的进销存都依赖零售云配套App（零售云，零售云店员，零售云管家）。零售云App提供进货服务，零售云店员提供销售服务，零售云管家提供库存管理，报表查询等服务。可以看出，一个用户使用出现问题，就会影响到一家门店的日常销售，导致不能正常销售，每一家门店每天都付着店面租金和人员酬劳，不能营业的后果非常严重。

3. 前期快速迭代满足业务遇到的问题

1）系统问题需要门店上报给运营，运营再同步给研发负责人，问题的流程较长响应比较慢。

2）研发需要跟门店人员确认操作过程，甚至借用登录账号，体验不好。

3）App到数量的灰度发布，不能精确试点，一旦出错，影响范围较大。

4. App稳定保障思路

系统稳定的三个特点：可监控，可灰度，可回溯。对于App来说，一旦新包发出去后，想回溯就不太现实了，办法无非是提示更新或者热更新，所以我们主要针对前面两点来实现。

4.1 可监控

在监控上我们做了两个方面的工作：

1）云迹性能监控，类似友盟或者Buggly的性能统计，包括崩溃，卡顿，日活等等；
2）云迹实时日志统计分析。

4.2 可灰度

1）实现到店铺层面的灰度更新

下面我们来展开讲讲这两点的实现方式。

5. 到人的请求监控（可监控）

类似友盟或者Buggly的性能统计，我相信大部分App也都接入了，这边不做解释了，不管TO B还是TO C业务都一样。

正是基于上面的性能统计，我们得知，零售云App的使用用户，60%左右是在WIFI环境下。上面也解释了TO B业务对系统的强依赖性，但是对于流量消耗的敏感度却不高。基于前提条件，我们决定把客户端所有的网络请求数据和业务错误轨迹都记录在云迹平台，并且配置错误告警。这样做的好处有两个：1）通过短信和邮件告警，可以快速知道错误。2）通过实时日志埋点可以知道每个用户的行为和操作轨迹，方便快速定位错误。流程图如下所示：

$\"image\"$

5.1异常告警

我们根据自己的需求，配置搜索条件，告警触发条件，并以短信和邮件的方式通知给对应的负责人。如下图所示：

$\"image\"$

当有异常触发告警条件时，对应负责人会短信和邮件收到告警通知，第一时间发现问题。

5.2日志查询

1.当收到告警后，对应负责人需要登录到云迹实时日志分析平台 1）选择对应的系统名 2）选择日志类型 3）选择查询时间 4）通过kibana查询语法，即可查询到该条件下的日志。

$\"image\"$

2.我们随便点开一条日志，可以看到详细的用户信息。

$\"image\"$

根据上图日志内容可以快速获取如下关键信息：

1）app版本
2）手机版本，手机型号
3）业务信息（请求地址，请求参数，返回参数，堆栈信息）
4）账号

通过上面信息可以快速定位到某个时间点下错误的请求。

3.某个用户轨迹

很多时候，某些错误是在用户特定操作下才会触发，这个时候，需要知道用户的操作轨迹，我们可以通过kibana查询语法，筛选出某个用户的所有日志，根据请求时间可以很方便的知道，用户的整个操作轨迹。如图所示，该用户最近三小时的操作行为都可以查到。

$\"image\"$

得到用户的行为轨迹，很多错误场景，研发可以自己模拟，不需要再远程咨询门店用户，方便高效定位问题。

6. 到店的移动App灰度发布（可灰度）

TO C的场景一般是用户量的灰度，比如一次灰度10000个用户，但是对于TO B却不适合，比如一次灰度100个用户，可能覆盖到100家店铺，一旦出问题这100家店铺正常销售受到影响，而且统计哪些店铺受到影响也很困难。针对零售云特殊的情况，我们制定了特殊的灰度发布流程。每个app在苏宁升级平台（MPCS）上面配置两个appid，一个为正式版本包，一个为灰度版本包，客户端根据分销前台返回的appId（0/1），区分取正式包还是灰度包的appid，进行版本更新请求。灰度期间，通过分销前台配置店铺白名单，在白名单文件中的店铺下的用户提示升级到最新版本，其他用户无影响。在灰度成功后，分销前台关闭灰度开关，进行全量升级。流程图如下所示：

$\"image\"$

灰度期间只有白名单用户才调用灰度包更新接口，其他用户调用正式包升级接口。逐步增加灰度的店铺，10个-\u0026gt;20个-\u0026gt;50个-\u0026gt;100个-\u0026gt;全量，期间注意观察云迹异常。

7. 避免的生产问题

通过上面的稳定保障，我们避免了不少生产问题，这边举两个例子：

1）四月份的一个下午，突然收到很多告警，打开云迹实时日志查到一个小时内报大量的请求超时，而且集中在某个区域，通过这些关键信息，最后定位是运营商网络的问题，当天就快速修复，对于用户来说对于整个修复过程无感知。

2）云迹告警商品详情页接口会偶尔失败，通过云迹查询到日志信息发现，商品详情页需要传的店铺编码，某些时候客户端传的是空，但是review客户端相关模块代码，确认每次都是传了店铺编码，这个时候就需要模拟用户的操作轨迹。通过查询该用户所有操作日志，分析出失败接口前面几分钟的操作行为得知，在四级页停留了很长时间后登陆失效，再次登陆后店铺编码为空，知道具体错误后，就可以在下个版本修复避免生产问题。

8. 目标展望

为了保障零售云App的稳定，我们其实还做了很多工作，这里不一一列举了，当然我们还有很多的提升空间，未来我们会不断优化监控和灰度方案，加强数据收集和分析，保障零售云App的稳定。再稳定的系统也不能保证百分之百不出问题，所以在应对可能出现的问题时，我们必须要在第一时间发现问题，快速响应解决问题。

作者简介

曹银飞，苏宁易购IT总部Android技术专家，拥有多年Android研发和管理经验。曾就职于联创，腾讯等大型互联网公司，现负责苏宁易购Android开发部产品研发与技术管理工作，在Android项目架构设计，性能优化，团队管理上有多年的实战经验。现致力于打造苏宁智慧零售相关App，希望将苏宁的零售技术能力发挥到极致。

https://www.dkcj.cn/info/23953.html

1. 背景

2. 零售云业务的特殊性

3. 前期快速迭代满足业务遇到的问题

4. App稳定保障思路

4.1 可监控

4.2 可灰度

5. 到人的请求监控（可监控）

5.1异常告警

5.2日志查询

6. 到店的移动App灰度发布（可灰度）

7. 避免的生产问题

8. 目标展望

作者简介

相关文章：