今天坐M365，我又悟了

说来也怪,每天坐的这趟M365公交车，居然让我一个文科生琢磨起了云计算的事儿，事情是这样的——

上周二早上,我照例在“车来了”小程序上盯着M365的实时位置，那个绿色的小图标在手机地图上慢慢移动，显示还有8分钟到站，我掐着点下楼，刚到站台，车就来了，上车、扫码、“滴”一声，整个过程行云流水，我找了个靠窗的位置坐下，忽然脑子里冒出来一个念头：这个实时公交功能，是不是就有点像那个什么“云服务”？

你看,我的手机本身并没有能力去追踪那辆M365到底在哪，它所做的事情很简单：把我的位置发给远端的服务器，服务器根据公交车上GPS设备回传的数据，算出来这辆车大概还有多久到我这站，然后把这个结果再传回我的手机上，我的手机不过是一个显示终端罢了，真正的计算都在我看不见的地方完成，这不就是“云”最朴素的样子么——计算发生在远方，结果呈现在眼前。

后来我越想越觉得,M365这条线路本身，就像极了一套精心设计的分布式系统。

先说调度,M365跑的是高新区到市中心这条线，早高峰往市中心方向挤得跟沙丁鱼罐头似的，晚高峰反方向又是同样的情况，如果每辆车都按固定间隔发车，那高峰期肯定有人挤不上，平峰期又可能空跑大半程，但我发现M365不是这样的——早高峰的时候，往市中心方向差不多五分钟就来一班，有时候甚至两辆连着来，调度中心那帮人肯定有一套算法，根据各个站点实时传回的客流数据、路况拥堵情况，动态调整发车频率和车辆分配，这不就是负载均衡嘛，负载高的线路多分配资源，负载低的少分配，整个系统的效率就上去了。

用个表格把这条线路的基本面捋一捋,你就知道为什么我把它比作一个信息系统了：

再说过滤和降级,有一回坐M365，车上那块显示到站信息的电子屏坏了，全程黑屏，但是司机师傅每到一站都大声报站名——“XX路到了啊，有下的没有？没有走了啊！”偶尔搭一两站的那种乘客，就挤到前面来问师傅哪站下，你看，这就是系统设计里的优雅降级——电子屏这个“组件”挂了，人工报站这个“备用方案”立刻顶上，核心功能“让乘客知道到哪站了”没有丢，还有更绝的，有次整条路封路施工，M365临时改道绕行，手机App上立刻更新了绕行通知和临时站点，这种实时响应机制放到软件系统里，就是服务熔断和动态路由嘛。

后来有一次跟一个在公交集团上班的朋友吃饭,聊起M365，他说这条线算他们内部的一个试点，车上装了不少传感器，发动机温度、刹车片磨损、轮胎胎压这些数据都实时上传，维修部门不再是定期检修了，而是看数据预警——哪个零件快不行了，提前换，这样既安全又省钱，车也不会半路趴窝，他说这叫“预测性维护”，我当时听完就说，这不就是现在搞运维的那帮人天天挂在嘴边的AIOps嘛，从被动响应变成主动预防。

现在每天早上坐M365,我都有点恍惚了，你说它是一辆公交车吧，确实就是，装着几十号人轰隆隆地在城市里跑，但你换个角度看，它又是一个不停运转的数据节点，被调度算法安排着，被实时监控保护着，把我们从城市的一头送到另一头，这两种身份就这么奇妙地叠在一起，像一个庞大系统里一颗不起眼但又不可或缺的螺丝钉。

图1：M365公交车行驶在城市高架桥上，车身上的线路编号在晨光里泛着微光

图2：手机App显示M365实时位置和到站预报的界面截图

这么一想,每天早上那声“滴”的刷卡声，本质上就是一次API调用——我发出乘车请求，系统确认扣款并授权通行，只不过这个“服务器”是一辆实实在在的大巴车，而“响应”是把我从家附近运到公司楼下，等哪天M365真的用上了云端调度、车路协同那些更高级的东西，我估计坐一趟车能写三千字的心得，到站了，不说了。