我從事嵌入式軟件開發(fā)有6、7個年頭，bsp，驅(qū)動，應(yīng)用軟件，android hall，framework等都有涉獵。平時除了關(guān)注嵌入式行業(yè)的發(fā)展，也多少對Web，后臺服務(wù)端，分布式等方向的技術(shù)有一些關(guān)注。

近期有萌生換個行業(yè)方向的想法，想做做后臺服務(wù)器相關(guān)的開發(fā)，由于之前工作中并沒有這方面的實際需求，只是自己平時關(guān)注，了解了些知識，比如：NIO，epoll，ngnix，zeromq，libevent，libuv，高并發(fā)，分布式，redis，python，tornado，django，涉獵比較雜，都了解個皮毛，不精。意外的是屢屢被互聯(lián)網(wǎng)行業(yè)鄙視，面試機(jī)會都寥寥無幾。

此時我想到底是什么問題呢，難道嵌入式出身的已經(jīng)這么不受待見了嗎？想當(dāng)初，嵌入式，驅(qū)動開發(fā)，可是趨之若鶩的行業(yè)（有點夸張，不過8，9年前嵌入式可是聽著比做java web的要牛逼些哦）。

問題總是有原因的，我說下自己的理解：

為什么沒有嵌入式軟件架構(gòu)師？

打開各種招聘網(wǎng)站，搜索架構(gòu)師，會出現(xiàn)各種系統(tǒng)架構(gòu)師，web架構(gòu)師，后臺服務(wù)端架構(gòu)師等等，但是唯獨很難看到嵌入式軟件架構(gòu)師。嵌入式軟件不需要架構(gòu)嗎，驅(qū)動不需要架構(gòu)嗎？答案是當(dāng)然需要，不過為什么沒有這方面的職位？

我的看法：目前國內(nèi)的嵌入式開發(fā)主要分為嵌入式底層開發(fā)和嵌入式應(yīng)用開發(fā)，嵌入式的底層開發(fā)一般叫做驅(qū)動開發(fā)，或者bsp開發(fā)，有時也有稱之為linux內(nèi)核開發(fā)，名字聽著都很高大上的感覺。

這么高大上的名字為什么沒有架構(gòu)師呢：linux kernel的架構(gòu)師是linus等一眾linux kernel開發(fā)維護(hù)者，因為本身linux kernel或者操作系統(tǒng)就是一個通用的平臺，解決通用的問題，linux開源屆的大牛都已經(jīng)制定好了架構(gòu)規(guī)則，留給可發(fā)揮的地方并不多，大部分工作只需要按照規(guī)則框架填充就可以了。

而且以目前國內(nèi)大部分公司的業(yè)務(wù)需求，只是在做外圍設(shè)備的集成，嵌入式平臺的porting，搭建裁剪，業(yè)務(wù)需求完全不會超過kernel里提供的功能范圍。
導(dǎo)致沒有什么新的架構(gòu)需要開發(fā)人員去設(shè)計，實現(xiàn)。

那嵌入式bsp開發(fā)人員都在做什么：除了調(diào)試多種多樣的外設(shè)，替硬件擦屁股，就是解些穩(wěn)定性的bug了（這里對具體工作不詳細(xì)描述了，調(diào)試外設(shè)只會增加一些經(jīng)驗，增加廣度，對提高深度貢獻(xiàn)不大，只是按不會調(diào)試->會調(diào)試->調(diào)試的快這個路線發(fā)展，而解穩(wěn)定性問題確實是需要一些積累經(jīng)驗）。

而嵌入式上的應(yīng)用開發(fā)，一般業(yè)務(wù)邏輯比較簡單，被很多人忽略，所以招聘方也會感覺沒有什么必要找架構(gòu)師級別的了。

至此感覺嵌入式行業(yè)的確不需要架構(gòu)師，被互聯(lián)網(wǎng)行業(yè)的鄙視也沒什么大驚小怪的。

但的確是這樣子的嗎？對于嵌入式底層的開發(fā)，有能力對kernel，驅(qū)動架構(gòu)提出架構(gòu)層優(yōu)化的，國內(nèi)的開發(fā)人員應(yīng)該不多，所以對于大部分普通人，還是不要“妄想”做Linux kernel的架構(gòu)師了（當(dāng)然我相信國人中一定存在有這個能力的大牛），發(fā)現(xiàn)，解決一些bug，到更靠譜些。

