微服務正在完全打亂我們當今構建應用程式的方式。當涉及到軟體體系結構時，這是最熱門的趨勢之一。越來越多的開發人員正在採用它。微服務是整體方法的替代方法，可為開發人員提供構建複雜軟體應用程式所需的靈活性，可伸縮性和簡便性。全世界的公司都已經意識到他們通過微服務所獲得的優勢。亞馬遜，Netflix，eBay，Spotify，Uber，Groupon和SoundCloud只是其中一些。

在這裡，我們總結了您需要了解的有關微服務的所有知識，以便上手。這些是我們將討論的主題：

• 什麼是微服務？
• 整體與微服務架構
• 為什麼選擇微服務？
• 微服務的挑戰
• 微服務和Docker
• 微服務和Kubernetes
• 建立微服務架構
• 何時使用微服務？

什麼是微服務？

使用微服務意味著從鬆散耦合的服務建立應用程式。該應用程式由幾個小服務組成，每個小服務代表一個單獨的業務目標。在複雜的應用程式中結合使用之後，它們可以單獨開發和維護。您還可以使用不同的程式語言，例如Node.js，Java，PHP等。

微服務使開發團隊可以自由選擇他們最喜歡的技術堆疊。他們免除了他們對其正在開發的應用程式將產生的影響的擔憂。與使用整體架構時相比，這使它們可以更快地執行並更有信心。但是，這並不意味著我們應該完全消除並忘記整體架構。

單片整體(單體)與微服務架構

具有整體式架構意味著建立單個單元作為所有功能元件的基礎。這包括資料庫操作，業務邏輯，後臺處理等。它們都可以一次部署並在同一伺服器上執行。

一切都在一個單獨的程式碼庫中，所有更新均在該程式碼庫中進行。由於應用程式變得太複雜而無法處理，這使擴充套件變得棘手。當程式碼庫較大時，新增更多功能將成為一個更大的問題。這限制了靈活性，並且沒有新思想的餘地。

單體架構意味著流程緊密耦合。如果僅其中之一存在問題，則整個體系結構將崩潰。這是非常危險的，因為整個應用程式可能會由於一個小錯誤而失敗。

另一方面，微服務體系結構由單獨的服務而不是單個單元組成。這些服務代表通過API進行通訊的單獨的程式碼庫。由於每個服務都代表一個單獨的功能，因此您也可以獨立更新，部署和擴充套件它。這不會影響其餘的微服務。

在以下情況下，單片架構會更好：

• 您正在開發的應用程式很簡單，並且所有內容都使用相同的語言和框架，
• 您只需啟動應用程式即可快速輕鬆地進行測試，
• 而且您沒有太多新功能會觸發整個應用程式的釋出。

為什麼選擇微服務？

微服務對您的應用程式更好的原因有幾個：

1. 可擴充套件性，在微服務架構中，每個服務都可以彼此獨立地擴充套件。這意味著每個功能都可以獨立執行，從而使團隊可以選擇最合適的技術堆疊。而且，他們可以估算每個功能的成本，並在需要時進行修改。
2. 生產率，微服務絕對是大型團隊的必經之路。當他們處理佔用大量時間和精力的大型專案時，微服務方法允許團隊將其分為幾個獨立的服務。這些服務獨立執行。這意味著團隊成員將能夠在無需協調的情況下從事同一專案。從事特定微服務的團隊可以自行制定決策，而不必等待其他團隊。對於初學者來說，他們將可以自由選擇要編寫微服務的語言。他們不必與其他團隊正在使用的技術堆疊進行協調。
3. 敏捷，敏捷是當今大多數開發團隊所追求的。微服務體系結構允許一個大團隊分成幾個負責獨立服務的小團隊。這使他們具有自治權，並有可能通過縮短開發週期來提高效率。
4. 可重用性，使用微服務意味著將小段程式碼配對到大型應用程式中。這些代表應用程式不同功能的部分也可以獨立執行。這意味著您可以將它們用作基礎或其他功能的補充。開發人員節省了很多時間，因為他們不必總是從頭開始編寫程式碼。而且，所有這些零件都可以更換。因此，如果應用程式的功能過時，則可以輕鬆地對其進行重寫和重新新增。這不會破壞整個應用程式的功能。您始終可以根據團隊目標和績效進行更改。

