透過本篇文章您可以瞭解到以下內容：
- Monolithic到Microservices的思考（回顧）
- 應用現代化策略的評估和規劃
- 應用現代化策略的5R模式
- 微服務架構設計的最佳實踐
- 總結
Monolithic到Microservices的思考（回顧）
首先讓我們做一個簡單的回顧：
- 本系列文章的第一篇向大家詳細介紹了Monolithic 架構的優勢、劣勢，以及闡述了從Monolithic 架構演進到Microservices 架構的原因。
- · 本系列文章的第二篇向大家詳細介紹了Microservices 架構的優勢以及大家普遍採用微服務拆分設計的理論指導原則（Domain Driven Design）
透過之前兩篇文章的介紹，相信大家對無論是Monolithic 架構還是Microservices 架構都有了一個較為清晰的理解和認知，同時大家可能也會存在一些疑問，例如：
- 既然微服務架構具有諸多優勢，那麼在應用現代化改造的過程中是否將所有的傳統單體應用都要進行拆分、改造成微服務架構呢？
- 如果對於上一點提出的問題回答是否定的，那麼判斷衡量的標準又是什麼呢？
- 對於不拆分、改造成微服務架構的傳統單體應用，它們應用現代化改造的最佳實踐是什麼？
- 對於需要拆分、改造成微服務架構的單體應用，這種拆分、改造的最佳實踐又是什麼？
接下來讓我們帶著上面的這些疑問，走進今天的內容。
應用現代化策略的評估和規劃
在應用現代化道路上，我們首先想的不是用什麼技術框架、也不是傳統單體應用怎麼進行拆分，改造成微服務架構，而是在我們已知改造範圍的前提下，從技術和業務角度進行評估和規劃改造的優先順序。
如上圖所示，從技術和業務角度分別羅列了需要考量的因素。 從技術方面涉及到了目前使用何種技術框架、是否使用了專有的工具、系統集成、依賴程度等因素。 在此階段我們可以透過一些工具來幫助我們進行有效的評估，這裡面包括手動分析工具，以及自動掃描工具等。
SNAP一種有效的手動分析工具，首先透過不同語言技術創建不同模版，在模版中會包含諸多技術因素，以Java為例，例如JDK版本、緩存（Caching）使用何種技術、編譯工具（Ant 、Maven、Gradle等）、代碼測試覆蓋率、數據存取模式（ORM何種技術框架）等因素。 透過一系列因素的填寫，判斷，最終會得出一個分數，分數代表了改造的難易程度。
相比SNAP手動分析的情況，在可以獲取原始程式碼許可權時，我們可以採用自動化掃描工具VMware Cloud Suitability Analyzer（簡稱CSA）。 CSA掃描規則採用yaml方式進行編寫，根據編寫規則，CSA會對應用進行掃描，並最終會得到技術改造成本高低的分數 （雲親和性），透過此分數，我們可以很好的從技術角度進行判斷，舉個例子，如果使用EJB和使用Spring Boot這兩種不同的框架，改造的成本是大大不同的。
另一方面，從業務維度涉及到了我們改造後帶來的收益是什麼？ 改造過程的風險又有多高？ 這個應用系統對應的業務重要程度又是怎樣？ 業務變更頻率等因素。
應用現代化策略的5R模式
在上一章節我們瞭解到，透過技術、業務角度進行評估並非所有傳統應用在現階段都適合進行拆分、改造成微服務架構。 根據評估和規劃，我們可以把傳統應用進行應用現代化改造歸類為5種方式。 如下圖所示：
我們首先來看看關於Retire、Retain、Rehost的解釋。
Retire退役
核心關鍵詞“退役”，顧名思義這一類應用停止開發、維護，並由新的SaaS解決方案進行替代。
Retain保持
核心關鍵詞是“保持現狀”，這一類應用並不會進行遷移改造（上雲）而是繼續交給團隊進行本地優化和維護。 之所以出現這類情況的原因很多，例如遷移改造成本過高等因素。
Rehost重新託管
核心關鍵詞是「轉移、挪動」 這一類應用會從本地遷移到雲上進行託管，即可以理解為由現有本地物理機和虛擬伺服器上進行部署轉移到雲上IaaS解決方案的過程。 值得注意的是Rehost可能會促進未來應用架構的升級、改造。
接下來是Replatform和Refactor，這裡我們重點討論下這兩類模式。
平臺重構
適用於業務功能相對固定、無需改動的應用系統。 這種方式的特點是少量改動與外部依賴的相關代碼以及少量修改相關配置。 以鏡像方式進行部署、運行在Kubernetes中。 雖然改動會帶來一些成本的增加，但是透過這種改造，可以享受到雲原生帶來的部分技術紅利。
適用於業務功能持續變化、更新較為頻繁的應用系統。 這種方式通常的做法是重構、拆分現有的單體應用，並設計成微服務架構，同時採用雲原生的相關技術。
需要注意的是，在Refactor模式下，我們需要將傳統應用進行拆分、改造成微服務架構。 接下來就讓我們看看微服務架構設計的最佳實踐是什麼？
微服務架構設計的最佳實踐
整體來說微服務架構設計包括兩大方面，技術方面、業務方面。
對於技術方面：
我們可以理解為在已經拆分好微服務的基礎上，透過選定的技術框架進行落地實施。 以Java技術棧為例，我們可以透過Spring提供的全家桶解決方案Spring Cloud來幫助我們建構微服務架構， 亦或使用Spring Boot並結合Kubernetes進行建構。 至於Spring技術體系的相關內容，本章節不做過多說明，後續的文章中會向大家進行詳細的介紹。
對於業務方面：
我們可以理解為根據業務實際情況如何進行微服務的劃分。 VMware在進行微服務架構設計方面，是採用SWIFT方法論，是由Pivotal在2016年創造出來的。
接下來讓我們看看什麼是SWIFT？
SWIFT定義：
SWIFT是一種輕量級、敏捷、高效同時又快速的將單體應用拆分、轉化為微服務架構的方法。 SWIFT從業務領域分析入手，逐步過渡到架構設計。 以Workshop對話的形式進行，同時融合了領域驅動設計（Domain Driven Design）的思想和原則， 整個過程更多的是引入了白板、貼紙等可視化元素，促進各領域專家、技術、管理等多角色人員共同參與和協作。
既然SWIFT是一整套的能夠落地的方法，那麼它的流程是怎樣的呢？
從圖中可以看出整個SWIFT流程概括為七個步驟，這裡面著重介紹下Event Storming、Boris Workshop、Snap-E、Thin Slice步驟 。
事件風暴
事件風暴（Event Storming）快速發掘和梳理業務流程，形成業務邊界、初步的微服務劃分，並形成統一的業務語言。
Boris工作坊
生成應用系統的概念型微服務架構，確定應用系統交互方式（同步、異步）
Snap-E
在進行Boris的同時，實時的記錄下每個微服務的要素，這些要素包括（API、DATA、PUB/ SUB、STORIES、UI、RISK）。
Thin Slice
一個薄切片（Thin Slice）指的是一個短的領域事件流，通常是對於最終使用者有意義的一個端到端的業務流程。
總結
回顧全篇內容，整體包括以下三方面內容：
- 首先回顧了Monolithic 架構和Microservices 架構，並引申出既然微服務架構具有諸多優勢，那麼是否在應用現代化改造的過程中， 將所有傳統單體應用都需要立馬進行微服務架構的改造等一系列疑問。 進一步瞭解到，我們需要做的是透過合理、科學的手段進行應用現代化策略的評估（技術、業務兩個維度），同時在評估完成後，會進行對應5R模式的歸類。
- 其次對於應用現代化策略的5R模式進行了解讀
- 最後針對於Refactor（傳統應用重寫、改造成微服務架構）這種情況，進行了詳細介紹，這其中包括SWIFT方法的定義、實踐流程等。
同時在SWIFT方法中的Event Storming、Boris Workshop、Snap-E又可以理解為從業務角度微服務架構設計的三把利器。 那麼作為利器之一的Event Storming具體實踐流程的細節是怎樣的？ 又有哪些參與人員？ 在這個實踐過程中又會結合使用哪些工具？ 對於上述問題，在下期的文章中會繼續和大家進行交流分享，敬請期待！ 如您有任何建議，歡迎隨時聯繫我們！
參考連結：
- https://tanzu.vmware.com/application-modernization
- https://github.com/vmware-tanzu/cloud-suitability-analyzer
- https://tanzu.vmware.com/developer/practices/swift-method
作者簡介
李剛，VMware 大中華區應用現代化部門高級系統架構師，資深企業級軟體開發和軟體系統架構師。 Spring Cloud開源社區項目貢獻者、Netflix開源社區貢獻者。 近幾年，參與並主導了許多大型企業客戶的應用現代化數位轉型專案，涉及物流、製造、金融等諸多領域。 特別對微服務實現方法、現代化應用架構設計、雲原生實施落地、開源軟體技術等方面有著豐富經驗。
