作為一種架構模式，微服務將復雜龐大的業務系統切分為數十個乃至數百個小的服務，每個服務負責實現一個獨立的業務邏輯。這些小服務易于被小型的軟件工程師團隊所理解和修改，并帶來了語言和框架選擇靈活性，縮短應用開發上線時間，可根據不同的工作負載和資源要求對服務進行獨立縮擴容等優勢。單體架構跟微服務架構區別微服務改造策略：微服務改造的過程其實就是將原有的單體架構改造成微服務架構的過程，微服務改造是一個漫長的過程，需要充分考慮遺留系統的情況，在改造的過程中原有的遺留系統跟改造后的微服務系統需要共存很長一段時間，基于不同的規模改造所需要的時間從幾個月到一兩年甚至數年的時間不等。目前微服務的改造的常見策略可以分為二種：絞殺模式：絞殺者策略是一種逐步剝離業務能力，用微服務逐步替代原有單體系統的策略。它對單體系統進行領域建模，根據領域邊界，在單體系統之外，將新功能和部分業務能力獨立出來，建設獨立的微服務。新微服務與單體系統保持松耦合關系，隨著時間的推移，大部分單體系統的功能將被獨立為微服務，這樣就慢慢絞殺掉了原來的單體系統。絞殺者策略類似建筑拆遷，完成部分新建筑物后，然后拆除部分舊建筑物通俗的來講類似“從農村包圍城市”。修繕模式：修繕者策略是一種維持原有系統整體能力不變，逐步優化系統整體能力的策略。它是在現有系統的基礎上，剝離影響整體業務的部分功能，獨立為微服務，比如高性能要求的功能，代碼質量不高或者版本發布頻率不一致的功能等，通過這些功能的剝離，我們就可以兼顧整體和局部，解決系統整體不協調的問題。修繕者策略類似古建筑修復，將存在問題的部分功能重建或者修復后，重新加入到原有的建筑中，保持建筑原貌和功能不變。一般人從外表感覺不到這個變化，但是建筑物質量卻得到了很大的提升。微服務改造關鍵要素：微服務改造的過程有二個關鍵點：1.微服務設計規劃；2.遺留系統遷移規劃；微服務設計規劃：微服務設計規劃中從大到小的范圍又包含二個關鍵步驟：業務拆分、技術實現；業務拆分主要是指針對原有的業務系統進行業務層的梳理，基于業務層面來看哪些功能應該放到同一個服務，哪些必須分開，從而實現龐大的單體系統的拆分，最終保證微服務與微服務之間的高內聚、低耦合。目前常見的實現方式比如：基于事件風暴的方式進行業務流程梳理。技術實現是指基于業務梳理的微服務拆分結果進行微服務開發，其中就包含用何種開發語言、框架、中間件、開發模式等。遺留系統遷移規劃：遺留系統遷移規劃主要是指將企業遺留系統平穩的向微服務過渡，其關鍵點是實現核心業務、高并發業務、低容錯業務從遺留系統無縫的遷移到微服務架構，此部分內容一般都會先選取試點項目，基于試點項目進行實踐，從而總結出一套適用于企業自身的最佳流程或者實踐，然后再大規模的組織內推廣，從而真正實現遺留系統的微服務化改造。微服務改造實施步驟：如何進行微服務改造，微服務改造具體步驟是怎么樣的？我們基于部分項目的經驗總結如下，當然并不一定適應于所有的業務場景，正如前面所說每個企業的業務場景、各種環境因素各不一樣，所以還是要具體問題具體分析，微服務改造實施計劃如下：選取業務領域：微服務改造不是一蹴而就的，一般會先選取部分業務場景作為改造試點從而總結成功的流程和最佳實踐，至于業務場景的選擇說法各異，有的推薦從邊緣業務開發，這樣的風險較低，但是也有可能看不到明顯效果從而導致整體改造過程停滯不前，有的推薦從核心業務開始，這樣效果最明顯但是風險相對較高，各有優缺點，看改造決心和當前系統“痛”的程度，也可以參照“絞殺”、“修繕”。等模式進行業務領域選擇。建立統一目標、愿景：基于公司的整體目標，針對業務領域建立統一目標、愿景，讓大家都能清晰知道，所有人朝著同一個目標進行。遺留系統分析（業務拆分）：微服務規劃階段前，團隊需要了解業務知識，改造遺留系統前，團隊首先要學習遺留系統知識，為遷移做準備。針對業務領域進行整體的業務流程梳理，結合業內領域驅動設計方式，以事件風暴的實踐進行，常見的步驟如下：1.識別事件，2.識別命令，3.尋找聚合，4.劃分子域和界限上下文，5.微服務劃分制定遷移策略和路徑：綜合管理、業務、技術等因素，為遺留系統微服務架構升級制定遷移策略和實施路徑。技術選型和基礎設施建設：基于公司的總體目標架構，根據系統分析結果、遷移策略和路徑以及遺留系統現狀，選擇微服務基礎設施和技術組件，如：SpringCloud、ServiceMesh、Docker、K8s 等等。團隊規劃、賦能：進行微服務開發團隊規劃，結合康威定律，根據服務、架構的方式組建相應的團隊，各微服務開發團隊是自組織、自管理的團隊。同時針對團隊成員進行新的技術架構、框架、開發方式方法進行賦能，確保后續步驟的順利進行。迭代交付：微服務開發過程通常結合敏捷開發、DevOps等前沿理念進行，通過敏捷開發、DevOps工具鏈加速整個微服務的開發過程，保證開發質量。總結項目經驗，沉淀最佳流程和實踐：基于項目實施過程總結沉淀出適合企業自身的最佳改造流程、規范、最佳實踐等，這一階段是不斷循環完善的過程。組織內推廣微服務改造方式方法實踐案例：該項目是某全球領先的大型營養和健康管理公司，其現有業務受到傳統技術架構限制，存在諸多問題，之前系統是一個龐大的單體應用，對接第三方系統較多，開發語言各不一樣，經過了多年變化，IT團隊為了滿足之前大型集團的業務需要已經舉步維艱，響應跟不上業務的變化。我們基于微服務、容器、DevOps等云原生全棧技術幫助客戶建立了技術中臺，基于我們的微服務平臺實現服務注冊發現、服務限流、服務路由、服務鑒權、服務熔斷等一系列服務治理能力的同時，為企業業務應用也提供全生命周期的管理，包括容器部署、虛擬機部署等用戶自定義IaaS層資源的能力；除此之外，在服務框架層面我們既兼容了SpringCloud和Dubbo兩種常見的微服務框架，也兼容Istio的ServiceMesh能力，用戶只需要在開發時引入相應的SDK或者Jar包，即可開發自己的業務應用。基于技術中臺幫助客戶建立了業務中臺，從而實現技術與業務的雙向聯動，整體架構如下圖：

