原文在我的部落格：2021-03-25 「PHP架構師」面試準備
崗位資訊
職位：PHP架構師
工作職責：
- 負責應用類產品後端架構設計、開發與最佳化
- 負責業務整體設計，具有良好的維護性和擴充套件性
- 參與需求分析與評審，瞭解業務，從技術角度推進業務的安全、穩定執行
任職要求：
- 掌握微服務開發，拆分，saga事務模型
- 掌握訊息佇列
- 熟悉其他的語言
- 掌握docker，k8s
- 熟悉TCP、UDP、http協議
- 熟悉 linux 基礎命令，瞭解如何排查系統效能瓶頸
- 熟練掌握mysql資料庫的效能最佳化，表拆分
- 熟練掌握php，瞭解PHP的優勢
- 統招全日制本科及以上學歷，理工科專業。
知識點
saga 事務模型
概念
saga 是啥？ 我們可沒聽過呀。
《傳奇》是由布萊恩·K·沃恩（Brian K. Vaughan）撰寫並由菲奧娜·斯臺普斯（Fiona Staples）繪製的史詩般的太空歌劇/奇幻漫畫系列，由美國公司Image Comics每月出版。該系列作品深受《星球大戰》（Star Wars）的影響，並基於沃恩（Vaughan）既是孩子又是父母的想法。
—— saga
呃，貌似對找工作沒啥幫助，既然是漫畫先收藏起來。
再搜找到了以下相關的介紹：
1987年普林斯頓大學的 Hector Garcia-Molina 和 Kenneth Salem 發表了一篇 Paper Sagas（點這裡可以看原文），講述的是如何處理 long lived transaction（長活事務）。Saga 是一個長活事務可被分解成可以交錯執行的子事務集合。其中每個子事務都是一個保持資料庫一致性的真實事務。
The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.
Saga 設計模式是一種在分散式事務方案中跨微服務管理資料一致性的方法。 saga 是更新每個服務併發布訊息或事件以觸發下一個事務步驟的事務序列。 如果步驟失敗，saga 將執行補償事務，這些事務會消除前面的事務。
—— Saga distributed transactions pattern - Azure Design Patterns
You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple service so you need a mechanism to implement transactions that span services. For example, let’s imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases owned by different services the application cannot simply use a local ACID transaction.
Implement each business transaction that spans multiple services is a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
你已經使用了 Database per Service 模型，每個服務有自己的資料庫。然而有些業務的事務是跨多個服務的，所以需要一個實現跨服務的事務機制。
例如你在建立一個客戶有信用限制的電商系統，系統必須確保新建立的訂單不會超出客戶的信用限制。但是因為訂單和客戶在不同服務的資料庫中，系統就無法簡單的使用本地 ACID 事務。實現業務事務跨多個服務執行就叫 saga。Saga 是一個本地事務的序列。每個本地事務更新資料庫，併發布一條訊息或事件，以觸發 saga 中的下一個本地事務。如果本地事務因違反業務規則而失敗，那麼 saga 將執行一系列補償事務，這些事務將撤銷之前本地事務所做的更改。
saga 事務有兩種恢復策略
向前恢復（forward recovery）：
對於執行不透過的事務，會嘗試重試事務，這裡有一個假設就是每個子事務最終都會成功。這種方式適用於必須要成功的場景。
向後恢復（backward recovery）：
在執行事務失敗時，補償所有已完成的事務，是“一退到底”的方式。
saga 事務協調
Choreography（編排）:
參與者（子事務）之間的呼叫、分配、決策和排序，透過交換事件進行進行。是一種去中心化的模式，參與者之間透過訊息機制進行溝通，透過監聽器的方式監聽其他參與者發出的訊息，從而執行後續的邏輯處理。由於沒有中間協調點，靠參與靠自己進行相互協調。
優點：
簡單：每個子事務進行操作時只用釋出事件訊息，其他子事務監聽處理。
松耦合：參與者（服務）之間透過訂閱事件進行溝通，組合會更加靈活
缺點：
理解困難：沒有對業務流程進行完整的描述，要了解整個事務的執行過程需要透過閱讀程式碼完成。增加開發人員理解和維護程式碼的難度。
存在服務的迴圈依賴：由於透過訊息和事件進行溝通，參與者之間會存在迴圈依賴的情況。也就是A服務呼叫B服務，B服務又呼叫A服務的情況。這也增加了架構設計的複雜度，在設計初期需要認真考慮。
緊耦合風險：每個參與者執行的方法都依賴於上一步參與者發出的訊息，但是上一步的參與者的所有訊息都需要被訂閱，才能瞭解參與者的真實狀態，無形中增加了兩個服務的耦合度。
Orchestration（控制）:
saga 提供一個控制類，其方便參與者之前的協調工作。事務執行的命令從控制類發起，按照邏輯順序請求 saga 的參與者，從參與者那裡接受到反饋以後，控制類再發起向其他參與者的呼叫。所有 saga 的參與者都圍繞這個控制類進行溝通和協調工作。
優點：
避免迴圈依賴：在編排模式中存在參與者之間的迴圈呼叫，而中心控制類的方式可以避免這種情況的發生。
降低複雜性：所有事務交給控制器完成，它負責命令的執行和回覆的處理，參與者只需要完成自身的任務，不用考慮處理訊息的方式，降低參與者接入的複雜性。
容易測試：測試工作集中在集中控制類上，其他服務單獨測試功能即可。
- 容易擴充套件：如果事務需要新增新步驟，只需修改控制類，保持事務複雜性保持線性，回滾更容易管理
缺點：
依賴控制器：控制器中集中太多邏輯的風險。
增加管理難度：這種模式除了管理各個業務服務以外，還需要額外管理控制類服務，無形中增加了管理的難度和複雜度。而且存在單點風險，一旦控制器出現問題，整個業務就處於癱瘓中。
總結
首先Saga是針對分散式長活事務的解決方案，針對事務長、多、複雜的情況，特別是服務由多個公司開發具有不可控性，可以使用Saga模式進行分散式事務的處理。Saga在處理事務一致性方面採取了向前恢復和向後恢復策略，前者透過不斷重試的方式保證事務完成，而後者透過子事務的補償事務，逐一回滾的方式讓事務標記失敗。在分散式協調方面，Saga採用了兩種模式：編排和控制。前者讓參與者（服務）之間透過訊息進行溝通，根據事件出發事務的執行流程，是一種去中心化的模式。後者透過中心控制類，處理事務的執行和回滾步驟，統一呼叫服務和接受服務的反饋。
微服務
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable（高度可維護、可測試）
- Loosely coupled（松耦合）
- Independently deployable（可獨立部署）
- Organized around business capabilities（圍繞業務能力進行組織）
- Owned by a small team（由一個小團隊擁有）
The microservice architecture enables the rapid（快速）, frequent（頻繁） and reliable（可靠） delivery of large, complex（複雜的） applications. It also enables an organization to evolve（改進、演化） its technology stack.
訊息佇列（Message Queue）
能夠在服務叢集中廣播訊息，並傳遞到每個服務中。具有這個功能的像是 NSQ 或是 RabbitMQ。你能夠在 A 服務上廣播一個“建立新使用者”的事件，這個事件可以順便帶有新使用者的資料。而 B 服務可以監聽這個事件並在接收到之後有所處理。這些過程都是非同步處理的，這意味著 A 服務並不需要等到 B 服務處理完該事件後才能繼續，而這也代表 A 服務無法獲取 B 服務的處理結果。與事件儲存中心近乎相似，但有所不同的是：訊息佇列並不會儲存事件。一旦事件被消化（接收）後就會從佇列中消失，這很適合用在像傳送歡迎信件的時機。
—— 微服務
本作品採用《CC 協議》，轉載必須註明作者和本文連結