广州地铁
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 系统。它总结了过往数十年的人流量数据，在高效运营的同时保证乘客的安全（数据安全）。