2022-09-26

伍总监：“目前为止你写过最复杂的架构是什么？我们车企需要自己研发中间件，对架构方面要求颇高。”

他重点是“我写过”什么架构，而不是“我用过”什么架构。

我……省略一万字说了个不痛不痒的应用层架构。很多年不怎么写应用程序了，最多写些测试用例，近年一直干着预研的工作，很少涉及具体应用。

2个我写的架构

其实2015-2018年干应用层的时候，倒是写过几个架构，其中有2个架构不是孤芳自赏，它们还得到同事的认可，在其他项目上也得到应用。

MiniShellEx：诞生于2014年中旬，应用程序命令行接口，提供命令补全、提示功能，最有价值的是可以依靠它去编写单元测试， 节省单元测试代码量。其实还有一个精简版MiniShell Tiny，用于stm32单片机后台调试，MiniShell Tiny它不依赖Linux库libreadline。

EpollServerX：诞生于2015年初，看名字都知到他是基于epoll的以太网服务器库，它与MiniShellEx结合起来，可以搭建远程单元测试框架， 既可以做服务器，也可以做客户端。若当时我知道libevent的存在，或许我不会重复造轮子。

它们的链接如下（你可能需要梯子）：

• https://github.com/MenglongWu/EpollServerX

• https://gitee.com/MenglongWu/MiniShellEx

最复杂架构

我所认为的架构，应该是尽可能使用现存架构，除非确认已存在的架构存在瓶颈，才少量尝试创新、突破。

2015年干过一个最复杂的架构，我毫掩饰地评价它是最恶心架构，说他恶心的根本原因是我本可以编写少量、甚至不编写代码，也就是上文说所的尽可能使用现存架构， 不仅同时用上EpollServerX和MiniShellEx，还写了一个本不应该写的软路由，最后该工程框架成了公司祖传代码，后面2个同事拿着它做二次开发。

我们的工程是这样的，一个19寸机箱里有13快业务板和1块软路由板。像这样的机箱有百来个，他们都与服务器发生数据交互。

行业里的做法应该是软路由上搭建NAPT，服务器向软路由发起连接，根据端口区分业务板。例如：

• 软路由IP：192.168.1.5

• 业务板服务器和端口：192.168.0.1:1000

• 业务板服务器和端口：192.168.0.2:1000

• 当服务器要像业务板1通信，则连接192.168.1.5:10001；

• 当服务器要像业务板2通信，则连接192.168.1.5:10002；

• 软路由做的工作叫做端口映射NAPT；

而我们产品经理偏不按常理出牌，要要在软路由上开放端口2000，软路由连接机框内各业务板，服务器只连接软路由，开发服务器的工程师说担心服务器处理不过来，毕竟几百个机框累计起来，服务器得维护数前个连接呢，只连接软路仅几百个连接。

我纳闷：“数千个连接不多呀，你不是用Windows下的完成端口模式吗，应该没什么压力，而且我们的业务板也不是事实都有数据流量。”

Windows的完成端口设计目的与Linux的epoll一样，都是应对多连接场景。

老工程师：“以前都是如此干的，要动架构不太好改。”

好吧，拧不过老干部。于是我开始实现又长又臭的业务。

如此设计

第1秀：私有命令码

EpollServerX监听两个端口，端口2000是项目业务所需要的，协议按照项目的来。业务命令码有近100条，我特意向产品经理申请一条私有命令码。留下一条后门，专门用于传送字符串，字符串的内容提供给MiniShellEx解析，使我有更多的方式去调试。

开发阶段，软路由就在我的桌面，我完全可以ssh、telnet远程登录操作板卡。当真正上业务后，运营商会封死任何与业务无关的端口，真要出问题我就抓瞎了。拥有私有命令码后，依靠现有端口完全可以秀各种操作，包括shell反弹、连接重定向。

第2秀：自连接

EpollServerX目的是充当服务器，其二也可以充当客户端。但你有想过服务器自己连接自己吗？

开放2000端口，然后自己连接自己，为什么有奇葩需求？——为了编写测试用例，实现除了软路由之外的业务。

某飞机操作系统，或者说飞机上的应用程序，下载后文件有百万行，实际使用的代码只有几万航而已，其他的都是他的测试用例。通常我们会把测试用例与业务代码分离出来，不过飞机项目可是把测试用例与业务一同编译、打包、发布。

当初设计时我没打算向飞机项目看齐，仅仅是当时年轻，提出反对意见没人听，倘若老干部的代码有BUG我要是没有足够证据去证明，老干部是不承认的。

于是未雨绸缪，把他们的业务都实现了（传递的是假数据），集成测试能够自己先测试。

第3秀：数据流

正式业务数据流很简单，业务数据从以太网来，指定业务端口，数据流直上到应用层，最后从原路返回。

测试阶段我可以用命令行，在本地ttyX终端执行任何测试用例子：

如果测试用例属于本地查询业务，则执1、2流程；如果测试用例属于主动向其他板卡发送指令，则执3、4流程；

当业务开通后，运营商只开通业务端口2000，真个数据流和第二张图几乎一抹一样，差别在于一个命令来源于ttyX、另一个来源于私有命令码。

当同事还没开发完成业务板、服务器，我则使用ttyX对自己的软路由做自连接测试，ttyX启动测试用例，模拟其他网络节点向软路由发送数据。

好了，框图还是比较好画的，至于具体实现要牵扯到数据结构，太多，以后有空再写，其实本项目可以用无锁编程，调试起来会麻烦一点，当年还是用上了少量的锁。

开发

记得我和同事A讨论：“测试50号命令，代码在8千xx行。”

旁边的另一个同事B听着：“你不是做软路由吗，几行代码不就写完了，怎么搞出8千行。给你年轻人减轻压力，看来也做不出什么东西。”

同事A是知道我实现3份代码的，没多争辩：“他实现的内容会比你实现的东西稳定得多。”继续和我调试。

项目第一阶段我是开发最久的，其他两人大概2.5月完成，我花了3个月。核心业务其实不超过6千行，为了6千行的稳定写了8千行去实现其他业务的代码，以及几千行测试用例。测试用例子与实际业务工作量差不多是4：1。

在测试阶段，我借助着MiniShellEx只花费1天时间测试万80多条命令。反观几天后甲方来与我们联调，3天时间测试不足20条命令。

收货

项目第一阶段交付，交付后甲方提出下一阶段的要求，列出若干新增业务，业务板、软路由板、服务器3块业务开发的同事都分配到了任务。

粗略计算大概要1个多月才能提交第二阶段，我呢在一周后叫到：“完工，什么时候可以和你们集成测试？”

之前嘲讽我为什么写8千多行代码的同事：“灌鸭子啊！这么快！”

我挺得意：“不仅仅功能实现，测试用例也跑了一遍，现在就等你们完工给我真实数据。”微笑脸。

工作量守恒定律。前面看似吃点亏把其它不归我的业务也实现了，正是我在第一阶段实现了3块业务，它也创造一个测试环境，我可以不依赖其他同事任务进度，独自完成软路由的功能测试。其二，我的架构能同时兼容3种业务的实现，也证明架构有一定的弹性。