回顧首篇文章替整個系列訂下了開發與學習的目標，在系列文的最後一篇我們將側重於總結我們達成的目標，與現有的其他解決方案。

回顧

單體式應用程式與微服務

在單體式應用程式中，所有功能都是密不可分的，並且緊密相連。這樣的設計雖然在某些情境下有其優點，但也帶來了一些困難，如當系統需要硬體擴充時，可能會面臨資源浪費和管理的挑戰。

微服務則是另一個極端，將系統分解為數個小型且獨立運作的服務。每個服務都有其自己的功能和職責，且獨立於其他服務運作。這不僅使得開發更為靈活和模組化，還提供了更好的擴展性。

微服務的溝通方式

無論是將現有服務給微服務化，還是從頭建構一個微服務，都不是一件簡單的事情。雖然清晰明瞭的架構能夠替我們帶來維護的便利與容易分工的益處，但也在開發中替我們帶來了不小的挑戰。

微服務中的每個服務都被視為一個獨立的應用程式，並提供某種形式的介面供其他使用者或服務存取。常用的存取介面通常是以 HTTP 為主的 API，或者是事件驅動的溝通模式。

• 與「客戶端」溝通的模式:

  1. API 直接呼叫模式：
     客戶端直接呼叫後端微服務。雖然簡單，但可能會遇到效能問題和維護困難。
  2. API 閘道器模式：
     所有客戶端的請求都先經由一個中央閘道器，再由該閘道器轉發到適當的後端微服務，有助於減少微服務與客戶端之間的過度耦合問題。同時，在這個閘道器中可能統一整合了身分認證、負載均衡或是反向路由等功能，多數的雲端提供商都有開箱即用的 API Gateway 相關服務。
  3. API 組合模式：
     透過閘道器，客戶端可以一次請求取得多個微服務的資料。減少客戶端必須發出的請求次數，提升效率。

• 與「服務」溝通的模式:

  1. 服務編排模式（Service Choreography）：
     微服務彷彿是經過訓練的舞者，各自知道什麼時候該做什麼。此模式使用事件驅動的方法，每個服務只專注於自己的工作並在完成後通知其他服務。
  2. 服務協作模式（Service Orchestration）：
     有一個中央指揮者或協作器控制複雜的業務邏輯流程。所有微服務僅提供基本的功能，並由中央協作器指導完成整體的業務邏輯。

以服務協作模式指揮微服務

本篇系列文章以 PHP 程式庫 Anser 作為基礎，其中 Anser 提供了基於服務協作的 PHP 微服務溝通解決方案；Anser 不仰賴任何外部伺服器或其他程式語言，完全使用 PHP 進行製作，能夠直接融入你目前的 PHP 專案中。

以下將列出相似的解決方案。

• AWS Step Functions
  AWS Step Functions 允許開發者設計和執行多個步驟的工作流程。使用 Step Functions，你可以組合 Lambda、決策邏輯或是整合建置於 AWS 上的 APIs 。
• Google Cloud Workflows
  Google Cloud Workflows 提供連接 Google Cloud 服務的能力，使開發者能夠編寫應用程式工作流程。透過編排不同的 Google Cloud 服務或者是基於 HTTP 的 API，開發者可以輕鬆地創建、部署和監視多步驟的應用程式流程。
• DTM, DTM PHP Client
  DTM 是一個以 Golang 撰寫的分散式交易管理系統，它提供了在不同的服務之間執行交易的能力；DTM PHP Library 是 DTM SDK 的 PHP 版本，透過這個 SDK 的支援 PHP 開發者輕鬆地將交易任務傳遞到 DTM 中進行分散式交易任務的管理。

微服務交易

分散式交易

由於微服務的獨立性，每個服務都有自己獨立的資料庫，當業務流程需要跨多個服務時，確保資料的一致性變得具有挑戰性。本系列文章介紹了三種主要的分散式交易解決方案：二階段提交（2PC）、三階段提交（3PC）和 Saga 模式。

