遠離錯誤的微服務資料庫架構設計
落實微服務的資料庫私有化(Database per service)
坊間討論微服務的文章和演講相當多，到處都在強調微服務必須實現「資料庫私有化（Database per service）」，甚至有文章直接講類似的話：
「如果你正在使用共享資料庫，那你可能沒有把微服務做對。」
資料庫架構設計議題，對於微服務架構來說非常重要，錯誤的設計會導致錯誤的微服務架構，最終得到滿是問題的結果，甚至比不採用微服務架構之前還要糟糕。這幾乎已經是業界的共識，如果你不理解資料如何解耦，如何實現微服務的私有化資料庫（Database per service），建議千萬別輕舉妄動。
循序漸進落實資料庫架構改造
不可否認，而這個議題，一直是微服務中最讓人頭痛的地方。由於應用開發人員太習慣三層式架構的設計，以致總是將資料庫的所有問題，全部都交給傳統的資料庫系統解決方案處理。因此，開發人員對於資料庫架構的設計往往很陌生，甚至害怕去面對。
但是，避開資料庫架構的設計議題，絕對是錯誤的選擇。
的確要設計一個完整的資料庫系統，非常具有難度，也不是一般人可以勝任的工作。對於應用程式開發者來說，討論一個過於理論的底層技術，也並不現實。所以在導入微服務架構時，我們通常也不打算討論太底層的資料庫系統實作議題，而重點會放在應用層面的資料流、資料處理架構。
事實上，微服務的資料解耦、資料庫架構設計並不是一件難事，雖然看似工作繁瑣，但都有道理可循，看似風險很高，卻有方法可以循序漸進。
為什麼不懂處理資料庫議題就做不成微服務？
微服務架構的設計上，通常是圍繞在應用業務的需求上，而這些應用需要妥善的「資料供應和管理」來支撐其運作。如果不懂得解耦資料、處理相關資料庫議題，這代表可能沒有完全搞清楚業務的需求，更代表著沒有完全處理好業務邏輯的解耦和拆分。在這種情況下所設計出來的微服務，肯定是有極大問題存在。
的確，資料層的拆分問題相當麻煩且不易，除了對既有系統進行拆分有巨大風險外，即使重新設計一個全新的系統，亦難以直觀地去設計資料架構，並考量完整的維運策略。
有鑑於此，這導致很多人會取巧以避免資料層的設計，甚至刻意忽略這段工作。不過要注意的是，若只處理商業邏輯層面的服務拆分，而不處理資料分享的問題，這樣所設計出來的架構，除了對開發分工管理的部分有幫助外，對整體系統效能改善是沒有太大的幫助，多半可能還傷害並降低系統整體表現，也同時增加了系統複雜度。
只做了一半的業務拆分工作，本質上並沒有實現微服務的分散式架構想法，不會在系統表現上獲得好處，而且會承攬許多微服務架構所帶來的缺點，例如延遲性、複雜度以及增加資料庫的負擔等。所以，除非系統本來的用量不高，不然這樣半吊子的實作，會帶來更大的麻煩，還不如不要拆分太深，選擇傳統 SOA 的做法就好。
關於更多資料解耦如何影響微服務架構設計的議題，可以參考舊文「為什麼導入微服務架構很容易撞牆？」和「CQRS 的神奇把戲：微服務資料解耦」。
實現資料庫私有化（Database per service）
在微服務架構下，有一個資料庫私有化（Database per service）的設計模式，顧名思義，指的是每個服務擁有自己的資料庫。為了保持服務之間低耦合及具隔離性的設計，我們會避免資料庫共享的情形，所以設計上會讓服務擁有自己的資料庫。由於資料庫只能被擁有者所存取，其他外部的服務或系統，只能透過擁有者所提供的 API 來存取該資料庫的資料。
表面上，實現資料庫私有化，是為服務配置屬於自己的資料庫。但實際上，其意義是為了進行資料解耦的工作，確認資料歸屬。一旦實現資料庫私有化，這代表服務真正的被拆分和獨立運作，滿足微服務架構的需要。
拆既有資料庫風險很高，如何解決？
資料解耦才是微服務資料庫議題的核心，而資料解耦的意義在於確認資料的歸屬，然後圍繞在資料擁有者（服務）的身上，發展出應用和功能。所以，當我們確認了資料歸屬，首先要確定這個資料的擁有者（服務），在使用這個資料時，不會衝擊原有的資料庫的效能，也不會大幅增加其管理的難度。
這時，善用 防腐層設計模式（Anti-Corruption Layer Pattern）來處理這個問題，就是很好的手段。簡單來說，可以利用 CQRS （Command and Query Responsibility Segregation）將服務所擁有的資料，從原有的資料庫系統抽取出來，然後建立一個新的獨立資料庫作為過渡，以滿足資料庫私有化的需求。
雖然這樣做，身為該資料擁有者的服務還不能全權掌控資料，但某程度來說微服務的資料庫架構基礎已經成形，至少，未來不管從哪來的需求，如果要存取這些資料，一定要透過這個身為資料擁有者的服務來進行。
註：防腐層設計模式（Anti-Corruption Layer Pattern）是 Eric Evans 於領域驅動設計中（Domain-Driven Design）所提及的設計模式。
如何看待並導入 CQRS？
在微服務架構設計中，CQRS 被用來解耦資料庫結構並滿足資料一致性，實際上在採用 CQRS 時，需要結合應用的功能設計，才能發揮最大的效用，甚至實現資料和資料歸屬的實體隔離。
若要討論 CQRS 實務上的規劃，花三天三夜也討論不完，這是一個永遠會因應業務需求而不斷調整的議題，所以，針對當下需求去使用 CQRS，並選擇一個能保留彈性的設計，是最優先的考量。
對於初入微服務架構的人，或是希望導入微服務技術來逐漸改善既有系統的企業，可以先嘗試運用 CQRS 來實現「資料庫快取（Cache）」，將部分業務跟原始資料庫進行隔離，並利用快取設計，提高系統的查詢效率。很多企業早已經導入 CDC 或 Replication 等抄寫和讀寫分離解決方案，某種程度上，已經算是實現初步的快取機制。
對於已經很熟悉或是很習慣快取資料庫存在的人，則開始要考慮「規模化的快取」，也就是能快速建置快取資料庫、依照不同需求實現「多視圖（Multiple Views）」的機制。換句話說，就是考量業務需求與系統效能的平衡，去設計各式各樣的快取機制，並能夠快速擴增以滿足未來不斷新增的業務。
到這個階段，逐步或全面引用事件驅動架構（EDA, Event-driven Architecture）來設計資料管線（Data pipeline），會是最主要的工作。
落實應用層交易機制
可以說，交易機制是將所有資料綁死在單一資料庫的關鍵，之所以資料難以解耦，很大一部分是因為要遷就交易機制在單一資料庫內執行。如果能使交易機制，從資料庫系統脫離後在應用層落實，就可以讓資料解耦的工作進展一大步。
這同時也是為什麼，很多人在導入微服務時，會覺得微服務複雜又沒有實際效益。因為許多人考量到交易機制離開了資料庫系統後，就不容易實現，所以仍然把有相關聯、有相互間交易同步需求的資料都放在同一座資料庫裡。這導致實際上的資料和業務並沒有隔離，對系統效能影響最大的關鍵仍然沒有改變。
在這種情況下，資料和交易機制沒有解耦，只會創造出更多的空殼服務和邏輯，伴隨著更複雜的系統架構加上效能低落的資料庫系統，只有壞處沒有好處。因此，應用層交易機制，便是在處理「資料快取」和「資料中繼」後，首要解決的最大議題。
若對於微服務交易機制的實現，可參考舊文「淺談微服務架構交易機制實現」。
強烈不推薦直接打掉重練
很多人學會了領域驅動設計（Domain-Driven Design），開始懂得切割和劃分服務、系統，於是想試圖大刀闊斧進行改革。但這其實是很危險的事，如果不熟悉各種資料一致性、資料解耦的技術，一次導入太多、太少、或是選擇錯誤，只會造成更大的麻煩。不但系統的開發方向不會朝一開始的設計前進，甚至可能左支右絀，與其背道而馳。
所以在導入微服務技術時，通常並不推薦推翻重練的形式來滿足新的架構，而是針對痛點、特定功能、特定服務，以「優化」的方式進行。所以在實務導入時，也要從最不影響系統運作的地方著手。
即便是實現一個新的應用、服務，在沒有包袱的情況下，建議也是要先對資料處理架構進行全面的思考和設計，再來進行。若實在陌生，可以參考本文前面章節，從資料快取、歸屬權等角度逐步引入設計，然後再來討論應用層的交易機制。
本文資料，來源皆參考自 寬橋（Brobridge） 的微服務架構設計教育訓練課程，想要暸解更多關於微服務架構設計的議題，可以與我們聯絡。如果您想要導入「資料快取平台」，為您的微服務導入之路打下堅實基礎，也為未來的「數據中台」和「資料中繼平台」做好準備，歡迎與我們洽詢。
