嵌入式为什么没有软件架构师?

点击上方“小麦大叔”,选择“置顶/星标公众号”

福利干货,第一时间送达

我从事嵌入式软件开发有6、7个年头,bsp,驱动,应用软件,android hall,framework等都有涉猎。平时除了关注嵌入式行业的发展,也多少对Web,后台服务端,分布式等方向的技术有一些关注。

近期有萌生换个行业方向的想法,想做做后台服务器相关的开发,由于之前工作中并没有这方面的实际需求,只是自己平时关注,了解了些知识,比如:NIOepollngnixzeromqlibeventlibuv,高并发,分布式,redispythontornadodjango,涉猎比较杂,都了解个皮毛,不精。意外的是屡屡被互联网行业鄙视,面试机会都寥寥无几。

此时我想到底是什么问题呢,难道嵌入式出身的已经这么不受待见了吗?想当初,嵌入式,驱动开发,可是趋之若鹜的行业(有点夸张,不过8,9年前嵌入式可是听着比做java web的要牛逼些哦)

问题总是有原因的,我说下自己的理解:

为什么没有嵌入式软件架构师?

打开各种招聘网站,搜索架构师,会出现各种系统架构师,web架构师,后台服务端架构师等等,但是唯独很难看到嵌入式软件架构师。嵌入式软件不需要架构吗,驱动不需要架构吗?答案是当然需要,不过为什么没有这方面的职位?

我的看法:**目前国内的嵌入式开发主要分为嵌入式底层开发和嵌入式应用开发,嵌入式的底层开发一般叫做驱动开发,或者bsp开发,有时也有称之为linux内核开发,**名字听着都很高大上的感觉。

这么高大上的名字为什么没有架构师呢:linux kernel的架构师是linus等一众linux kernel开发维护者,因为本身linux kernel或者操作系统就是一个通用的平台,解决通用的问题,linux开源届的大牛都已经制定好了架构规则,留给可发挥的地方并不多,大部分工作只需要按照规则框架填充就可以了。

而且以目前国内大部分公司的业务需求,只是在做外围设备的集成,嵌入式平台的porting,搭建裁剪,业务需求完全不会超过kernel里提供的功能范围。
导致没有什么新的架构需要开发人员去设计,实现。

那嵌入式bsp开发人员都在做什么:除了调试多种多样的外设,替硬件擦屁股,就是解些稳定性的bug了(这里对具体工作不详细描述了,调试外设只会增加一些经验,增加广度,对提高深度贡献不大,只是按不会调试->会调试->调试的快这个路线发展,而解稳定性问题确实是需要一些积累经验)

而嵌入式上的应用开发,一般业务逻辑比较简单,被很多人忽略,所以招聘方也会感觉没有什么必要找架构师级别的了。

至此感觉嵌入式行业的确不需要架构师,被互联网行业的鄙视也没什么大惊小怪的。

但的确是这样子的吗?对于嵌入式底层的开发,有能力对kernel,驱动架构提出架构层优化的,国内的开发人员应该不多,所以对于大部分普通人,还是不要“妄想”做Linux kernel的架构师了(当然我相信国人中一定存在有这个能力的大牛),发现,解决一些bug,到更靠谱些。

我们真的不需要架构吗?

以自己的实际经历讲述下曾经对一个嵌入式设备应用软件的架构设计和优化:

我曾经接手过一个项目,项目采用单进程多线程的模型,项目中包括几个模块,以a, b, c, d,e代表。这个项目的业务逻辑决定这几个模块有不少关联。

例如:最初的设计中a模块是一个状态监测模块,它会基于监测到的状态调用b,c模块的接口实现一些功能(多线程的好处就是直接调用很方便,所以开发人员大多这么干,简单粗暴),但是需求总是千变万化,加入一个f模块,f模块也需要对a模块监测的状态进行一个处理,按照之前的套路,完成这个功能分两步:

1,在f模块提供个接口;

2,在a模块中调用该接口。至此新需求已经“完美”的解决了。

