什麼是微服務？
微服務，也稱為微服務架構，是指將應用程式合併成一組服務集合的軟體開發方法。從本質上講，這套應用程式本身做為一個完整應用程式進行部署，其中的服務會一起運作以構成整個應用程式。所有微服務都遵循下列模式：它們是圍繞著業務功能而組織、為鬆散耦合狀態、可獨立部署、並且可測試。因為它們是鬆散耦合的，所以微服務可以分開構建、部署和擴展。
每個服務都透過標準化的應用程式介面 (API) 與其他服務進行通訊，從而使服務能夠以不同的語言或不同的技術編寫。這與構建為單體結構的系統完全不同，在單體結構中，服務彼此相連密不可分，只能一起擴展，牽一髮動全身。
由於每項服務都只有受限的（通常僅有單一）功能，因此它的規模和複雜性會小得多，「微服務」一詞就是來自於這種離散的功能設計。
透過將應用程式分解為實現特定業務功能的細項服務，微服務可為現代開發人員提供一種容易擴展且靈活的應用程式設計方法。
為什麼使用微服務？
微服務之所以越來越受歡迎，是因為它們的模組化特性帶來了靈活性、可擴展性，並能減少開發工作量。它們的部署靈活性，加上雲端原生無伺服器和功能即服務部署選項的興起，為微服務在當今 IT 環境中蓬勃發展創造了完美的環境。這些雲端平台使微服務和功能可以從靜止狀態、迅速擴展成大容量、然後再次恢復原狀，而客戶只需為他們使用的運算容量付費。
隨著企業不斷尋求更加敏捷、減少瓶頸、縮短應用程式遞送時間，微服務架構越來越受歡迎。
過去，公司開發的專業企業應用程式具有三個主要組件：
- 一個面對客戶的介面，通常是在使用者機器上執行的 HTML 網頁
- 一個資料庫，通常是關聯式資料庫管理系統中的許多表格
- 一個伺服器端應用程式，負責處理所有請求，像是資料檢索、HTTP 請求、填寫內容到 HTML 瀏覽器
對於使用者來說，一切似乎都是透過單一接觸點進行。開發、測試和部署使用的是部署管道，您還可以透過執行多個執行個體來橫向擴展。
但是，它們的開發成本很高，任何更改都需要重新設計、重建和重新部署整個系統。而隨著組織的發展和變化，其實很難保持乾淨的模組化結構。此外，無論修訂多麼小，擴展後都需要針對任何更改，對整個應用程式進行重新測試、調整、部署。所有這些問題最終導致了一個昂貴且回應不快的系統，而且這個系統很快就跟不上快速變化的技術環境了。
您可以將這些傳統的整體系統視為現成的玩具屋一般。雖然您可以編輯結構或佈局，但操作並不容易，而且您的整體尺寸受到限制，除非您購買另一個玩具屋並與原來的連接在一起。
使用微服務時，並不需要重新部署整個應用程式，而是只要重新部署需要它的服務即可。您可以將微服務視為一堆樂高積木，而不是像玩具屋這樣的單一結構體。從技術上講，每個微服務都是獨立的，但是將它們組合在一起時，就形成一個具有完整結構的應用程式。如果您想添加隔間或終止某些內容，可以輕鬆刪除、添加、擴大和編輯它，因此能快速有效地適應不斷變化的需求，而無需關閉整個應用程式。
微服務架構的好處
對於希望採用微服務並將其整合到產品中的企業來說，這種方式有許多顯著的好處，下文將對這一點進行更詳細的探討。
加快上市時間
能夠快速添加和刪除功能，意味著業務可以變得異常敏捷，因為可以快速添加新功能，所以更能跟上業務成長的步伐。與傳統的單體軟體不同，系統某一部分的程式碼更改不會影響到其他模組，因此無需額外測試、關閉整個應用程式、或重新部署所有內容。
提高功能性，降低營運成本
由於微服務中的模組都是獨立的，因此出現導致整個應用程式失敗的潛在問題或錯誤的風險就小得多。在傳統的軟體系統中，一部分功能的更改可能會導致另一部分出現缺陷或錯誤，但微服務的鬆散耦合可以實現分區升級和增強。它還允許使用雲端原生的功能即服務部署選項，進而顯著降低營運成本。
易於擴展的應用程式
微服務的擴展決策可以在更精細的層級上實施，因此能夠為系統優化做出最有效的決策。當需要擴大規模時，採用微服務的組織能夠立即做出最適合他們的選擇。
持續整合
微服務是使用單獨的持續開發和部署串流進行開發。這些串流可以長久保持流動，因此當一個團隊根據客戶意見進行任何更改時，另一項服務不會中斷，這意味著能夠提高最終使用者的滿意度。
專門的開發團隊
與無法同時有多個開發團隊的單體系統不同，微服務能夠支援團隊專注處理系統中的某些特定部分。由於軟體模組不彼此互動，因此不存在導致錯誤或跨團隊工作重疊的風險，使得不同微服務團隊可以擁有自己專門的軟體開發人員，各個團隊也可以跨不同時區或地理位置一起工作。
所有這些好處加起來，便獲得最重要的一個優勢：業務敏捷性。您可以快速進行小而簡單的更改，且更容易對流程進行實驗。微服務可以帶領業務巨大飛躍，或者快速應對發生的問題並即時做出反應。此外研究發現，在部署微服務架構的幾個月內，三分之一的公司組織就開始獲得競爭優勢，這意味著開發時程縮短了，程式碼錯誤減少了，功能增加了，對於業務營運的積極影響幾乎可以立即感受得到。
微服務的特點
- 鬆散耦合
- 可獨立部署的組件
- 自動化部署
- 去中心化的資料和語言控制
- 容易維護
- 易於測試
- 圍繞著企業或組織的需求和能力進行組織
- 每項服務往往由一個小團隊負責
微服務面臨的挑戰
雖然微服務確實解決了許多問題，但在架構以及最初應用時仍可能遇到一些困難和問題。
去中心化資料管理
與單體系統不同，微服務通常不依賴一個做為公司資料單一真實來源的資料庫，客戶資料可能存在一個地方，而供應商資料在另一處，也許庫存資訊儲存在線上銷售入口網站，但訂購系統保留在單獨資料庫中。這種情形可能會給您的資料品質和一致性帶來麻煩，除非您為此制定了具體的計畫。
企業文化與內部組織挑戰
讓公司接受和適應新的軟體系統可能很困難，通常管理階層可能不願意放棄控制權，或者某一部門為了他們的「孤島」行為辯解。無論團隊是出於什麼原因而抗拒接受新系統，最重要的是，有時人們就是不喜歡改變。
要在整個組織範圍內應用微服務，關鍵是先理解，引入新系統和流程可能會造成破壞，但同樣重要的是，也要明白這樣做的好處是值得的。在開始向微服務過渡時，最好在規劃架構時就讓受影響的團隊參與進來，共同制定計畫來評估可用的解決方案，並確保選擇最適合業務需求的解決方案。
微服務可能會導致您的架構變得複雜
雖然構成微服務的各項服務本身可以很小且很簡單，但組合在一起時，整個應用程式最終可能包含許多難以管理的移動部件。由於有成百上千個互連關係，微服務的複雜性會迅速增加。
建議在實施微服務時，就在設計和基本實施方案中進行徹底思考和規劃。良好的基本架構設計可以避免許多複雜性問題，該設計也有利於未來面對成長和變化。
微服務架構使用案例範例
採用雲端原生部署選項：利用無伺服器和功能即服務，來實現更高效和可擴展的運作。
從老舊應用程式移轉功能：將大型單體應用程式分解成細項服務，以便它們可以獨立維護和擴展。
利用現代化應用程式架構：採用事件驅動、鬆散耦合的微服務應用程式模式，就能根據使用案例需求來使用不同的編程語言。例如，使用運算量大的函數 Node.js 使 Web 應用程式變快。
DevOps 是什麼？為何微服務經常提到它？
DevOps 可以解釋為以工具為中心的概念，本質上，它是一組結合了工具和技術的實踐方法，目的是簡化開發人員所需完成的工作。除了改進工具之外，它也有助於營運和開發團隊之間彼此合作，以更快、更高效地完成專案。
例如，假設您正要建立一個允許使用者查詢其帳戶餘額的應用程式，在過去的應用程式開發週期中，這通常需要開發人員先建立應用程式，再將其交給營運團隊，但無需對最終結果負責，因為營運團隊的工作就是讓應用程式能夠順利運作。但在互動更緊密的 DevOps 環境中，雙方需要共同合作，這表示開發人員將從開始到結束，全程負責應用程式的生命週期，這意味著他們在發行期間也必須隨時待命。雙方團隊需要持續溝通，確保一切順利，然後您就可以充分享受到 DevOps 的好處（上市速度加快、開發週期更輕鬆、人員更加負責等）。
新的 DevOps 工作模式會帶來重大文化轉變，單靠使用新工具並無法讓 DevOps 計畫成功。如果您單純堅信新工具自動會使一切運行妥當，則很可能會影響成果。
基於微服務的特性，部署過程通常需要強大的 DevOps 程序支援，而增加工具使用和增強共享實務，有助於減少各項任務被任何細小、變動的內容所影響。您除了可以降低這種轉變的打擊或負荷，還能繼續享有微服務的諸多好處。
展望未來：事件驅動的微服務、無伺服器運算、功能即服務（FaaS）
當人們首次開始嘗試微服務時，他們通常預設使用熟悉的技術，例如 RESTful API，但 REST 的運作方式為請求-回應通訊類型，這種同步方法的問題在於，各項服務變得相互依賴，而您必須等待回應。這意味著，如果某項服務運行緩慢或沒有回應，則呼叫它的服務也會運行緩慢或失敗。這種耦合方式可能失去某些微服務架構的效益，因為它建立的結構使相互依存性提高，類似於服務導向架構 (SOA) 風格。
如果您使用 beyond-REST 或事件驅動模型來設計服務，則可以確保某些部分的應用程式繼續運作。其他部分可能不受影響，而不是整個應用程式都變得沒反應。Netflix 功能就是這一點的完美例子，您有時可能會發現「繼續觀看」按鈕消失了。這是因為某項特定服務變得不可用，但不表示整個 Netflix 停止，使用者仍然可以瀏覽節目和觀看預告。因此，即使 Netflix 可能不提供某一項服務，但其他服務還是可用的。
完全接受微服務方法的開發人員會意識到，真正的擴充性來自於鬆散耦合和事件導向架構。一項服務可以不與其他服務同步，它可以做某個動作、播送一條訊息，然後繼續執行原來的主要功能，而不必等待另一個服務的回應。
微服務的工作原理
微服務並不是一個新的想法。三十多年前，Unix 開發了一種 SOA，便是使用類似的設計原則，但實施成本很高，而且經常出錯，因此不被認為是企業的理想選擇。20 年後，微服務可達到更好的一致性，因此現在更有利於公司去應用。
至於微服務實際上是如何工作的，首先，軟體功能被分解成小的、獨立的模組，這些模組具有已定義的獨立任務。然後，系統透過應用程式介面 (API) 將這些小軟體連接在一起共同工作。
API 是讓兩個不相關的程式相互「對話」的程式碼片段，例如嵌入了 Google 地圖的應用程式或網站便是 API 的一個實際應用範例。一個 API 在 Google 地圖和應用程式之間來回發送資訊，允許使用者即時查看他們的地圖、向司機提供指示，並向您信任的聯絡人回報您的位置。雖然 Google 地圖仍然是一個獨立的實體，但 API 允許地圖和應用程式之間來回通訊。因此，您可以將 API 當做連接器來拼湊許多小樂高積木，而不是操作一個預製好的玩具屋，因為玩具屋裡一切都已經計畫好、僵化、難以改變。標準化的技術平台可能會導致一些限制，但並非每個問題都是釘子，也不是每個解決方案都是錘子，微服務允許您使用正確的工具來完成工作。
微服務具有一定的好處，成功採用微服務架構模型的公司已經從更快、更敏捷的業務 IT 結構中獲益。然而，有些組織卻認為該系統是生產力的殺手和營運的負擔，為什麼呢？成功與失敗的區別在於兩部分：組織的文化及其接受和使用微服務的意願，以及對微服務地圖的規劃和深謀遠慮。
通常，新系統需要很多年才能真正實現收益，而單體架構有時會在那些年裡變得過時或開始陳腐。但是，微服務很少會衰退，修補問題是一件簡單得多的事情。
解決這些潛在問題的一種方法是從單體應用開始，允許使用一個基礎軟體，讓您在擴大規模時將其他東西固定在上面，從而製作出一個具備樂高擴展性的玩具屋。雖然這可能不是最優雅的方法，但它是讓企業可以繼續推動下去的一種方式，尤其是在現有資料庫或程式處於營運核心而不得擅動的情況下。