經過了這麼多天的主體，你還是繼續往下走之後，應該是前面講的兇猛野獸都無法勸退你想要遷移到微服務架構的決心，很可能你處於一個大型複雜應用程式開發的現場，每次上線都是相當的緩慢而且面對著改東壞西的問題。於是乎，你開始許願，然後有很多人跟你說試試看微服務吧！
於是，就開始入坑了！至於，最終是否能真的擺脫單體式的地獄到達開發與維運人員幸福的一天，就看造化了。
首先，當你想要將既有「大型複雜應用程式」移轉成「彈性敏捷的微服務」時，先打消一個念頭。
我會做出一個完美的微服務應用系統，然後順利上線。我們應該說，這個系統一直不斷地在「演進」當中，隨著業務的變遷市場的改變而不斷地自我修正，企圖滿足市場的需求。
在 Microservice Architecture Pattern 的書中提到「Strangler Application」的遷移模式。
Strangler Fig Tree 是指，絞殺植物，又名殺手樹。在維基百科中的定義是一種植物以附生來開始它的生長，然後通過根莖的成長成為獨立生活的植物，並採用擠壓、攀抱、纏繞等方式盤剝寄樹營養，剝奪寄樹的生存空間，從而殺死寄樹。這些絞殺植物主要為生長於熱帶及亞熱帶的植物物種，介於藤本植物和附生植物之間，生活在熱帶雨林中。它們主要包括部分榕亞屬的物種，以及其他不相關的攀緣植物。(這個隱喻可能要植物學家比較容易理解，但 Martin Fowler 就以這個來表示如何重構一個大型複雜的應用系統)。
換個簡單白話的說法，就是「逐步將單體架構轉換為微服務架構」的過程，或者是說「應用程式現代化」，主要的主旨是將遺留系統轉換成現代化的架構與技術框架。從我開始工作以來，每個時期都有這樣的議題，將過去的應用系統透過一個專案調整成新的技術框架（通常業務核心沒什麼改變）。
在這些「應用程式現代化」的相關專案中 (我現在討論的案例並不單純針對「微服務」，而是任何大型的重構或是重寫的專案)，通常採用「一步到位的方式」，指的都是一次入坑，難以擺脫的專案焦油坑。
拋棄既有的程式，透過需求訪談重新打造一個新的應用系統是很有趣而且沒有包袱。但是，請相信一件事，現場除了程式碼之外每一位使用者都可能沒有跟你講述事情的全貌，直到他開始測試然後發現跟他以前的經驗不一樣，你才會開始知道需求原來是這樣。
在我的職涯中，有多次其他廠商無法順利完成專案於是由我們接手的經驗，前一手無一不不是採用「打掉重練」這個模式來進行專案，於是乎總是無法將先前的需求全部涵蓋其中。正如 Martin Fowler 在他的文章內所述「推倒重寫的唯一保證，就是徹底搞砸一切」。配合我們實際的經驗，這句話有幾分的真實，而且不斷地重演上映。
因此，在 Microservice Architecture Pattern 中提出來的 「Strangler Application」 就是採取逐步式的移轉，將原本單體式應用系統中一部份一部份的抽離，最終成為一個一個獨立運作的微服務個體。如上圖「Strangler the monolith」所演示，隨著時間的演進「單體應用程式」逐步地被抽取出來的「服務程式」所取代。最終，單體應用完全被這些服務程式所取代。然而，這些重構的過程可能會需要歷經「數月」或是「數年」，據說：Amazon 花了許多時間來重構它的系統。甚至有些大型系統，你永遠不可能完成所有的過程。舉例來說：你可能會接到一個新的開發任務，開發新的業務功能以為公司帶來新的收益。這通常比「重構」這個系統要來得重要。
所以，不用想把整個應用系統都拆成微服務後才能上線，這有點不切實際。依據敏捷開發的精神，我們應該：
到這裡，你可以理解「微服務」的重構是一個演進式的過程，可能相當的耗時。永遠記得一件事，將系統改成「微服務」架構並不是我們的目標，而是為了達成某些商業目標的「手段」。因此，時時刻刻重新檢視「業務目標」確認是否隨著系統的狀況或是市場的反應而需要進行調整。
重構也不一定是針對整個系統，有效率地選擇對「業務目標」最有幫助的部分進行處理才是達到最大效益的關鍵。再來，後面兩天我們會開始討論「應用程式」跟「資料庫」的分拆。到底，誰先誰後，怎麼拆？有沒有什麼不能拆？其實，很多的文獻都已經有將一些經驗紀錄在案，我們可以藉由前人累積的經驗來降低我們導入微服務架構時可能遭遇的問題。
iThome鐵人賽
看影片追技術