前面提到需求总是千变万化的,新的需求又来了,客户提出定制需求,需要加入另一个g模块,同样处理a模块监测的状态,但是该定制需求不需要刚刚加入的f模块,此时最简单粗暴的方式是,定义一个宏,区分该定制需求和之前的通用需求,build两个程序版本。

这样的做法看似简单,但后面如果定制需求逐渐增多,维护这么多定制版本程序就是个噩梦,代码管理和通用性也会是很大的问题,同时代码中充斥着对不同宏定义的差异化处理,

#ifdef xxx
do_something;
#endif

比较好的做法是加入设备型号版本的动态监测,用一个build程序版本动态支持所有的定制需求,这样减少了对不同build程序的维护。

但是这种做法只解决build程序的版本维护工作,没有解决宏定义差异化处理的问题,只是会将之前的宏判断,改为动态设备版本号判断,如果这些差异化的判断只集中在一处进行,也不会引起大的复杂化的问题,但显然这个是不好保证,有可能这些差异化的处理会蔓延到整个项目的各个角落,这样项目维护起来就会变成一场噩梦。

ef7404c015a3f86e77a86e445153c321.png
图片

不需要什么高深的软件思想,大部人都会想到把差异化的部分提取出来,放在一个统一的地方集中管理,对差异化的修改只集中在这个统一管理的地方。

通用做法就是采用callback设置钩子,然后在callback中定制差异化的需求,对callback的处理做差异化的配置

对应到上面例子,就是在a模块添加一个钩子,然后在系统初始化时,根据设备版本号的不同,差异化定制callback处理函数,同时要将这些定制callback处理函数放在同一地方处理,否则仍然分散在各个角落里就没有意义(前一种方式不放置钩子是无法将这些差异化配置放在一起的)。

这样处理带来的另外一个好处是,我们对功能性需求的改变,不会影响到a模块的处理,也就是我们添加功能,不需要修改a模块的代码了(前一种方式要修改a模块的调用流程),这样也就实现了一个模块的分离。

至此第二种的方案的架构(其实也谈不上架构了)相比第一种方案已经有了不少提升,至少让开发人员稍微轻松了些,对于其他定制需求,开发人员之需要修改这个callback处理,关注差异化部分就可以了。

软件是需要不断进化的,第二种方案是最优解吗,当然不是,还有优化空间吗?

下面先跑个题,谈谈多线程/多进程模型的优缺点,主要谈多进程的优点了:

教科书上的解释就不提了,首先我对大的项目是推崇多进程模型,无关性能,主要原因有:

模块的解耦

很多开发人员维护开发的多线程模型项目应该都多少会存在下面的问题:跨模块间的直接调用,如果不相信,好,你的项目一定是分模块的吧,现在随机的删掉一个模块,build下看能build通过吗(只需要build不需要运行),我相信大部分情况下一定会遇到某个函数调用,某个全局变量找不到的情况,这种情况说明你的模块间存在强耦合了。

由于多线程天然的优势,地址空间的相互可见,导致直接调用十分容易,很多经验尚浅的工程师,很容易就写出直接调用的简单粗暴的接口,如果遇到个static接口的函数,图方便也会把static去掉,直接拿过来用了。

这样整个工程随着功能不断的添加,模块间的交叉越来越多,耦合越高。

而我之所以推崇多进程的原因就是,多进程能从物理上隔绝了这种“方便”的通讯方式,导致在想实现一个模块交互时,会多思考下这个交互是必要的吗,如果是必要的,则会进一步思考接口定义是否简单明了(因为进程间的通讯相对会麻烦些,开发人员会本着能减少交互,明确接口的想法去仔细考虑接口,协议的定义,否则折腾的是自己了),这如同人生,如果一直顺风顺水,人们可能不会想太多,思考太多,而如果道路上有些坎坷,则会有另一种感悟吧。

所以我的想法是多进程的模型会逼迫你去更多的思考想程序的设计,物理上减少模块的耦合。

