盡管嵌入式設(shè)備的使用越來越多，但嵌入式開發(fā)技術(shù)仍然停留在過去。時至今日，軟件和硬件之間仍有很強的依賴性，通常使用整體設(shè)計。這意味著每次都要從頭開始，而且完全缺乏敏捷性。

 

硬件設(shè)備需要有更多的無處不在的連接，代碼應(yīng)該能夠重用——在微服務(wù)方法中。這意味著從現(xiàn)代軟件開發(fā)中借鑒概念，并將其應(yīng)用于嵌入式世界——在機器人、家庭自動化、航空、太空和許多其他領(lǐng)域——這將使開發(fā)更快、更容易。

 

這篇文章將闡述采用現(xiàn)代軟件開發(fā)并將其應(yīng)用于邊緣和嵌入式開發(fā)（基于開源方法）的理由，并展示這是如何實現(xiàn)的，以及人們今天如何開始。我們將研究在嵌入式項目中使用微服務(wù)的優(yōu)勢和潛在障礙，以及在吞吐量、延遲和安全性方面需要考慮的變量。

 

開始考慮微服務(wù)而不是單片：嵌入式開發(fā)人員的冒險之旅

人們習慣于將項目視為一組相互依賴的復(fù)雜的電路板、驅(qū)動程序和應(yīng)用程序。比如，我們開發(fā)了幾個星期的代碼，然后有人在某個地方做了一些小改動，我們不得不從頭開始重新編碼所有內(nèi)容。

 

在這個越來越關(guān)注敏捷性和成本控制的時代，似乎難以相信，只要你改變項目中的變量，就可以繼續(xù)開發(fā)無法重用的代碼。開發(fā)一個不容易根據(jù)外部變化（例如半導(dǎo)體短缺）及時調(diào)整的項目變得不可思議。這種浪費時間和精力的行為不能再這樣下去了。

因此，很重要的一點是，看看這種靈活性的缺乏在嵌入式開發(fā)之外的其他領(lǐng)域是否也是如此。硬件經(jīng)常被比作軟件，在這種情況下，它提供了一個例子。

 

九年來，Docker如何使容器中的可移植軟件應(yīng)用程序的開發(fā)大眾化？組成一個系統(tǒng)的小段代碼？可以隨意重用的獨立服務(wù)？

 

微服務(wù)理念似乎顯而易見

在軟件開發(fā)中，部分得益于微服務(wù)的出現(xiàn)，許多想法可以很快推出。當你對一個應(yīng)用程序、軟件或web應(yīng)用程序有了想法時，你甚至不考慮它背后運行的是什么硬件。它是透明的、流動的，并且隨時間而變化。但是，我們在嵌入式開發(fā)中，嵌入式系統(tǒng)沒有這種通用性，因為它們需要大量的抽象。

 

微服務(wù)是在2000年出現(xiàn)的。根據(jù)谷歌趨勢，自2014年以來，人們一直在談?wù)撨@個話題。在先驅(qū)中，Netflix致力于普及這些架構(gòu)。

這個想法是把這個大蛋糕分成幾個小蛋糕，每個蛋糕都是一種服務(wù)。服務(wù)是一個獨立的單元，它執(zhí)行特定的任務(wù)，并與其他服務(wù)通信以完成其使命。

 

隨著物聯(lián)網(wǎng)的興起，微服務(wù)已經(jīng)出現(xiàn)在硬件領(lǐng)域。但目前，這些設(shè)備是唯一使用微服務(wù)的設(shè)備，可能是因為它們可以訪問互聯(lián)網(wǎng)。我們的設(shè)備、機器人和系統(tǒng)的內(nèi)部網(wǎng)絡(luò)在很大程度上仍然停留在過去。

 

嵌入式開發(fā)的挑戰(zhàn)

嵌入式開發(fā)的主要挑戰(zhàn)是克服軟件和硬件之間的強耦合。在軟件世界中，我們有API允許我們開發(fā)代碼而不需要處理底層硬件。我們可以改變應(yīng)用程序的數(shù)據(jù)庫，而不必改變使用它的代碼。在硬件領(lǐng)域，通常需要非常了解所用的電路板、其寄存器或協(xié)議，以便能夠與固件交換信息，使我們的系統(tǒng)正常工作。

 

這使得很難從一個項目到另一個項目重用代碼，也很難快速適應(yīng)變化。通常還需要很好地了解用于開發(fā)的工具，這些工具通常專用于一個微控制器或一系列微控制器。

所有這些因素使得很難找到具有必要技能的開發(fā)人員，并使開發(fā)速度更慢、成本更高。

 

微服務(wù)在嵌入式開發(fā)中的優(yōu)勢

微服務(wù)的主要優(yōu)勢在于，它允許開發(fā)人員分離不同的軟件，從而在應(yīng)用程序和驅(qū)動程序之間實現(xiàn)清晰的分離。這使得可以為不同的硬件平臺重復(fù)使用相同的應(yīng)用程序代碼，并且改變硬件平臺而不必改變除了相關(guān)驅(qū)動程序之外的代碼。

 

微服務(wù)還有一個優(yōu)勢，即基于一組服務(wù)修訂更容易測試和部署特定的配置。

你可以使用開源微服務(wù)協(xié)調(diào)器（如Luos）輕松同步所有板上的所有服務(wù)或計算機或云上的遠程進程。

 

微服務(wù)對嵌入式開發(fā)的潛在障礙

微服務(wù)依賴于服務(wù)之間的通信。一個好的微服務(wù)架構(gòu)使得服務(wù)之間的通信變得容易和流暢。微服務(wù)架構(gòu)將控制你的主板之間的網(wǎng)絡(luò)。

在任何情況下，你都必須交換信息，以便微服務(wù)架構(gòu)不會對網(wǎng)絡(luò)延遲產(chǎn)生任何影響。但由于它簡單透明，很容易過度使用，這意味著需要更多的網(wǎng)絡(luò)數(shù)據(jù)帶寬。

 

對于在同一個微控制器上運行的多個服務(wù)，這會增加一些可能影響代碼性能的操作。敏捷是有代價的，即使是最小的RTOS也是如此。例如，如果服務(wù)需要從傳感器獲取數(shù)據(jù)，它必須發(fā)送請求，等待傳感器響應(yīng)，然后處理數(shù)據(jù)。

 

安全性可能是一個障礙，因為服務(wù)越多，潛在的攻擊面就越多。此外，微服務(wù)使代碼片段自然地協(xié)同工作，惡意代碼也是如此。因此，仔細考慮使用微服務(wù)的安全影響非常重要。

對于某些應(yīng)用程序，比如那些需要實時響應(yīng)的應(yīng)用程序，吞吐量和延遲比安全性更重要。對于其他應(yīng)用程序來說，安全性比吞吐量和延遲更重要，例如那些處理敏感數(shù)據(jù)的應(yīng)用程序。

 

選擇一個組織和簡化交流的協(xié)調(diào)器

在嵌入式領(lǐng)域，有很多現(xiàn)有的操作系統(tǒng)，如FreeRTOS、NuttX或澤法，但沒有太多的工具以一致的方式協(xié)調(diào)你的多個電路板。微服務(wù)協(xié)調(diào)器的使用使這個實際案例更加靈活。硬件不可知的引導(dǎo)加載程序?qū)⒃试S從任何物理連接更新任何板，而無需拆卸所有部件。我們可以連接到STM32以更新STM32。嵌入式開發(fā)人員需要在嵌入式和邊緣項目中獲得這種靈活性。