隨著雲端服務興起，微服務技術也正興起，由於在程式設計方面具有高度彈性與獨立性，受到網路服務商與雲端服務業者歡迎，尤其隨著數位轉型以及疫情浪潮影響，利用微服務提供遠端服務、線上服務模式逐漸受到中小企業矚目。
自從雲端運算開始發展以來，減少成本、增加彈性一直是雲端運算努力的方向。隨著雲端技術愈發成熟，如容器(Container)技術，讓開發者可以更容易隔離各程序的運作，進而促成具備高度調整彈性的微服務興起。
具體來說，到底什麼是微服務？微服務是一種軟體的架構形式，概念是將原本龐大的應用軟體，改由多種如樂高般的微小服務組合而成，共同完成最終的應用目標。每個微服務可看作一個能獨立工作的小型功能，能與其他微服務進行鬆散的連結。微服務間的連結可以透過應用程式介面(API)，例如：REST(Representational State Transfer)、JSON(JavaScript Object Notation)等服務介面進行連結。
微服務和傳統的架構有何不同，可以參考下圖傳統單體架構(Monolithic Architecture)與微服務架構(Microservices Architecture)的示意圖(圖1)。
圖1 傳統單體架構與微服務架構
單體應用服務架構將使用介面、商業邏輯、資料處理等功能進行一齊開發與部署；而微服務架構則將整體服務拆成更小的功能，個別進行開發、部署與連結。
比較傳統單體式服務架構，微服務架構的優點是具有專注特殊任務、鬆散式連結、程式語言與業務邏輯獨立等特性，意味著可以容易根據商業需求對微服務各自進行維護修改、資源擴展、容錯獨立等，使得應用服務更具彈性以適應變動商業需求。
但缺點是微服務的設計複雜度高、大量微服務間的整合困難、過多微服務影響應用服務整體運行效率、需要良好的軟體架構師設計等。所幸現在許多開源軟體開發工具，以及雲端廠商的各項服務支援，使得微服務的複雜性不斷降低。
在成本方面如同雲端服務，微服務的初始成本將會較高，隨著營運量愈大而降低成本。這也是為什麼微服務大多設計在雲端運算平台上，或是用於大量需求的服務。
微服務特性
微服務與傳統服務架構的不同，在其特性是包括專注特殊任務、鬆散式連結、程式語言獨立、業務邏輯獨立。
專注特殊任務
微服務應該能設計可完成單一工作，並盡量地微小。當然，並沒有一個規則能夠定義微服務應該多微小，端視軟體架構師與商業需求決定，如：訂單訂購任務。過多微服務才能完成單一商業任務，也可能影響整體運作效率。
因此，根據商業需求進行微服務的設計是一種軟體架構的藝術。例如：Amazon採用微服務架構的電子商務系統，將其商品目錄、訂單處理、庫存查詢、運送服務等服務設計為不同微服務，各自獨立完成各項商業需求。
鬆散式連結
每項微服務應該是各自獨立並鬆散的結合。這意味這某個微服務進行版本修改、編譯、重新部署時，不會影響其他微服務運作。這項特性也可以使得微服務能更快速地修改與升級，以滿足變動的商業需求。
程式語言獨立
不同微服務間可以透過API、REST等標準介面進行訊息傳遞，意即每個微服務可利用不同程式語言開發，而不會互相影響。
業務邏輯獨立
微服務間不應該有業務邏輯上的依賴，影響微服務專注特殊任務或是影響升級修改作業。例如：避免庫存查詢服務會受到使用權限功能更新影響，就應該把使用者權限、庫存查詢分為不同微服務。
從應用上來說，最早期發展微服務的是網路服務商，如：Amazon、Netflix、淘寶等服務商。在Amazon、IBM、Microsoft等雲端服務平台大力提倡微服務發展與運行後，許多企業亦開始考慮以微服務方式設計顧客、夥伴、創新業務等應用服務，以滿足快速發展、彈性擴展、便利維護等需求。
舉例來說，聯想電腦近年來極力支持「穩態」、「敏態」的「雙模IT」混合雲模式。所謂「穩態」主要指的是ERP、MES、PLM等傳統企業軟體，仍然以單體式架構、傳統或私有雲部署方式存在；「敏態」則是將微服務架構，應用在電子商務、行銷管理、線上智慧客服的開發部署。 此外，微服務微小的特性也適合運行在計算資源較低的智慧手機、物聯網設備上，使得許多物聯網服務商，如：GE、Siemens、Microsoft，這些廠商都積極地推廣微服務的應用。使得微服務成為支持製造業朝服務化、數位轉型發展的技術架構之一。
微服務將應用服務切割為專注特定功能的微小服務，而支持其運作環境的即為「容器」技術。
容器技術應用在微服務
藉由虛擬機器技術(Virual Machine)，應用系統在客戶端作業系統上運行。而容器技術則讓微服務運行在容器引擎中，載入作業系統函式庫的負擔更小。但與此同時，微服務分享的函式庫愈多，管理便會更複雜。此外，如果不同容器、不同虛擬機器的微服務訊息要傳遞，會使管理更加複雜。
所幸，許多雲端服務商、開源廠商發展容器技術架構，因而簡化這些管理上挑戰。其中Docker就是一個廣為使用的開源容器技術架構，協助將微服務應用程式容器化開發與部署。許多雲端服務廠商基於Docker提供相關容器化服務，如：AWS、Google、Microsoft雲服務。
例如AWS提供Amazon EC2 Container Service(ECS)，可以協助微服務的開發、運行、部署與管理。Amazon ECS服務奠基在Amazon EC2虛擬機器IaaS雲端服務上，建立微服務運行的容器執行緒(Container Instance)。用戶建立微服務並在Docker容器上執行，每個微服務同時有許多工作在執行，每個工作都占有CPU、記憶體資源。使用者可定義執行時間、可擴展性以及負載平衡等。
如果用戶發現單一工作執行服務的效率太差，可以擴展多個工作執行，甚至可以要求工作在不同的虛擬機器上面的容器執行緒上執行。因此，微服務可以容易地擴展、進行叢集運算以及備援。ECS Agent負責協助容器建立、排程、叢集運算等，向Amazon ECS服務要求分配虛擬機器上的資源。Amazon ECS的服務定價基於用戶運用微服務執行所消耗的CPU、記憶體資源與磁碟空間。
Microsoft基於Azure雲端服務平台，建構Azure Service Fabric架構，其包含幾個重要元素：Service Fabric Cluster用來部署與管理微服務在跨網路的虛擬機器上進行叢集管理；Virtual Machine Scale Sets可以設定群組，進行虛擬機器負載平衡，或自動擴展不同資源，也提供容錯與升級管理；服務(Services)可以包含無狀態與有狀態服務，無狀態服務並不保持服務運行資料儲存，當需要時可將資料儲存在資料庫服務中；Azure Pipelines可以提供開發者建立、測試、部署等工具；Azure Monitor可以蒐集與記錄微服務運行狀況；Azure API Management則是微服務的API呼叫介面，可作為閘道器，將客戶端需求轉到適當的微服務上。
如何讓微服務間有效率的協作，是確保微服務良好運作的關鍵。支援微服務的平台，具備以下微服務協作技術。
Orchestration協作資源配置
微服務分散式運行在不同虛擬機器、容器上，以減輕單一虛擬機器資源的負擔。也可讓微服務的臨時高用量需求，擴展到不同容器、虛擬機器上運行。
Google Kubernetes是目前最熱門的微服務協作的開源軟體，暱稱為K8s。K8s架構主要分為Master與Node兩部分，Pod為運行容器的最小單位，當中可以運行多個容器，每個容器中以緊密相關服務運行為規畫原則。透過K8s可以讓應用開發者更容易因應流量狀況進行自動擴展、負載平衡、錯誤偵測、錯誤復原管理等。
其他類似Kubernetes的軟體包含Docker Swarm、Apache Mesos等。雲端平台也提供「Kubernetes-as-a-service」的服務來提供開發者使用，如： Amazon EKS、Google Cloud Kubernetes Engine、AKS(Azure Kubernetes Service)等。
API Gateway呼叫服務
API Gateway是一個API反向代理程式，可以讓外界應用程式或微服務，透過API程式介面存取微服務。一般來說，API Gateway具備認證、資安政策、負載平衡等功能，以滿足外界使用微服務的需求。常見的API Gateway包含Amazon API Gateway、Microsoft API Gateway、Ambassador、Kong開源軟體等。
Service Mesh服務網格
Service Mesh主要用於協助服務與服務間溝通，滿足服務間負載平衡、服務呼叫繞路規則、重試、錯誤管理、安全控管等，使微服務整合起來，提升整體應用程式效率。Service Mesh的做法是在每一個微服務中插入sidecar代理程式，服務間的呼叫先透過sidecar代理程式，確保網路效率、熔斷等機制，再呼叫微服務。著名的Service Mesh軟體包含：Istio、Linkerd。
隨著數位轉型以及疫情浪潮，遠端服務、線上服務模式受到更多企業矚目。相較於許多大型企業，重視IT人員快速發展新服務與網站負荷過重的解決方案，中小型企業的重點，則重視如何將微服務應用在創造新商機、發展新商業模式。
(本文作者為資策會產業分析師)