微服務 MicroServices 容器 K8S DDD API Gateway DevOps

微服務生態系簡介

彭福彬 Willie Peng 2021/05/26 11:27:47

3 2816

一、微服務是什麼?

微服務是一種軟體設計與開發的方法，將應用系統拆分成各自獨立的數個服務，這些服務透過API介面來存取或彼此溝通，並藉由單一服務或多個服務之間的合作來提供應用系統所需的功能。採用微服務方法來建構應用系統，能帶來許多效益，例如系統能更彈性地因應功能變動以及功能之間不會輕易受到彼此影響等。

為了要真正發揮微服務的效益，從服務切分、API設計、軟體封裝運行到開發維運流程與團隊規劃，其實有許多需要搭配使用的軟體、技術與流程，這些圍繞在微服務周圍的部分，形成了一個微服務的生態系，同時也對於微服務系統能否成功建置扮演了重要的角色。如下圖所示，本文將從容器、API、DevOps、資料與人等5個面向來談談這個微服務的生態系。

資料來源 : 作者整理

二、容器

容器是一種封裝與運行軟體的技術，微服務通常會搭配容器技術，這是因為容器具有以下主要特性，讓微服務效益能夠更加展現出來 :

A.容器間各自獨立，不互相影響

B.能快速部署、調整個別功能

C.所佔資源小，啟動速度快

Deployment evolution

資料來源 : Kubernetes

1.Docker與Kubernetes(K8S)

目前最知名的容器技術為Docker，我們會透過Docker的映象檔(Image)來產生各式各樣的容器，並封裝我們所需要的軟體或微服務。當使用容器技術來封裝微服務時，會需要建置容器叢集來組織各個容器與其中的微服務，目前最主流的技術則為Kubernetes (簡稱K8S)，這是一個容器的編排系統(Orchestration)，讓我們可以有系統化的建立與管理的容器叢集。

資料來源 : Kubernetes

2.OpenShift(OCP)

為了更便利地管理容器叢集，有廠商推出商業版的容器管理軟體，例如Red Hat 公司的OpenShift (簡稱OCP)，這些軟體大都以Kubernetes為底層核心基礎，再增加許多套件與功能，並提供視覺化的管理介面與報表功能，讓容器叢集的建置與管理能更加便利。其他例如HP、VMWare等公司也有類似的軟體產品。

三、API

微服務的存取操作是透過API來進行，也就是前端程式(如App或Web)會透過API 來呼叫後端的微服務，以取得所需資料或結果。一般來說，前端程式會需要呼叫多個微服務來完成所需的功能，

1.API Gateway

為了避免後端微服務異動也連帶對前端程式造成太大影響，通常會建置獨立的API Gateway 來作為統一的進出端口，負責轉發或合併多個API 執行呼叫，再統一匯集起來傳給前端程式。這個的作法除了能保持架構彈性，更方便管理，也具備更好的安全性。此外，若有多個前端程式 (或用戶端)，也可建置多個API Gateway，分別擔任各前端程式(或用戶端)的進出端口，這樣的架構稱為「Backend for Frontend」(BFF)，如下圖所示，mobile app 是透過API Gateway-Mobile 來呼叫後端的微服務，Web app 是透過API Gateway-Web 來呼叫後端的微服務。對微服務來說，API 扮演了非常重要的角色，所以在建置微服務系統時，也會一併考量API管理議題(APIM)，並導入APIM軟體來管理各微服務的API，並擔任API Gateway的角色。有關APIM，請參考https://www.tpisoftware.com/products/digirunner。

資料來源 : 微軟

2.領域建模

當我們要使用微服務來開發應用系統時，往往首先要面對的問題時 : 「我的系統應該要有哪些微服務?」，也就是說，一個微服務的功能內容與涵蓋範圍要如何定義與切分。目前最常被使用的方法是Domain-Driven Design（領域驅動設計，簡稱DDD），提供了一套可以系統性的方法論，讓我們可以進行領域建模，也就是透過DDD方法，最終我們可以針對想開發的系統去切分出數個領域，每個領域中有多個Bounded Context (BC)，每個Bounded Context 中有聚合、Entity、Value Object(VO)或Event等，並定義出Bounded Context之間的關係與溝通方式，進而針對Bounded Context去設計微服務。對微服務而言，DDD提供了一種系統拆解的方法，讓我們知道要設計的系統中，應該包含哪些微服務。

