首先，我們從大多數人熟悉的單體式(Monolithic)架構說起。

Monolithic 就如同摩艾石像般，巨大、莊嚴，承載著文化的整體。

在單體式應用程式中，功能與功能之間有著密不可分的關係。雖然我們能夠以不同的設計模式拆分各個不同商業邏輯的程式內容，但在實際執行上任何功能組的故障都有可能導致整個應用程式出現延遲或無法提供服務。

若是在單體式應用程式中某個服務具有較高的負載需要擴充伺服器時，將會導致服務必須以「應用程式」為單位佈署於新的伺服器上，可能導致資源的浪費與擴充作業的負擔。

另一方面微服務（Microservices）是一種受到服務導向（service-oriented）啟發的軟體架構，無論是網路文章、書籍，或是學術論文皆已有許多比較它們差異的討論，因此本篇文章將不著墨於此。而不論哪種架構，近年來都是廣受討論的。依據 O'Reilly 於 2020 年的微服務採用調查，近三分之一的受訪者表示，他們正在大部分的系統中遷移或實作微服務架構。

在一個使用微服務實作的系統中，將會包含數個單一職責的小型服務。在微服務架構下開發人員得以專注於聚合相似功能的商業邏輯於單一服務，使得大型應用程式得以並行開發，並且不互相影響，能顯著提升軟體交付的速度。

由於微服務之間各自獨立，每個微服務都擁有自己的生命週期，這使得它們能夠使用不同的技術進行開發。同時，越來越多基於微服務的雲端原生架構與容器化技術的面世，讓微服務更易於佈署、複用、擴充，以及管理，使得微服務更加地彈性、快速並且有效。

在單體式架構與微服務架構的選擇上，我們無法斷定何種開發模式才是最棒的模式，軟體開發從來沒有銀彈，沒有任何技術架構可以概括所有軟體需求。依據團隊的技術線、軟體規模與時程等各方考量後，選擇最適合團隊或產品的開發架構才是王道。

依據 W3Techs.com 研究機構的調查結果顯示，目前伺服器端所被使用的程式語言中，PHP 的使用量依舊是高居各程式語言排行中的。與其他程式語言相比，鮮少有以 PHP 作為主題的微服務相關設計模式的簡單實作。因此筆者認為，基於 PHP 提出一套建構微服務架構的簡單方法極具價值。

挑戰

在本系列文章中，我們將著重聚焦在解決數種在實踐微服務架構時可能會面臨的挑戰。

服務連線與商業邏輯

在微服務架構中，系統的功能被切割成一個個小型服務，這些服務維護著屬於自己的資 料，並透過可用的API，讓外界能夠與之溝通。對於上層的開發人員而言，當實作一個複雜的商業邏輯時，可能是一個跨越不同服務且具有一定順序並互相影響的過程。此時，我們將使用何種模式來串連這些微服務將是一件重要的課題。

分散式交易

其次，在微服務架構帶來好處的同時，也產生了各端點間資料一致性的挑戰。分散式交易(Distributed Transaction)並不像單一資料庫 交易能輕易地滿足「ACID」中的原子性 (Atomicity)、一致性(Consistency)、隔離性 (Isolation)，與持久性(Durability)。

在微服務中，每個端點各自擁有獨立的資料庫系統，並維護著自身的資料庫交易實作。在同一業務邏輯下，若是涉及跨越多個微服務的資料改變，那麼將會面臨分散式交易的難題。若是在較長的業務邏輯中發生某一服務的執行失敗，或不明原因中斷業務邏輯的進行，已新增或已修改的資料必須還原(Rollback)為業務執行前的狀態。

而在微服務架構中，我們無法單靠服務間各自的資料庫解決交易問題，因各個服務的資料庫管理系統（DBMS）無法共享本地交易的執行狀態，也無法因為其他資料庫系統發生寫入失敗時觸發本地交易的還原。若是無法解決分散式交易的難題，將無法保障不同端點間的資料一致性。

可靠性交易

使用微服務架構需面臨的不只是邏輯層面引起的分散式資料一致性問題，在硬體資源耗盡或意外故障的場景下，也可能會造成分散式資料不一致的情況產生，這將導致開發人員於開發或部署微服務架構應用程式時，無法充分保障分散式交易完整性與可靠性。

在一些微服溝通的務設計模式中，所有的決策與流程將由某個中央控制器進行管理。在這種溝通模式中一旦遭遇意外故障，將會導致資料遺失，進而無法保證資料一致性。面對這種場景時，可使用故障轉移(Failover)、備份和還原(Backup and Restore)等方式提高服務可用性。

當服務集群中的某個節點發生崩潰時，如何在新節點中重新啟動服務，並連結至儲存備份資料的節點，以處理停擺狀態的交易，並恢復分散式交易且維持資料一致性也是重要的課題。

高效能 PHP 程式設計

隨著網頁應用程式的需求和複雜性持續增加，開發者們一直在尋找更高效能的方式來執行 PHP 應用程式。過去，PHP 被認為是一個適合於傳統的請求與回應模式的語言。在單一請求中立即解釋、編譯與執行程式碼，造成效能低落。

近年來，隨著常駐型 PHP 伺服器技術的出現，PHP 的性能極限已被大大推進。例如 RoadRunner、Swoole 和 Workerman ，它們皆提供了一個不斷運行的應用環境，使得應用程式可以在啟動後的每次請求中重複使用。

PHP 開發者現在可以直接建立高效能的 HTTP 伺服器，而無需依賴外部的大型 HTTP 伺服器，如 NGINX 或 Apache，藉此直接簡化部署與增加靈活性。同時，隨著常駐型 PHP 的出現，開發者可以更輕鬆地將應用分解為多個獨立運行的微服務，並保持著高效能與高彈性。因此，如何利用現有的先進技術打造高效能的 PHP 微服務系統也是我們得聚焦的重要課題。

目標

微服務架構是個龐大的領域，我們無法在三十天的時間內囊括所有的設計模式與可能面臨的問題。但筆者認為，這個系列的文章足以讓你具備一定的微服務開發思維。

這個系列文章適合怎麼樣的人閱讀？

1. 從未實踐或僅了解卻尚未實作過微服務架構的開發者

   你將能夠實踐一種簡單易懂的微服務溝通設計模式

2. 具備 PHP 開發經驗的開發者

   在大部分的範例中我們不會使用框架，將著重於邏輯的展示

筆者將在三十天的旅程內，帶領你從入門的角度宏觀地了解微服務（Microservices）與其所相關的設計模式。

同時，你將能透過 PHP 程式語言在實際的程式設計範例下實踐你的微服務，在旅途中我們將一起解決一些挑戰：

1. 了解常見的微服務設計模式
2. 學習簡單易入門的服務協作（Service Orchestration）設計模式
3. 透過 Saga 設計模式處理分散式架構所需面臨的交易問題
4. 使微服務的交易具備高可用性（High Availability）
5. 常駐式高效能 PHP Web 伺服器開發

期待在這趟旅程中，能夠使你收穫滿滿。

讀物推薦

1. Microservices Patterns: with examples in java
2. 建構微服務｜設計細微化的系統
3. 單體式系統到微服務
4. Web API 建構與設計
5. 持續API管理｜在不斷演變的生態系統中做出正確決策

參考資料

M. Loukides and S. Swoyer, "Microservices Adoption in 2020," O'Reilly, 15 7 2020. [Online]. Available: https://www.oreilly.com/radar/microservices-adoption-in-2020/. [Accessed 1 8 2021].

圖像資料

摩艾石像, Xavier Mena 發佈於 https://www.pexels.com/zh-tw/photo/14652645/