宝马雕车香满路，另类架构老司机

变道提前打灯

上海中环和罗山高架路上的不少电子警示牌，不厌其烦地提示着"变道请提前3秒打转向灯"，以前看到了也就看到了，因为笔者一直很守法，一般提前5秒就打了，所以此警示从未惊起什么波澜。某日清晨脑回路猛然搭住，就想如果变道不打灯被视作违章的话，这个识别的程序逻辑该怎么设计呢？

砍材不误磨刀功，不了解的领域准备工作还是要充分调研的：

大众熟知的闯红灯识别，步骤是通过路口的三个感应线圈触发摄像头的三次拍照，命中三次就视为违章，笔者开始也是想当然的认为摄像头大部分都是靠拍照。

后来跟专业的同学求证，新一代交通摄像头的工作原理其实大约是这样子的：摄像头会持续拍摄交通情况的视频，而在摄像头所在位置附近会有个本地的存储器和处理器，视频就存储在那里，而后处理器会基于图像识别或者人工智能blablabla等技术手段分析视频中的违章情况，一旦识别出就会截取视频生成图片，最后这些高清截图会上传到远程的市局服务器存储，而违章截图也是从此而来（该信息只是单方面求得，如有偏差欢迎指正）。

继续又去查了一下，汽车转向灯的频闪间隔大约是1Hz，也就是一秒钟闪烁一次，当然也有0.5秒闪烁一次的，这个汽车行业和国家并没有硬性规定。

抛开图像识别的领域不谈，剩下的实现难度在哪里呢？且让我直接写三个案例来阐明：

Case 1

变道前的4.01秒开启转向灯，到3.01秒的时候转向灯刚好熄灭，到2.01秒的时候转向灯再次亮起。

Case 2

变道前的4.99秒开启转向灯，到3.99秒的时候转向灯刚好熄灭，到2.99秒的时候转向灯再次亮起。

Case 3

需求只提到了提前3秒这个下限值，那上限值应该是多少呢？我可否提前5秒打转向，甚至提前1分钟打灯呢？很明显间隔太久的转向灯完全没有意义，所以这个需求描述是有缺陷的。

剖析解读

Case 1 & 2两个案例类似，都在3秒前打灯了所以肯定不违章，但是3秒这个时点上转向灯都是熄灭状态。视频分析所需的时间窗口当然不能卡在3秒这个时点上，那么需要放大到多少合适呢？案例1的时间窗口必须不小于3.02秒，案例2不小于4秒。注意，这里说的是时间窗口的下限。

而Case 3主要说的是时间窗口的上限，因为我不可能把时间窗口设置到无限大，按照交通实际情况，1分钟开外的转向警示基本无意义了。经查交通法规里确实没有这方面的描述，看来对于“提前”这件事情大家都知道很难量化的定义它。

再考虑一下需求设计问题：

（架构师的基本素质之一 -- 质疑需求&明确需求）

1. 是选择提前“时间”合适还是提前“距离”合适？选择“时间”就会出现上面的时间窗口临界问题。选择“距离”，在不同的车速状况下，“车速”越快打转向灯的提前距离就应该越大，若是需要再严谨些的描述，这个“车速”应该是前后车的“相对速度”，想想是不是如此？

2. 对于汽车的转向灯频闪频率国家似乎并没有一个统一标准，那就意味着有长有短，进一步造成时间窗口的不可确定性。

3. 闪烁次数前文也简单提过，基于频闪频率的最小闪烁次数也需要保证，否则连2S的时间窗口都看不到转向灯亮起过，这视频没法分析了。

另外，基于3个案例假设我们设定时间窗口为变道前的[-5s, -3s]，表示这个时间区间内必须出现过转向灯的亮起状态。如果某个极端情况转向灯在[-5s，-3s]仅亮起一次，(-3s, 0) 再也没有亮起过，也就是转向灯总共就闪了一次而已，警示作用很不明显，那么对于转向灯的最小闪烁次数是否有要求呢？经笔者对自己车子的多次测试，开启一下转向即使马上关闭，转向灯也至少闪烁3次。(对测试当日跟我车屁股后面的司机师傅们深表同情，你们可能一直在骂前面那个傻叉为什么一直在打转向？)

解决方案

透过问题看本质无非就是时间窗口的临界设定问题。

首先简单放大时间窗口这么低级的方案肯定为架构师所不齿，因为再大的时间窗口都可能会存在临界问题，而且时间窗口越大处理器分析的压力就越大。

这里我要祭出本人一直以来作为架构师灰常灰常重要但是很容易被忽视的一条原则：“能用规范化和标准化来解决的问题，就不要再花更多的成本用在工程手段上”。此原则在创业公司尤其适用。

