微服務的優勢衆多，在現在如果有誰沒有聽過微服務架構，可以從這裡了解一下。本文主要聊一聊是否值得花時間将單體架構重構為微服務架構？
微服務架構是一種架構風格，專注于軟體研發效能，主要包括機關時間内實作更多功能，或者軟體從想法到上線的整個持續傳遞的過程。在目前的網際網路環境中，業務變化迅速，也促使了微服務架構的普及。這種架構迫使團隊迅速反應，快速實施，在方案沒有過期之前已經上線運作，經受市場考察和考驗。
目前國内大多數公司正在運作的系統都是單體架構系統，不可否認，這些系統在公司發展過程中，發揮了不可替代的作用，保障了公司正常運作，創造了很多價值。但是，随着系統的日漸膨脹，內建的功能越來越多，開發效率變得越來越低，一個功能從想法到實作，需要花費越來越長的時間。更嚴重的是，由于代碼子產品糾結在一起，很多已經老化的架構或者廢棄的功能，已經成為新功能的阻礙。
衆所周知，單體架構随着功能增多，不可避免的是研發效能的降低：研發周期變長、研發資源占用增多。進而引發的情況是：新員工教育訓練時間增多、員工加班時間變長、員工要求漲薪或者跳槽。到了這種情況就說明，單體架構已經不能夠滿足企業發展需要，這個時候，需要更新架構來提升研發效能，比如微服務架構。
想要說明微服務架構的好處，可以來一個比喻。我們建了一個空間站，為此，我們需要将人、貨物和裝置運輸到空間站中，這個時候，運載火箭是表較好的選擇，盡管運載火箭造價也比較高，但是幾個月發射一次，也能夠滿足需求。随着空間站的擴大，火箭發射的間隔變短，運輸成本高的離譜，而且越來越沒法滿足空間站運轉需求。這個時候，可以嘗試另外一種方式，比如，太空電梯。當然太空電梯的造價成本高于一次飛行的費用，但是隻要建成，以後的成本就降低了很多。
這個比喻也是說明了微服務帶來的美好期望，同時也說明一個問題，實施微服務架構會帶來巨大的投資。是以，我們在建造太空電梯之前需要想好，我們真的需要這種投入，否則是能是一種浪費。
to be or not to be
決定從單體架構更新為微服務架構時，先問問自己下面幾個問題：
産品或系統是否經過市場考驗
是否需要超過一個團隊來保證産品釋出
系統是否對可靠性、可伸縮性有較高要求
微服務架構
什麼是微服務架構呢？Sam Newman認為是：“一組圍繞業務領域模組化的、小而自治的、彼此協同工作的服務。”
微服務架構中的服務，是根據業務能力抽取的業務子產品，獨立開發和部署，但是需要彼此配合完成整個業務功能。服務不是單純的資料存儲元件，那是資料庫。也不是單純的邏輯函單元，那是函數。隻有同時包括資料+邏輯，才是真正意義上的服務。
服務邊界
服務拆解過程中，DDD（領域驅動設計）可以作為微服務架構的指導方針。因為微服務是圍繞業務功能定義服務，根據服務定義團隊，這與DDD将業務域拆解為業務子域、定義限定上下文的方法論如出一轍，于是DDD作為微服務的指導方針，快速定義各個服務元件，完成從單體架構到微服務架構的遷移。
Alberto Brandolini提出識别服務上下文的方式叫做“Event Storming”。第一步是識别業務域中發生的事件，也就是說，我們的關注點是行為，不是資料結構。這樣做的好處是，系統中不同服務之間是松散耦合關系，而且單個服務能夠自治。
定義好了服務邊間，還需要定義事務邊界。過去，我們的服務在一個程序中，後面挂着一個資料庫，事務可以選擇強一緻性事務，也就是ACID。當服務增多，彼此配合，這個時候可以使用最終一緻性事務，也就是BASE。不同于ACID，BASE更加靈活，隻要資料在最終能夠保持一緻就可以了。這個最終的時間範圍，根據不同的業務場景不同，可能是分鐘、小時、天，甚至是周或者月。
準備工作
微服務架構願景美好，屬于重型武器，優點衆多，缺點也很明顯。服務增多，運維難度增大，錯誤調試難度增大。是以需要自動化建構、配置、測試和部署，需要日志收集、名額監控、調用鍊監控等工具，也就是需要DevOps實踐。實作DevOps的三步工作法中說明了實作DevOps文化的三個步驟。
除了上面提到的基礎，還需要在早期确定服務之間如何內建和彼此調用方式，還需要确定資料體系，包括事務一緻性和資料可靠性方法。随着服務增多，還需要配置管理、服務發現等衆多元件。具體需要的基礎元件可以參考微服務的基建工作。
這些基礎的服務和設計，最好在早起定義，否則，後期需要花費更多的資源才能夠完善架構。如果前期缺失，後期也沒有補足，造成的後果就是微服務架構遷移失敗，最後的系統也隻是披着微服務外衣的單體架構。
進化還是革命？
定義好服務邊界之後，還有一個問題需要解決：是逐漸進化更新系統、還是破釜沉舟重構整個系統。
第二種方式很誘人，比較符合大多數程式猿的思維，系統不行，推倒重來，名為重構。但是在大多數情況下，這種方式不能被允許，因為市場變化迅速、競争激烈，大多數公司不會停止業務，去等待重構一個能夠運作、隻是有些缺點的系統。是以，逐漸提取更新系統才是王道，大多數公司也能接受。這種方式又被稱為絞殺模式。
Transformation
該如何逐漸過渡到微服務架構？下面一步步進行展示：
第一步，将使用者視圖層與服務層部分邏輯進行分離。業務邏輯委托給服務層，支援頁面展示的查詢定向到資料庫。這個階段，我們不修改資料庫本身。
第二步，使用者視圖層與資料庫完全分離，依賴于服務層操作資料庫。
第三步，将使用者視圖層與服務層拆分為不同服務，并在服務層建立一個API層，使用者視圖層與服務層之間通信。
第四步，拆分資料庫，将不同業務資料拆分到不同的資料庫中，同時對應業務服務層拆分到不同的服務。使用者視圖層通過API網關與不同業務服務層的API元件通信。這個時候需要注意，如果團隊沒有微服務開發經驗，可以首先抽取簡單業務域服務，因為業務簡單，實作簡單，可以練手，積累經驗。
最後一步，拆分使用者視圖層。
絞殺模式的優勢就在于，我們可以随着業務變化随時調整方案，不會造成整個業務進化過程的停擺。
成功标準
當我們完成了整個更新過程，就需要檢查一下我們是否達到了預期的結果。引入微服務的目的首先是改善開發流程，我們可以通過簡單的名額來衡量：
開發周期：從概念到上線持續的時間
開發效能：機關時間内團隊或個人完成的功能或使用者故事
系統可伸縮性
平均維修時間：查找和排除故障所需時間
通過對比老架構和新架構的這些特性值，可以評估更新過程取得的效果。當然，更新過程中也要有這些名額的監控。
最重要的事
作為攻城獅，我們為能夠解決或改善周圍世界而自豪，着迷于提供解決方案。同時，我們也要意識到，我們付出的每一份努力，都要有回報。如果不能帶來任何回報的重構更新，都是浪費時間。