首页|资源下载
登录|注册

您现在的位置是:首页 > 技术阅读 >  座谈交流:你写过最复杂的架构是啥(修订版)

座谈交流:你写过最复杂的架构是啥(修订版)

时间:2024-01-05

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条命令。

推荐阅读