此處嵌入式特指基于linux平臺，單片機和其他rtos不在討論范圍~

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

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

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

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

嵌入式是否真的高大上？為什么沒有嵌入式軟件架構(gòu)師?

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

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

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

以目前國內(nèi)大部分公司的業(yè)務需求，只是在做外圍設備的集成，嵌入式平臺的porting、搭建裁剪、業(yè)務需求完全不會超過kernel里提供的功能范圍，導致沒有什么新的架構(gòu)需要開發(fā)人員去設計、實現(xiàn)。那嵌入式bsp開發(fā)人員都在做什么？除了調(diào)試多種多樣的外設，替硬件擦屁股，就是解些穩(wěn)定性的bug了(這里對具體工作不詳細描述了，調(diào)試外設只會增加一些經(jīng)驗，增加廣度，對提高深度貢獻不大，只是按不會調(diào)試-》會調(diào)試-》調(diào)試的快這個路線發(fā)展，而解穩(wěn)定性問題確實是需要一些積累經(jīng)驗)

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

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

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

那么對于嵌入式應用層的開發(fā)，我們真的不需要架構(gòu)嗎?

以自己的實際經(jīng)歷講述下曾經(jīng)對一個嵌入式設備應用軟件的架構(gòu)設計和優(yōu)化：我曾經(jīng)接手過一個項目，項目采用單進程多線程的模型，項目中包括幾個模塊，以a, b, c, d,e代表。這個項目的業(yè)務邏輯決定這幾個模塊有不少關(guān)聯(lián)。

例如：最初的設計中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)進行一個處理，按照之前的套路，完成這個功能分兩步：

在f模塊提供接口。

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

前面提到需求總是千變?nèi)f化的，新的需求又來了，客戶提出定制需求，需要加入另一個g模塊，同樣處理a模塊監(jiān)測的狀態(tài)，但是該定制需求不需要剛剛加入的f模塊，此時最簡單粗暴的方式是，定義一個宏，區(qū)分該定制需求和之前的通用需求，build兩個程序版本。這樣的做法看似簡單，但后面如果定制需求逐漸增多，維護這么多定制版本程序就是個噩夢，代碼管理和通用性也會是很大的問題，同時代碼中充斥著對不同宏定義的差異化處理。

比較好的做法是加入設備型號版本的動態(tài)監(jiān)測，用一個build程序版本動態(tài)支持所有的定制需求，這樣減少了對不同build程序的維護。但是這種做法只解決build程序的版本維護工作，沒有解決宏定義差異化處理的問題，只是會將之前的宏判斷，改為動態(tài)設備版本號判斷，如果這些差異化的判斷只集中在一處進行，也不會引起大的復雜化的問題，但顯然這個不好保證，有可能這些差異化的處理會蔓延到整個項目的各個角落，這樣項目維護起來就會變成一場噩夢。

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

通用做法就是采用callback設置鉤子，然后在callback中定制差異化的需求，對callback的處理做差異化的配置，對應到上面例子，就是在a模塊添加一個鉤子，然后在系統(tǒng)初始化時，根據(jù)設備版本號的不同，差異化定制callback處理函數(shù)，同時要將這些定制callback處理函數(shù)放在同一地方處理，否則仍然分散在各個角落里就沒有意義(前一種方式不放置鉤子是無法將這些差異化配置放在一起的)，這樣處理帶來的另外一個好處是，我們對功能性需求的改變，不會影響到a模塊的處理，也就是我們添加功能，不需要修改a模塊的代碼了(前一種方式要修改a模塊的調(diào)用流程)，這樣也就實現(xiàn)了一個模塊的分離。

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

軟件是需要不斷進化的，第二種方案是最優(yōu)解嗎，當然不是，還有優(yōu)化空間嗎?

下面先跑個題，談談多線程/多進程模型的優(yōu)缺點，主要談多進程的優(yōu)點了：

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

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

由于多線程天然的優(yōu)勢，地址空間的相互可見，導致直接調(diào)用十分容易，很多經(jīng)驗尚淺的工程師，很容易就寫出直接調(diào)用的簡單粗暴的接口，如果遇到個static接口的函數(shù)，圖方便也會把static去掉，直接拿過來用了。這樣整個工程隨著功能不斷的添加，模塊間的交叉越來越多，耦合越高。

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

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

抽象通用組件，分離通用功能和業(yè)務邏輯功能：當把一個多線程模型修改為多進程模型的過程中，經(jīng)常會發(fā)現(xiàn)有些接口代碼重復的出現(xiàn)在多個進程模塊中，因為之前接口函數(shù)是在一個進程空間，大家都可以直接調(diào)用的，比如接口A被模塊a，b調(diào)用，模塊a，b分離為兩個獨立的進程后，接口A需要在a，b中分別實現(xiàn)了，無需解釋，重復代碼這個在軟件工程中是大忌，必須消除。做法也很簡單，將這些被多個模塊調(diào)用的接口分離處理做成lib，供其他模塊調(diào)用，當你完成這部分工作后，你發(fā)現(xiàn)了什么，是不是剝離的接口，可以作為整個項目的通用組件存在了，完美的情況下，lib下的代碼是通用基礎組件，各個模塊中是獨立的業(yè)務處理模塊。

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

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

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

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

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

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

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

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

上面說了這么多，該考慮下把之前項目的例子改成多進程模型，否則就只是紙上談兵了。

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

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

但是僅僅采用socket來實現(xiàn)前面例子的功能，同樣會存在一些問題：還是前面的例子，首先說明前面我們優(yōu)化后的第二種方案在多進程模型已經(jīng)不能在繼續(xù)使用了，原因比較簡單，應該不需要解釋。

簡單的做法即基于方案一，把直接調(diào)用改為socket通信(定義好通信協(xié)議即可)，但是熟悉socket開發(fā)的工程師都清楚，開始socket通信要先進行一些前期的工作(主要就是連接，將兩個模塊關(guān)聯(lián)起來)，所以前面的例子會變成這個樣子，模塊a要和模塊b，c建立連接，如果加入f模塊，模塊a還要和f模塊建立連接。這樣情況在心里畫一張連接圖就會發(fā)現(xiàn)好像我們織了一張蜘蛛網(wǎng)，節(jié)點間的關(guān)系錯綜復雜，而且和方案一一樣，我們添加一個和a關(guān)聯(lián)的模塊，就要修改模塊a的代碼，而且這種情況比多線程模型還有繁瑣復雜的多了。這種做法絕對是個噩夢。

如何解決？我想很多人一定想到了采用總線分發(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ā)布的觀察者模式來進行規(guī)則的定義。(嵌入式開發(fā)或者c語言開發(fā)者，經(jīng)常會誤以為設計模式是和面向?qū)ο笳Z言關(guān)聯(lián)的，是面向?qū)ο笳Z言獨有，雖然有很多大牛做了這方面的普及，但鑒于有些開發(fā)者的信息渠道比較閉塞，導致這種想法仍然十分盛行)

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

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

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

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

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

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

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

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

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

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

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