我們真的不需要架構(gòu)嗎？

以自己的實際經(jīng)歷講述下曾經(jīng)對一個嵌入式設(shè)備應(yīng)用軟件的架構(gòu)設(shè)計和優(yōu)化：

我曾經(jīng)接手過一個項目，項目采用單進(jìn)程多線程的模型，項目中包括幾個模塊，以abcde代表。這個項目的業(yè)務(wù)邏輯決定這幾個模塊有不少關(guān)聯(lián)。

例如：最初的設(shè)計中a模塊是一個狀態(tài)監(jiān)測模塊，它會基于監(jiān)測到的狀態(tài)調(diào)用b，c模塊的接口實現(xiàn)一些功能（多線程的好處就是直接調(diào)用很方便，所以開發(fā)人員大多這么干，簡單粗暴），但是需求總是千變?nèi)f化，加入一個f模塊，f模塊也需要對a模塊監(jiān)測的狀態(tài)進(jìn)行一個處理，按照之前的套路，完成這個功能分兩步：

1、在f模塊提供個接口；

2、在a模塊中調(diào)用該接口。至此，新需求已經(jīng)“完美”的解決了。

前面提到需求總是千變?nèi)f化的，新的需求又來了，客戶提出定制需求，需要加入另一個g模塊，同樣處理a模塊監(jiān)測的狀態(tài)，但是該定制需求不需要剛剛加入的f模塊，此時最簡單粗暴的方式是，定義一個宏，區(qū)分該定制需求和之前的通用需求，build兩個程序版本。

這樣的做法看似簡單，但后面如果定制需求逐漸增多，維護(hù)這么多定制版本程序就是個噩夢，代碼管理和通用性也會是很大的問題，同時代碼中充斥著對不同宏定義的差異化處理，

#ifdef?xxx
do_something;
#endif

比較好的做法是加入設(shè)備型號版本的動態(tài)監(jiān)測，用一個build程序版本動態(tài)支持所有的定制需求，這樣減少了對不同build程序的維護(hù)。

但是這種做法只解決build程序的版本維護(hù)工作，沒有解決宏定義差異化處理的問題，只是會將之前的宏判斷，改為動態(tài)設(shè)備版本號判斷，如果這些差異化的判斷只集中在一處進(jìn)行，也不會引起大的復(fù)雜化的問題，但顯然這個是不好保證，有可能這些差異化的處理會蔓延到整個項目的各個角落，這樣項目維護(hù)起來就會變成一場噩夢。

不需要什么高深的軟件思想，大部人都會想到把差異化的部分提取出來，放在一個統(tǒng)一的地方集中管理，對差異化的修改只集中在這個統(tǒng)一管理的地方。

通用做法就是采用callback設(shè)置鉤子，然后在callback中定制差異化的需求，對callback的處理做差異化的配置。

對應(yīng)到上面例子，就是在a模塊添加一個鉤子，然后在系統(tǒng)初始化時，根據(jù)設(shè)備版本號的不同，差異化定制callback處理函數(shù)，同時要將這些定制callback處理函數(shù)放在同一地方處理，否則仍然分散在各個角落里就沒有意義（前一種方式不放置鉤子是無法將這些差異化配置放在一起的）。

這樣處理帶來的另外一個好處是，我們對功能性需求的改變，不會影響到a模塊的處理，也就是我們添加功能，不需要修改a模塊的代碼了（前一種方式要修改a模塊的調(diào)用流程），這樣也就實現(xiàn)了一個模塊的分離。

至此第二種的方案的架構(gòu)（其實也談不上架構(gòu)了）相比第一種方案已經(jīng)有了不少提升，至少讓開發(fā)人員稍微輕松了些，對于其他定制需求，開發(fā)人員之需要修改這個callback處理，關(guān)注差異化部分就可以了。

軟件是需要不斷進(jìn)化的，第二種方案是最優(yōu)解嗎，當(dāng)然不是，還有優(yōu)化空間嗎？

下面先跑個題，談?wù)劧嗑€程/多進(jìn)程模型的優(yōu)缺點，主要談多進(jìn)程的優(yōu)點了：

