网站建设方案新闻,网页设计页面大小,购物网站 页面设计,旅游公网站如何做简介#xff1a; 2019 年 双11 过后#xff0c;世纪联华快速上云#xff0c;将线上核心业务改造为全 Serverless 架构的中台模式#xff0c;采用“函数计算API 网关OTS”作为计算网络存储核心#xff0c;弹性支撑日常和大促峰谷所需资源#xff0c;轻松支撑 618 / 双11 /…简介 2019 年 双11 过后世纪联华快速上云将线上核心业务改造为全 Serverless 架构的中台模式采用“函数计算API 网关OTS”作为计算网络存储核心弹性支撑日常和大促峰谷所需资源轻松支撑 618 / 双11 / 双12 大促。 作者 | 朱鹏旻苍 来源 | Serverless 公众号
一、世纪联华超市简介
1. 公司简介 杭州联华华商集团有限公司成立于 2002 年 7 月主要业务涵盖购物中心、大卖场、超市、便利店等零售业态G20 杭州峰会食材总仓建设、保障单位是浙江省商贸龙头企业。
集团 200 多家门店中主要涉及 POS 机交易、联华超市、CITY LIFE、天华世纪城等除此之外还有线上精选 APP提供线上购买、送货到家服务还会不定时推出优惠券领取、限时秒杀等活动。
2. 世纪联华技术架构演进方案 2002 年公司成立后一直使用物理单机架构。2014 年因为双十二事件导致公司不得不做出改变将业务迁移到中央机房。2018 年随着国内公共云的发展开始部署全面上云。2019 年 6 月公共云上出现数据库压力过大世纪联华由此开始探索新架构方式。到 2019 年 11 月仅用大概 4 个月时间世纪联华就把一部分业务搬到了阿里云的 Serverless 上包括 API 网关、函数计算、表格存储在 双11 期间这三款产品的应用表现非常优异使得世纪联华决定 All in Serverless。截至 2020 年 11 月All in Serverless 使得整个公司的开发效率得到极大提高成本大幅节省。
二、技术架构演进
1. 物理单机架构 2014 年及以前物理单机架构下一个超市通常只有 2~20 台 POS 机最多 20 个客户端架构非常简洁只要在一台物理机上部署好本地数据库交易系统、会员系统、商品管理全都放在一个进程上就足够。如果要做相关操作比如调取某个交易、给用户注册相关信息、调整商品价格只要通过 Admin 客户端连接进程再做相应改动即可。通常来说一个大型超市只要买一台性能足够强的机器就可以服务好几十个 POS 机发起的请求。
单机架构优劣势比较
1优势
架构简洁不受外界网络环境的影响POS 机分散后单机冲击相对小。
2劣势
数据迁移查询汇总困难
2014 年问题逐渐暴露比如在杭州的总部想查询湖州某个门店的实时交易量基本不可能跨网络查询和数据量大是难以解决的问题。
数据分发靠定期同步
比如客户在 a 门店注册的会员卡很难去 b 门店消费只能靠定期同步把 a 门店的数据定期拷贝到 b 门店去这其中存在很多问题对消费者来说也非常麻烦。
故障时很难第一时间维护修复
我们不可能每个门店都派一名专业的维护人员如果机器出了故障只能打电话给总部的工程师这种情况就很难做到第一时间赶到现场修复这是很严重的问题。
单点故障容灾困难
因为所有的业务都包含在一个进程里面如果进程出现异常 也没办法把业务交给另一个进程处理。
升级困难
我们在浙江省有上百家门店每一次升级都需要专业的运维人员把新代码包部署到不同的机器上。
新业务部署在单机上冲击巨大
举个案例2014 年双十二支付宝推出了使用支付宝钱包付款可以打 5 折的线下优惠活动当时全国线下近百个品牌、2 万多家门店都参与其中世纪联华也有参与但是当天却出现了大量消费者无法结账在超市排起长队的情况。 因为我们刚刚引入一个新的支付方式所有的业务都在单个进程上耦合度过高当时大家集中结账访问量过大导致支付出现问题整个单机访问无法进行下去其他的业务模块也因此受到影响最后只能重启机器。因为这个问题世纪联华开始尝试做出新的改变。
2. 中央机房部署架构
单机最大问题是如果门店出现问题相关工程师无法第一时间赶到现场尤其是多个机器、多个门店同时出现问题的情况这时最好的办法是把所有机器集中在一起做集中的数据修复、运维管理和软件升级。
2014 年到 2018 年期间世纪联华逐渐把单机架构整个迁移到了中央机房。中央机房是自建的做法就是把数据库、交易系统、会员系统、商品管理全部拆分到多个进程当中。这样一来如果会员系统挂掉了还可以暂时匿名购买商品管理临时出问题但只要交易系统没问题就还可以顶上。耦合一旦降低对于整个门店的业务保障来说有了很大的提升。 在这里我们做了一个 node 节点node 节点连接中央机房的数据库以及各个系统模块。如果出现问题只需要在中央机房做相关修复即可。除此以外如果需要调整商品价格也只需在中央机房上直接设置然后同步到所有门店的 node 节点上就可以了。
中央机房部署架构的改进和不足
1改进
问题可集中维护处理商品价格调整下发全部走网络数据可集中查询统计汇总。
2不足
管理员需要掌控机器细节宕机断网事件调查困难应急方案薄弱硬件升级成本高需要提前采购大量硬件备灾软件、系统批量部署成本高资源预算困难。
3. 全面上云 2016 年以后随着国内公共云的迅速发展全面上云势不可挡。在此期间阿里云在技术上取得了许多突破与提升例如 ECS 的对外发布。世纪联华在 2018~2019 年期间把自建机房中的各个系统模块逐渐迁移到了公有云整体架构没有太大改变因此迁移工作相对顺利。
全面上云的改进和不足
1改进
主要有以下三个方面
不再需要关心网络、操作系统的硬件细节
比如阿里云的 ECS 会提前做调度和预警把用户数据转移并做多份数据的备灾防止磁盘坏掉的情况发生。
硬件升级快捷简单
比如用户使用的是 4 核的机器当发现业务增长迅速需要做硬件升级时就只需要做一个镜像。比如在夜间做一个磁盘快照重新申请一台新机器然后把快照恢复上去就可以完成一键迁移。对世纪联华来说这是非常快捷的方式对开发者来说也是比较好的体验。
机器扩容时间大幅缩短
上面提到的是单机扩容比如 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容例如用户交易系统的 API 接口随着业务的发展需要由原来的 2 台机器扩到 8 台机器这种情况下用户只需去申请机器然后将镜像扩展到不同的机器上即可。
2不足
主要有以下六个方面
资源预算困难
由于无法预估业务遇到大促等活动时所能达到的体量因此无法准确计算出所需硬件的数量。
水平扩展
水平扩展对研发有较高的要求。比如数据是否要做到无状态无状态的话水平扩展会比较容易而如果是有状态数据可能就需要做缓存这就会涉及到数据库相关的问题例如数据过期、一致性等。如果对这些了解不够透彻做水平扩展就会比较困难。
水位监控
许多开发者在水位监控上处理得并不完善如果将各个业务系统混在一台机器上当遇到机器水位较高想要快速排查问题并及时进行流控、拆分、临时修复等就显得尤为困难。
财务预算困难
与资源预算困难类似。
硬件升级成本高
要做到用户无感无损升级可能会涉及到连接上的处理与数据库一致性的问题。如果多个模块需要同时升级还要注意数据结构的兼容问题。
数据库单点故障
许多厂家将数据全部放在一个数据库中如果处理不妥当可能会造成单点故障。这就要做数据拆分粗拆的话需要注意事务和锁相关的问题效率会大打折扣细拆的话做查询和排序时就会比较困难给业务实现造成一定麻烦。
4. Serverless 的探索和尝试
1线上不可控业务上的预防 2019 年年中大促时由于线上业务用户访问不可控数据量过大MySQL 单机访问被打爆导致了存储数据库出现问题影响到了多个系统造成了一定的损失。 此事件之后世纪联华就想直接把 MySQL 替换掉这时我们发现阿里云有一款产品叫“表格存储”表格存储最大的优点是用户不需要关心访问量和机器数的比例关系。只要访问量扩大后台会自动扩容增扩机器满足高并发的数据读取在数据并发请求降低处于低峰期时后台就会将机器回收用户不再需要关心机器的数量及如何调动。 针对用户流量不可控问题世纪联华引入了阿里云的产品“API 网关”API 网关可以针对不同渠道商做管控发布及流量控制。比如发现微信渠道流量有异常就可以借助 API 网关进行限流。
另外计算也是一个非常重要的问题世纪联华经过探索发现阿里云的“函数计算”非常契合我们的业务场景。比如定时抢购、优惠券投放等活动造成巨大的 burst 冲击当发现计算资源不够的时候再去买机器肯定是来不及的而函数计算及时扩容的功能就很好地解决了这个问题。另外其数据观测和异常报警功能也吸引到了世纪联华。
世纪联华将这三个产品相结合替换掉了原来的会员查询功能最终得以成功渡过 2019 年的 双11 大促难关。
2Serverless 带来的新曙光 快速迭代部署
Serverless 研发效率快、运维效率高、架构解耦。
高并发、高弹性
Serverless 不需要人工扩容和运维管控。
稳定、可靠、安全
Serverless 使抢购活动和大促的整体体验都非常流畅。
数据、运营、成本控制
Serverless 提供了完整的运维观测和报警监控功能运维工程师可以轻松很多另外按使用资源计费资源利用率可达 100%。
5. 函数计算 2.0 及 All in Serverless 曲线图 1类似 ECS 方案曲线显示有资源不足和资源浪费的情况。曲线图 2机器扩容有延迟和误差需要提前操作它的实时性和伸缩性都比较差。曲线图 3函数计算 2.0 预留模式有预留资源和弹性资源可以实时扩容。资源管理层面人工运维 → 云平台工具运维 → Serverless 免运维实现完全自动化。资源利用率预算采购低利用率 → 有限弹性高利用率 → Serverless 100% 资源利用率。资源成本固定成本支出 → 根据资源策略伸缩 → Serverless 根据业务策略适配。2019 年 双11 过后世纪联华快速上云将线上核心业务改造为全 Serverless 架构的中台模式采用“函数计算API 网关OTS”作为计算网络存储核心弹性支撑日常和大促峰谷所需资源轻松支撑 618 / 双11 / 双12 大促。 图2020 年 双11 大促
2020 年 双11 大促世纪联华线上业务实现 All in Serverless上为流量时间的曲线图下为调用延迟时间的曲线图。 图Serverless 助力世纪联华降本提效
三、设计架构演进总结
从物理单机到 All in Serverless 的架构演进 物理单机 架构简单高度耦合数据同步难升级困难无法横向扩容 自建机房 统一维护升级数据同步统一系统部署困难硬件成本高非业务调查难临时扩容 全面上云 硬件升级简单扩容能力提升备灾能力提升设计要求高监测告警原始数据库单点流控问题 Serverless 尝试 数据库单点问题流控问题解决横向扩容监控告警费用免预算部分延迟较大 All in Serverless 解耦冷启动体验提升研发效率提升成本费用下降
四、函数计算简介
1. 阿里云函数计算产品全景
函数计算是国内生态最完整、功能最丰富的 Serverless 产品开发者一步上云、一键 Serverless 化将成为现实。 2. 业界发展趋势
谁在使用函数计算 作者简介 朱鹏花名旻苍函数计算一线技术专家专注函数计算资源调度设计研发。
原文链接
本文为阿里云原创内容未经允许不得转载。
