世纪联华的 Serverless 之路

2002 年，公司成立后一直使用物理单机架构。

2014 年，因为双十二事件，导致公司不得不做出改变，将业务迁移到中央机房。

2018 年，随着国内公共云的发展，开始部署全面上云。

2019 年 6 月，公共云上出现数据库压力过大，世纪联华由此开始探索新架构方式。

到 2019 年 11 月，仅用大概 4 个月时间，世纪联华就把一部分业务搬到了阿里云的 Serverless 上，包括 API Server、函数计算、表格存储，在 双11 期间，这三款产品的应用表现非常优异，使得世纪联华决定 All in Serverless。

截至 2020 年 11 月，All in Serverless 使得整个公司的开发效率得到极大提高，成本大幅节省。

架构简洁；

不受外界网络环境的影响；

POS 机分散后单机冲击相对小。

数据迁移查询汇总困难，2014 年问题逐渐暴露，比如在杭州的总部，想查询湖州某个门店的实时交易量，基本不可能，跨网络查询和数据量大是难以解决的问题。

数据分发靠定期同步，比如客户在 a 门店注册的会员卡，很难去 b 门店消费，只能靠定期同步，把 a 门店的数据定期拷贝到 b 门店去，这其中存在很多问题，对消费者来说也非常麻烦。

故障时很难第一时间维护修复，我们不可能每个门店都派一名专业的维护人员，如果机器出了故障，只能打电话给总部的工程师，这种情况就很难做到第一时间赶到现场修复，这是很严重的问题。

单点故障容灾困难，因为所有的业务都包含在一个进程里面，如果进程出现异常， 也没办法把业务交给另一个进程处理。

升级困难，我们在浙江省有上百家门店，每一次升级都需要专业的运维人员把新代码包部署到不同的机器上。

新业务部署在单机上冲击巨大，举个案例，2014 年双十二，支付宝推出了使用支付宝钱包付款可以打 5 折的线下优惠活动，当时全国线下近百个品牌、2 万多家门店都参与其中，世纪联华也有参与，但是当天却出现了大量消费者无法结账在超市排起长队的情况。

问题可集中维护处理；

商品价格调整下发全部走网络；

数据可集中查询统计汇总。

管理员需要掌控机器细节；

宕机断网事件调查困难应急方案薄弱；

硬件升级成本高；

需要提前采购大量硬件备灾；

软件、系统批量部署成本高；

资源预算困难。

不再需要关心网络、操作系统的硬件细节。比如阿里云的 ECS 会提前做调度和预警，把用户数据转移并做多份数据的备灾，防止磁盘坏掉的情况发生。

硬件升级快捷简单。比如用户使用的是 4 核的机器，当发现业务增长迅速需要做硬件升级时，就只需要做一个镜像。比如在夜间做一个磁盘快照，重新申请一台新机器，然后把快照恢复上去，就可以完成一键迁移。对世纪联华来说，这是非常快捷的方式，对开发者来说也是比较好的体验。

机器扩容时间大幅缩短。上面提到的是单机扩容，比如 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容，例如用户交易系统的 API 接口，随着业务的发展需要由原来的 2 台机器扩到 8 台机器，这种情况下用户只需去申请机器，然后将镜像扩展到不同的机器上即可。

资源预算困难，由于无法预估业务遇到大促等活动时所能达到的体量，因此无法准确计算出所需硬件的数量。

水平扩展，水平扩展对研发有较高的要求。比如数据是否要做到无状态，无状态的话水平扩展会比较容易，而如果是有状态，数据可能就需要做缓存，这就会涉及到数据库相关的问题，例如数据过期、一致性等。如果对这些了解不够透彻，做水平扩展就会比较困难。

水位监控，许多开发者在水位监控上处理得并不完善，如果将各个业务系统混在一台机器上，当遇到机器水位较高，想要快速排查问题并及时进行流控、拆分、临时修复等就显得尤为困难。

财务预算困难，与资源预算困难类似。

硬件升级成本高，要做到用户无感无损升级，可能会涉及到连接上的处理与数据库一致性的问题。如果多个模块需要同时升级，还要注意数据结构的兼容问题。

数据库单点故障，许多厂家将数据全部放在一个数据库中，如果处理不妥当可能会造成单点故障。这就要做数据拆分，粗拆的话，需要注意事务和锁相关的问题，效率会大打折扣；细拆的话，做查询和排序时就会比较困难，给业务实现造成一定麻烦。

快速迭代部署，Serverless 研发效率快、运维效率高、架构解耦。

高并发、高弹性，Serverless 不需要人工扩容和运维管控。

稳定、可靠、安全，Serverless 使抢购活动和大促的整体体验都非常流畅。

数据、运营、成本控制，Serverless 提供了完整的运维观测和报警监控功能，运维工程师可以轻松很多；另外按使用资源计费，资源利用率可达 100%。

曲线图 1：类似 ECS 方案，曲线显示有资源不足和资源浪费的情况。

曲线图 2：机器扩容，有延迟和误差，需要提前操作，它的实时性和伸缩性都比较差。

曲线图 3：函数计算 2.0 预留模式，有预留资源和弹性资源，可以实时扩容。

资源管理层面：人工运维 -> 云平台工具运维 -> Serverless 免运维，实现完全自动化。

资源利用率：预算采购低利用率 -> 有限弹性高利用率 -> Serverless 100% 资源利用率。

资源成本：固定成本支出 -> 根据资源策略伸缩 -> Serverless 根据业务策略适配。

物理单机

自建机房

全面上云‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Serverless 尝试

All in Serverless