MACH架構：微服務質量工程指南

banq發表於2022-08-18
Mac架構微服務

MACH 是一個首字母縮略詞，它提取了為數字組織構建的服務的本質，尤其是那些需要在生態系統中進行最多整合的組織。它同樣適用於業務和內部服務，例如提供自助服務體驗的 CI/CD 平臺。
MACH的 4 個關鍵要素是：
  1. Microservices：微服務是關於模組化的
  2. APIs ：API強調介面的使用
  3. Cloud-native SaaS：雲原生 SaaS推動託管服務
  4. Headless ：無頭意味著沒有與前端的耦合。


MACH中的微服務是關於構建模組化的服務，這些服務能很好地與它們所解決的業務領域保持一致。DDD 是一種實踐，可以利用它來構建具有 "高內聚力和低耦合 "的平衡服務。

API是指透過明確的介面提供抽象，幫助生產者和消費者在功能上脫鉤。線上版本、文件和標準協議（如REST）有助於提高服務的連線性。

雲原生SaaS把重點放在雲端的管理服務上，而不是建立一個內部的解決方案，在第一階段可以提供幫助，但在企業還需要關注其業務的時候，就無法擴充套件必要的功能、規模和維護。

Headless遵循MACH其他屬性中的關注點分離。它是關於提供技術API，以便任何消費者可以在自己的環境中使用服務，即無頭工作流、網路或移動使用者介面。它最大限度地提高了連線性和開放性。

MACH 成功因素
MACH 為 Quality at Speed 微服務做“正確的事情”的關鍵屬性提供了一個參考框架。但它們的有效實施需要確保“把事情做對”。
以下是 MACH 服務的 8 個成功因素：

  1. 業務驅動
  2. 從宏服務開始
  3. 互操作標準
  4. 真正的雲原生
  5. 有目的的無頭
  6. 非同步優於同步
  7. 復古相容
  8. 可在自助服務中使用。


1. 業務驅動
團隊在關注技術縮寫和 "MACH "架構的同時，可能會忽略業務重點"。然後，這種距離會影響到服務的顆粒度和潛在的價值，最終集中在技術而不是業務上。

因此，作為一個團隊，保持一個系統的業務第一的思維方式是很重要的。應用領域驅動設計（DDD）的方法是一個很好的例子，以保持業務領域和將要建立的MACH服務之間的一致性。

當團隊幾乎無法論證他們為什麼要建立一個服務，或者無法確定使用者和目的時，是時候停下來，首先回到業務願景。

2. 從宏服務開始
"微服務 "是一個充滿了歧義的詞。有些人會理解為所有的業務功能都應該作為一個 "功能 "來實現，利用容器的雲原生生態系統，甚至功能即服務，而忽略了應用的周界。

過於細化的方法所帶來的危險是建立了過於複雜的服務集，再加上在沒有必要的自動化、可觀察性和其他對這種 "沙粒 "複雜程度的要求的情況下，操作這種服務的失敗機率很大。

因此，第一個重點是按照 "高內聚、低耦合 "和 "關注點分離 "的原則，在應用程式之間建立具有強大模組化的顆粒狀應用程式。從這裡開始，要出現的顆粒度已經考慮到了微服務。

3. 可互操作的標準
暴露一個具有功能解耦的介面是在MACH服務中構建服務的正確方式。但如果使用的技術不是生態系統內的標準，那麼在尋求快速迭代的生態系統中，其採用的潛力就會急劇下降。

確保在服務中使用可互操作的標準是對高速服務質量的要求。一個建議是在大多數服務中使用REST/JSON，在同步的情況下增加事件，在某些情況下依靠GraphQL聯盟。

而在一些行業的互操作標準也在功能層發揮作用，例如行業資料字典和介面格式。如果你的行業是這樣的情況，請仔細考慮使用這些標準。

4. 真正的雲原生
在 "雲原生SaaS "中，"原生 "一詞有其重要性。許多雲的採用是以 "提升和轉移 "的方式進行的，以減少遷移風險和增加採用。但這種遷移技術很少能創造出 "雲原生 "的能力，也不能從中受益。

雲原生的服務遵循最佳實踐，例如12因素應用，它將所有配置外部化，提供跨環境的可移植部署，並以多個例項進行擴充套件。

缺乏雲原生元素的MACH服務將遭受整合問題、迭代速度減慢，並遲早會在可擴充套件性方面達到限制。知道了什麼是利害關係，最好確保雲原生是一個設計要求。

5. 有目的的無頭服務
為多個消費者建立的無頭服務，隨著時間的推移，為適應許多消費者而進行的小改動的積累，會變得過於龐大。挑戰在於如何在中期內保持模組化，有時要接受建立另一個元件。

歷史上IT行業的 "重用 "和 "最佳化 "文化可能導致團隊試圖透過將所有的變化加入到現有的服務中來節省建立新服務的成本。這種行為表明缺乏雲原生文化，在中期是危險的。

決策標準不應該是建立服務的成本，因為這個成本必須是在正確的自動化條件下的剩餘成本。主要的決策標準是關於模組化和解耦原則，即使是無頭的，也要始終了解使用者。

6. 非同步而非同步
API給人的感覺是，所有的交流都是透過同步API呼叫完成的，這與SOA架構中的REST或之前的SOAP API的使用標準相悖。問題是，同步呼叫很少需要，而且它們迅速達到了可擴充套件性的限制。

MACH服務的成功因素是透過web-hook和事件驅動的模式，預設為非同步交流的特權，這些模式仍然提供可以嵌入API門戶的服務。同步模式只在例外情況下和真正需要時才會出現。

7. 舊系統相容
即使一切都在MACH架構原則下建立和交付，以質量和速度運送變化仍然是頭號業務目標。而隨著使用者數量的增加，這意味著掌握軟體變更。

執行對MACH服務的更改需要透過非破壞性的更改模式來確保舊系統的相容性。當一個服務被髮布並與其他應用程式連線的那一天，不管是內部還是外部，改變將更加困難。

主要的問題是將消費者從一個版本遷移到另一個版本，因為這涉及到在沒有相同優先順序的分散式行為者之間進行昂貴的協調。因此，透過設計使變化最小化，並具有追溯相容性是一個要求。

8. 可用於自助服務
數字化競爭要求在使用者和合作夥伴的目標範圍內快速部署成功的產品。這種速度要求在生命週期的每個階段都有最大限度的自動化，特別是在整合和維護服務方面。

在自助服務中提供業務服務需要在一個使用者友好的門戶中提供API，並提供適當的文件、用例和必要的資訊來利用這些服務，然後開始付費--所有這些都儘量減少人類的互動。

交付自助服務的要求需要從設計階段開始考慮，最好是在程式碼庫內。對於一些服務，還需要投資於該領域的專業人士的技術寫作。畢竟，這關係到數字業務的發展。
 

相關文章