資料來源 : https://resources.sei.cmu.edu/asset_files/Presentation/2019_017_001_546253.pdf

四、DevOps

當應用系統以微服務方法來設計與開發時，整體系統會由數個甚至數百個以上的微服務所組成，每個微服務也可能由不同人員或團隊以不同的技術所開發，相較於以往的單體式架構，其實在作業與管理上的複雜度是變高的，也就是在作業面上必須要讓每個微服務的程式碼能要被正確且有效地管理、打包、測試與整合與部署，我們才能真正享受微服務架構所帶來的好處與效益。因此，若能有更系統化、標準化與自動化的作業流程與機制，將能讓我們更加專注在為服務的整體設計、服務切分與API開發。

DevOps相關軟體與技術的出現，剛好可以運用在建立這樣的作業流程與機制。DevOps設計的核心概念是通過自動執行“持續整合（CI）”和“持續部署（CD）”的自動化流程來解決開發團隊和維運團隊之間的問題，從而可以快速，頻繁且可靠的構建，測試和軟體發佈。也就是說，我們可以建立CI/CD Pipeline，將原始碼管理、編譯、打包、測試、整合與部署等作業標準化，並透過系統化的軟體工具來執行，儘量將可自動化的部分透過這些軟體工具來執行，常見的軟體工具包含Git、Jenkins、ANT、Maven、SonarQube、Selenium、Appium等。

五、資料

當我們把應用系統的功能拆解成數個微服務時，同時也要思考資料面應該如何重新調整與切分，若是所有資料仍是混合在一起，也無法真正發揮微服務的效益。以微服務的方法，每個微服務會有自己的資料模型與資料，也就是所謂的資料庫私有化(Database per service)，每個微服務的資料只能透過該服務的API來存取，且每個服務的資料都可以獨立地擴展。

資料來源 : 微軟

1.Message Broker

當微服務間的資料需要進行溝通、交換與傳遞等動作時，Message Broker (或稱為Message Queue、Event Bus)是常見的作法之一，透過事件發布與訂閱的機制來完成資料的傳遞動作，微服務可以發布事件資訊到Broker，有訂閱事件的微服務就會收到事件資訊，並進行後續的資料處理，常見的軟體包含Apache Kafka、RabbitMQ與IBM MQ等。

資料來源 : https://dzone.com/articles/communicating-between-microservices

2.Log

應用系統通常會產生日誌 (Log)，以便於紀錄與追蹤資訊。當我們使用微服務方法來建構系統時，每個獨立的微服務可能會產生各自的日誌，這樣的狀況可能會造成後續的管理困難，例如當有需要查詢多個微服務的日誌時，會需要耗費大量時間去蒐集、匯整與比對。因此，在以微服務建構應用系統時，也應一併考量建置一個集中式的日誌管理系統，來統一蒐集與管理各微服務的日誌。且因為應用系統往往會呼叫執行多個微服務來完成一個功能或交易，所以若需要追查問題，也會需要查詢多個微服務的日誌，甚至是依照執行微服務的順序來查詢與追蹤。若要建立這樣的集中式日誌管理系統，請參考https://www.tpisoftware.com/media-center#media-banner。

資料來源 : 微軟

六、人

當我們運用微服務方法來建構應用系統時，除了要掌握各種DDD、API Gateway與K8S等方法與技術，另外就是要組成一個團隊，遴選具備各種技能的成員來擔任不同的角色，並建議透過Agile (Scrum)方式來進行專案。尤其是對初次使用微服務的人員與組織，更會涉及到新方法 (如DDD)、新技術 (如K8S)、與新流程 (如CI/CD)的導入與建置，並考量如何提供現有人員的技能，以及是否需要外部顧問的專業協助等議題。有關微服務專業顧問，請參考https://www.tpisoftware.com/。