教科書上的解釋就不提了，首先我對大的項目是推崇多進(jìn)程模型，無關(guān)性能，主要原因有：

模塊的解耦

很多開發(fā)人員維護(hù)開發(fā)的多線程模型項目應(yīng)該都多少會存在下面的問題：跨模塊間的直接調(diào)用，如果不相信，好，你的項目一定是分模塊的吧，現(xiàn)在隨機(jī)的刪掉一個模塊，build下看能build通過嗎（只需要build不需要運行），我相信大部分情況下一定會遇到某個函數(shù)調(diào)用，某個全局變量找不到的情況，這種情況說明你的模塊間存在強(qiáng)耦合了。

由于多線程天然的優(yōu)勢，地址空間的相互可見，導(dǎo)致直接調(diào)用十分容易，很多經(jīng)驗尚淺的工程師，很容易就寫出直接調(diào)用的簡單粗暴的接口，如果遇到個static接口的函數(shù)，圖方便也會把static去掉，直接拿過來用了。

這樣整個工程隨著功能不斷的添加，模塊間的交叉越來越多，耦合越高。

而我之所以推崇多進(jìn)程的原因就是，多進(jìn)程能從物理上隔絕了這種“方便”的通訊方式，導(dǎo)致在想實現(xiàn)一個模塊交互時，會多思考下這個交互是必要的嗎，如果是必要的，則會進(jìn)一步思考接口定義是否簡單明了（因為進(jìn)程間的通訊相對會麻煩些，開發(fā)人員會本著能減少交互，明確接口的想法去仔細(xì)考慮接口，協(xié)議的定義，否則折騰的是自己了），這如同人生，如果一直順風(fēng)順?biāo)?，人們可能不會想太多，思考太多，而如果道路上有些坎坷，則會有另一種感悟吧。

所以我的想法是多進(jìn)程的模型會逼迫你去更多的思考想程序的設(shè)計，物理上減少模塊的耦合。

抽象通用組件，分離通用功能和業(yè)務(wù)邏輯功能：當(dāng)把一個多線程模型修改為多進(jìn)程模型的過程中，經(jīng)常會發(fā)現(xiàn)有些接口代碼重復(fù)的出現(xiàn)在多個進(jìn)程模塊中，因為之前接口函數(shù)是在一個進(jìn)程空間，大家都可以直接調(diào)用的，比如接口A被模塊a；

b調(diào)用，模塊a，b分離為兩個獨立的進(jìn)程后，接口A需要在a，b中分別實現(xiàn)了，無需解釋，重復(fù)代碼這個在軟件工程中是大忌，必須消除。

做法也很簡單，將這些被多個模塊調(diào)用的接口分離處理做成lib，供其他模塊調(diào)用，當(dāng)你完成這部分工作后，你發(fā)現(xiàn)了什么，是不是剝離的接口，可以作為整個項目的通用組件存在了，完美的情況下，lib下的代碼是通用基礎(chǔ)組件，各個模塊中是獨立的業(yè)務(wù)處理模塊。

方便定位問題

多線程模型中當(dāng)又一個線程異常退出，會導(dǎo)致整個進(jìn)程退出，當(dāng)然通過一些crash信息，可以定位是那個線程死掉，但如果這些線程模塊是由多個小組，人員維護(hù)，當(dāng)整個進(jìn)程崩潰掉后，如何判斷由那個小組解決，會是一個大的問題，而且有時還會出現(xiàn)的現(xiàn)象是掛在一個線程，但其實是另外一個線程模塊引起的（耦合的禍端），遇到這種情況，難免出現(xiàn)小組間的扯皮，推諉（自信的工程師都認(rèn)為我的代碼沒有問題）。

而如果采用多進(jìn)程的模型，好吧，你的服務(wù)進(jìn)程掛了，你自己找原因吧，沒什么可爭辯的了。

方便性能測試

多線程種單個線程的資源占用不是很好查看（至少有些嵌入式系統(tǒng)沒有完善的命令），當(dāng)整個進(jìn)程資源消耗很高時，如何判斷定位時那個模塊線程的問題，同3一樣難以抉擇，而如果是多進(jìn)程的模型，誰的進(jìn)程占了好多資源，誰就去查下吧，其實這個還是個顆粒度的問題，同樣的系統(tǒng)，劃分成多個進(jìn)程，單個進(jìn)程的復(fù)雜度一定比只有一個進(jìn)程的復(fù)雜度低的多，復(fù)雜度降低，也就更容易定位查找各種問題。

