广州地铁

广州地铁

Zeusro
Zeusro

web 本质是一种流量,一种数据的流转。当前的 web 只是 Serverless 的一种特例(存活期很长的 Serverless )。如果从这个角度上看,其实广州地铁是一个很优美的 Serverless 系统。

高效率的web,本质是一种希望数据的流转尽可能快(TPS越高越好),这跟广州的地铁的设计理念是不谋而合的。我之前在知乎上说过,广州地铁本质上是一个排水系统 ,他设计的目的不是把你运送到目的地,而是希望你尽快离站。所以现在就算你进站后再出站,也要收费(以前有一段时间我记得不用)。

回到本题。 Serverless 是一种存活期相对较短的设计。比如广州地铁的存活期一般是日间,到了夜间设备要进行维护。我们把整个问题简单化,只取一号线来讲。假设平时只运行 3~50 辆车。那么低峰期应该只运行3辆车(降低成本),高峰期应该在确保安全的前提下,把运营效率尽可能提高(增加班次)。而到了晚上,众鸟归巢。运行实例为0。

Serverless 的优势

减少成本:每一个站台只需要少量的广州地铁人员,就能撑起一个站点。地铁工作人员无需关注底层系统(地铁)的运维。他们只需要在调度室吹空调,按按这个按按那个按钮就行。

快速创新:以前广州地铁需要人工买票什么的,现在支持银联卡,NFC,微信,支付宝计费。

按需使用、灵活弹性:业务可以根据配置的条件灵活调配资源,它会在夜间睡觉(运行实例为0),在低峰期低开(运行实例为3),在高峰期高开(运行实例50),在超高峰期限流,从而实现资源的最大化利用与运营成本的压缩。

广州地铁其实是一种实时数据流处理

从乘客角度,搭地铁本质上是一种数据库事务。 原子性(Atomicity)是妹子要么上车,要么不决定搭地铁; 一致性(Consistency)是指妹子上车下车会按照她的期望值,如果她下错站了,说明了她没有实现一致性; 隔离性(Isolation)是指妹子懒得理你; 持久性(Durability)是指妹子上车这一行为有地铁系统作证(上下车买票的凭证)。

而从地铁角度,整个广州地铁其实是实现了分布式事务的一套实时数据流处理系统。

广州地铁2020

前端常驻,后端动态高效伸缩容

我们会发现,那些固定设施都固定在那里的。基础设施是一种“前端”。而地铁列车是一种“后端”。

因为广州地铁事关人命,所以在伸缩容方面采取的策略是根据过往数据预测未来。而伸缩容目前是用人工方式解决。

这一点也是一种提醒。我们在设计 web 系统的时候通常分前后端。如果按照 Serverless 角度来重新思考这个问题。那么应该让前端资源常驻(前端只是一些简单的静态文件,占用服务器资源很少),而让后端动态伸缩。这样就不会影响用户体验。

流量切分

高峰期广州地铁的运营人员会设置各个栅栏。超高峰期会飞站或者拒绝乘客搭乘。从而实现数据的安全(乘客的安全)。

计量能力

根据乘客的搭乘距离计费。而站台距离本质上是时间。可以说使用时间越长,费用越高。

后端的单一职责

基本上广州地铁是偏向于人运,而不是货运。每次我要搬家的时候,搭广州地铁总是相对比较麻烦。因为一开始我也说了,广州地铁的设计理念就是一个排水系统。如果变成货运的话,运营效率会大幅度降低。

所以,我们在设计 Serverless 后端微服务的时候,也要记住这一点。尽可能让后端微服务的职责尽可能小,小到甚至不需要微服务发现系统。举个例子,xx网盘通过 Serverless 服务处理瞬时的视频转码请求。

结论

广州地铁其实是一个运营很高效的 Serverless 系统。它总结了过往数十年的人流量数据,在高效运营的同时保证乘客的安全(数据安全)。