在 Microservices 之前

傳統的設計框架，大部分都是將所有功能組件整合在單一應用程式中的設計方法，我們稱為 Monolithic（單體架構）。這意味著整個應用程式的所有功能，例如資料庫操作、業務邏輯和用戶介面，都是在一個單獨的Codebase中進行開發、部署和管理。這種架構的優點在於其簡單性，尤其是在初期開發階段，所有的組件都集中在一起，開發團隊可以快速進行開發和部署。然而，隨著應用程式規模的增長，Monolithic 架構開始顯露出其劣勢，包括難以維護、升級和擴展。

為什麼要 Microservices

隨著應用程式需求的複雜性增加，企業開始轉向 Microservices（微服務）架構。微服務是一種將應用程式劃分為多個獨立、鬆散耦合的小服務的架構方式，每個服務負責單一的業務功能，並且可以獨立開發、部署和管理。這種架構有助於解決單體架構中的缺點，特別是對於大型和複雜的應用程式，微服務架構提供了更高的靈活性和可擴展性。微服務可以根據需求獨立擴展，並且由於每個服務都是獨立的，開發團隊可以並行開發，從而加快開發速度。

Microservices 常用的 Patterns

在微服務架構中，有一些常見的設計模式來幫助管理資料和服務之間的互動：

• Database-per-Service：每個微服務都有自己的資料庫，這樣可以實現資料的分散化，並且不同的服務可以根據其需求使用不同的資料庫技術，並且分散風險。
  
• Shared Database：多個微服務共用一個資料庫，這樣雖然減少了資料的複製和同步問題，但也可能導致耦合性增加。
  
• CQRS（Command Query Responsibility Segregation）：這種模式將讀取操作和寫入操作分開，使得可以針對不同的操作使用不同的資料庫技術，特別適合讀取操作遠多於寫入操作的情境。
  
• Event Sourcing：將資料變更記錄為事件，這樣可以輕鬆地回溯和重播事件以重建資料狀態。
  
• Saga：處理跨多個微服務的分散式事務，保證整個事務的一致性，即使其中某些服務失敗，也能通過補償交易來恢復狀態。

Microservices 的優勢

微服務架構可以顯著改善資料管理，尤其是在處理大量資料或需要快速響應的場景中。每個微服務都可以專注於特定的資料處理任務，例如資料擷取、轉換和載入（ETL），並且這些服務可以根據需求獨立擴展。這種架構允許企業靈活地調整其資料處理流程，以適應不同的業務需求和技術變革。此外，微服務還能提高應用程式的可靠性和可維護性，因為每個服務都是獨立的，當一個服務出現問題時，不會影響到整個系統的運行。

Microservices 的挑戰是什麼

儘管微服務架構有許多優點，但也帶來了一些挑戰：

1. 資料一致性：由於資料分佈在多個微服務中，保持資料一致性變得更加困難，需要額外的設計來處理分散式交易和資料同步。
2. 複雜性增加：隨著微服務的數量增加，系統的整體複雜性也隨之增加，特別是在部署和管理方面，團隊需要更多的工具和流程來保持系統的運行。
3. 調試和故障排除：由於系統被分解為多個獨立的服務，這些服務需要透過網路進行互相通信，調試和故障排除變得更加困難，尤其是在服務之間的互動導致問題時。
4. 網路延遲和性能：服務之間的通信通常依賴網路，這可能會導致額外的延遲和性能問題，特別是在高並發環境下。
5. 團隊協作：微服務要求團隊之間有更高的協作能力，特別是在 service interface 或資料格式變更時，需要進行良好的協調。

結論

微服務架構為現代資料管理提供了一種靈活且可擴展的解決方案，特別適合那些需要處理大量資料並且要求快速響應的企業。雖然這種架構可以帶來很多好處，如提高靈活性、可擴展性和系統可靠性，但同時也增加了系統的複雜性和管理難度。因此，在實施微服務架構時，我們需要仔細評估其需求和自身的能力，並且確保有足夠的資源來應對隨之而來的挑戰。