分布式部署

互聯(lián)網(wǎng)行業(yè)一直強(qiáng)調(diào)的分布式，云啊什么的，嵌入式行業(yè)就很苦逼了，貌似不需要什么分布式吧，其實也對，大部分情況下，嵌入式采用單芯片，獨立運行，分布式遇到的很少。但如果萬一那天你在一個設(shè)備中，將本來一個芯片完成的功能分散到兩個芯片中處理呢，多進(jìn)程的擴(kuò)展就容易的多了。

這只是舉個特殊的例子，其實嵌入式設(shè)備就是個分布式的行業(yè)，只是一開始就已經(jīng)實現(xiàn)分離了，而不是從集中到分布式的路線發(fā)展起來的。

方便公司的代碼權(quán)限隔離：其實我鄙視這種做法，公司要相信自己的員工，但鑒于誠信在中國已經(jīng)……做些隔離也無可厚非了。

多線程模型下，前面講到如果去除一個模塊，你可能都不能build了，那么是要把所有代碼暴露給所有的工程師嗎，顯然不能，所以各個模塊只能提供庫的形式了，不過我覺得將通用功能接口組織成通用庫是正常的做法，而如果把和業(yè)務(wù)相關(guān)的模塊也提供成庫，就有點……

至此在補(bǔ)充一下，以上所有的優(yōu)點，其實都不是很關(guān)鍵的點，都不能夠讓多進(jìn)程有絕對的優(yōu)勢壓倒多線程模型，只是從個人的角度覺得，多進(jìn)程模型更能強(qiáng)迫工程師思考解決一些問題（而這些問題有經(jīng)驗的工程師無論什么模型都會思考的）。

上面說了這么多，該考慮下把之前項目的例子改成多進(jìn)程模型，否則就只是紙上談兵了，下面開始：

首當(dāng)其沖的問題就是：選擇多進(jìn)程的通訊方式，多線程間的直接調(diào)用是不能用了，那么如何選擇多進(jìn)程的通訊方式呢？

linux下提供很多ipc方式，此處不一一列舉，對于非大數(shù)據(jù)量的控制，通訊消息的傳遞，比較好的方式是采用socket，本機(jī)上更多采用unix socket方式（這種方式有什么好處？當(dāng)你有需要把單一系統(tǒng)做成分布式系統(tǒng)時，優(yōu)勢就明顯了）。

但是僅僅采用socket來實現(xiàn)前面例子的功能，同樣會存在一些問題：

還是前面的例子，首先說明前面我們優(yōu)化后的第二種方案在多進(jìn)程模型已經(jīng)不能在繼續(xù)使用了，原因比較簡單，應(yīng)該不需要解釋……

簡單的做法即基于方案一，把直接調(diào)用改為socket通信（定義好通信協(xié)議即可），但是熟悉socket開發(fā)的工程師都清楚，開始socket通信要先進(jìn)行一些前期的工作（主要就是連接，將兩個模塊關(guān)聯(lián)起來），所以前面的例子會變成這個樣子，模塊a要和模塊b，c建立連接，如果加入f模塊，模塊a還要和f模塊建立連接。

這樣情況在心里畫一張連接圖就會發(fā)現(xiàn)好像我們織了一張蜘蛛網(wǎng)，節(jié)點間的關(guān)系錯綜復(fù)雜，而且和方案一一樣，我們添加一個和a關(guān)聯(lián)的模塊，就要修改模塊a的代碼，而且這種情況比多線程模型還有繁瑣復(fù)雜的多了。這種做法絕對是個噩夢。

好吧如何解決，我想很多人一定想到了采用總線分發(fā)的方式。了解android系統(tǒng)開發(fā)的會想到binder，了解openwrt的會想到ubus，了解桌面會想到dbus，互聯(lián)網(wǎng)行業(yè)的開發(fā)者一定也知道redis里提供的sub/pub模塊。

