嵌入式为什么没有嵌入式软件架构师？(1)，2024年最新Golangstudio基础

那么对于嵌入式应用层的开发，我们真的不需要架构吗?

以自己的实际经历讲述下曾经对一个嵌入式设备应用软件的架构设计和优化：我曾经接手过一个项目，项目采用单进程多线程的模型，项目中包括几个模块，以a, b, c, d,e代表。这个项目的业务逻辑决定这几个模块有不少关联。

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

在f模块提供接口。

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

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

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

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

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

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

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

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

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

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

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

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

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

抽象通用组件，分离通用功能和业务逻辑功能：当把一个多线程模型修改为多进程模型的过程中，经常会发现有些接口代码重复的出现在多个进程模块中，因为之前接口函数是在一个进程空间，大家都可以直接调用的，比如接口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的进程，从而实现了软件工程的一个目标：功能的添加如同搭积木一样，只需要把一个模块插入(启动)或拔出(不启动)即可，功能的改变只局限在一个或某几个模块间，对主体框架不会有任何影响。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

PEtRJG-1713027963456)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！