軟體架構是軟體系統開發和實施的高層次結構。隨著軟體越來越普及和無所不在，不同的架構風格勢必會演變。在如此擁擠的街道上，微服務架構獲得了大量的關注和相關性。讓我們深入了解更多關於微服務、它們如何透過 API 進行通訊，以及像 Swagger 和 SwaggerHub 這樣的工具如何提供協助。
什麼是微服務？
微服務——也稱為微服務架構——是一種架構風格，它將應用程式建構成一系列鬆散耦合的服務，每個服務都實施業務功能。微服務架構可以持續交付和部署大型、複雜的應用程式。它還使組織能夠隨著時間的推移發展其技術堆疊、擴展並更具彈性。 微服務架構提倡將單一應用程式開發成一系列鬆散關聯的服務。這些單元還能夠持續交付和部署大型單體應用程式，而無需最小限度的集中化。 
（圖片來源：NGINX 部落格）
為什麼選擇微服務？
為了理解微服務的普及，理解單體應用程式很重要。任何應用程式都將包含一個客戶端介面、一個用於儲存和處理資料的資料庫，以及伺服器端邏輯。單體應用程式是作為一個單一單元建構的。在單體應用程式中，伺服器端邏輯以單體的形式捆綁在一起，所有用於處理請求的邏輯都在單一進程中執行。對此系統的所有更新都將需要部署新版本的伺服器端應用程式。 雖然市場上已經存在數千個成功的基於單體的應用程式，但開發團隊開始感受到如此大規模部署操作的衝擊。例如，在單體應用程式中，任何小的修改都與整個變更週期相關，而且這些週期總是相互關聯的。特定功能和模組的精細擴展也是不可能的，因為團隊必須擴展整個應用程式。 
（圖片來源：martinfowler.com）
為了克服管理、更新和部署應用程式（尤其是在雲端上）日益增長的複雜性，微服務架構的採用開始盛行。每個微服務定義一個特定的業務功能，並且只定義與此功能相關的操作，使其非常輕量且可移植。微服務可以部署在較小的主機中執行，而不必使用傳統架構的 RAM 和 CPU 資源。這些操作也可以根據使用案例使用不同的語言進行開發，因此可以在 Ruby 中建構一個留言板服務，而將它們傳送到不同使用者的服務可以使用 Node 建構。 以上所有這些都促成了基於微服務的架構的大規模採用，其中最突出的例子是 Netflix。
這是 SOA 嗎？
在應用程式中邏輯分離功能單元並不是一個新概念。最常見的比較形式是微服務和服務導向架構 (SOA) 之間的比較。我不會在此深入探討，但僅需說明微服務和 SOA 在許多方面有所不同。SOA 在介面層級上運作，旨在將功能公開為服務介面。這些介面使得在下一代應用程式中使用其資料和操作變得更加容易。SOA 的範圍圍繞應用程式之間介面的標準化，而微服務的範圍則圍繞應用程式層級。
微服務的缺點
與任何架構風格一樣，微服務也有一些缺點。一個很大的問題是將應用程式的整個業務能力分解為多個細粒度單元，在子業務單元周圍劃清界線可能很困難且棘手。定義不佳的邊界可能會對擴展應用程式產生負面影響。跨不同服務重複使用程式碼也很困難，尤其是在使用不同語言建構時。 追蹤執行各種服務的主機可能很繁瑣，並且可能會導致大量的混亂和資源支出，試圖將這些各種元件協調在一起。微服務架構也需要技術技能才能有效執行，對於習慣傳統應用程式工程形式的開發人員來說，這是一個很大的轉變。
容器如何提供協助？
微服務架構的採用導致需要克服其一些缺點。這促進了容器生態系統的興起。容器是一種作業服務虛擬化形式，它允許各種服務在獨立於資源的單元中執行。Linux 容器使用核心介面。核心是作業系統的核心電腦程式，也是在啟動時載入的第一個程式。 
（圖片來源：wikipedia）
容器的組態允許多個容器共享同一個核心，同時獨立運行，彼此之間互不干擾。作業系統虛擬化使得程式碼的傳輸和部署效率更高，甚至比僅虛擬化硬體的傳統虛擬機器更高。Docker是最流行的容器技術，並且在很短的時間內就成為數千個應用程式中使用的標準基於 Linux 核心的容器。 同一個主機上的容器之間的獨立性使得部署基於不同技術和框架構建的微服務變得非常容易和直接。容器的可移植性和輕量性對於微服務的部署也是很好的優勢。 為了解決微服務管理的問題，各種容器管理系統應運而生，以便更好地管理和協調這些容器，以及配置和管理整個叢集伺服器。這裡有一篇很棒的文章比較了一些流行的工具。
API 的作用
我們知道微服務是獨立維護的組件，它們構成一個較大的應用程式。我們也知道容器是部署它們的好方法。微服務和容器使用行程間通訊 (IPC) 機制來彼此互動。這些互動可以是
- 一對一，其中客戶端請求由一個服務處理
- 一對多，其中客戶端請求由多個服務處理
如果 IPC 機制涉及請求-回應週期，那麼最常見的通訊方式是 RESTful，它幾乎總是使用 HTTP/JSON API。用作微服務之間 IPC 的 API 與傳統形式不同。這些 API 更精細。由於公開微服務的 API 公開了細粒度資料，客戶端可能必須遵循服務之間的一對多形式的互動才能獲得所需的資料。 
（圖片來源：IBM developerWorks）
例如，假設您正在按照微服務模式構建一個電子商務網站。一個正在銷售的產品的完整圖像可以透過多個服務來呈現，例如一個公開基本產品資訊（如標題和描述）的服務、一個公開價格的服務、一個導出評論的服務等等。希望獲得產品完整資料的客戶端現在必須呼叫所有這些服務。在多設備生態系統中，不同的設備可能需要不同的資料，例如桌面應用程式可能需要比行動版本更詳細的資料。
微服務的設計優先方法
我們已經討論過 API 如何成為各種服務彼此通訊的最常見方式。為了透過 API 更好地公開服務，需要有一個通用的 API 介面來明確指出每個服務應該做什麼。此介面是一個合約，定義了客戶端和服務之間的 SLA。 OpenAPI (Swagger) 規格已成為定義此合約的標準格式，它既可由人類讀取，也可由機器讀取，使得服務更容易有效地溝通和協調整個應用程式。 微服務架構主要是一種企業級的運作方式，因此，必須優先處理公開微服務資料的 API。許多組織採用了設計優先方法來構建微服務，這涉及首先設計和定義微服務的介面，審查和穩定這個合約，然後才實作服務。設計優先方法可確保您的服務在任何實際開發發生之前，就符合客戶端的需求。 以下是採用 API 設計優先（或 API 優先）方法的一些關鍵考量：
上市速度
微服務本質上是內部的，旨在盡量減少計算能力和使用時間。這同樣適用於公開它們的 API。因此，自動化這些 API 的設計、文檔和開發對於實現快速 API 交付率至關重要。Swagger 介面不僅定義了客戶端和服務之間的共同 SLA，它還允許產生伺服器和客戶端模板以及測試案例，使開發和測試過程變得更加容易。 諸如 SwaggerHub 之類的專業工具，它提供了用於智慧設計的智慧 API 編輯器和用於加速 API 設計交付的 Domains，可以幫助您的 API 實現快速上市速度。
彈性協調
我們談到了公開微服務的 API 如何具有細粒度和精細度，這意味著需要特定實體資料的客戶端應用程式可能總是需要呼叫多個 API。處理基於微服務的應用程式的資料交換複雜性是一個巨大的問題。 處理多個服務請求的解決方案是實作一個 API 閘道，該閘道可以透過單個入口點處理請求。由於閘道的基本 API 合約上的每個 API 都在 OpenAPI/Swagger 規格中定義，因此透過 API 閘道從設計階段有效轉移到部署階段變得非常容易。SwaggerHub 與 AWS、Azure 和 IBM API Connect 等 API 閘道的直接整合，是專為希望有效協調這些請求的組織而設計。
負責任的設計
多個團隊構建不同的服務可能會很棘手。不僅管理您的人力資源很困難，而且當這些團隊開始開發服務的介面時，情況可能會變得更加複雜。當多個團隊定義和構建 RESTful 介面時，URL 結構、回應標頭和請求-回應週期物件中的設計模式分歧是一種非常常見的情況。 由於介面定義了客戶端和服務如何互動，因此設計上的差異會導致服務開發階段的混亂和開銷。修復此問題只會導致資源支出，形式為時間、金錢和人力資本。 可以使用 SwaggerHub 的兩個核心設計功能來克服這個問題：Domains 和 Style Validator。Style Validator 確保您的 RESTful 介面符合基於您組織要求的標準藍圖。這可能意味著確保所有介面都具有駝峰式運算符、在其回應封包中定義的範例，或具有在本地定義的模型。 在 Domains 中，您可以儲存通用的、可重複使用的語法，無論是模型還是請求-回應物件，都可以在公開您的微服務業務功能的多個 API 中快速參考。這使您可以對您的 API 風格採取更細緻的方法，為公開您的服務的所有 RESTful 設計提供一個控制中心。Domains 和 Style Validator 是 SwaggerHub 獨有的，可確保在構建服務 IPC 時保持設計一致性和快速上市時間。
網路研討會：將企業轉型為 API 平台的經驗教訓
您的數位轉型工作是否將您的業務引向正確的方向？4 月 10 日，我們將舉辦一場免費的網路研討會：將企業轉型為 API 平台的經驗教訓。本課程重點介紹了在與酒店、貸款發起和金融科技等各個組織合作開發和部署其 API 平台時吸取的教訓。這些企業實作了 API 優先設計、聯合治理和 API 管理層，作為其整體平台策略的一部分。我們將探討哪些方法有效、哪些方法無效，以及簡化您的轉型計畫的技巧。將討論的主題
- 開發有效的 API 程式，以促進內部重複使用和蓬勃發展的合作夥伴計畫
- 實作 API 治理的技術，包括探索集中式與聯合式治理
- 微服務和模組化軟體設計如何改變當今企業的文化
- 透過開發出色的入口網站和開發人員支援流程來增加 API 的導入和採用
- 透過以 API 為中心的企業方法來加速您的轉型計畫的提示
立即註冊 