摘要：
1. 爲什麼說企業數字化轉型需要進行微服務架構升級
主要描述傳統企業IT應用受互聯網衝擊的大背景，引出傳統企業轉系需要在架構上向互聯網企業學習。
2. 傳統企業實施微服務架構的難點是什麼：歷史包袱太重
從傳統企業應用和互聯網企業應用的不同特點說起，講述傳統企業架構升級微服務 過程中的一些重點關注的內容、方法和建議。
3. 傳統SOA和微服務差別在哪：運行期的快速變更能力不同
講述SOA與微服務的差異，進而介紹微服務改造的一些關鍵點。
4. 實施微服務，第一步幹什麼 : DevOps
結合上兩節，指出實現微服務架構升級和數字化轉型，需要建立先進的生產線DevOps來支撐，並說明DevOps平臺需要具備的能力和遷移過程說明。
5. 基於DevOps的企業微服務架構"長"什麼樣子
簡單介紹一下基於DevOps的企業架構以及DevOps平臺的架構。
6. 總結
1. 爲什麼說企業數字化轉型
需要進行微服務架構升級
面對互聯網的強大活力和競爭態勢，傳統企業也要變革，也要向市場開放，直接面向用戶，增強自身的競爭力，因此IT系統建設向數字化轉型的需求也變的非常迫切。
目前企業的傳統IT應用主要以服務企業內部用戶爲主，其特點是需求明確、功能全，覆蓋廣，大集成，中央控制，非常適合企業穩定和發展階段，但缺點也非常明顯，剛性強，難以快速變化，維護成本高，無法支持快速變革的新業態。
常見的一些對業務應用可靠性要求很高的企業如銀行，他們對應用的變更和發佈有非常嚴苛的流程控制，編寫投產手冊、反覆進行投產演練、成立投產臨時指揮部、安排各個部門角色的值班與協調工作等，非常複雜，一次投產流程從準備到提交審批再到最終投產完畢會持續三個月左右，整個項目週期中約一半時間都是在投產，這樣的投產雖然一定程度上能夠提高投產的可靠性，但效率屬實很低。這樣的情況實實在在的發生在了我們傳統企業中IT水平較高的銀行中，是非常有代表性的。毋庸置疑，這種狀況一定是需要改進的，問題出在哪裏以及怎麼來解決值得我們思考和研究。
新興的互聯網應用的特點則是主要服務外部客戶或合作伙伴，需求變動快，功能簡單，獨立和分散，分佈式進化，一切都從零開始，業務與IT緊密結合，需要快速創新，規模變化大，大範圍廣泛的嘗試，易失敗（淘汰），對業務彈性、快速發佈要求高。以上這些正是現在火熱的微服務架構應用的特點和能力。
成熟的互聯網企業的應用從代碼提交開始，會運行各種自動測試驗證，再到配置、部署也可以做到全自動化，軟件投產流程可以在幾分鐘內自動完成。具備了很強的持續集成和快速交付的能力，一天多次部署，一週多次發佈就成了順利成章的事情。
相比互聯網企業，傳統企業應用想要做到持續集成和快速交付，在企業的架構方面需要向互聯網型應用學習，業務應用架構需逐步向微服務架構應用轉型升級，提升整體IT建設的效率與可靠性，才能更有效的加速業務創新。
2. 傳統企業實施微服務架構的難點
是什麼：歷史包袱太重
傳統企業與互聯網企業IT系統建設很大的不同點在於互聯網企業很多是從零開始，而傳統企業則需要在之前大量的IT系統基礎之上進行逐步轉型和改進，因此傳統企業的轉型與改造更需要先進的方法論，制定標準的流程與規範，並需要完善的生產線和平臺來進行支撐，盲目試錯是不行的。企業應用架構轉型的決策者們在規劃轉型的路線和方法時需要從多方位來進行思考，重點應該關注以下幾個方面：
1. 需要從關注單個應用的架構改進爲支撐整個企業的架構
2. IT應用架構需要從傳統架構模式向互聯網型應用轉變
3. 開發過程和規範需要從只關注開發階段改進到關注整個應用從設計到運營的全生命週期的關注
從單體巨石型應用架構向微服務架構的轉型和升級要兼顧情懷與現實，既要面向未來，又要尊重歷史，不走極端。不能推翻重來，更不能原地踏步，而是要逐步將關鍵應用向微服務架構方向升級和改造。在很長一段時間內，應該是新老架構應用並存，雙模運行的狀態。不論是單體架構應用還是微服務架構應用，他們的共性是在運維方面，都需要進行配置和部署，因此，我們建議以配置和部署作爲切入點，來逐步進行歷史應用的改造和升級。以下是一些傳統架構升級方面的一些建議：
1. 基礎設施虛擬化，基礎設施即服務（IaaS）
2. 配置部署自動化，逐步淘汰人工流程，採用自動化的方式替代人工處理
3. 應用分層，抽取公共模塊組件作爲基礎服務
4. 貼近客戶的應用或者升級後可能獲益最大的應用優先改造
5. 按功能特性進行微服務系統劃分和建立功能特性相關的微服務團隊
3.傳統SOA和微服務差別在哪：
運行期的快速變更能力不同
關於應用微服務化改造，我們再來一起探討一下。前些年都在搞SOA，現在又出來個炙手可熱的微服務，這些概念到底有啥關係？
其實這兩個概念面向的對象還是有些差異的。SOA講的是系統間的集成與交互的方式；而微服務則是一種將傳統的一個巨石型大系統切分成一個個小系統的架構理論模型。
說到這裏，就又要有疑問了，拆分一個大系統，不就是模塊化組件化麼？
沒錯微服務本質也就是要做模塊化組件化，區別在於原來我們做模塊化組件化主要是用以設計開發期用以分工，並行開發用的，打包部署後還是一個大WAR包，運行期還是巨石應用，完全無法做到快速變更和投產上線，然而不具備快速變化能力就無法適應互聯網千變萬化的形勢。
因此微服務化改造，是巨石應用面向互聯網轉型的必要條件。關於微服務化改造這裏梳理了以下一些要點供大家參考：
1. 梳理和抽取基礎服務、技術服務、業務服務作爲獨立的服務下沉，形成穩定可靠的服務中心並作爲開發平臺中的基礎服務提供
2. 前後端分離，將前端展現與後端業務分離，實現前後分離的層次化架構；
3. 按照功能特性拆分子系統，拆分方法論可以參照 《The Art of Scalability》一書中描述的分佈式擴展立方體，微服務化拆分對應圖中按照Y軸即功能獨立性進行拆分，將一個大系統拆分爲多個獨立的子系統，參見下圖：
4. 選擇合適的微服務容器，微服務容器選型對於微服務的快速開發交付非常重要，需要具備輕量、快速等特點。通常微服務容器需要具備秒級的啓動速度，提供微服務運行的必備功能如服務發佈、註冊，服務發現、路由、調用等能力。選擇微服務容器還需編譯打包部署方面的便利性等。目前通過驗證我們推薦選擇SpringBoot作爲Java類型後端微服務應用的基礎容器。
5.統一微服務間的通信方式，我們也做了不同協議和方案的選型與評估，最終選擇了基於Http協議的RESTful風格接口作爲微服務間的主要通信方式，Http協議具有無狀態、安全等特點，RESTful 這種面向資源的API訪問方式也與微服務架構非常匹配。
4.實施微服務，第一步幹什麼 :
DevOps
企業要進行數字化轉型，要將傳統應用逐步向微服務架構升級，除了有先進的方法論和標準流程規範之外，還需要有先進的企業級平臺生產線來支撐落地實施，這個裏說的生產線就是火熱的DevOps。我們認爲企業數字化轉型，實施微服務架構升級需要從DevOps平臺建設開始。
那麼DevOps是前面說到的自動化配置部署嗎？當然不是，前面我們也提到了，自動化配置與部署，只是一個切入點，屬於DevOps中的一部分能力。目前通過自動化配置部署替代人工操作，能夠解決傳統IT面臨的一個巨大的痛點和瓶頸，解決了這個瓶頸後，接下來可以有更多的資源和精力投入，進一步完善DevOps生產線，逐步優化整個企業IT架構。
一個完善的DevOps生產線應該具有以下特點：
1. IT資產管理，能夠將整個企業的IT系統當做數字化的資產來進行統一管理
2. 全生命週期管理，能夠對應用進行生命週期管理提供流程規範與工具支撐
3. 支持新老並存雙模運行，能夠時支持傳統應用和微服務應用並存與協同
4. 持續敏捷迭代，自動化一切
5. 跨部門組織溝通、協作，打破需求、架構、開發、運維、管理等部門牆
6. 統一的概念模型，建立統一的概念模型，提供集成統一且完整的工具鏈（打通過程、質量、源碼、測試、部署、監控、安全等工具鏈）
7. 完善的系統體系，組織、技術、流程規範等多方面提供理論指導和IT支撐
下面我們來看一下，如何從DevOps開始，逐步將傳統應用從單體巨石架構向微服務架構升級，緊接着向雲端遷移，建設公有云或者企業私有云，將企業轉型爲數字化企業，示意圖如下：
參見上圖，總體思路就是傳統應用需要先從自動化配置部署開始，逐步打造DevOps平臺，接下來以DevOps平臺爲生產線，來對企業應用進行統一的管理和運營，再將傳統應用架構改造爲微服務型的應用架構，最後則可以更便捷的向雲端遷移，實現數字化企業轉型，精益運營。
整個遷移過程從技術角度講，DevOps平臺首先要做到的是應用和基礎設施解耦，傳統應用中的應用部署過程，耦合了太多的下層基礎設施，包括各種配置（操作系統、數據庫、應用服務器、消息服務器、路由等等）。讓每一次的應用部署過程變成一個非常繁雜的過程，需要來回的驗證和多方的確認。那麼要做到應用與基礎設施解耦，需要建立以微服務爲中心的統一概念模型，微服務一定要與基礎設施環境解耦。執行層面，建設DevOps自動化開發運維平臺和微服務化拆分結合較緊密，也可並行實施，逐步完善後，DevOps平臺會成爲很好的支撐微服務的快速開發交付運維的生產線，屏蔽了底層環境和依賴系統的差異，結合PaaS與IaaS基礎設施，最終能夠將更方面應用遷移到雲端運營。
5.基於DevOps的企業微服務架構
“長”什麼樣子
參見上圖，傳統企業應用架構向數字化互聯網型應用架構轉型過程中，在很長一段時間週期內，企業的應用架構應該是類似圖中的樣子，即上文所述的雙模運行模式。新系統和已經做好微服務升級的系統採用類似互聯網應用架構的模式，傳統SOA應用未完成架構升級的系統同時也在運行，一起爲企業的業務提供IT能力支撐。傳統SOA架構應用可以通過服務總線與新架構應用互通。傳統應用由軟件資產管理開始，逐步進行微服務化升級，最終由DevOps生產線統一管理，集中監控。
我所在的團隊目前正在按照上述思路持續迭代研發DevOps雲平臺生產線，基於微服務架構抽象出了統一的概念模型，爲應用的全生命週期管理、各部門角色協同工作等提供了統一集成的工具鏈，依託於容器化的基礎設施服務CaaS，結合了多年傳統企業應用的實踐經驗總結，目標是爲企業應用向微服務和數字化轉型提供切實的理論指導和有力的技術支撐。下圖爲DevOps雲平臺的邏輯架構圖請參考：
6.總結
本文的主要目的是將傳統企業數字化轉型中關於微服務改造方面的一些經驗分享給大家，這也是站在平臺提供者角度對支撐企業應用的經驗總結和轉型方面探索的一些思路，希望能夠對大家有所啓發。簡單總結一下，就是企業數字化轉型是大勢所趨，微服務架構升級又是轉型的必由之路，而實施微服務架構升級則需要從DevOps開始。
建設DevOps平臺同企業數字化轉型一樣，都是一個持續改進優化的過程，不可能一蹴而就，也不可畏首畏尾裹足不前。不同企業需結合自身情況儘快找到一個切入點推進數字化轉型，爲走向互聯網、面向企業的未來打好每一場戰役，讓我們遇見未來！
