為何需要微服務?

ㄧ些可能會想到關於微服務的討論是關於可擴展性.大部分可能不是.可以確定的是我們閱讀到像Netflix 或Amazon開發的微服務架構的偉大.讓我問一個問題:世界上多少的公司能像此？循著此問題另一個：世上多少公司需要去處理如同Netflix 或Amazon等級的擴充性需求？

這個答案是世上絕大主要的開發者處理是企業應用軟體.現在我不想低估Netflix 或Amazon的領域模式.但一個企業領域模式已是野獸般需要去處理

所以對於我們大多數的開發者而言,微服務通常不是為了擴充性.他主要是為了增進我們發行的開發時程與縮小批次尺寸

但我們有開發維運分享一樣的目標,所以為什麼我們還需要去討論用微服務去達成呢？或許你的開發團隊如此大與你的程式碼庫如此巨大到改變任何事難以避免搞混一大多不同的觀點在你的應用上.協調工作在人與整個巨大,緊耦合和糾纏的程式庫是困難的事.

透過微服務,我們試著去拆開這個超大獨佔的程式庫到一個較小,定義良好,高內聚低耦合產出物.我們稱這小片段為微服務.如果我們能在我們程式庫中識別ㄧ些自然變化片段在一起並與其他的分離,我們可以把他們分開至另一個可以從其他產物獨立被發行的產物.我們將能改善我們的開發時程與批次尺寸.因為我們不需要等待其他片段準備好,就可以量產發布我們的微服務.

你需要用此高度去使用微服務

微服務架構伴隨多種產物每一個都必須被量產發布.如果你在量產發布一個大單一個體仍有問題什麼會讓你認為你在處理多個產物會有更少問題？在任何的微服務架構一個非常成熟的軟體開發排程是一個絕對的需求.有些可用來評估產線成熟度就是手動介入的數量.自動測試.自動配置環境與監控的數量.

分散系統如同人是困難的.我們必須意識到當我們面對微服務時需要面對一整個分散系統帶到檯面上的新問題.追蹤,監控,日誌彙整與彈性等一些你面對單一獨佔系統時不需要處理的問題

微服務架構伴隨高標準,但值得投入如果這問題在你的獨佔系統代價更高的話.獨佔和微服務架構是不同架構,架構就是關於取捨.