比起「建構一個新的微服務系統」我認為「移轉到微服務架構」這個議題更值得討論，或許是因為我個人經歷的都是從既有系統移轉的專案而造成的偏見，所以我認為「移轉到微服務架構」的需求會是比較多的。

我聽過很多業主，他的需求是這樣「我們要把某系統改成微服務架構」。但，一直以來我很少明確聽到有一個明確且清晰的目標，比較多的是「如果為服務對其他公司有好處，那麼對我們應該也有好處」的思維模式來考慮要往微服務架構邁進。很多時候，我們在「不真正了解原因即決定要採用微服務架構」。

因為原廠都說微服務好，新的趨勢，那我們也來做！

為什麼你要用微服務架構？

所以，在導入微服務的時候我喜歡用 Sam Newman 在「從單體式系統到為服務」一書中提到的三個重要問題：

1. 您希望達到什麼目標？
2. 您是否考慮過使用微服務之外的替代方案
3. 您要如何得知遷移是否有效？
   用來了解，客戶為什麽要選擇微服務，以及希望達成的「目標」。畢竟，微服務是一種「手段」而不是要達成的「目標」。

或許，有其他的手段值得我們考慮，通常在比較之下你會選擇出一個比較沒那麼差的解決方案。

底下，我們針對幾個常見的「理由」來進行一個範例式的討論：

縮短產品上市時間

藉著可以對微服務進行獨立的部署作業，無需等待其他合作方的發佈即可上線來提供服務。
上述問題，或許透過「模組化」解耦合的設計就可以解決上述問題，微服務或許是一個解決方案，但可能不是唯一的答案。

有效擴展負載規模

藉著將處理程序分拆成一個一個的微服務，使得這些處理程序可以「獨立擴展」，也就是說可以更經濟且高效率地擴展系統。
在沒有討論微服務之前，我們通常透過「負載平衡器」或是「Message Queue」的方式來讓後端應用服務可以執行多個副本，已處理更多的負載。思考一下，我們的應用是否透過這個方式即可以應對？在架構上是否需要做到更動化地擴展動作？如果是，那我們就積極地規劃微服務架構。

擴展開發人員數量

有時候，我們會希望可以用更多的開發人員來加速開發的進程。但是，從「人月神話」的案例來說，如果應用系統無法被解耦的話，將難以達到這個目標。
所以，微服務就是一個可以實現這種透過加入更多「開發人員」來提升開發效率的一種解決方案。但是，其實將應用程式加以做模組的分割可能就可以達成一定程度的改善效果。

擁抱新技術

在傳統上，單體式架構往往限制了技術的選擇性，原本專案採用什麼技術後續就要用相同的技術來完成。
但是，現在技術已經很發達，就算有新的功能要用新的技術開發都可以過 Web API 的方式來進行整合，雖然這樣可能某種程度就已經將新的應用調整成微服務的系統，但也不一定說整個應用程式都要完成微服務的架構。

但是，如果你發現你目前所使用的技術已經是「接近落日」的技術，不容易找到可以維護的技術人員，例如：COBOL 的話，或許規劃一次大型的重構是一個必要之惡。

其實微服務沒你想像中美好 (勸退)

在這講裡面，我想要表達的是**「微服務」不一定總是對的答案**，所以「三思而後行」這件事很重要。

1. 所以，如果自己對於自己的行業的領域還沒思考清楚的話，不適合微服務。
2. 新創公司首要的任務是生存下去，很多時候都還在思考「商業模式」，業務領域也還沒有很明確的輪廓，所以很容易落入第一類的情境。所以，新創公司可能不適合在第一天就談「微服務」。據說，Netflix 或是 Airbnb 這樣的公司也是在發展至成熟期後才開始轉向微服務架構。
3. 如果你是開發產品讓客戶自己安裝來使用的話，那麼微服務可能是一個不好的選項。因為客戶要了解所有的模組之間的相依性，並且部署到對的地方。所以，如果不能夠做到讓客戶一鍵式的完成安裝則不建議採用微服務架構。
4. 如果你沒有明確的目標，充分的理由，那就先不要考慮微服務了！

假設，經過這些的卻說後，你仍然決定要邁向為服務這條路。就記住三件事
1. 漸進式遷移
2. 漸進式遷移
3. 漸進式遷移
很重要，所以說三次。

「如果你進行一次大規模的重寫，唯一可以保證的就是會大爆炸。」 --- Martin Fowler

一次從既有系統提取一點出來，你將可以限制出錯的影響範圍 (當你開始走向遷移至微服務這條路，我們唯一可以保證的就是你一定會出錯)!

因此，如果你一次修改了很多東西，你將很難定位是哪些部分得到良好或是不良的回饋，所以分成多個階段的頻繁交付就是一個重要的原則(這裡，為微服務與敏捷開發鋪了一些後續發展的劇情)。

透過一次拆分一個微服務可以漸進地釋出微服務帶來的價值，而不必等到大規模的重構部署。如果到這邊，你還是認為要用微服務架構，後續的幾天就讓我們開始探討有關「單體式」重構成「微服務」的幾個議題。

結語

所以再來文章的走向就會開始往如何從既有系統遷移至微服務來進行討論了！不過，好像篇幅會超過 30 篇，反正就是有整理就繼續貼就是了！