抽象通用组件,分离通用功能和业务逻辑功能:当把一个多线程模型修改为多进程模型的过程中,经常会发现有些接口代码重复的出现在多个进程模块中,因为之前接口函数是在一个进程空间,大家都可以直接调用的,比如接口A被模块a;

b调用,模块a,b分离为两个独立的进程后,接口A需要在a,b中分别实现了,无需解释,重复代码这个在软件工程中是大忌,必须消除。

做法也很简单,将这些被多个模块调用的接口分离处理做成lib,供其他模块调用,当你完成这部分工作后,你发现了什么,是不是剥离的接口,可以作为整个项目的通用组件存在了,完美的情况下,lib下的代码是通用基础组件,各个模块中是独立的业务处理模块。

方便定位问题

多线程模型中当又一个线程异常退出,会导致整个进程退出,当然通过一些crash信息,可以定位是那个线程死掉,但如果这些线程模块是由多个小组,人员维护,当整个进程崩溃掉后,如何判断由那个小组解决,会是一个大的问题,而且有时还会出现的现象是挂在一个线程,但其实是另外一个线程模块引起的(耦合的祸端),遇到这种情况,难免出现小组间的扯皮,推诿。(自信的工程师都认为我的代码没有问题)

而如果采用多进程的模型,好吧,你的服务进程挂了,你自己找原因吧,没什么可争辩的了。

方便性能测试

多线程种单个线程的资源占用不是很好查看(至少有些嵌入式系统没有完善的命令),当整个进程资源消耗很高时,如何判断定位时那个模块线程的问题,同3一样难以抉择,而如果是多进程的模型,谁的进程占了好多资源,谁就去查下吧,其实这个还是个颗粒度的问题,同样的系统,划分成多个进程,单个进程的复杂度一定比只有一个进程的复杂度低的多,复杂度降低,也就更容易定位查找各种问题。

分布式部署

互联网行业一直强调的分布式,云啊什么的,嵌入式行业就很苦逼了,貌似不需要什么分布式吧,其实也对,大部分情况下,嵌入式采用单芯片,独立运行,分布式遇到的很少。但如果万一那天你在一个设备中,将本来一个芯片完成的功能分散到两个芯片中处理呢,多进程的扩展就容易的多了。

这只是举个特殊的例子,其实嵌入式设备就是个分布式的行业,只是一开始就已经实现分离了,而不是从集中到分布式的路线发展起来的。

方便公司的代码权限隔离:其实我鄙视这种做法,公司要相信自己的员工,但鉴于诚信在中国已经。。。。,做些隔离也无可厚非了。

多线程模型下,前面讲到如果去除一个模块,你可能都不能build了,那么是要把所有代码暴露给所有的工程师吗,显然不能,所以各个模块只能提供库的形式了,不过我觉得将通用功能接口组织成通用库是正常的做法,而如果把和业务相关的模块也提供成库,就有点。。。。

至此在补充一下,以上所有的优点,其实都不是很关键的点,都不能够让多进程有绝对的优势压倒多线程模型,只是从个人的角度觉得,多进程模型更能强迫工程师思考解决一些问题。(而这些问题有经验的工程师无论什么模型都会思考的)

上面说了这么多,该考虑下把之前项目的例子改成多进程模型,否则就只是纸上谈兵了,下面开始:

首当其冲的问题就是:选择多进程的通讯方式,多线程间的直接调用是不能用了,那么如何选择多进程的通讯方式呢?

linux下提供很多ipc方式,此处不一一列举,对于非大数据量的控制,通讯消息的传递,比较好的方式是采用socket,本机上更多采用unix socket方式,(这种方式有什么好处?当你有需要把单一系统做成分布式系统时,优势就明显了)

但是仅仅采用socket来实现前面例子的功能,同样会存在一些问题:

还是前面的例子,首先说明前面我们优化后的第二种方案在多进程模型已经不能在继续使用了,原因比较简单,应该不需要解释……

