淺談微服務架構的資料快取和發佈策略
只要別亂動我的資料庫，你想怎麼做都可以！
包括我們的客戶、無數企業、開發者和決策者，為了數位轉型、IT 轉型，試圖在將來導入微服務架構。這些日子做盡一切努力，花了大錢打造 Kubernetes 容器基礎設施、更複雜且更具規模的監控管理機制，大刀闊斧改造組織、開發流程，甚至不惜打掉重練幾十年來的軟體架構。
軟體開發人員更是痛苦，學習了種種新的開發流程和規範、新的開發工具以及新的架構概念，還要學習和研究種種設計模式、協定、技術方法，暸解了理論，還要煩惱實作議題，在實際應用面與架構實作上，顧此失彼。
令人難過的是，無論如何努力，永遠有更多的陷阱、更困難的議題在前面等著，這條路上走得戰戰兢兢，不只是沒有把握，也讓所有參與者、尤其是第一線的開發人員痛苦不堪。
到底導入微服務的關鍵問題是什麼？是什麼讓所有人都這麼痛苦？遲遲無法讓容器變成微服務，而讓所有微服務顧問都束手無策了？
我們都不願意面對的「資料」議題
其實大家都知道，最困難的問題關鍵就在「資料（Data）」之上，但說什麼就是不願意去做、不願意去拆分解耦，因為更動資料的結構和管理方式，意味著要承擔許多風險，對企業來說更是一個莫大的賭注。這資料解耦心臟手術，誰都不可能會輕易去動。
所以，無論我們怎麼談論資料解耦、拆表拆庫、資料庫私有化（Database per service）、事件溯源（Event Sourcing）還是 CQRS（命令與權責分離），都只是紙上談兵，沒有人真的願意好好落實。更別說這些微服務架構常見的設計模式和技術，往往都需要開發人員大量投入，其複雜的各種機制和架構，都足以讓開發人員頭大，可否一人得道雞犬升天不說，一步錯則萬劫不覆是明顯擺在眼前。
但是不處理資料議題，微服務架構又無法正確實現，錯誤的實現方法，又會帶來更多效能問題、管理問題、開發複雜度問題，甚至不如舊的軟體架構。這矛盾之處讓所有人頭痛不已，不面對也不行，面對也不行，而動彈不得。
只要不隨便動我的資料庫，什麼都可以！
你應該已經聽不下去微服務的種種設計模式和理論，早就對 CQRS、Event Sourcing 和 Database per service 等至高原則感到厭煩，因為，在你的眼中，這幾乎不可能在既有的企業架構中實現。動你的資料，就像要了你的命一樣，更多時候可能是要了整個技術團隊的命，甚至連你老闆的命都拖下水。
以「別隨便動我的資料庫！」為前提，到底有什麼方法或策略？所有人都想知道答案。
幸運的是，在過去幾年的微服務顧問經驗中，我們確實發現有方法，可以讓企業無需直接對資料庫開刀，就能滿足大部分微服務架構上對資料機制上的需求。尤其是對於初入微服務的企業來說，是一個無痛且可以接受的選項。
而這個答案，就是從「資料快取和發佈策略」下著手，實現微服務的資料快取和發佈平台。
微服務的資料快取策略（Caching Strategy）
到底如何以資料快取策略，來滿足微服務架構的需求，可以從前端（Frontend）發展史發現端倪。在前端獨立化、甚至微前端化的今天，我們應對不同需求、來自不同地區、不同瀏覽器、不同裝置甚至是不同頻寬速度的方法，仰賴的不再是單一或特定的 Server 及來源。而是依賴著 CDN 進行前端資料和內容的發佈，將前端所需的內容，依終端的需求，切片並發佈到適合的內容提供 Server 身上，這些 Server 所在位置甚至遍佈全世界。
我們回頭看微服務架構，分散式架構下，其實也需要類似的機制，將資料依照目標服務的需求，發佈並快取於其最近的資料庫之上。只是，在後端的微服務架構下，這個發佈和快取會更複雜一些，除了需要支援更多的資料源、資料庫類型、不同的訊息佇列系統，也需要能滿足雙向及多對多的發佈和快取需求。
若要更完善的考量，甚至要考慮發佈的「延遲（Latency）」程度和「吞吐量（Throughput）」，實現平行分流的架構和技術。如果能跟容器平台做最佳的整合，實現容錯、橫向擴展和動態部署，更是最佳的策略。
此外，每個快取管線也需要更迅速敏捷的部署、更容易的管理。
巨量且多方資料快取管線的部署和維護是關鍵
可以說，巨量資料快取管線或是資料發佈管線，能支撐著微服務所需的資料供應，伴隨著微服務的敏捷開發及上線速度，這些成千上萬資料管線的部署效率和維護容易性，勢必就是微服務架構成型的關鍵所在。
此外，在微服務架構的巨量服務交織之下，多方資料來源的發佈和快取，更是一件不容易的事，若是沒有一個宏觀全局的設計，在開發設計微服務架構時，光是資料格式、同步頻率和通訊協定的統一，就足以讓來自不同服務、應用的開發人員吵翻了天。一點點事件或是資料格式的修改及調整，哪怕改動幅度極小，都會直接摧毀相關的其他服務。
因此如何部署和維護這些資料快取和發佈管線，已經超出微服務架構設計模式的議題，更是一個管理議題。
妥善的發佈機制能解決微服務資料分享議題
所有的快取資料，都是依照目標業務和服務的需求建立而成，除了只發佈「必要」的資料外，也意味著使用快取的服務，可以用最省力、快速的方式去取得資料。而且，因為已經與最原始的資料源或資料庫獨立，所以原始的資料源有任何異狀或改動，並不會被直接影響。
另外，若是在快取管線中，引入了過濾器機制，甚至可以實現去識別化、安全掃描等工作，減少敏感資料和重要資料的安全問題，未來可以更容易沒有疑慮的與第三方系統及混合雲進行串接整合。
微服務仰賴快取管線的規模和部署效率程度
要實現微服務架構所需要的資料發佈機制，其實並不困難，困難的是一般企業有多少資源可以專心處理這件事，將其變成一個通用、易用的元件和架構。或是讓原本應該專心於應用開發的技術人員，浪費大量心力去照顧這些與應用毫不相關的複雜機制。
說穿了，這些機制其實就是微服務架構中常聽到的事件溯源（Event Sourcing）、CQRS、訊息佇列（Message Queuing），以及介接傳統的事件架構（EDA, Event-Driven Architecture）、資料事件擷取（CDC）、資料抄寫（Replication）及大數據中常講的 ETL。但整合設計是一件事，整合起來後維護、部署、擴展又是另一件事，以及其吞吐量、資料同步效能更是完全不同領域的事。
苦命的應用開發人員花了大量時間照顧這些需求和機制，還有足夠餘裕去落實實際應用嗎？之所以很多企業遲遲無法真正落實微服務架構，其根本原因就是會花太多時間在摸著石頭過河，而且每一個應用、服務，都要重新過一次河，相當痛苦。
因此，一個能夠敏捷部署的微服務資料快取和發佈平台，就是微服務快取策略下必要的元件。
你需要的資料快取和發佈平台 Gravity
應用瞬息萬變，引入敏捷開發，目的也是為了要因應多變的業務需求，不同的業務也需要不同的資料供應，唯有能敏捷部署的快取管線，才能跟得上微服務的發展。要實現這樣的架構，必須採用 Ambassador 模式，去實現資料快取平台。
為此，我們寬橋（Brobridge）琢磨了兩年，在顧問期間從客戶的苦水和哀號中找到痛點和需求，投入實現了 Gravity 解決方案，期望讓客戶的開發人員從微服務資料管理的地獄中得到自由。
功能特色如下：
- 部署即用，免開發
- 特殊平行管線分流技術，低延遲、高吞吐量
- 可透過 YAML 敏捷部署多路快取
- 可擴充支援多種事件來源和 MQ 通訊協定（Kafka, NATS, RabbitMQ）
- 可整合外部 CDC 資料源
- 可同時支援異質資料庫系統（MySQL/PostgreSQL/Oracle/MSSQL/MongoDB 等）
- 支援事件遺失容錯和資料還原
- 內建事件來源 (Event Sourcing)
- 內建資料快照 (Data Snapshot)
- 可客製化事件與資料過濾規則
- 與 Kubernetes 高度整合，支援快速橫向擴展
Gravity 未來衍生的更多應用場景
微服務架構的資料議題，在引入資料快取和發佈平台之後，只是開始，解決了微服務的資料共享和吞吐量議題後，未來還有混合雲、跨第三方應用等需求在等著。但不用擔心，因為只要快取資料管線足夠完整，且容易部署和管理，這都將不會是問題。
會搞砸，別把交易機制和資料議題混為一談！
最後提醒，過往經驗中，想要利用一套方法，要把交易機制和資料管理議題一次解決，通常不會有什麼好下場，其交織的複雜度遠不是一般開發人員能夠輕易掌握。很多技術人員在微服務之路上的疑問和瓶頸，往往是因為想不透「大統一理論」而越走越偏，或是將整個架構搞得過於複雜。
所以最理想的情況下是「分部處理」，先處理資料發佈和快取機制，讓大多數微服務架構能夠成形，並能於實際應用上發揮作用，然後再來面對和處理交易機制的問題。而關於交易機制議題，我們寬橋有 Twist 分散式交易解決方案，這就是另外一件事了。
本文資料，來源為 Kubernetes Summit 2020 的 Keynote 議程「迎接後容器時代，微服務該如何大步前行」簡報內容，其細節參考自 寬橋（Brobridge） 的微服務架構設計顧問材料。如果想要暸解更多關於微服務架構設計的議題，可以與我們聯絡。若對資料快取和發佈平台 Brobridge Gravity 及其資料解耦的議題感興趣，也歡迎與我們接洽。
