解决方案:寺库网:直面业务,拥抱新技术架构优化转型
优采云 发布时间: 2022-12-02 21:45解决方案:寺库网:直面业务,拥抱新技术架构优化转型
前言:
如果我们把中国消费品的数字化进程看成是班级竞赛,那么书籍、服装、3C一定是班级里积极努力的“优等生”,而生鲜、家装则是令人担忧的“后进生”。至于奢侈品,因为安于现状,虽然偶有杰作,但依然是不起眼的“中学生”。
这只是在中国。在奢侈品行业成熟的欧美,以Burberry、Gucci为首的“探索者”在Instagram、Line、Snapchat上勇猛横冲直撞,对“直播走秀”和“直播”非常熟悉和购买”。当前形势下,奢侈品企业在中国探索互联网是谨慎的,但不是不能激进,而是不想这么做。
奢侈变得不那么“奢侈”了。当我们说惯了Gucci新一季针对年轻消费者的卡通印花,积家和papi酱的微信广告,或者爆红朋友圈的YSL明星唇彩,很难想到这些品牌的前身。它是18世纪工匠为取悦皇室贵族而创造的身份象征。
这样的身份已经融入了奢侈品牌的血液。尽管它们在很大程度上已经沦为大众消费品,但在每一个转型的关键时刻,曾经存在于骨子里的“贵族”都会再次跳出来,阻碍其走向主流与现实的妥协——从定制化到大众化生产,从高级时装到手表、香水和彩妆,再到今天的数字化转型,比普通消费品需要更长的时间来准备,或者说,接受这种转型。
那么,奢侈品牌的变革方向是什么?尤其是在复杂多变的中国市场,他们要的是什么?
数据是移动互联网时代的金矿,对奢侈品公司亦然
礼宾神殿,天府宝库——寺库自2008年成立以来,拥有国内最大的高端购物中心。全球奢华会所,全方位服务高端人群,线上线下让用户感受卓越体验。同时,寺库打造了国内最专业的奢侈品鉴定团队和全球最大的奢侈品维修工厂,旨在打造最强大的全球领先的奢侈品一站式服务平台和追求高品质人士的交流平台。品质生活。
大数据支撑,持续追求优质服务
奢华本身就是一种生活态度。寺库不仅仅是奢侈品电商,而是通过电商推广这种新的生活方式。寺库结合互联网、手机客户端和体验店,遍布北京、上海、成都、香港、米兰、纽约、东京、马来西亚,以会所形式为名人学者搭建高贵典雅的交流平台,增强人们对品质生活的追求意识。
通过电商平台购买奢侈品,真伪问题一直是消费者关心的问题。在这方面,寺库团队的奢侈品鉴定服务在业内树立了口碑。最重要的是拥有庞大的解码数据库,对每个品牌进行解码,形成大数据,完善寺库的数据库体系。全程识别工作服务,同时更好地为消费者提供智能化、体验式服务。
奢侈品不再“冷”,电商服务转型
随着寺库的发展,自身的业务体系不断拓展。在逐渐触及奢侈品电商利益的顶层后,寺库开始思考自身的发展与转型。寺库明白仅仅用传统的思路做奢侈品电商,发展是有限的,于是开始思考奢侈品用户的属性和自身定位。
寺库认为,他的潜在竞争对手不是淘宝、京东等电商巨头,也不是新天地等大型线下奢侈品购物中心,而是用户的生活方式。因为用户的生活方式决定了用户的购买行为,如何改变和提升用户的生活方式决定了寺库未来的订单价值,未来奢侈品消费涉及的领域将更加生活化。
但是寺库作为一家互联网电商,还是有其他普通电商的共同特点,就是在做闪购和促销的时候存在用户体验问题,即用户同时涌入网站短时间内,对网站服务器和APP本身的性能造成负面影响。大考验。
传统电子商务的结构
为保证促销活动的顺利进行,寺库在每次重大促销活动前都会对系统进行单点和复合场景的压力测试,重点测试服务的QPS和响应时间,确保应用达到最优状态.
这里,有两个部分来处理高流量:
➢第一部分是提供内容展示(如:频道、话题、详情页)
1.去数据库访问,数据按照指定格式实时同步到Redis集群
2.转到Java,使用openresty,在Nginx层完成逻辑处理
" />
3.负载均衡,流量负载到不同的Nginx节点
4、服务水平扩展架构,可水平扩展Nginx和Redis集群
5. 图片、CSS、JS文件CDN
➢第二部分是数据交互(如:购物车、优惠券、秒杀)
1.去数据库访问,数据按照指定格式实时同步到Redis集群
2.转到java,使用openresty,在Nginx层完成逻辑处理
3.负载均衡,流量负载到不同的Nginx节点
4、服务水平扩展架构,可水平扩展Nginx和Redis集群
5.异步任务,比如发放优惠券的动作,后台任务异步完成
自主可控,系统服务优化系统
寺库非常重视用户体验,奢侈品电商的每一位用户都有相当大的订单价值,因此需要关注每一位用户的购物体验。对此,寺库根据自身实际情况从两方面进行优化。在优化自身系统服务方面,寺库有自己的一套体系:
寺库技术架构
1、从直接连接数据库到数据库连接池的管理,再到数据库的读写分离,再到现在前端直接从Redis取数据
直连数据库的方式会带来较大的资源开销。连接被频繁创建和关闭,无法有效地重用。读写分离虽然有效的解决了锁争用,但是会受到数据复杂度带来的读取开销的限制。数据以固定格式存储在Redis中,读取复杂度低,将大大提高性能。
2、从Java到OpenResty,Servlet容器到Web容器
通过openresty做的接口网关统一接口,使用Nginx的11个执行流程,更好的接口兼容,通用业务解耦,统一限流和规则校验。
3、从单点Redis到高可用Redis,再到现在的Redis集群
单点Redis的风险在于,一旦宕机,即使恢复,也会有一段时间服务中断。Redis的高可用就是当请求量很大的时候,不能通过并行扩展来降低单台服务器的压力。
4、从事务到Redis,到数据异构同步框架postern(内部框架)的耦合保存数据库
将数据库耦合保存,在Service中保存Redis,对于开发来说,必须考虑数据的最终一致性,增加了开发工作量。postern会通过配置规则监控MySQL-binlog进行异步数据同步,保证数据的最终一致性。
5、从静态商品详情页到基于openresty的动态商品详情页
静态商品详情页极大的提升了商品详情页的吞吐量。然而,副作用是一旦涉及到全面的改变,就需要很长时间。
6. 从类代码 CMS 到可视化 CMS
" />
CMS的类码对运营商的使用要求很高,需要了解一定的使用规则。可视化CMS,在已有组件库中随意拖拽拼接组成主题,实时预览,所见即所得。
7、前台同步处理任务到后台实时异步任务
类似于用户在前台领取优惠券,接口同步发送会阻塞用户接收请求的响应时间,同时不会释放连接。大量的请求必然会对服务造成影响。后台异步任务是在收到前台请求后释放连接,后台异步完成发送请求,只需要及时保证发送成功即可。
8. 从混乱的海量接口到接口网关(openresty)
没有接口网关,不好做统一验证,请求限流,统一响应,设置用户行为路径等。
APM辅助,针对用户的优化
寺库认为,对于线上线下的奢侈品电商而言,线上用户体验与线下实际体验同样重要,而在国内互联网市场竞争日趋激烈的背景下,尤其是奢侈品电商行业,用户体验已经成为一种趋势。越来越成为影响用户选择的重要指标之一。尤其是奢侈品电商的订单金额比较大。在用户购买欲望低下,又担心假冒商品等安全问题的情况下,为用户提供舒适的体验和完善的服务成为了每一寸奢侈品电商的必须。领域之争,而寺库则是这一领域的先行者。
寺库选择听云作为应用性能管理领域的合作伙伴,听云针对电商行业的完整解决方案,全方位为寺库提供移动客户端、浏览器、网络、服务器的完美用户体验。其中,听云通过日常性能故障定位和慢交互跟踪,帮助寺库优化网络层和应用层代码的性能瓶颈,降低应用系统故障率,提升用户访问体验。
➢朗姆酒
有效结合APP端和浏览器端,通过听云RUM解决方案进行有针对性的全面优化。在竞争激烈的互联网服务领域,用户体验是影响用户选择品牌的重要指标。页面无法正常打开、打开速度慢、APP闪退、卡顿等问题将直接导致品牌受损,用户流失率将大幅增加。通过听云在全球部署的模拟监控终端,在页面中插入JS代码,对寺库重点业务页面进行全国各地真实用户访问,监控页面性能问题,抓取真实用户访问的真实数据网站; 并在APP中嵌入SDK的方式采集真实用户体验的表现,帮助寺库'
➢Synthetic(听云网)
采用听云网络在现网环境下的真实流量压力测试,听云在国内470个城市和国外150个城市部署,共计30万个模拟监控点,在寺库新业务系统上线前提前预测。高负载给应用系统瓶颈带来压力,为寺库大流量营销提供了更科学的决策依据。
➢全栈溯源
通过在服务端部署听云Server,结合听云App和听云网络,实现全终端、跨应用的监控,帮助快速实现不同业务逻辑下的性能排查。全栈溯源,即在复杂的应用环境下,准确定位和确定网络、移动端、浏览器、服务器性能问题的根源,减少跨部门排查和沟通成本,实现完整的业务链调用跟踪。
听云全栈溯源
全栈溯源从以下三个方面完善了寺库的业务运维体系:
1、打通全业务平台:从网络和应用看问题。问题定位效率从天天变成分钟,登录慢、支付货慢,简单几步就能找到问题根源。
2、快速准确的错误定位:无论是网络还是业务或数据库问题,准确定位数据源,厘清问题根源。
3、完整的业务调用链跟踪:以用户为中心跟踪用户的每一笔交易。如果用户交易失败,交易超过系统阈值,将记录整个行为跟踪。
作为一家奢侈品电商,寺库无疑站在了行业的前沿。正是因为电子商务直接服务于互联网终端用户的特殊性,用户体验直接决定了用户留存。因此,寺库坚信,“服务”永远是区分一家电商企业定位是否正确的根本标准之一。听云致力于为所有电商企业打造完美适用的解决方案。优化之路充满艰辛,没有尽头。听云将一路陪伴寺库。
本文对话:YU,寺库前端总监
解决方案:iOS App送审,审核4.3被拒问题怎样处理我来告诉你
写这篇文章的原因很简单,我遇到了iOS审核4.3的问题,老大需要我解释一下,如何避免。为了回答这个问题,我整理了自己了解到的资料,历时4个多小时。可能存在偏差或不适用。原因是本人能力有限,不保证一定能通过iOS 4.3的审核。
初审,什么是4.3问题rejected email
3设计:垃圾邮件
指南 4.3-设计
此应用程序复制您或其他开发者提交给 App Store 的其他应用程序的内容和功能,这被视为一种垃圾邮件形式。
简单地复制内容或功能的应用程序会造成混乱,最大限度地减少最终用户的整体体验,并降低开发人员营销其应用程序的能力。
下次提交此应用可能需要更长的审核时间,在解决此问题之前,此应用将无法获得加急审核资格。
下一步
提交旨在误导或伤害客户或逃避审查流程的应用程序可能会导致您的 Apple Developer Program 帐户被终止。查看 Apple Developer Program 的条款和条件,以详细了解我们有关终止的政策。
如果您认为您的应用符合 App Store 审查指南,您可以提交申诉。或者,您可以通过直接回复此消息来提供有关您的应用程序的其他详细信息。
一个简单的解释就是,苹果认为该应用复用了自己的产品,或者模仿了其他开发者应用的内容或功能,提交到应用商店市场进行审核。应用商店市场不接受类似产品。如果没有合理的解释,就会送审,耽误你。前半个月,如果发现以逃避审核为目的,直接封号。
对此,不仅要考虑为什么会出现iOS审核4.3问题,还要考虑苹果是如何判断的。在回答这个问题之前,我们先来说说目前市场上的iOS audit 4.3问题是如何处理的。只有知道别人做了什么,才能反过来介绍一些玩法。
从iOS audit 4.3问题出现至今,处理iOS audit 4.3问题的方法从时间和复杂度上大致经历了以下过程。那时候最后的结果就是我不玩了。
UI不变,代码不变,新开发者账号提交审核
UI不变,代码混乱,新开发者账号提交审核
UI外壳,代码不变,新开发者账号提交审核,苹果审核看到固定页面
UI套管,代码混淆,新开发者账号提交审核,苹果审核看到固定页面
UI套管,代码混淆,新增类名,函数名,新增开发者账号提交审核,苹果审核看到固定页面
全新UI,代码重构,全新类名,函数名,全新开发者账号审核,打包设备,全新IP审核,相当于全新产品
注:代码混淆是添加垃圾代码,调用独立页面,客户端没有入口
目前处理iOS审核4.3问题最常用的方法是第四种方法。市面上号称可以处理iOS audit 4.3问题,使用加固软件,底层处理方式可能是添加垃圾代码。
" />
看苹果的iOS audit 4.3 issue rejection邮件内容,大致可以归纳为以下三种iOS audit 4.3 issue的猜想,第三种更多是我个人的猜测:
1、代码层面iOS审计问题4.3 2、设计层面iOS审计问题4.3 3、iOS审计问题4.3设备、IP、开发者账号、联系人、银行卡绑定等信息关联
为什么会得出上述猜想?众所周知,苹果的审核会分为机器审核和人工审核两部分。机器审核和人工审核拒绝的邮件内容会有个体差异。
一般来说,对于代码层面的iOS audit 4.3 issues,被拒绝的邮件回复是没有任何截图的。其次,我们通过后台查看审核时间内是否有非公司IP或非白名单设备登录,可能查不到任何记录。.
至于设计层面的iOS review 4.3 issue,很大一部分被拒绝的邮件都会附上截图,而且大部分都是首页。因为已经激活,所以可以查询审稿人的设备,IP,浏览了哪些页面等等。之前试过,收到被拒绝的邮件,里面附有类似某APP的信息。
此外,针对设备、IP等信息被关联屏蔽时出现的iOS审核4.3问题,被拒邮件的内容更偏向于代码级模板。如果没有记录,则拒绝。
注意:如何查询异常IP/设备,追踪数据埋点,然后提交版本审核,除公司内部人员可以登录外,其他人无法登录审核包
遇到以上三个iOS审核4.3问题怎么办。在说怎么处理之前,先详细说一下4.3问题的三类
1.代码级iOS审核 4.3 两款产品代码级相似度太高,超过70%(我猜的数据,判断新增垃圾代码的一般标准是30%以上)。无论是与线上商品代码相似还是与已送审未通过的商品代码相似,这种情况有以下几种可能: ,更可能存在于综合功能产品中。分拆小功能产品,或在模板化产品上开发使用开源代码或接口,造成代码雷同增加垃圾代码混淆,垃圾代码比例过高导致代码雷同
2. iOS audit 4.3 设计层面的问题这些iOS audit 4.3问题是人为造成的。严格来说这个App是通过了机审,但是其他的设计都差不多,比如itc后台的icon图标/审稿截图/app名称后缀版本,整体App设计类似,首页就是相同的; 很容易导致审稿人直接假设克隆包存在。这可能就是iOS review 4.3 issue被拒邮件内容中有首页截图的原因。也许问题又来了。对于Apple审核员来说,如何做到每天审核的数十万种产品在标识设计上的相似性。简单来说,就是对某个app的印象的一种解释,很难让人满意,也很难让人信服。对此,有两个疑问需要解答:审稿人如何知道与某款APP相似,截屏审稿人的背景是什么?很多帖子都经历过的事情。比如SEO的伪原创文章(类似大学论文的检测),原理是根据一个背景,通过对稿件的技术比对,从而得到两者或几篇之间的相似度。在伪原创文章检测的背景下对比稿件,不仅可以给出文章的整体相似度,还可以给出与那些文章相似度的比例;视频图片内容网站的*敏*感*词*监控系统进行了三点识别和缺肉比例。通过其他技术识别后,得到大概的比例,通过监管比例做分层预警系统,最后交由人审核;百度和谷歌的图像识别系统有一种错觉,和苹果的评论极其相似,作为万亿美元的苹果公司,技术上是可以的。而且IOS开发还是一个封闭的生态系统,多产品比较简单。基于这些,也引出了我个人对iOS audit 4.3问题的第三个猜测;作为市值万亿美元的苹果公司,技术上是可行的。而且IOS开发还是一个封闭的生态系统,多产品比较简单。基于这些,也引出了我个人对iOS audit 4.3问题的第三个猜测;作为市值万亿美元的苹果公司,技术上是可行的。而且IOS开发还是一个封闭的生态系统,多产品比较单一。基于这些,也引出了我个人对iOS audit 4.3问题的第三个猜测;
3、iOS审核4.3问题涉及设备、IP、开发者账号、联系人、绑定银行卡等信息。2016年直播的时候,有人账号被封,这有共同点。同一个贝壳直播产品绑定一个认证*敏*感*词*下的多个账户,或者同一个银行信息下的多个账户,都将被屏蔽,而其他没有这些信息的信息则神奇地避开了。如果不能从代码相似度上给出合理的解释,那少数幸存者又是怎么回事呢?很多开发者开发了一个新的app,但是在送审的时候莫名其妙的遇到了4.3的问题。明明是新产品,代码无关,UI全新,市面上没有同类产品,
针对这种情况,我想到了以下几种可能:开发者使用了别人的开源代码,不幸的是这部分开源代码被苹果审核并标记为克隆包代码;开发者使用他人开源代码,在自己产品中代码占比过高,且代码被多个开发者使用,视为克隆包;开发者本身就是一个克隆包玩家,生产太多的克隆包,导致自己的设备、IP、开发者账号、联系人、银行卡等信息成为苹果黑名单,被苹果审核,只要开发的产品这些信息的开发者都被认为是克隆包
至此,iOS审核4.3的拒绝信息大部分都表明存在第三种可能,避开该信息也有助于马甲过关。游戏界人士早有体会。
基于以上猜想,结合各种情况,我们目前应该如何处理4.3的各种问题?
1. 代码级iOS审核 4.3 Issues 整理过往所有提交审核的开发者账号,整理类似clone bar产品的账号,移除已经上架的产品,处理未上架的产品审核通过,更新统一版本,上传空壳包。并且所有的应用都被命名为废弃包+时间点;
代码相似度
1⃣️现有代码混淆(改类名,改函数名)
2⃣️添加垃圾代码,让垃圾代码调用某个函数,而这个函数集中在某个页面,客户端是看不到的
垃圾代码的类似处理
避免其他产品克隆包添加的相同垃圾代码
" />
2.设计级iOS审计4.3问题
设计一套新的UI,微调基调和交互
交互方面,尽量使用苹果最新特性的交互,适配苹果最新产品
itc后台review提交图标和申请截图重新设计,与目前上线产品明显不同
命名应用名称,使用新名称代替产品后缀名,如星白快捷版
3. 4.3 设备、IP、开发者账号、联系人、银行卡绑定等信息相关问题。
开发者账号避免处理
1⃣️不要将相同和相似的产品放在同一个账号上审核
2⃣️同一个开发者账号尽量不要关联多个背心包产品
包装计算机设备以供处置
有条件的话最好不要使用同一个MAC包,无条件的话克隆包尽量不要超过5个
上传包IP处理
上传克隆包IP,尽量避免与其他克隆包IP相同
处理联系人和接收银行卡信息
克隆包过多,尽量避免相同的银行卡信息和联系人关联
技术网站和隐私协议用独立域名处理
可能的话,尽量使用独立的域名,技术网站尽量复杂,有产品信息、*敏*感*词*、公司信息等。
以前做背心包的时候,经常用类似的在线工具建官网。
关于app内的商品,可以直接访问科技网官网,官网上可以找到隐私协议,虽然不知道会不会影响,而且是假货一应俱全
以下为虚构的苹果评测背景,纯属虚构,无雷同之处。
本文由本人首发。【iOS代码混淆工具】版本:ZFJObsLib 1.7.2