简单的做法即基于方案一,把直接调用改为socket通信(定义好通信协议即可),但是熟悉socket开发的工程师都清楚,开始socket通信要先进行一些前期的工作(主要就是连接,将两个模块关联起来),所以前面的例子会变成这个样子,模块a要和模块b,c建立连接,如果加入f模块,模块a还要和f模块建立连接。

这样情况在心里画一张连接图就会发现好像我们织了一张蜘蛛网,节点间的关系错综复杂,而且和方案一一样,我们添加一个和a关联的模块,就要修改模块a的代码,而且这种情况比多线程模型还有繁琐复杂的多了。这种做法绝对是个噩梦。

5bc3fde624f2f751ba830f7ae14051a6.png

好吧如何解决,我想很多人一定想到了采用总线分发的方式。了解android系统开发的会想到binder,了解openwrt的会想到ubus,了解桌面会想到dbus,互联网行业的开发者一定也知道redis里提供的sub/pub模块。

上面的binder,ubus等原理很简单,就是建立一个消息中心,构建一个转发路由模型,所有其他模块之间不直接交互,而是采用消息中心转发,路由,而如何决定路由规则,则采用订阅/发布的观察者模式来进行规则的定义。

嵌入式开发或者c语言开发者,经常会误以为设计模式是和面向对象语言关联的,是面向对象语言独有,虽然有很多大牛做了这方面的普及,但鉴于有些开发者的信息渠道比较闭塞,导致这种想法仍然十分盛行

基于这个模型,我们上面例子的需求就很好解决了,加入一个消息中心模块,所有需要通信的模块只同该消息中心模块连接,然后订阅自己感兴趣的事件,当事件发生时,只需要进行相应的处理就可以了。

这样上面的模块b,c订阅模块a的事件,当模块a检测到某事件时,发布该事件,该事件先到达消息中心,在由消息中心转发给模块b,c,而对于新加入的模块f,也只需要订阅该模块,而不需要在修改到模块a的代码,使功能的扩展十分方便。

同时对于前面提到的定制化开发同样得到了简化,如果定制化版本需要加入模块g,这样只需要定制化版本中将模块g作为一个独立进程启动,然后订阅模块a的事件即可,而定制版本和通用版的区别就在于是否启动模块g的进程,从而实现了软件工程的一个目标:功能的添加如同搭积木一样,只需要把一个模块插入(启动)或拔出(不启动)即可,功能的改变只局限在一个或某几个模块间,对主体框架不会有任何影响。

以上大概描述了对一个项目需求逐步优化的过程,例子看似是基于嵌入式项目,但貌似对软件工程同样适用。

来到互联网行业

查看下各大网站架构师对本网站技术架构变革分享的文章,首先提到的一般都是,基于业务将之前的一个应用服务器功能拆分,更加细化(比如电商对登录,注册,交易,商品,卖家等业务服务的拆分),然后将拆分出来的服务部署在多台服务器上,来提供并发。

这里是否有些耳熟,和前面讲到的多线程到多进程的划分是否有相似呢。

拆分后同样遇到通信的问题,此时很多消息中间件应运而生,比如阿里的duboo,简单了解下这些中间件的原理,无外乎订阅发布,RPC等机制,可以说大同小异,而难点在于协议的制定和性能处理的提升。

在对照下互联网行业的负载均衡方案,仿佛那个负载均衡的前端也像一个消息中心了。

上面说了这么多,只是想说明一个问题,软件的设计是相通的,基于的思想是相同的,虽然嵌入式行业的业务逻辑相对比较简单,但其实在仔细思考后,仍然会有很多架构上的改进,设计。

但是让我感到悲哀的是,有些嵌入式开发者,鉴于业务逻辑的简单,感觉采用一些不那么好的处理方式也能解决问题,不去思考如何去优化,改进。**比如上面例子的方案一,如果在定制需求不多的情况下,维护起来也没太大问题,即使定制需求多了,再招些初级程序员也能维护的过来,一个人一套代码负责一个项目的公司也不是不存在。

同样互联网行业和嵌入式行业也不应该存在一个不可以逾越的高墙,我们更应该关注的是通用的软件工程思想。