上面的binder，ubus等原理很簡單，就是建立一個消息中心，構(gòu)建一個轉(zhuǎn)發(fā)路由模型，所有其他模塊之間不直接交互，而是采用消息中心轉(zhuǎn)發(fā)，路由，而如何決定路由規(guī)則，則采用訂閱/發(fā)布的觀察者模式來進(jìn)行規(guī)則的定義。

嵌入式開發(fā)或者c語言開發(fā)者，經(jīng)常會誤以為設(shè)計模式是和面向?qū)ο笳Z言關(guān)聯(lián)的，是面向?qū)ο笳Z言獨有，雖然有很多大牛做了這方面的普及，但鑒于有些開發(fā)者的信息渠道比較閉塞，導(dǎo)致這種想法仍然十分盛行

基于這個模型，我們上面例子的需求就很好解決了，加入一個消息中心模塊，所有需要通信的模塊只同該消息中心模塊連接，然后訂閱自己感興趣的事件，當(dāng)事件發(fā)生時，只需要進(jìn)行相應(yīng)的處理就可以了。

這樣上面的模塊b，c訂閱模塊a的事件，當(dāng)模塊a檢測到某事件時，發(fā)布該事件，該事件先到達(dá)消息中心，在由消息中心轉(zhuǎn)發(fā)給模塊b，c，而對于新加入的模塊f，也只需要訂閱該模塊，而不需要在修改到模塊a的代碼，使功能的擴(kuò)展十分方便。

同時對于前面提到的定制化開發(fā)同樣得到了簡化，如果定制化版本需要加入模塊g，這樣只需要定制化版本中將模塊g作為一個獨立進(jìn)程啟動，然后訂閱模塊a的事件即可，而定制版本和通用版的區(qū)別就在于是否啟動模塊g的進(jìn)程，從而實現(xiàn)了軟件工程的一個目標(biāo)：功能的添加如同搭積木一樣，只需要把一個模塊插入（啟動）或拔出（不啟動）即可，功能的改變只局限在一個或某幾個模塊間，對主體框架不會有任何影響。

以上大概描述了對一個項目需求逐步優(yōu)化的過程，例子看似是基于嵌入式項目，但貌似對軟件工程同樣適用。

來到互聯(lián)網(wǎng)行業(yè)

查看下各大網(wǎng)站架構(gòu)師對本網(wǎng)站技術(shù)架構(gòu)變革分享的文章，首先提到的一般都是，基于業(yè)務(wù)將之前的一個應(yīng)用服務(wù)器功能拆分，更加細(xì)化（比如電商對登錄，注冊，交易，商品，賣家等業(yè)務(wù)服務(wù)的拆分），然后將拆分出來的服務(wù)部署在多臺服務(wù)器上，來提供并發(fā)。

這里是否有些耳熟，和前面講到的多線程到多進(jìn)程的劃分是否有相似呢。

拆分后同樣遇到通信的問題，此時很多消息中間件應(yīng)運而生，比如阿里的duboo，簡單了解下這些中間件的原理，無外乎訂閱發(fā)布，RPC等機(jī)制，可以說大同小異，而難點在于協(xié)議的制定和性能處理的提升。

在對照下互聯(lián)網(wǎng)行業(yè)的負(fù)載均衡方案，仿佛那個負(fù)載均衡的前端也像一個消息中心了。

上面說了這么多，只是想說明一個問題，軟件的設(shè)計是相通的，基于的思想是相同的，雖然嵌入式行業(yè)的業(yè)務(wù)邏輯相對比較簡單，但其實在仔細(xì)思考后，仍然會有很多架構(gòu)上的改進(jìn)，設(shè)計。

但是讓我感到悲哀的是，有些嵌入式開發(fā)者，鑒于業(yè)務(wù)邏輯的簡單，感覺采用一些不那么好的處理方式也能解決問題，不去思考如何去優(yōu)化，改進(jìn)。**比如上面例子的方案一，如果在定制需求不多的情況下，維護(hù)起來也沒太大問題，即使定制需求多了，再招些初級程序員也能維護(hù)的過來，一個人一套代碼負(fù)責(zé)一個項目的公司也不是不存在。

同樣互聯(lián)網(wǎng)行業(yè)和嵌入式行業(yè)也不應(yīng)該存在一個不可以逾越的高墻，我們更應(yīng)該關(guān)注的是通用的軟件工程思想。

編輯：黃飛

?