比如费尽九牛二虎之力研发了一个元数据管理系统，可以对业务系统里各类风格迥异千奇百怪格式的日志进行解析，后果是这个元数据系统可能永远跟不上业务系统更新的速度，而你只能跟在屁股后面不停的修正这个元数据系统。如果写个日志组件，规定让所有的业务系统必须集成，直接打印出规范的统一标准的日志来，元数据系统的设计就可以相当简单了。

再比如运维耗尽全力为了实现基于容器化的持续部署，不得不为每个业务系统不统一的变量声明方式编写大量的yaml配置文件，为什么不能让业务系统统一改造成规范的变量配置方式呢？相信这才是一劳永逸且最省力的方式吧。

回到转向灯的问题上来，我的解决方案首选压根就不是技术方案，而是先把上面提到的所有不确定的问题先制定出标准来。比如闪烁频率，最少闪烁次数等。

解决方案我会用软件产品的几个典型场景来类比，让大家自己去联想吧。

银行日终跑批

银行支付类金融系统都会有日切，做一些停业记账、清算、会计日期切换等操作，而这个窗口就算时间足够的短，也不得不停止某些业务比如转账，这段时间也就是银行日切黑暗期。有的银行在晚上 9-11点，有的在凌晨1-2点，不一而足。首先对于庞大的信息系统要做好时间的完全同步和一致是基本不可能的，所以时间窗口可能产生交叉，由此出现任何的账务数据异常，都是很可怕的一件事情。

TCP的滑动窗口实现

前面描述的所有细节都是基于变道这个时点来往前倒推，如果用类似TCP的滑动窗口方式呢？比如我们就设定5秒的滑动窗口，交通摄像头我们估算一秒100帧的水平，那么5秒的窗口里就有500帧图像需要处理。对滑动窗口内的每帧图像进行识别，标示出当前转向灯亮暗的状态，当某一帧识别出变道动作，那只要把[-5s, -3s)区间内的图像识别的转向灯状态做个简单的运算即可，就算区间再大一些也完全不是问题。

当然转向灯闪烁间隔是一秒的话连续100帧图像都应该是一样的状态，如果只是做转向灯的识别那么可以把粒度放宽直接跳过其他的99帧，如果也做其他的违章识别另当别论。

随着处理器给出分析结果，窗口向后滑动，继续处理新帧和等待处理器的应答，如此循环往复。

另外，流式数据处理框架Spark Streaming也采用了滑动窗口实现方式。

Minimum Window Substring算法

最小覆盖子串算法，也是从滑动窗口延伸的一个算法，当然也有数据结构的小窍门。因为要取最小，所以也涉及到如何收缩窗口让子串最小。请考虑如何让收缩窗口让视频分析的区间更小呢？

算法讲解参见 https://www.jianshu.com/p/ce80b4c07c22

分布式锁的临界问题

分布式锁的实现方案很多，市面上以Zookeeper, Redis实现的居多。不管是哪种，都要考虑这么一个问题：持锁的进程在释放锁之前崩溃了，导致锁一直在无法释放的状态。为了避免这种情况，一般会设置一个锁失效时间，这个时长设定一般要比99%的持锁时间久，那么就引入另一个问题，假如持锁的进程A就是不小心抖动了一下导致持锁时长超过了失效时长，而失效机制导致锁的释放就意味着进程B也可以持有这个锁。A B两个进程同时持有锁，我就问你怕不怕！我就问你慌不慌！不然的话，或者你的系统允许这种极端情况的发生，有一定的容错能力，大不了最后再补救。或者你需要一个双向的锁检测机制，客户端在逻辑链路上的关键节点不断检测锁的剩余时间，然后基于自己估算的仍需时间延长锁的失效时间，反过来，服务端也可以检测客户端的持锁时长，在超时那一刻，通知客户端必须做出锁失效/快速失败的回滚处理等等。这些细节都不是那么容易操作的，所以我也就抛出个思路，拿走不谢。

移步《理解锁以及分布式锁》

路面积水问题

当日是个雨后的早晨，四处都有积水。

这是发生在“变道转向”之后再次让我陷入思考的第二件事。

示意图如上，我要说的积水问题必须是在高架上下闸道口的坡面上的。为什么我不说更常见的平坦路面的积水区呢？因为作为一个有素质的老司机，经过平坦路面的积水区时路边若是有行人，必然速度放缓慢慢前行，以防积水泼溅到路人。而在高架坡面上因为视野中看不到高架底下的行车或者行人，有些时候下意识的就冲过去，高架下方“争渡争渡惊起一滩鸥鹭”。

这里还是友情提醒一下，驾车但凡涉水不管什么情况都要放缓，这对别人对自己都没坏处。

那么这个故事到底对架构有借鉴意义呢？请大家思考：

• 路面为什么会有积水？
• 积水情况是否有监控？
• 我只是高架路面设计师，如何想得到高架下的行车或行人？

