“微服務體系架構提供了一系列技術好處，這些好處有助於軟件項目的開發速度和產品質量，同時也有助於整體業務敏捷性”– Mark Emeis, CA技術公司軟件技術高級總監

自從“微服務”這個術語出現以來，它在軟件開發方面已經取得了進展。微服務，又名微服務體系結構，是面向服務體系結構(SOA)的變體，用於開發大型應用程序，其中服務根據業務領域的具體情況被劃分爲多個塊。它支持複雜應用程序的持續交付/部署，使應用程序更易於理解、開發和測試，並且對體系結構的侵蝕更有彈性。微服務體系結構提供了一種以新穎的方式編織現有系統的新方法，以便快速交付軟件解決方案。它是軟件行業中最熱門的話題之一，因爲它能夠提供模塊化、可伸縮性和可用性;許多企業軟件開發公司都熱衷於採用它。

Microservices究竟是什麼?

微服務能改善組織的文化、技能和需求嗎?爲了深入理解微服務，讓我們首先了解相反方法的要點:單體架構。

關於單體軟件的

維基百科說，“一個單一的應用程序描述了一個單層的軟件應用程序，其中用戶界面和數據訪問代碼從一個平臺合併成一個程序。”

單體架構軟件使用三層結構:

Presentation Layer – 應用程序的最頂層，並描述用戶界面。主要功能是將任務和結果轉換爲用戶能夠理解的內容。用戶界面代碼是用HTML、JavaScript和CSS等客戶端技術編寫的。Business Layer – 該層做出邏輯決策並執行計算。它處理兩層之間的數據，並使用Spring等技術。Data Access Layer –在這裏，信息從數據庫中存儲和檢索。信息被傳遞到業務層，然後最終傳遞給用戶。它使用像Hibernate這樣的ORM工具來處理信息。

web應用程序客戶機發送請求，層執行業務邏輯，數據庫存儲應用程序特定的數據，UI向用戶顯示特定的數據。但是，由於它們共享相同的代碼庫，可能會出現一些問題。

這種類型的體系結構在一段時間內運行良好，但是由於對持續交付的需求不斷增加，這種模型存在多個問題。

單體架構的缺點

Operational Overhead: 不同的涉衆使用不同的單體應用程序層;因此，團隊將侷限於特定的領域專家。在表示層工作的團隊專門從事UI技術，但對數據訪問層的知識最少。因此，如果要添加新特性，就需要不同的團隊來協調並交付特定的特性。這導致了從構思到投放市場的更長的時間跨度，並最終影響業務ROI。Software stack autonomy: 它限制了技術選擇，迫使整個層使用單一框架。例如，如果表示層是在HTML框架中編寫的，那麼整個層將在同一個框架中實現。這避免了實現最新的技術，從而導致應用程序代碼在短時間內變得過時。Implicit Interface: 由於這代碼是在單個文件中發佈的，因此應用程序中的一個小更改需要重新構建整個應用程序。因此，不斷進行的應用程序被放下，導致需要重新部署新版本。這種特性導致更新更少，並且不能以應有的速度發展。Scalability: 單體應用程序具有一維可伸縮性;因此無法縮放各個組件。因此，整個應用程序需要縮放，即使大多數應用程序可能不需要縮放。

沒有良好的體系結構開發軟件會給組織帶來很大的成本。例如:如果軟件開發公司採用非模塊化的方法開發軟件，其中UI功能和業務功能混合在相同的源文件中，那麼公司可能需要投入大量資金來支持其在最新的智能手機原生應用程序中的應用程序。這嚴重影響了軟件的可維護性，增加了上市時間，最終影響了公司的銷售。

單片架構一直是傳統的方法，但是由於伸縮性的限制、維護大型代碼庫的困難、高風險的升級和大量的前期設置成本，迫使企業或軟件開發公司探索不同的方法。單片應用程序是一個很難解決的難題，並且隨着時間的推移難以理解和擴展。

因此，爲了避免這些問題，微服務體系結構可以成爲救世主!爲解決上述複雜性提供了360度扭轉;幫助軟件開發公司在競爭對手中脫穎而出。

微服務體系架構簡介

微服務體系結構是一種軟件開發技術，它將應用程序構造爲鬆散耦合服務的集合。每個服務都是自包含的，應該實現單個業務功能。微服務體系結構旨在克服大型應用程序的挑戰、故障和故障。微服務提供了向系統添加彈性的機會，以便組件能夠優雅地處理尖峯和錯誤。這樣，每個涉衆都可以只關注整個應用程序的一個特定元素，使用自己的編程風格，而不關心其他組件。微服務中的通信可以毫不費力地進行，因爲它們是無狀態的，並且在定義良好的接口中(請求和響應是獨立的)。

