經過昨天的威脅恐嚇後，如果你還是要面對微服務的議題，就先假設你找到「命定的目標」了，所以代表你有需要知道該怎麼導入微服務，後續就開始我自己怎麼思考這件事情的心得了！

在今天開始，我想進入「微服務架構模式」的討論。在過去，我們和客戶討論微服務通常的起點是 Kubernetes 或是容器化的議題，很多人已經把這個概念混淆在一起。

但是，「微服務」這個名詞可能比 Kubernetes 這些出現的時間還早，這些概念會被擺在一起主要是在 Kubernetes 讓微服務可以得到的好處被放大了，再加上很多業者的鼓吹，使得有些人會想像這些就是在一起的概念。

在 Sam Newman 「建構微服務 (第二版)」一書中有提到，最開始建立微服務的時候可能先不需要考慮 Kubernetes 的部分。

那，我們怎麼開始進行「微服務」的導入，通常你會先聽到一個名詞「領域驅動設計 (Domain Driven Design）」，因為我們要對服務進行「拆分」。沒錯，這可能也是我會採取的第一個手段 (藉此順便理解客戶的領域知識)。

但，這一系列的文章中我想先談談「微服務架構模式」，底下會針對其採用的「場景」、「問題」、「解決方案」等逐一描述：

故事場景

你正在開發一個對業務至關重要的企業級應用。為了讓業務在當今多變、不可預測、複雜且模糊（VUCA）的環境中茁壯，你必須能快速、頻繁且可靠地交付變更。基於此，你的工程組織依據 Team Topologies 的理念，編組為小型、鬆耦合、跨職能的團隊。每個團隊遵循 《DevOps 手冊》所界定的 DevOps 實務來交付軟體；特別是，採用持續部署（Continuous Deployment）。團隊以自動化部署管線測試並將一連串小而頻繁的變更部署到生產環境。

上面是一段導入微服務前會陷入的業務場景，它定義了業務的目標「快速、頻繁且可靠地交付變更」，說明了團隊的拆分「小型、鬆耦合、跨職能的團隊」以及大家的工作守則「DevOps 手冊」來將工作分解並且自動化。

核心問題

1. 我怎麼讓團隊有效地工作起來，並且互相協作完成最大的商業價值
2. 我應該把這個企業應用分成哪幾個部分讓個團隊可以分工執行 (最好還不要互相影響)

解決方案

基本上，就是設計一個微服務架構，可以解決上述的「核心問題」。

Microservice Architecture Pattern Language

經過上述的描述，比較簡單的想法就是把我們的企業應用程式切好模組讓他可以獨立部署，這樣就可以收工了！

如果，事情都這麼順利，那我也沒有素材可以寫這些文章了，目前鋪排可能還會超過 30 天 (我就繼續把手邊的筆記跟實際遇到的狀況一一吐出)。

過去，在客戶開始跟我討論「微服務」這件事的時候，我大概就有一些概念可以跟客戶分享 (因為以前研究論文是做 SOA)，後來在 Sam Newman 出版第一版「建構微服務」的時候也有拜讀過，所以一些基礎的概念是有的。

但是，怎麼讓這些概念得以落實？最初，就很單純地把應用程式分拆 (這時候客戶會問我怎麼切才是最適合的微服務)。後來有人來問我，他在網路上看到資料庫應該也要被分解！除此之外，很多時候都是從既有的系統移轉過去，如何確保移轉的過程是「安全」的，陸陸續續地遇到好多質疑 (雖然，在那個時期能做好這些事情的還是有限)。

所以，我就想到以前我研究論文時最常拿什麼 Architecture Pattern 還是 Design Pattern 相關的設計來做文章，那這件事是不是也有「模式」？底下，我先針對兩個概念釐清一下：

模式 (Pattern)

是對「反覆出現的設計問題」與「可重複使用的解法」的一種抽象表述

模式語言 (Pattern Language)

是把這些模式組織成一張有脈絡的地圖，讓你能從「問題 → 解法」快速導航，並理解不同解法之間的取捨與連動

有了這樣的概念後，我就到 Google 打了 Microservice Pattern 還真讓我找到一個參考的資料，我發現 Chris Richardson 有寫一本書「Microservice Architect Pattern」，將微服務落地會遇到的問題，整理成一張全景圖。從「如何拆分服務」到「資料一致性、通訊、部署、觀測、測試、安全…」一應俱全。這不只是教科書，而是一份設計與評估的工作手冊。

(節錄至 Microservice Architecture 網站)

這張圖上面說明了導入微服務可能要處理的各種問題與解決方案，圖上有「動機模式 (Motivating Pattern)」與「解決方案模式 (Solution Pattern)」，意指你在系統架構上遭遇了什麼問題 (Motivating Pattern)，線的另外一端就是這個問題的解決方案。

有時候，解決方案不是只有一種，所以就還有「虛線」的箭頭來表示，透過這個模型讓我們可以有一個「地圖式的指引」，讓我們在進行微服務導入工作的時候能有所本，也可以檢視這張全景圖，確認自己有沒有哪些準備工作有遺漏。

結語

寫到這裡，突然覺得這個素材有點多，可能再把這個 Pattern Language 分層次的議題放在下一篇文章再來介紹才不會一瞬之間有資訊爆炸的感覺。

Microservice Architecture Pattern Language 給了我們一張可溝通、可追溯、可檢核的設計地圖。把上述模式的待辦清單逐項落實到設計與文件裡，我們就能把微服務從口號，變成可實作、可驗收、可營運的工程成果 (還有很多實作跟規劃的「苦」要吃)。