声明:本文素材来源网络,版权归原作者所有。如涉及作品版权问题,请与我联系删除。

—— The End ——

推荐好文  点击图片即可跳转

d1cd0e20c3367c54a30728f1d195ad69.png

嵌入式入门必看,看看老鸟如何华丽蜕变!(干货分享帖)


8669ddb49673091aa004ecd5bc72dd43.png

C语言如何使用断言避免踩坑


2ea0f54e41b51efce80848e183345046.png

6步!教你写一个mqtt调试助手


75b8fa20edc8d18983294e7ee57b468f.png

提高单片机设计的秘诀,不容忽视的10个细节


分享 💬  点赞 👍  在看 ❤️ 

以“三连”行动支持优质内容!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/61069.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

总结一下进程是什么

1、我们常说的进程是什么? 进程(Process)是计算机中的程序关于某数据集合上的运行活动,是系统进行资源分配和调度的基本单位,是操作系统结构的基础。 进程是程序的基本执的实体 2、进程状态 就绪状态 进程已获得除处…

Vue 方法中this指向 引起的祸端

可忽略 最近在写 vue 项目, 使用 总监封装 好的框架,遇到一个问题: vue 实例 methods 中的 方法在传递后,通过 函数名() 方式调用后, 其内部 this 竟然没有指向 window。当时就不服了&#xff…

PHP语言25周年,PHP是世界上最好的语言

1995年6月8日,PHP 1.0版本正式问世,目前已经更迭到7.4版本,PHP 8.0 Alpha1版本也有望于今年6月中旬发布。25周年之际,杜蕾斯官方微博发文庆祝:“#PHP语言25周年#不管PHP是不是世界上最好的语言,反正—— pr…

“5G 太耗电,关掉它!”

作者 | Carol 出品 | CSDN(ID:CSDNnews) 随着5G的普及,如今已经有很多手机用户已经体验到了5G的便捷了。无论国内外,从各大运营商及手机厂商向5G的投入中可见,5G的普及只不过是时间问题罢了。 但就在大家都…

Android App 耗电量统计

前言 在Android统计App耗电量比较麻烦,直至Android 4.4,它仍没公开“电量统计”API或文档……额,是的,仅没有公开,并不是没有。平时在手机“设置- 电量”看到的数据 就是系统调用内部API的统计结果。 基础概念 1. 手机…

泰安柒柒:一篇文章带你了解爆火的ChatGPT

OpenAI发布聊天机器人模型ChatGPT,迅速出圈全网。它以对话方式进行交互。以更贴近人的对话方式与使用者互动,可以回答问题、承认错误、挑战不正确的前提、拒绝不适当的请求。 那么,ChatGPT为什么会爆火呢? 1 ChatGPT是什么&#…

ControlNet-有条件图文生成论文阅读

文章目录 摘要算法:ControlNetControlNet in Image Diffusion ModelTrainingImproved Training 实验Canny edgesHough linesHuman scribblesHED boundary mapOpenpifpaf poseOpenposeADE20K segmentation mapCOCO-Stuff segmentation mapDIODE normal mapDepth-to-I…

如何解决“德语/文”等外文字符显示乱码问题

目录 1“德文/语字符”等外文显示乱码原因 2 如何解决“德文/语字符”等外文显示乱码 2.1 使用支持多个“编码”切换的工具打开该文本 2.2 使用变音字符的标准ASCII字符 2.3 将计算机系统切换至西欧编码 3 结尾 1“德文/语字符”等外文显示乱码原因 以德文/语为例&#…

Domino NotesV11开放下载啦!

大家好,才是真的好。此刻我正在北京的Domino NotesV11培训现场写Domino Notes V11,人数众多,群情激扬。上周五,Domino Notes V11已经开放下载,不知道朋友们下到了没有?要是下到了,告诉大家一个好…

Window内置ubuntu安装与图形界面显示