路面为什么会有积水

原因无非两个，路面不平整或者没有倾斜度，排水系统不给力。对于路面施工的质量问题，没什么好说的，施工和验收环节都没做到位。而依赖的排水系统不给力，对于高架施工队来说这个锅好像是可以甩给排水系统团队的。

无需多言，这里我要类比的软件架构类别是“服务治理”。很明显高架路面系统依赖了排水系统，那我们就来说道说道限流、路由、熔断、降级这四块。

限流比较容易理解，我的排水管道就这么粗，你拿盆往里灌肯定喷出来，所以超出排水管道处理能力的水就不收了。那多的这些水怎么处理呢？不知道大家有没有听过“海绵城市”，通过一些特殊材料或特殊管道设计，将这些水先蓄在某些地方，以后随时可以拿来浇浇公园的花草啥的也算有效利用，架构里这就是常见的“削峰”，一般通过MQ队列来实现。当然还有更简单粗暴的就是水从哪里来回哪里去，我路边整几排烧红的铁棒，水一沾上就变为蒸汽蒸发掉了(好像发现了什么了不得的发明), 架构里对应的就是“快速失败”，既然系统已经处理不了你了，就直接给你个失败应答完事。

路由就是把水引流到不同的排水口(多个排水口可以理解成排水系统的分布式多节点)，污水和雨水是不同的排水通道，这个可以叫灰度或A/BTest；大雨会启动更多的排水口进行排水，或者易积水路段使用大的排水口，这个叫“弹性扩容”或者“权重路由”。

熔断就像家里的保险丝，当排水系统达到自己能力的上限，水再也进去不去的时候（响应超时或持续报错），排水口可以考虑自动关闭。等排水系统缓过劲来之后，可以打开排水口继续接受排水，这里需要不时的去探测排水系统是否恢复，决定何时再开启排水口。此处的熔断就是为了保护排水系统本身，不要因为大量的水灌入导致排水管道的破裂脱节之类的恶劣情况发生。

降级之前要先分级，在排水压力很大的情况下，可以让关键核心路段的积水先排掉别让交通完全瘫痪，其他边缘路段就自我牺牲一下先关闭主动排水口，也就是说在排水能力有限的情况下，把优先权让给关键核心，这种是资源抢占式的降级；假设平日的排水是在管道流动的过程中加入了过滤杂质的功能，以防大形体的垃圾进入排水系统堵塞住出水口，那在暴雨天气排水压力很大的情况下，是否可以考虑关停过滤功能，或者把过滤的标准放宽，这样排水的过程必然顺畅很多，这种是裁剪枝节、降低失败率、提高关键流程吞吐量的降级。

积水情况是否有监控

这个问题其实有一定的迷惑性，积水这种表象级别的监控绝对不是我们的目的，而是应该看更深一层，如何监控到路面的凹陷凸起。类比到软件系统，如果没有监控，我们对它们将一无所知。可悲的是，有相当比例的工程师对于系统上线后的感知，仍旧是通过是否有异常日志或者业务故障通知，才意识到自己系统的问题。实际上软件产品的交付物其中一个很重要的特性就是“可监控”，对于一个无法从内到外看个透彻的黑匣子，是相当恐怖的一件事情。

那么到底应该监控什么呢？除了对自身业务或技术指标的监控，对于依赖方的监控同样重要。不能只盯着自己高架路面的平整度，还要监控你依赖的排水系统处理能力，如果处理速度越来越慢，那就要考虑告警并介入了。

细节为王，眼界放宽

开篇我说过现在的架构师不好混，实际上作为一个经验老到的架构师，他的能力就深藏在一些细节和眼界上，而这些都不是吃快餐养成的“准”架构师们短时间内可以望其项背的。就像上面的问题“我只是高架路面设计师，如何想得到高架下的行车或行人？” 话说没吃过猪肉也见过猪跑，我就不信你没有在雨天有积水的马路上走过，或者亲身经历或者看到别人被积水坑害过。

回到软件架构上，有些细节可能让你空想你是想不出来的，但是你从初级工程师成长起来肯定踩到过某些坑，而这些坑都应该在你的架构设计里避免。一个标准的系统应用特性，很多人可以张嘴就来：可扩展性、高可靠、高可用、低延迟、BLABLABLA，又有多少人真正的对“可运维”“可监控”“可排障”“可持续交付”等在概要设计初期就有考虑呢?

课间不休息了，我再啰嗦两句

到这里，发现自己就半小时的车程感悟了这么多，也真的挺难为自己的。

总结性陈述：其实主要就扯了临界时间窗口、服务治理两个架构设计经常遇到的点，结合提前打转向灯 和 防止路面积水两个场景做了发散性的对比，其他一些只言片语的架构思想仅为个人心得，如有异议随时欢迎来怼。

就此搁笔，有缘再见。