微服務的挑戰

在決定遷移到微服務架構之前，您還應該瞭解可能發生的挑戰：

1. 溝通的複雜性，現在，該應用程式包含幾個獨立執行的不同服務，因此應謹慎設定它們之間的通訊。開發人員必須處理的模組之間會有請求。他們可能還必須新增一些其他程式碼以保持流程的進行。如果微服務的數量很大，它們之間的通訊可能會導致許多複雜情況。
2. 需要更多的努力，與所有元件都位於同一單元中的整體架構不同，微服務具有更多的資料庫，需要更好的事務管理。而且，每個獨立的單元都必須分別部署和監視。這意味著團隊將不得不花費時間和精力來監視和準備每個單獨的服務以進行部署。
3. 測試多個單元，在整體方法中，您只需要啟動伺服器上具有的單個單元並確保它已連線到資料庫。既然您擁有更多的服務和資料庫，則必須分別確認每個服務和資料庫，然後才能測試整個應用程式。在某些情況下，其中一項服務可能會阻止測試階段並停止其餘服務的部署。這意味著微服務需要更多的測試時間。您將有很多要測試的介面，並且每個測試過程都必須與其他過程分開完成。

Docker和微服務

微服務通常部署在容器中，這些容器是充當微服務包裝的虛擬作業系統環境。Docker是最受歡迎的容器解決方案之一。 Docker是虛擬機器的輕量級系統，可幫助開發人員更有效地管理和部署微服務。

使用Docker，每個微服務都放置在Docker映象和Docker容器中。這些部分完全獨立於宿主環境。

Docker通過在其Docker主機上共享作業系統核心來取代擁有自己的虛擬作業系統環境的需求。

Docker允許將微服務拆分為更小的程式碼段，並通過名為Dockerfiles的檔案將其建立為Docker映像。這些Dockerfile使得將微服務連結到大型應用程式變得更加容易。

微服務系統通常由多個Docker容器構建，這些容器通過虛擬網路進行協調。由於容器必須進行通訊，因此Docker構建了Docker Compose環境，該環境允許伺服器之間進行通訊。

Docker通常與Kubernetes混在一起。但是，這兩個不是競爭對手。實際上，它們的組合可以帶來更好的結果。讓我們分解一下。

微服務和Kubernetes

Kubernetes（k8s或“ kube”）是一個開源系統，用於自動化容器的部署，擴充套件和管理。它最初是由Google工程師開發的。自那時以來， Google在容器中執行所有內容，並且每週生成超過20億個容器部署。

開發人員正在廣泛採用Kubernetes，以使生活更輕鬆。他們通過Kubernetes社群進行連線，該社群包括成千上萬的貢獻者和許多認證的合作伙伴。

通過將執行容器的組合並在一起，Kubernetes可以建立易於管理的叢集。您可以在各種雲中管理這些叢集，包括公共雲，私有云和混合雲。這就是使用Kubernetes託管可快速擴充套件的雲原生應用程式的原因。

因此，Kubernetes不能替代Docker。Docker也不取代Kubernetes。它們都可以獨立執行。但是，配對時，它們可以彼此受益匪淺。

Docker是一種可安裝在計算機上並執行容器化應用程式的軟體。如果您的計算機上安裝了Docker，則可以使用Kubernetes自動化容器操作，如管理，網路，安全性，擴充套件等。如果Docker安裝在多個Docker主機或節點上，則可以執行此操作。Kubernetes管理的一組節點集稱為Kubernetes叢集。

Kubernetes可以做很多事情：

• 將應用程式拆分為在不同雲環境中執行的小容器
• 整合和編排容器
• 管理程式碼庫並有效測試單獨的輸入和輸出
• 即時擴充套件應用程式並加快上市時間
• 從一家主機供應商遷移到另一家主機供應商，而無需在流程中進行重大更改
• 使用配置檔案，這樣可以確保您的應用程式完全按照您的規範執行。您可以宣告式管理它們
• 自動重啟，複製和擴充套件應用程式，使其能夠獨立修復

建立微服務架構

您可以在許多不同的框架中構建微服務。以下是最受歡迎的：