firointcndl

Apipli^tiCih-中臺業務架構Security安全叫*肝村岫Middle-Pla-tfomn中M岫鈿firointcndl

Apipli^tiCih-中臺業務架構Security安全叫*肝村岫Middle-Pla-tfomn中M岫鈿我們采用DDD方法、事件風暴實踐對該企業業務進行重新梳理，采用微服務架構按業務領域進行劃分，建設全新業務系統，業務遷移采用微服務的絞殺者模式逐步對頻繁變化的業務優先絞殺遷移到新平臺，逐漸遷移，直到全到功能遷移到新平臺。開發過程基于敏捷開發的理念進行快速迭代，同時通過DevOps工具鏈實現快速開發、簡化微服務運維工作量。改造前該企業原有庫存業務各客戶端沒有統一服務化管理，APP端、小程序端各自維護，導致庫存頻繁出現超賣、分配不均等業務問題，第三方系統對接時不得不對接多套已有系統等技術問題。我們幫助客戶對其業務重新進行了梳理，重新設計了各業務微服務，統一了庫存微服務化管理，打造了庫存中臺，APP端、小程序端共享庫存中臺微服務，入口收斂、業務實現了統一。最終有效防止了庫存超賣、動態分配、全局共享等長期困擾客戶的業務痛點。庫存業務架構圖庫存業務架構圖關于我們:安暢網絡是中國市場專業的云托管服務商(CloudMSP),在數據中心和云計算領域有近十年的專業交付和管理經驗，目前正服務于2000多家企業級客戶并與全球多家超大