• 2PC 和 3PC 著重於透過協調機制與資料庫鎖定來確保所有參與節點的資料一致性，但可能在某些情境中效率較低或帶來阻塞。
• Saga 模式將交易拆分成多個小步驟，每個步驟都有相應的補償機制；Saga 模式可以透過兩種主要方式來實現：服務編排和服務協作。兩者都有其優缺點，取決於特定的業務需求和系統架構。

在 PHP 中，你可以透過 DTM 的 Saga 相關元件達成與本系列文章相似的交易管理與微服務協作。但在一些細節上可能有不同的概念與需要注意的地方，你可以前往這個 Git 儲存庫 了解如何使用這個開發架構；你也可以參考第 19 到 25 章的文章內容，使用 Anser 的 Saga 元件完成在 PHP 程式語言的 Saga 設計模式。

微服務設計

與分散式交易所關注的角度不同，微服務本身具有自己的資料庫以及交易實作。在實作微幅務時安全地存取自身的資源，才能夠支持分散式的交易環境中的健壯性。

• 關注自身的交易：
  微服務需要確保其內部的交易是安全和一致的，無論是資源的建立或是修改，在一個完整的業務邏輯中若是涉及了多個資料表的資料異動，使用完整的交易保障這些異動的完整性是一件必須達成的事。
• 樂觀鎖定：
  樂觀鎖定作為一種資料庫操作策略，目的是在高並行請求的執行下能減少資料表鎖定的使用以提高效能。你能夠透過「資料的版本控制」和「更新時檢查數值」等策略來達成樂觀鎖定的效果。
• 冪等的服務呼叫：
  在顧及冪等性的程式設計下，不論執行多少次結果都是相同的。我們可以透過「唯一的交易識別碼」或是「軟性刪除」等方式達成冪等的服務呼叫。
• 留下操作記錄：
  在重要的資源改變中留下修改記錄，可以幫助開發人員和系統管理員追蹤和了解問題的根本原因。

高效能 PHP 開發方案

PHP 通常採用 PHP-FPM 搭配 HTTP 伺服器一同執行，每個連線都有各自獨立的生命週期處理結束立即銷毀，這在高並行的請求下可能不是最佳選擇。為了解決這問題，我們可以透過像是 Swoole、RoadRunnder 或是 Workerman 等新穎技術進行應用程式的開發，透過重複使用留存在記憶體中的 PHP 程序，達到更好的執行效能。

不只 Go 語言，我們可以透過 Swoole 或是 Swow 等 PHP 開發引擎，在 PHP 的環境下進行 Coroutine 模式的程式設計。透過 Coroutine 開發者能夠在單一執行緒中管理與進行多任務。同時我們也能夠過 Workerman 和 Coroutine 結合，提供非阻塞式的常駐型 PHP HTTP 應用伺服器。

在 Workerman 與 Swow 環境下，我們能夠透過抽換 Anser 中的 Guzzle 核心，使 Anser 在 Swow 的 Coroutine 模式中無縫地執行。你也可以透過下列採用新技術的 PHP 開發框架完成你的高效能微服務：

• Laravel Octane:
  採用 Swoole 與 RoadRunner 執行的 Laravel 框架整合方案。
• Swoft
  基於 Swoole 的全 Coroutine 開發框架。
• hyperf
  能夠以 Swoole, Swow 下執行的全 Coroutine 開發框架。

結語

透過本系列文章，我們探討了從單體式應用程式到微服務的轉變，並學習了多種微服務間的溝通方式以及交易管理方法。而 PHP 作為一門廣泛使用的後端語言，也正在對這樣子的軟體開發趨勢做出改變。

無論使用哪種技術或設計模式，關鍵都在於如何在正確的需求下選擇最合適的實作。當我們深入了解各種模式和最佳實踐時，也應該持續評估我們的業務需求和系統架構，使系統朝向最正確的方向改變。

最後，希望這系列文章能夠為你提供一個探索 PHP 微服務開發的叩門磚，不論你是剛開始還是已經走在這條路上，都希望你能從中受益。