盡管嵌入式設(shè)備的使用越來(lái)越多，但嵌入式開(kāi)發(fā)技術(shù)仍然停留在過(guò)去。時(shí)至今日，軟件和硬件之間仍有很強(qiáng)的依賴(lài)性，通常使用整體設(shè)計(jì)。這意味著每次都要從頭開(kāi)始，而且完全缺乏敏捷性。
硬件設(shè)備需要有更多的無(wú)處不在的連接，代碼應(yīng)該能夠重用——在微服務(wù)方法中。這意味著從現(xiàn)代軟件開(kāi)發(fā)中借鑒概念，并將其應(yīng)用于嵌入式世界——在機(jī)器人、家庭自動(dòng)化、航空、太空和許多其他領(lǐng)域——這將使開(kāi)發(fā)更快、更容易。
這篇文章將闡述采用現(xiàn)代軟件開(kāi)發(fā)并將其應(yīng)用于邊緣和嵌入式開(kāi)發(fā)（基于開(kāi)源方法）的理由，并展示這是如何實(shí)現(xiàn)的，以及人們今天如何開(kāi)始。我們將研究在嵌入式項(xiàng)目中使用微服務(wù)的優(yōu)勢(shì)和潛在障礙，以及在吞吐量、延遲和安全性方面需要考慮的變量。
開(kāi)始考慮微服務(wù)而不是單片：嵌入式開(kāi)發(fā)人員的冒險(xiǎn)之旅
人們習(xí)慣于將項(xiàng)目視為一組相互依賴(lài)的復(fù)雜的電路板、驅(qū)動(dòng)程序和應(yīng)用程序。比如，我們開(kāi)發(fā)了幾個(gè)星期的代碼，然后有人在某個(gè)地方做了一些小改動(dòng)，我們不得不從頭開(kāi)始重新編碼所有內(nèi)容。
在這個(gè)越來(lái)越關(guān)注敏捷性和成本控制的時(shí)代，似乎難以相信，只要你改變項(xiàng)目中的變量，就可以繼續(xù)開(kāi)發(fā)無(wú)法重用的代碼。開(kāi)發(fā)一個(gè)不容易根據(jù)外部變化（例如半導(dǎo)體短缺）及時(shí)調(diào)整的項(xiàng)目變得不可思議。這種浪費(fèi)時(shí)間和精力的行為不能再這樣下去了。
因此，很重要的一點(diǎn)是，看看這種靈活性的缺乏在嵌入式開(kāi)發(fā)之外的其他領(lǐng)域是否也是如此。硬件經(jīng)常被比作軟件，在這種情況下，它提供了一個(gè)例子。
九年來(lái)，Docker如何使容器中的可移植軟件應(yīng)用程序的開(kāi)發(fā)大眾化？組成一個(gè)系統(tǒng)的小段代碼？可以隨意重用的獨(dú)立服務(wù)？
微服務(wù)理念似乎顯而易見(jiàn)
在軟件開(kāi)發(fā)中，部分得益于微服務(wù)的出現(xiàn)，許多想法可以很快推出。當(dāng)你對(duì)一個(gè)應(yīng)用程序、軟件或web應(yīng)用程序有了想法時(shí)，你甚至不考慮它背后運(yùn)行的是什么硬件。它是透明的、流動(dòng)的，并且隨時(shí)間而變化。但是，我們?cè)?/span>嵌入式開(kāi)發(fā)中，嵌入式系統(tǒng)沒(méi)有這種通用性，因?yàn)樗鼈冃枰罅康某橄蟆?o:p>
微服務(wù)是在2000年出現(xiàn)的。根據(jù)谷歌趨勢(shì)，自2014年以來(lái)，人們一直在談?wù)撨@個(gè)話(huà)題。在先驅(qū)中，Netflix致力于普及這些架構(gòu)。
這個(gè)想法是把這個(gè)大蛋糕分成幾個(gè)小蛋糕，每個(gè)蛋糕都是一種服務(wù)。服務(wù)是一個(gè)獨(dú)立的單元，它執(zhí)行特定的任務(wù)，并與其他服務(wù)通信以完成其使命。
隨著物聯(lián)網(wǎng)的興起，微服務(wù)已經(jīng)出現(xiàn)在硬件領(lǐng)域。但目前，這些設(shè)備是唯一使用微服務(wù)的設(shè)備，可能是因?yàn)樗鼈兛梢栽L(fǎng)問(wèn)互聯(lián)網(wǎng)。我們的設(shè)備、機(jī)器人和系統(tǒng)的內(nèi)部網(wǎng)絡(luò)在很大程度上仍然停留在過(guò)去。
嵌入式開(kāi)發(fā)的挑戰(zhàn)
嵌入式開(kāi)發(fā)的主要挑戰(zhàn)是克服軟件和硬件之間的強(qiáng)耦合。在軟件世界中，我們有API允許我們開(kāi)發(fā)代碼而不需要處理底層硬件。我們可以改變應(yīng)用程序的數(shù)據(jù)庫(kù)，而不必改變使用它的代碼。在硬件領(lǐng)域，通常需要非常了解所用的電路板、其寄存器或協(xié)議，以便能夠與固件交換信息，使我們的系統(tǒng)正常工作。
這使得很難從一個(gè)項(xiàng)目到另一個(gè)項(xiàng)目重用代碼，也很難快速適應(yīng)變化。通常還需要很好地了解用于開(kāi)發(fā)的工具，這些工具通常專(zhuān)用于一個(gè)微控制器或一系列微控制器。
所有這些因素使得很難找到具有必要技能的開(kāi)發(fā)人員，并使開(kāi)發(fā)速度更慢、成本更高。
微服務(wù)在嵌入式開(kāi)發(fā)中的優(yōu)勢(shì)
微服務(wù)的主要優(yōu)勢(shì)在于，它允許開(kāi)發(fā)人員分離不同的軟件，從而在應(yīng)用程序和驅(qū)動(dòng)程序之間實(shí)現(xiàn)清晰的分離。這使得可以為不同的硬件平臺(tái)重復(fù)使用相同的應(yīng)用程序代碼，并且改變硬件平臺(tái)而不必改變除了相關(guān)驅(qū)動(dòng)程序之外的代碼。
微服務(wù)還有一個(gè)優(yōu)勢(shì)，即基于一組服務(wù)修訂更容易測(cè)試和部署特定的配置。
你可以使用開(kāi)源微服務(wù)協(xié)調(diào)器（如Luos）輕松同步所有板上的所有服務(wù)或計(jì)算機(jī)或云上的遠(yuǎn)程進(jìn)程。
微服務(wù)對(duì)嵌入式開(kāi)發(fā)的潛在障礙
微服務(wù)依賴(lài)于服務(wù)之間的通信。一個(gè)好的微服務(wù)架構(gòu)使得服務(wù)之間的通信變得容易和流暢。微服務(wù)架構(gòu)將控制你的主板之間的網(wǎng)絡(luò)。
在任何情況下，你都必須交換信息，以便微服務(wù)架構(gòu)不會(huì)對(duì)網(wǎng)絡(luò)延遲產(chǎn)生任何影響。但由于它簡(jiǎn)單透明，很容易過(guò)度使用，這意味著需要更多的網(wǎng)絡(luò)數(shù)據(jù)帶寬。
對(duì)于在同一個(gè)微控制器上運(yùn)行的多個(gè)服務(wù)，這會(huì)增加一些可能影響代碼性能的操作。敏捷是有代價(jià)的，即使是最小的RTOS也是如此。例如，如果服務(wù)需要從傳感器獲取數(shù)據(jù)，它必須發(fā)送請(qǐng)求，等待傳感器響應(yīng)，然后處理數(shù)據(jù)。
安全性可能是一個(gè)障礙，因?yàn)榉?wù)越多，潛在的攻擊面就越多。此外，微服務(wù)使代碼片段自然地協(xié)同工作，惡意代碼也是如此。因此，仔細(xì)考慮使用微服務(wù)的安全影響非常重要。
對(duì)于某些應(yīng)用程序，比如那些需要實(shí)時(shí)響應(yīng)的應(yīng)用程序，吞吐量和延遲比安全性更重要。對(duì)于其他應(yīng)用程序來(lái)說(shuō)，安全性比吞吐量和延遲更重要，例如那些處理敏感數(shù)據(jù)的應(yīng)用程序。
選擇一個(gè)組織和簡(jiǎn)化交流的協(xié)調(diào)器
在嵌入式領(lǐng)域，有很多現(xiàn)有的操作系統(tǒng)，如FreeRTOS、NuttX或澤法，但沒(méi)有太多的工具以一致的方式協(xié)調(diào)你的多個(gè)電路板。微服務(wù)協(xié)調(diào)器的使用使這個(gè)實(shí)際案例更加靈活。硬件不可知的引導(dǎo)加載程序?qū)⒃试S從任何物理連接更新任何板，而無(wú)需拆卸所有部件。我們可以連接到STM32以更新STM32。嵌入式開(kāi)發(fā)人員需要在嵌入式和邊緣項(xiàng)目中獲得這種靈活性。