文章目录 一、Window安装ubuntu1.打开控制面板2.WSL升级1)启用适用于 Linux 的 Windows 子系统2)检查运行 WSL 2 的要求3) 启用虚拟机功能4) 下载 Linux 内核更新包5)将 WSL 2 设置为默认版本 3.安装ubuntu 二、图形界…

计算机需不需要考英语口语,哪些专业需要英语口语考试

哪些专业需要英语口语考试?下面小编为大家整理了相关内容,以供参考,一起来看看吧! 哪些专业需要英语口语考试 需要英语口语的都是英语专业或外贸,外交类专业。按照各院校要求,报考外语类专业或报考涉外专业…

【评测】SUPRAcap 100囊式深层过滤器 泽平科技一级代理

以最通用的囊式过滤器形式提供Seitz过滤介质的优良特性 对于安全可靠的工艺开发来说,可规模放大性是至关重要的,SUPRAcap 100以其通 用的结构、尺寸和可与其他滤器共同使用的特性,使其可以应用于任何开发工艺中。 借助于新的SUPRAcap100产品…

Database Meets AI: A Survey

文章目录 Abstract1 INTRODUCTION1.1 AI for DBLearning-based Database ConfigurationLearning-based Database OptimizationLearning-based Database DesignLearning-based Database MonitoringLearning-based Database Security 1.2 DB for AIDeclarative Query ParadigmDat…

突然加快,专家建议五年内禁售燃油车,新能源车迎来物联网智能科技革命

日前,著名经济学家任泽平在社交媒体发文,建议推出五年内燃油车禁售时间表,河北以南,大力发展新能源,双碳,扩大内需。新能源车辆和物联网技术结合使用将是推进该新能源车发展的重要趋势,也是实现…

MP支原体污染解决方案 | MP代理泽平科技

细胞培养过程中,经常会遇到细胞各种各样的污染。其中支原体污染是最顽固的、隐蔽的,污染率也高。这主要因为支原体是广泛存在于自然界中能独立生活的最小微生物, 直径300~800 nm, 很容易透过0.22~0.45 μm滤膜。支原体没有细胞壁,常用抗生素如…

IDT代理——北京泽平科技CRISPR基因编辑

IDT 成立于 1989年,是基因组学领域开发的领先者,也是公认的定制核酸生产行业的领导者。IDT 凭借在 DNA 合成领域的领导能力,为基因组学应用开发了专有技术,例如下一代测序、CRISPR 基因组编辑、合成生物学、数字 PCR 和 RNA 干扰。…

【评测】CellMaxx胎牛血 泽平科技代理

清原产地新西兰,自然条件优越,是世界公认的优质血源地之一;并且新西兰有着最高的动物健康标准,是欧盟指导委员会认定的极少数疯牛病非疫区。 CellMaxx胎牛血清生产采用完全认证的无菌过滤设备,严格执行GMP生产标准&…

官宣 慧存医疗与泽平科技战略合作1

近日,上海赛立维生物旗下慧存医疗科技有限公司与北京泽平科技有限责任公司达成战略合作,泽平科技成为慧存医疗全部医疗产品的全国总经销商,包含细胞冻存液、组织冻存复苏试剂盒、组织解离液、组织运输保存液、脐带组织和脐带血冻存液、肝脏细…

【智能制造】周宏仁:通俗易懂讲清楚制造业“数字化起步,网络化崛起,智能化发展”;任泽平:解码“德国制造”的七大基因

国家信息化专家咨询委员会常务副主任周宏仁撰文指出智能制造发展经历数字化起步,网络化崛起,智能化发展三个阶段。高瞻远瞩,通俗易懂,富有逻辑性,非常精彩,此文值得读三遍! 国家信息化专家咨询委…

任泽平:“云智一体”新基建将深刻影响我国实体经济

“新基建正在挑大梁!”著名经济学家任泽平在2023跨年演讲中表示。 本次演讲中,任泽平提出了2023年中国经济的十大预测。其中,“新基建”作为支撑未来20年中国经济繁荣发展的重要工程,将迎来新的发展机遇。 任泽平表示,…