推荐信息:
行业新闻
频道
您的位置:首页 > 行业新闻 > 社会热点 > 正文

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

2018/1/14 5:59:55 来源:传感器技术mp []

此处嵌入式特指基于linux平台,单片机和其他rtos不在讨论范围~

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

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

此时我想到底是什么问题呢,难道嵌入式出身的已经这么不受待见了吗?想当初,嵌入式,驱动开发,可是趋之若鹜的行业(有点夸张,不过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模块的接口实现一些功能(多线程的好处就是直接调用很方便,所以开发人员大多这么干,简单粗暴)。阅读haohaoyun.com但是需求总是千变万化,加入一个f模块,f模块也需要对a模块监测的状态进行一个处理,按照之前的套路,完成这个功能分两步:

  1. 在f模块提供接口。

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

前面提到需求总是千变万化的,新的需求又来了,客户提出定制需求,需要加入另一个g模块,同样处理a模块监测的状态,但是该定制需求不需要刚刚加入的f模块,此时最简单粗暴的方式是,定义一个宏,区分该定制需求和之前的通用需求,build两个程序版本。这样的做法看似简单,但后面如果定制需求逐渐增多,维护这么多定制版本程序就是个噩梦,代码管理和通用性也会是很大的问题,同时代码中充斥着对不同宏定义的差异化处理。

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

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

通用做法就是采用callback设置钩子,然后在callback中定制差异化的需求,对callback的处理做差异化的配置,对应到上面例子,就是在a模块添加一个钩子,然后在系统初始化时,根据设备版本号的不同,差异化定制callback处理函数,同时要将这些定制callback处理函数放在同一地方处理,否则仍然分散在各个角落里就没有意义(前一种方式不放置钩子是无法将这些差异化配置放在一起的),这样处理带来的另外一个好处是,我们对功能性需求的改变,不会影响到a模块的处理,也就是我们添加功能,不需要修改a模块的代码了(前一种方式要修改a模块的调用流程),这样也就实现了一个模块的分离。

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

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

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

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

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

由于多线程天然的优势,地址空间的相互可见,导致直接调用十分容易,很多经验尚浅的工程师,很容易就写出直接调用的简单粗暴的接口,如果遇到个static接口的函数,图方便也会把static去掉,直接拿过来用了。这样整个工程随着功能不断的添加,模块间的交叉越来越多,耦合越高。

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

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

抽象通用组件,分离通用功能和业务逻辑功能:当把一个多线程模型修改为多进程模型的过程中,经常会发现有些接口代码重复的出现在多个进程模块中,因为之前接口函数是在一个进程空间,大家都可以直接调用的,比如接口A被模块a,b调用,模块a,b分离为两个独立的进程后,接口A需要在a,b中分别实现了,无需解释,重复代码这个在软件工程中是大忌,必须消除。做法也很简单,将这些被多个模块调用的接口分离处理做成lib,供其他模块调用,当你完成这部分工作后,你发现了什么,是不是剥离的接口,可以作为整个项目的通用组件存在了,完美的情况下,lib下的代码是通用基础组件,各个模块中是独立的业务处理模块。

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

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

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

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

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

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

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

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

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

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

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

但是仅仅采用socket来实现前面例子的功能,同样会存在一些问题:还是前面的例子,首先说明前面我们优化后的第二种方案在多进程模型已经不能在继续使用了,原因比较简单,应该不需要解释。

简单的做法即基于方案一,把直接调用改为socket通信(定义好通信协议即可),但是熟悉socket开发的工程师都清楚,开始socket通信要先进行一些前期的工作(主要就是连接,将两个模块关联起来),所以前面的例子会变成这个样子,模块a要和模块b,c建立连接,如果加入f模块,模块a还要和f模块建立连接。这样情况在心里画一张连接图就会发现好像我们织了一张蜘蛛网,节点间的关系错综复杂,而且和方案一一样,我们添加一个和a关联的模块,就要修改模块a的代码,而且这种情况比多线程模型还有繁琐复杂的多了。这种做法绝对是个噩梦。

如何解决?我想很多人一定想到了采用总线分发的方式。了解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等机制,可以说大同小异,而难点在于协议的制定和性能处理的提升。

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

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

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

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

通过键盘前后键←→可实现翻页阅读

IT美食教育娱乐旅游母婴文化推荐

  • 厉害了,绿地进军人工智能!3亿战略入股深兰科技

    4月25日,绿地控股(600606.SH)宣布,与人工智能技术原创与应用开发龙头企业深兰科技(上海)有限公司(以下简称深兰科技)达成合作,绿地拟战略投资3亿元入股深兰科技,股权占比将超过13%,将成为公司第二大股东。同时,双方拟合资组建由绿地集团控股的“绿地深兰建筑科技有限公司”(以下简称绿地深兰建筑)和“绿地深兰机器人科技有限公司”(以下简称绿地深兰机器人),共同发展人工智能建筑和机器人智能科技。绿地科创产业的又一次升级,瞄准了“顶尖科技领域、顶尖科技公司”。深蓝科技到底有多牛?深兰科技成立于

  • 2018热水器行业高峰论坛召开 京东家电揭示千亿市场3大趋势

    4月26日,由中国家用电器协会与国家信息中心信息化和产业发展部指导、中国家电网主办的“2018中国热水器行业高峰论坛”在京举行。京东家电携手A.O.史密斯、卡萨帝、格兰仕、海尔、统帅、四季沐歌、美的、能率、林内、帅康、樱花、华帝、万和、万家乐等热水器领军品牌代表,一起梳理国内热水器行业现状,商议推动产品与市场结构升级。京东家电事业部厨卫采销部运营总监张京宣布,2018京东热水器节期间,参与0元安装服务的热水器将多达66款会议中,京东家电联合多家主流热水器品牌共同打造以“品质购”为主题的2018京

  • 黑鲨游戏手机绝配!小米游戏耳机发布,售价349元

    4月13日,小米投资的黑鲨游戏手机正式发布,而今日,小米商城上架了小米游戏耳机,这款产品内置7.1虚拟环绕立体声引擎,售价349元,已经在小米商城接受预约。小米游戏耳机采用人体工学设计,贴合头型,与头顶接触的部位舒适柔软,还采用全包式耳罩,官方称佩戴该机不压迫耳廓。另外小米游戏耳机支持LED炫彩游戏光效,用户可在电脑中自定义灯色和闪动模式,光随音动。据官方介绍,小米游戏耳机支持7.1虚拟环绕立体声引擎,可以营造立体环绕音效,支持声音定位,让用户在游戏中有身临其境的体验。该机内置40mm创新喇叭单

  • 沪嘉甬铁路实质性启动!正式列入国家铁路发展计划

    近日,“通苏嘉甬铁路”勘察设计开评标工作顺利开展,这意味着——纳入“通苏嘉甬铁路”整体项目的沪嘉甬铁路实质性启动,正式列入国家铁路发展计划。据最新获悉,项目前期研究已全面启动,前期工作取得重大进展。沪嘉甬铁路是国家高速铁路网“八纵八横”主骨架——沿海铁路客运通道的组成部分,亦是京沪二通道的南延工程。项目拟自嘉兴南站引出,跨越杭州湾后接入宁波枢纽,总投资300亿元以上。工程拟按客运专线标准建设,设计时速350公里,计划建设工期5年。值得一提的是,沪嘉甬铁路,将成为长三角城市群的重要联络通道。这一项

  • 数字中国30个最佳实践,多个由东方通提供基础软件支撑

    首届数字中国建设峰会备受瞩目,“年度最佳实践30强”推介也是数字中国建设峰会的重头戏。主办方向各部门和地方征集了154个最佳实践案例,成立数字中国建设年度最佳实践推介活动专家组,遴选出30个最佳实践。其中,多个重量级最佳实践均由东方通提供技术支撑和服务,再次证明了东方通基础软件在电子政务领域的强大实力和广泛应用。东方通,作为电子政务和数字中国领域软件基础设施的提供商,成立20多年来一直奋斗在电子政务和数字中国建设的第一线,其中间件产品、数据共享交换解决方案为各部委、全国各省市县区提供了安全、可靠

  • 让数据助力传统中小企业转型

    来自:数据观https://www.shujuguan.cn/?from=sohu传统营销找不到势能,钱花了却看不到效果?传统销售成本居高不下,销售额却跳崖式下滑?传统经营就像一潭死水,拖延、推诿,决策迟迟难以执行?这些都在倒逼传统中小企业不得不去思考如何做转型升级,如何通过“互联网+”、大数据这样的技术,来实现新的业务模式突破,以及形成新的盈利能力。本文将提供一个解决思路,帮助传统中小企业借助数据的力量实现转型升级。数据的价值正在被越来越多的传统企业重视,但是如何将数据真正作用于管理创新、业务

  • “信息孤岛”很顽固 中国机器人神秘拆解

    万家互联的信息社会,信息孤岛却依然存在,并且大多孤岛成为久攻不破的堡垒。这一现象自然是信息社会的一大障碍。不过,科学家们并没放过它们。链科技小编获悉,备受关注的“信息孤岛”协同难题被中国研制的全球首个区块链机器人解决。在近日于福州召开的首届数字中国建设峰会上,哈尔滨工程大学电子政务建模仿真国家工程实验室和价值链技术(深圳)有限公司联合研发的具有自主知识产权的全球首个区块链机器人正式亮相。信息孤岛的形成,原因比较复杂,其中既有各种技术因素,同时也掺杂大量人为因素。但不管什么原因,科技人员担负的任务

  • 上海万科发布“万科智造”产品主张,引领智能化美好生活场景

    上海万科发布2018年新一代产品主张“万科智造”,运用人工智能、移动互联网、新能源领域的高新科技手段构筑美好生活场景,旨在将人本、安全、健康、节能、共享、高效的六大核心特质赋能生活与工作。作为万科“以人民的美好生活为中心”和“城乡建设与生活服务商”的具象化表达,“万科智造”是上海万科基于当代奋斗者的痛点与需求提出的新一代产品主张。上海万科将利用自有的空间优势、场景优势,携手众多海内外科技领域的合作伙伴,将智能新技术场景化,打造满足未来需求的美好生活场景。在现场500余位宾客见证下,上海万科责任合

  • 我国动力电池行业进入快速洗牌期

    中国储能网讯:4月21日,中国化学与物理电源行业协会秘书长刘彦龙表示,我国动力电池行业进入了快速洗牌期,2015~2017年,动力电池配套企业已从150家降至100家左右,未来这一进程将会进一步加快。近年来,随着新能源汽车产业发展进入快车道,作为其核心零部件的动力电池行业也迎来了高速发展期。据中国汽车工业协会发布的最新数据显示,2017年,我国新能源汽车产销超预期完成目标,分别完成了79.4万辆和77.7万辆,同比分别增长53.8%、53.3%。据伊维经济研究院数据显示,电池成本下降与续航里程要

  • 美容祛痘生发平台支付宝小程序

    在现实生活中,美容美发行业有很多痛点等待解决,比如在发廊排队等待美发就是一件很枯燥的事情,而且对于理发师的选择、各种美发产品选择更是无从下手,所以美容美发店拓客渠道受限。随着互联网的不断发展,大部分美容生发商家都在以不同的形式加入互联网市场。尤其是小程序推出后,为专注线下服务的中小商家提供了更便捷的渠道。近日上线的“美容祛痘生发平台支付宝小程序”就是其中的一家。美容祛痘生发平台支付宝小程序是依托于支付宝这个支付工具而开发的线上商城,整合周边优秀的美容养生保健商家,提供美容美发、美甲服务、祛痘服务