关于java:世纪联华的-Serverless-之路

50次阅读

共计 4607 个字符,预计需要花费 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 大促难关。

2)Serverless 带来的新曙光

  • 疾速迭代部署

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. 业界发展趋势

谁在应用函数计算?

作者简介:
朱鹏,花名:旻苍,函数计算一线技术专家,专一函数计算资源调度设计研发。

本文整顿自【Serverless Live 系列直播】1 月 28 日场
直播回看链接:https://developer.aliyun.com/topic/serverless/practices

Serverless 电子书下载

本书亮点:

  • 从架构演进开始,介绍 Serverless 架构及技术选型构建 Serverless 思维;
  • 理解业界风行的 Serverless 架构运行原理;
  • 把握 10 大 Serverless 实在落地案例,活学活用。

下载链接:https://developer.aliyun.com/topic/download?id=1128

正文完
 0