导语
华南零售行业全渠道联盟，简称“南零商盟”，华南时尚行业CIO联盟和广州鞋服行业信息化联盟、华南CIO联盟（筹）唯一联合指导交流社群，汇聚服饰、时尚行业新零售全渠道搭建双方的精英联盟；
| 专心 | 专业 | 专研|
时尚行业信息化第一微信公号
2020·第二届智慧（新）零售信息化大会
暨华南时尚行业CIO年会
即将开启报名！
大家好，我是无锡迅羽科技的陈强，毕业之后一直做技术这方面的工作，然后先后在IBM，还有云计算做过，目前在迅羽科技担任技术总监一职。
我今天给大家分享的是，最近做的商城项目的一些经历，就是包括品牌商如何从一开始搭建商城到后面随着流量的提升，我们怎么去优化系统，然后另外还有业务量大幅提升的时候，比如像类似于双11这样的活动的时候，我们系统应该怎么样去调整。
作为品牌商，我们现在要去做一个微信小程序商城，我们怎么去平衡一些中间的因素，比如说成本，人员，技术转型，还有考虑到后续的一些系统升级，成本，成本主要就是说，如果是自建团队还是外包。当然考虑外包的话，后期维护更新怎么保证，还有如果是自建团队的话，比如说人招过来了，那这个项目结束了，后续的人员怎么工作，分配，包括这个成本负担。那不管是自建还是外包人员的流动性对项目会产生较大的影响，那我们这个时候如果是算外包，我们要去考虑他人员稳定性，那自建的话更要去考虑人员的稳定性。
我经历过一些品牌大的品牌商，他们在自建团队过程中，一开始是这个比较成功，但是后期人员的稳定性产生了很大问题，导致主要的核心人员流失，整个项目后续没有办法去维护。
然后技术转型这一块儿要考虑的因素比较多，一是这个项目人员的技能，还有技术框架的稳定性，另外一个是在我们很多时候我们要选择自主开发。这时候我们要考虑我们购买的产品，它使用的技术，那购买产品的技术会影响我们的转型。
这样可以把这个成本降下来，同时也保证后续更新。可以随时满足业务的一个需求，因为是自己人，可以随时的去进行一些调整。
下面这个图呢，是一般一个小型的电商网站的一个架构图，主要是这个web，web服务器，搜索服务器，应用服务器，数据库服务器。我们在服务器选型的时候，我们现在建议都是直接就上阿里云，腾讯云，第三方服务，这样的话。不管是这个服务器维护，管理，包括后续的系统的升级都特别方便，系统遇到硬件的性能瓶颈的时候，我们可以很快的在阿里云购买那个网络，硬件升级。
网站一开始都要去做一下这个web服务器，几个搜索服务器，在架构上做个切分。其实当只有几百人同时并发的时候，这个网站是够用了，但是为了考虑到到后期的扩容，所以我们建议就是一开始建设的时候，我们就把相应的业务去做个切分，这样后续升级的时候都比较很方便地去进行升级，通常电商网站是整合我们内部的一个商品，会员库存，还有订单系统对外呢，整合一个第三方登录还有支付短信，包括email这些。
最上面这个架构图是我们在跟那个客户做运维的过程中，出现了第一次升级，主要原因是当有几百上升到几千的时候，整个服务器的带宽明显就是瓶颈了，这时我们去做了一次架构的调整，主要是添加了一些web服务、搜索服务，还有内存数据库，然后来应对这个峰值的一些访问。
电商网站通常图片比较多，图片会大量的占用那个带宽，导致带宽拥挤，甚至堵塞，造成整个网站访问较慢，用户体验比较差，那我们给出一个比较好的建议，就是把这个静态资源放到第三方上，这样不但可以降低个升级带宽的费用，第三方可以直接进行调整，可以提升用户体验，另外，用户访问。浏览网站的时候，大部分都是固定内容，像商品啊，这些其实是相对来说不会发生大的变化，这些内容搜索速度快。而且可以进行多维度的搜索。
另外就是用户访问频次高，这个数据变化频繁，比如说库存，还有商品收藏数，购买数，这些数据。放在内存SD内存数据库中。提高这个提升性能的同时，降低这个直接去访问数据库对数据库造成的压力。
但用户访问量比较大的是我们重点去监控网络的一个带宽，这个带宽页面访问数量。数据库性能。另外考虑就是配合第三方的一些应用，反正是做小程序统计的，腾讯的，或者百度的统计，对这个页面用户访问的。页面做将以访问频次做监控，做监控的目的就是我们结合这个访问频次和数据库的性能监控，然后去对性能比较差的页面去做逻辑切分，去掉一些不必要的逻辑优化，性能比较差的逻辑。
另外，结合我们跟客户做这个微商城。因为我们在做的过程中也用过阿里云的RDS和腾讯云的，这个RDS。推荐使用阿里云RDS，因为阿里云的RDS，他的数据库如果真的出现性能瓶颈的时候，比如数据库的性能瓶颈，它的SQL语句给一些比较好的提示，可以快速的把数据库的性能提升一下，因为腾讯云，它是只是有一个慢思考的一个日志，我们只能去把MYSQL日志拉下来，然后对他进行一个日志分析，然后才再去解决这样的问题。
上面这个架构图是我们对系统进一步优化之后的一个架构图，流量上升，最后业务量激增了。那要应对类似双11这种下单的一个场景设计。这个其中下单会对于it系统产生比较大的冲击，所以我们要去调整通信机制。让整个服务器架构主要来承载前端的一个访问流量，访问的压力和下单的压力。我们可以考虑读写分离来提升数据库的一个响应性能。
这里我分享一个案例，这个这个图就是案例的一些，这个案例的一些特点，整个业务场景是这样的，业务为了清库存，他拿出一部分热销单品参与促销，然后整个网站参与促销。指定固定时间开始开放下单，也就是中午12点的样子，然后。由于整个库存产品，大部分产品的库存并不是这么多，特别是热销产品，库存深度较浅，所以整个促销的特点，就是说，库存深度浅，热销单品集中，促销力度大，预热的效果也很好，然后又是他指定一个时间点下单。
那我们网站这个时候的一个订单的处理逻辑，其实是一个标准的。电商的网站的处理逻辑，他是订单提交的时候，检查数据，里面的库存是否满足，如果满足的话，库存扣减，如果订单中任一件产品库存不满足的时候，整个订单提交失败，那这个时候就都会出现如果用户提交的订单中的商品重合，会导致这个在数据库级别出现等待。因为他是更新同一条库存记录，然后订单处理速度就会相对比较慢，特别是出现比较大的订单，比如单个订单中出现10个，20个款号儿的时候，订单处理速度特别慢，然后大量出现订单提交失败，由于这个数据库大量的等待，数据库连接池也会被占满，整个网站速度都会变慢，订单无法提交。
这个图就是刚才上面描述的产品的一个图的示意，就是用户统一提交的订单中有商品，交叉的时候库存处理会排队，这样的话就是排队的时间超过整个事物的时间，他就会事务超时。
面临这种情况来说，我们做了一些数据分析，主要就是，热销产品的加购物车数量特别多，在预热的时候加的特别多，然后他库存深度也比较浅，所以导致大家都疯狂的去抢这些热销的单品，后来我们在技术上就是说提出了一些解决方案，比如说，在用户加购物车的时候就进行库存的一个逻辑处理，还有库存锁的机制，我们有内存数据库调，数据库中同时引入排队机制，加购物车处理，进行库存处理，在那个提交订单的时候，我们可以检查一下这个是不是库存已经处理，如果已经处理了，就不再进行，库存处理。
当然，架构处理库存需要考虑一些其他因素，比如说。用户，用户恶意下单，还有库存返还的相关项逻辑的调整，都要去考虑清楚，不然的话会导致整个网站没有库存，影响业务的开展，因为之前的下单逻辑是直接进行数据库，那个操作是做成一个直接等待的一个直接原因，那我们将这个数据库的处理放在内存数据库中，当然也是要进行数据库锁的，但是内存数据库的处理速度会处理比较快。这样同时也避免了数据库连接池占满，提升整个系统的响应。
第三个办法就是用户提交订单后将这个订单处理，减少用户重复提交订单，这样从那个数据库调到内存数据库，然后引入排队机制，我们经过压力测试，我发现整个系统的性能，订单处理性能提高了大概15倍，从一分钟，五分钟，从五分钟100单左右提到了五分钟1800单左右。
另外，我想说的就是网站的优化，其实是几个因素的平衡，主要是业务，成本，技术。我们技术主要是在满足业务的需求，但是我们也要让业务知道技术的边界，和一些调整对应的成本。然后在面对一些大的促销活动的时候，最好是业务和技术一起评估，预计这个销量和访问量，然后。这边技术，可以给一些风险评估，以及建议方案，当然我们也要包含这些方案的成本。然后我再和业务一起讨论一下，是否愿意去做这样的投入，因为有时候这个投入产出比其实并不高的。
下面这张图梳理一下，就是整个优化过程中的一个思路，主要就是限流，分流和提高通过率，现在主要就是限制用户的访问量，我们可以通过用户名单，或者是IP的方式去限制用户的一个访问量，那分流主要就是把这个压力给分开，比如说分到多个页面，从时间维度上分开，还要从这个服务器上，我们分到多个服务器上，另外一个。就静态资源的一个分离，还有一个这个，排队也算是一个分流的一种形式。
提高通过率，主要就是说，提高程序级别的一个响应性能，我们刚有提到引入这种软件的内存数据库，这种类似缓存，还有一些复杂逻辑，我们去看一看，是不是可以做个拆分，还有去掉无用的逻辑，这个思考，是不是可以优化一下，主要是加索引，还有优化SQL语句，要权衡一下，有些逻辑是不是可以提前处理，如果可以提前处理的话，那就提前处理，不要把所有的逻辑放在一个时间点来处理。
那今天晚上我要讲的主要内容，就这些，稍后我会把我今天晚上讲的这个PPT。具体翻译出来分享给大家，如果大家有什么问题啊，讨论一下的话可以说一下，我跟你一块儿来讨论一下。
另外一个提高通过率的常规手段，就是做数据库的读写分离，我在一个电商项目中去做了，读写分离之后，这个整个网站的访问性能大概提高了十倍以上，所以这个性能提升是非常明显的，另外一个它访问历史的数据也要定期的去做一些清理，订单数据，用户的访问数据定时清理，这样的话，性能也会提升不少。
注：以上内容摘选自南零商盟分享会，转载仅限学习分享；
如产生版权问题，请联系我们处理；
文章不代表”华南时尚行业CIO联盟“立场！
本篇文章来源于微信公众号: 时尚消费品行业CIO
关注微信公众号
