微服務專案實踐之中建專案

導讀：本文介紹了中建專案上雲的過程，包括原有業務架構分析、遷移目標制定和遷移方案制定，上雲的相關流程和規範。詳細說明了上雲後的部署形態和微服務優化分析。

1.中建專案簡介：

  中建專案全程是“用友建築分公司上雲專案”目標是支撐建築分公司將原有技術架構遷移到用友雲的專屬雲上，完成上雲過程，因此該專案是一場支援建築分公司的“友誼戰”。

  用友建築是用友股份的旗下子公司，在子公司“上雲”戰役中，中建是第一個從其他框架遷移到微服務的，支撐好中建專案的重要意義不言而喻；

  中建專案的遷移過程中遇到很多問題，比如：微服務框架相容性問題、原專案規範如日誌規範改變問題、開發者中心和微服務在一些細節方面使用者提示不夠人性化、環境本身問題等；

  在模組多時間緊的情況下，建築分公司將平臺和模組劃分給團隊，落實到每個人負責遷移的專案；股份公司雲平臺也劃分開發者中心和微服務給不同人員，分別通過矚目遠端會議，去武漢分公司出差及駐留北京建築分公司的方式將問題一一排查和解決。

  中建專案進展順利，建築同事和股份公司雲平臺同事群策群力，目標一致，基情滿滿，齊頭並進一起加班是專案組的真實寫照。

2.用友建築上雲過程：

  用友建築上雲過程有以下步驟：分析建築的原有平臺業務和技術框架、制定了相關遷移目標及方案、上雲實施及規範依據。

  2.1原有業務架構分析：

  用友建築平臺模組劃分：

  用友建築原有系統架構：

  2.2遷移目標制定：

  針對用友建築的當前情況，並且應總部818完成上線的要求，制定了遷移目標：

  （1）首先遷移iCOP基礎平臺和i建造業務模組，i設計、i紀檢、i審計及i合約這四個業務平臺暫不做遷移；

  （2）iCOP基礎平臺在原有環境保留一份以支援未遷移的i設計、i紀檢、i審計及i合約；

  （3）並且首先在測試環境完成遷移和功能測試，並做切流測試；

  （4）完成後將方案應用到線上環境，完成線上環境切流遷移。

  2.3遷移方案制定：

  遷移的技術方案制定：

  o針對用友建築原有的Dubbo框架，制定了遷移到用友雲微服務遷移方案：

  ·iCOP基礎平臺和i建造改造原有程式碼，使用profile機制分別編譯出Dubbo及用友微服務兩套程式碼。

  ·使用iris-dubbo-support元件支援使用dubbo的配置方式配置用友微服務。

  o針對用友建築原有的SpringCloudConfig方案，為相容用友雲微服務制定了外掛方案：

  o同一jenkins部署測試環境和線上環境的方案：

  ·針對用友雲持續整合外掛app-upload-plugin設定推送到開發者中心的環境地址；

  2.4上雲相關流程/規範：

  建築上雲流程：

  o部署資源設定大小參考：

3.用友建築上雲後……

  3.1上雲後的部署形態：

  3.2上雲後的微服務優化分析：

  傳統業務遷移到用友雲後，用友雲提供的各類功能有針對性的對微服務的各個維度進行分析和管理：

  通過以上功能分析出業務潛在的問題，為微服務解耦和效能優化提供了參考依據，舉個例子：

  ·通過微服務依賴統計呼叫圖分析出被嚴重依賴的微服務和頻繁呼叫的微服務，如下圖中的icop-orgcenter-web無論在被依賴程度還是被呼叫次數上都是第一，屬於重點解耦和優化物件。

  ·根據微服務熱力圖直觀的看出耦合程度和被呼叫次數（被呼叫次數與顏色成正比： 綠<藍<黃<紅<深紅）：

  ·並且統計出了業務的潛在頻繁呼叫問題：

  自上線後的一週內所有專案共發起RPC呼叫21593770次，但約90％的RPC集中在一個API，大部分API的RPC呼叫都在0-2萬次之間。

  以下是呼叫次數超過兩萬的相關API統計：

4.總結：建築上雲1+1，賦能用友建築雲   用友雲-專屬雲提供的能力支援：

  建築服務上雲，用友雲提供DevOps最佳實踐和微服務框架及分析機制，統一的監控平臺和運維規範，提供自動化、智慧化開發運維機制，最終實現1+1大於2的效果，助力用友建築業務更快更好發展。