本章概覽#

關於微服務架構（microservice architecture），社群裡的看法分歧極大：有人視之為軟體開發的未來,也有人主張它是反模式（anti-pattern）。實情一如既往，是「視情況而定」。本章要回答的核心問題是：到底應該在什麼情況下採用微服務架構?它解決了什麼問題?又是怎麼解決的?

採用微服務架構的主要動機,是為了解決一個今日多數團隊都會面臨的痛點:必須以更快、更可靠、風險更低的方式交付軟體,讓組織能在競爭激烈的環境中持續成長。靠加班與意志力得到的改善往往短暫且代價高昂;真正可持續的進步,來自改變開發軟體的方式,有時甚至要改變軟體本身的架構。

加速軟體交付的關鍵,是採用一種稱為「流暢交付」(fast flow)的交付風格,以及能讓這種風格成立的架構。對許多(但不是全部)應用程式而言,微服務架構正是這種架構。

本章將討論的主題#

• 採用微服務架構的主要動機
• 微服務架構的關鍵特徵
• 採用微服務架構時必須跨越的障礙
• 何時該、何時不該使用微服務架構

各小節導讀#

• 1.1 為何需要流暢交付:解釋流暢交付的定義、意義,以及達成它所需的開發流程、組織結構與架構三大要素。
• 1.2 流暢交付的架構需求:探討讓流暢交付成立的架構特性,並說明為何巨石(monolithic)在某些情境下也能勝任。
• 1.3 微服務架構簡介:給出微服務架構的明確定義,說明其優勢與內建的挑戰與缺點。
• 1.4 何時該用微服務:依「全新開發」與「重構巨石」兩種情境,提供決策依據。