微服務架構關鍵要素
良好的架構讓企業走在數位轉型之旅的正確方向、並且走得輕鬆…
一、 微服務化已經成為 IT 數位轉型的重要手段
雲端應用經過這幾年的探索與使用，伴隨著容器技術與容器平台(尤其是Kubernetes)的成熟，逐漸發現微服務架構開發與佈署程式的好處，於是紛紛開始改造傳統的單體式程式架構轉向為分散式微服務架構。
現代化企業應用服務採用微服務架構的優勢在於:
- 易於開發與維護
微服务相对小，易于理解 - 獨立部署
一個微服務的修改不需要協調其它服務 - 高彈性
每個服務都可按硬體資源的需求進行獨立擴容 - 與組織結構相配
每個團隊獨立負責某些服務，獲得更高的生產力 - 技術異構性
使用最適合該服務的技術，降低嘗試新技術的成本 - 企業環境下的特殊要求
去中心化和集中管控/治理的平衡，分散式和閉環資料模型的平衡
二、正確的架構是微服務實現的成敗關鍵
微服務需要的基礎架構除了微服務容器與容器管理平台(如 Kubernetes)主體系統之外，前端的服務治理(Service Mesh)與後端數據治理(Data Mesh)更是不可缺乏的關鍵系統，離開這兩個 Mesh 的治理，幾乎可以斷定微服務是完全不能落地為企業提供應有的效益。
我們打造微服務架構的時候，必須通盤考慮到現有系統過渡到新架構的平穩性。基於服務穩定性與客戶體驗的要求，微服務的遷移必須是漸進式而非暴力切換方式，我們相信在微服務上線後有相當一段時間會是新舊系統並存的狀態。在這種混合服務框架模式下(即便是完全過渡為微服務框架後)：
- 必須有一套良好的 API 管理方案來滿足各種各樣的服務請求調度
- 同時也必須有一套完整且彈性的資料供應方案來滿足各種各樣的資料請求調度。
三、以微服務APIM解決服務間東西南北向流量管理
APIM 雖然不是一個新的技術方案，我們在傳統的服務架構中已經大量運用 APIM 來治理外部服務請求及內部資料中心之間的服務流量。傳統的 APIM 產品生命週期管理也相當成熟。然而, 基於雲原生技術運行的微服務流量所需的 Layer-4 處理能力，卻是傳統 APIM 從缺的。
因此，服務網格(Service Mesh)方案成為了微服務新架構下必須具備的服務治理方案。但遺憾的是，現階段的雲原生服務網格並沒有提供圖形化的管理工具，維運人員只能透過大量的 YAML 配置檔與複雜的指令才能完成部分服務治理工作，這不僅嚴重影響到微服務的部署效率與可用性，也增加了人為錯誤風險。
寬橋的 PILOTWAVE (ATOMIC included) 是雲原生(Cloud Natvie) APIM 解決方案，提供圖型化介面讓使用者可以依照需求快速地建立 API 組態設定、部署 API、收攏應用程式成為 Composite Service，最後將 API 上線，一氣呵成的連貫性操作，讓管理流程更加直覺順暢，拋開繁瑣的 YAML 配置檔即可輕鬆管理大量的 Kubernetes 服務，包含流量控管、服務請求引導、安全加密、各類型的檔案與服務協定轉換、以及身分認證等各項功能，即時掌握服務狀態，同時也能管理並收斂既有的舊式內部各種服務。大幅降低維運時間，避開人為配置錯誤風險，提升整體 IT 服務供應品質。
3.1 PILOTWAVE 主要功能
- API 上下架：完整的 API 生命流程管理
- 資訊安全：符合金融法規各式要求
- API 版本管理：提供 API 版控避免錯誤發生
- 快速開發：結合 CI/CD 達成快速開發
- 服務網格：100% Service Mesh 相容服務變更：當 API 服務異動可進行相關處理
3.2 CLOUD NATIVE APIM 的兩大重點功能
1. APIM 連線管理
- 整合 SERVICE MESH
控管所有服務間（東西向及南北向）的流量和連線，形成服務顆粒度層級的網路連線管理架構，包括連線加密、API 授權、存取控管等機制。 - 動態控管流量
並轉移流量、調配流量分流比例到指定的後端服務進行處理。
2. API 封裝合成管理
- 支援高度客製化的動態 API 邏輯編排
並能連接整合來自容器、虛擬機或其他不同系統的資料和 API。 - 將 API 邏輯編排封裝成微服務容器
使其可依據流量需求快速橫向擴展或達成不斷線換版。
長期以來，APIM 的邏輯流程都必須仰賴具備程式設計能力的維運人員進行設計，這不但造成人才招募與養成的困難，同時也延宕了產品服務上線的迭代週期，對企業競爭力上造成負面影響。為了解決這個議題，寬橋的 API 封裝產品 ATOMIC 內建了圖形化微服務開發框架，即使維運人員未具備深厚的程式編寫能力，也能透過拖拉式視覺化 API 邏輯編排開發部署。
同時， ATOMIC 還具備以下的功能與特色，足以應付現代化應用服務的 APIM 管理需求：
- 可整合 CI/CD 結合 DevOps 流程
- 支援標準通訊協定：HTTP、TCP、WebSocket 等
- 支援多種資料格式處理：JSON、XML、CSV、YAML 等
- 支援基本檔案讀寫操作
- 具有更多模組擴充性，可支援資料庫存取、MQ 介接等可整合數據中台平台快速打造對外的資料存取 API
四、分散式資料架構解決分散式微服務即時資料供應
微服務實作流程中至為重要的階段是”解偶”階段，經過這幾年的探索與經驗累積，大多數開發團隊已經逐漸了解到微服務解偶的重要性，也慢慢掌握到其中的關鍵技巧，例如領域驅動設計(DDD)與事件驅動架構(EDA)等相關方法運用亦趨於嫻熟。然而，當人們將服務拆分到某一個程度之後，自然會發現傳統的中央式資料架構無法滿足分散式架構的微服務需求。隨著微服務上線數量越多問題的嚴重性就越加明顯，許多過往在傳統架構下未出現的各種隱性資料問題也就逐一浮上檯面。
2019 年 ThoughWork 公司的一位架構師 Zhamak Dehghani 提出了一個全新的去中央化的分散式資料架構，命名為 Data Mesh，這兩年被全球的資料權威廣泛討論到，一致認為 Data Mesh 是微服務架構下的理想資料框架，必將取代傳統的中央式資料架構。Data Mesh 為我們制訂了四項基本資料原則：
1. Domain-oriented decentralized data ownership & architecture
2. Data as a Product
3. Self-serve data infrastructure as a platform
4. Federated computational governance
對於全新的 Data Mesh 架構討論大部分仍處於早期的理論探索階段，雖然我們已看到一些資料公司正在嚐試將 Data Mesh 的概念融入其產品當中。然而，能完整實作 Data Mesh 四大原則的產品似乎還是雷聲大雨點小。
寬橋的 Gravity 是全新按照 Data Mesh 原則進行設計開發的分散式數據產品管理平台。
透過去中央化的 Mesh設計與資料庫私有化(Database per Service)以及資料快取快照、資料變更擷取(CDC)等先進技術，Gravity 可以隨意將資料節點部署到企業的任何分支與部門，將地端與雲端的數據孤島快速串聯起來，並以最短的路徑、最低的酬載、最快的速度將資料以產品形式即時同步到應用服務端的專屬資料庫。
在微服務的技術實作上，非常仰賴讀寫分離(CQRS)的資料技術支援。Gravity 完整的為微服務程式實作了讀寫分離的資料管線，並提供 API 大幅度簡化服務程式的設計。不僅如此，Gravity 還提供了一個共用型分散交易協調器(TWIST)，讓服務程式在盡可能少幅度變更的情況下處理掉分散交易的難題。
針對企業現代化數據治理議題，Gravity 也同時提供如下功能：
- 透過數據網格的 Data Catalog 機制呈現資料產品，資料網路的訂閱者，可以無需考慮原始資料所在，而隨選並訂閱所需要的資料產品。
- 使用金鑰進行資料的加密授權、存取驗證，確保資料的安全性。並符合台灣金融法規針對雲端資料供應的要求。
- 資料的交換不再需要大量的客製化，也可以滿足大量的資料取用需求，輕易的開放近乎即時的資料供外部系統、第三方系統所使用。
- 資料的流向都有紀錄，除了滿足監控與稽核的需求，也可應用於系統改善調整的參考，協助企業落實 DataOps 理念。
基本上，Gravity 針對資料的來源整合、資料彙整、儲存、處理、供應、消費等不同層階的需求，都預先為企業準備好應對方案，同時打通地端與雲端無間斷的即時資料同步。
此外，在微服務的程式設計上，服務之間的狀態同步逐漸從資料庫的讀寫抽離出來，訊息貯列(Message Queue)普遍被採納作為服務間的通訊規範。這些設計在相同領域(Domain)內非常容易實作，但在跨領域的場景中則需要一個訊息平台來處理領域間的訊息同步。
Gravity 除了在領域間提供即時的資料供應之外, 也能利用其內建的訊息叢集提供高可用的訊息同步服務，進一步降低微服務在全企業範圍內的實作難度，加速數位轉型的進程。
— — END — —