如果應用/軟件是使用微服務方法開發的，它將有助於採用DevOps方法，並將消除部署效率低下，從而縮短上市時間。由於微服務與設備和平臺無關，因此它能夠開發應用程序，爲大多數平臺(包括web、移動設備、物聯網、平板電腦、可穿戴設備等)提供增強的用戶體驗。

例如，沃爾瑪加拿大公司在2012年之前就使用了單片架構!該公司在處理600萬次/分鐘的頁面瀏覽量時遇到了問題，這消耗了更多的時間，導致銷售減少。由於這些問題，他們將軟件架構重構爲微服務，並在一夜之間發現了即時結果和高轉化率。停機時間最小化，公司能夠使用更便宜的x86服務器，而不是昂貴的硬件，從而節省了20%-50%的成本。

Microservices 和 SOA

它是SOA的自然演進，各種技術堆棧將技術多樣性引入開發團隊。SOA和微服務都允許將複雜的工作負載分解爲更小、更易於管理和獨立的部分。

然而，兩者之間有一些基本的區別。

Microservices vs SOA

關注分離和有界上下文系統的改變創造了新的服務關注持續交付和DevOps使用輕量級協議，如HTTP、REST等。各個微服務之間提供了獨立的數據存儲MicroservicesSOA目標最大化的重用性

系統的改變需要修改整體結構

關注持續交付和DevOps

使用簡單的消息傳遞系統進行通信使用企業服務總線(ESB)進行通信支持消息協議

共享的數據存儲

Microservices哲學

微服務的哲學類似於Unix哲學，“只做一件事，做好它”。其特點如下:

執行單個功能的組件化

根據業務能力進行組織

關注產品，而不是過程

分散的治理和數據管理

服務是彈性的、彈性的、可組合的、最小的和完整的

爲什麼軟件開發公司應該投資於微服務架構?

Improves Fault Isolation

在微服務體系結構中，開發人員確切地知道在何處查找要解決的問題。如果單個模塊受到影響，它可以很容易地拆卸或解決，而不影響應用程序的其他部分;提高應用程序的可用性。這在單片應用中是完全矛盾的;單個組件的故障可能導致整個應用程序崩潰。例如，移動遊戲應用程序(構建在單塊架構上)有不同的組件，比如支付、登錄、玩家、歷史等等。如果一個特定的組件開始消耗更多的內存空間，整個應用程序將受到影響，這將導致糟糕的用戶體驗。

Easy to Modify the Technology Stack

通過使用微服務，軟件開發公司可以在特定組件上嘗試新的堆棧或最新技術，以提高可用性，並在應用程序級別獲得更大的好處。由於不存在依賴問題，如果軟件開發人員沒有提供一致的用戶體驗，他們可以避免使用特定的技術棧。這樣持續的現代化，你的系統不會輕易過時。

Provides scalability微服務對有性能問題的部件進行擴展，並使用最符合服務需求的硬件。由於每個服務都是單獨的組件，因此可以使用更多的容器部署可伸縮性，從而實現更有效的容量規劃、更少的許可成本和適當的硬件。關鍵服務的組件可以部署在多個服務器上，以提高可用性和性能，而不會影響其他服務的性能。這種可伸縮性可以帶來更好的客戶體驗並節省成本。

Aligned With the Organization

如果一個組織正在使用微服務，那麼可以定義團隊規模來匹配所需的任務。此外，團隊可以被分成更小的小組，並且可以專注於應用程序的單個組件。由於最終目標是客戶滿意度和良好的用戶體驗，所以團隊不分爲UI團隊、數據庫團隊等。例如，如果在UAE工作的團隊要處理3個服務，而在California工作的團隊要處理5個服務，那麼在California和UAE工作的每個團隊都可以獨立發佈和部署不同的功能。這些跨職能團隊致力於實現單一功能，打破團隊之間的隔閡，促進更好的協作。

Improved Productivity and Speed

有了微服務，生產率和速度可以很容易地解決。不同的團隊可以同時處理不同的組件，而不必等待一個團隊完成任務。這就加快了質量保證的速度，因爲每個微服務都可以單獨測試。其他涉衆可以致力於增強已經開發的組件，而其他程序員則致力於其他組件。這提高了速度，並導致更快的產品發佈。

需要考慮的障礙

僅僅因爲一切看起來都很華麗，並不意味着它對軟件行業來說是完美的;它確實有潛在的痛苦，這也需要解決:

由於微服務側重於分佈式系統和獨立服務，每個請求都需要在模塊之間小心處理。其中一個服務可能沒有響應，這迫使開發人員編寫額外的代碼以避免中斷。

基於微服務的應用程序的測試可能是一項痛苦的任務，因爲在開始測試之前需要確認每個依賴的服務。隨着服務數量的增加，複雜性不再停留在後臺!在所有服務上保留標籤變得不切實際，因爲可能會出現數據庫錯誤、網絡延遲、緩存問題等。因此，彈性測試和錯誤注入成爲了必須。

每個服務都依賴於它自己的API和平臺，跟蹤每一件事都是一項痛苦的工作。領導者需要監視多個實體並管理整個基礎設施，因爲如果任何服務出現故障，跟蹤問題就變得很乏味。因此，健壯的監視是必要的。

隨着持續的交付和快速的發展，員工必須跟上敏捷性和速度要求利用微服務的好處。如果他們花很長一段時間提供服務器，公司可能會陷入嚴重的麻煩。

微服務和整體架構之間區別

整個應用程序中的每個組件都必須很小，並且必須交付最終目標不同的技術可以用於不同的微服務

Microservices ArchitectureMonolithic Architecture遵循所有業務目標的單層體系結構

Services are fastTakes more time即使一個服務宕機，也不會影響其他組件。其他服務可以繼續進行如果某一特定特性存在問題，則需要將整個系統拉下鬆散耦合和分散。所有獨立工作All services are tightly coupled更多的資源可以用來產生高收入由於服務不是孤立的，因此不可能進行更多的資源分配應用程序擴展是可能的;因此，硬件可以按照需求進行分配縮放有點困難;因此，硬件分配可能會造成浪費微型服務迅速發展，持續可用流程需要從頭開始;快速發展會變得困難通過定義良好的接口與其他微服務進行通信Communication can be messed upFocuses on productFocuses on entire project最新的技術不能被使用，因爲一個程序依賴於其他程序

微服務架構的未來

您可能已經清楚地瞭解了微服務體系結構及其改變軟件行業的潛力!隨着數字技術和多設備支持的日益普及;軟件開發正在深入到複雜的過程中。但是軟件行業有幸擁有微服務體系結構，它可以作爲解決軟件開發公司複雜性的完美解決方案。如果公司想採用它，它肯定會在技術和操作上影響企業文化。

大公司已經在使用中

今天，隨着微服務的興起，大多數公司都在推倒單體架構，採用現代架構來在激烈的競爭中發揮作用。其中包括Netflix、eBay、亞馬遜(Amazon)、Twitter、貝寶(PayPal)、沃爾瑪(Walmart)等等……

Netflix

NetFlix是最早在SOA體系結構中使用微服務的公司之一。在公司快速增長的時候，無法建立數據中心來提供可伸縮性。開發中的小問題需要軟件開發人員一次又一次地尋找問題。但是，當他們用微服務重構現有的架構時，他們每天能夠通過800種不同設備的api處理10億個調用。如今，Netflix正在使用500+微服務和30+工程團隊。

優步

優步開始了它的微服務之旅，在一個城市建立的單一的單體架構。由於它只在一個城市運行，一個代碼庫選項似乎是乾淨的選項，可以解決所有的業務問題。但是，當它迅速擴展到其他城市時，組件變得緊密耦合，封裝是另一個問題，而持續集成則是一個負擔。因此，爲了解決所有這些複雜性，工程團隊重構了現有的應用程序並使用了微服務。

1.所有乘客和司機通過API網關連接

2.部署單獨的單元來執行單獨的功能

3.所有功能都可以單獨縮放

因此，從單體架構到微服務架構的轉變讓優步受益匪淺。

Amazon

亞馬遜是大型電子商務商店之一，它遵循單體的應用程序，使開發人員彼此分離，並將團隊從最終目標中分離出來。該公司必須解決協調過程之間的衝突，將它們合併爲一個單獨的版本，並生成所有版本的主版本。需要重新運行全新的代碼庫、測試用例，以確保沒有倉促的工作。這些小故障使得公司使用微服務架構!這個軟件解決方案通過自己的web服務api與世界進行通信。因此，它非常成功。

做出選擇

無論你選擇是整體服務還是微服務，兩者都有其優點和缺點。最後，選擇軟件架構取決於您的項目需求、項目的大小等等。如果您希望構建小型軟件，那麼單體架構是一種選擇，如果您喜歡開發複雜的軟件，那麼微服務體系結構無疑是一個很好的選擇。