• 帶有Spring Cloud的Spring Boot —一個Java框架，具有各種擴充套件功能，用於Spring Cloud上的全棧微服務。
• Vert.x-在JVM上執行的工具，使您可以選擇語言並提供簡單的API。
• Akka —基於角色的框架，非常適合響應式微服務。
• Quarkus-用於構建模組化微服務應用程式的Kubernetes本機Java框架。
• Falcon-一個專注於質量控制並針對微服務進行了優化的Python框架。
• Molecular（分子） — Node.js的微服務框架，支援事件驅動的體系結構。

如何部署微服務？

有幾種選擇。您也可以將其中一些結合起來。

• 在雲上，要獲得擴充套件能力併為來自不同位置的許多使用者提供服務的能力，
• 使用容器，可以縮短產品上市時間，輕鬆擴充套件並快速解決問題。
• 作為PaaS（平臺即服務），從雲提供商那裡租用開發工具，基礎架構和作業系統，
• 無伺服器，當預計會有大流量時，
• 如果您有足夠的資源來執行此操作，則構建自己的IT基礎結構。

使用什麼雲提供商？

以下是一些選項：

• AWS具有大量服務，並且適用於幾乎所有型別的技術。
• Azure是.NET堆疊的最佳解決方案，有助於開發，資料儲存和託管解決方案。
• Google Cloud Platform通過可訪問的AI和資料分析解決了問題，併為Kubernetes提供了強大的支援。
• Digital Ocean支援一鍵式應用程式和標準分發，並在8個資料中心區域統一定價。

如何監控微服務？

您可以使用許多工具。這裡有一些建議：

• Datadog-我們將其用於監視，跟蹤日誌分析和警報。當涉及到錯誤檢測和效能下降時，它非常有效。
• Dynatrace —由AI驅動的平臺，用於監視動態混合雲環境。
• NewRelic —用於雲環境的集中式監視和報告工具。
• Splunk-日誌分析的靈活工具。
• AppDynamix —實時監視應用程式和伺服器效能。
• Zabbix —一個用於效能監視的開源網路。

如何自動化CI / CD過程？

Microtica涵蓋了整個軟體交付自動化流程，從完整的雲基礎架構設定到使用Kubernetes在雲中交付應用程式和服務。Microtica標準化了我們的開發人員在雲中開發，測試和部署程式碼的方式。這使得他們的工作可重複用於將來的專案。

要測試什麼？

這是我們使用的：

• Mocha + Chai用於單元整合測試和
• API測試自動化的Postman 。我們為每個公共API定義了一個測試用例。我們每天結束時執行它們，並立即獲得報告。出現問題時，我們會立即修復並部署到生產環境。

微服務最佳實踐

有很多做法，但讓我們看一些最常見的做法：

• 微型前端 -整體式Web介面分為幾個獨立的元件，這些元件作為微服務進行通訊
• 連續交付 -如果您只需要更改一項功能而無需動用其餘功能
• 域驅動的設計 —解決緊密耦合的微服務的挑戰
• 每個服務的資料庫 -儘管這需要團隊之間更多的溝通，但是每個微服務中的資料庫都帶來了更多的可持續性

但是，在開始之前，請不要錯過以下注意事項： *

• 您需要多少儲存空間？如果您依賴本地儲存，則無法靈活地進行擴充套件和擴充套件。您將無法處理大量工作負載。
• 您的應用是事件驅動的嗎？如果是這樣，則您應該能夠非同步處理，因為您的應用程式將跨多臺機器進行擴充套件。
• 需要靈活的訊息傳遞。將有多個事件源，並且都必須對其進行處理。這就是為什麼您需要一個健壯的訊息傳遞模型。
• 由於微服務將使用其API進行通訊，因此建立API通訊模式也是必不可少的。
• 您將需要一個更安全的模型，該模型將允許一個微服務僅訪問其所需的資源，而不會使其他微服務受到安全威脅。

微服務在軟體體系結構方面進行了一場重大的革命。在構建應用程式時，應認真考慮它們。Netflix，Amazon，Uber和Spotify只是決定將微服務的優勢用於大型，複雜應用程式的科技巨頭中的一些。

但是，遷移到微服務應取決於專案和團隊結構。這對整個公司來說都是非常重要的，因此您應該認真討論。