6月24日-25日， 由雙態運維聯盟主辦， 中國電子工業標準技術協會資訊技術服務分會資料中心運營管理工作組(簡稱：ITSS-DCMG)指導， 12家聯盟創始成員聯合承辦的"2017中國雙態運維大會·烏鎮峰會"落下帷幕。
本次峰會圍繞雙態IT環境， 為企業IT運維升級轉型提供方法指導及最佳實踐參考， 來自國家部委、大型央企、金融Top10、證券保險、高端製造業等超400位企業的資料中心負責人、運維負責人、科技部的領導首次同台論道。 網易雲作為國內領先的雲服務提供者， 受邀出席本次大會， 網易雲解決方案總架構師劉超在雲計算專題研討中發表了題為《金融創新業務基於容器雲的微服務化案例分享》的演講，
雲計算發展至今， 從普通的虛擬化到OpenStack再到容器雲， 解決方案的設計日趨複雜， 尤其是容器雲和微服務化的解決方案， 已經不像傳統的解決方案， 給客戶講解一下就可以進行招標了， 需要和對方技術人員真正地“短兵相接”， 瞭解客戶的架構和痛點， 以及流程中的問題， 並給出建議， 才能完成解決方案的工作。
金融行業對安全要求很高， 所以傳統金融業務對容器雲解決方案都是心存疑慮的， 但是傳統金融行業也在慢慢地互聯網化， 因為互聯網金融企業已經帶來了很大的衝擊， 他們會採取各種策略進行創新性的實驗。 劉超通過網易雲一個真實的金融客戶案例， 分享了傳統金融客戶進行創新業務的實踐和經驗。 這個客戶有非常強的訴求去嘗試創新業務， 不但要面臨傳統金融企業安全、高可用、容災和簡化運維的基本需求， 還需要應對互聯網化的新挑戰，
比如這個客戶的業務之前主要在本省， 隨著互聯網化的發展， 希望將業務擴展到更多的地區， 但是經過計算發現原來的系統無法支撐未來的業務規劃；此外， 他們開始舉辦一些線上秒殺理財產品的活動， 突發的流量讓他們始料未及。 這時微服務架構及相關技術進入了他們的視線， 由於缺乏相關技術人才和經驗的支援， 這個客戶開始了和網易雲的合作。
網易有很多內部的產品如網易雲音樂， 雲課堂， 考拉， 嚴選等都進行過微服務化改造， 積累了豐富的經驗。 在這些內部應用上雲的過程中，
網易雲基礎服務架構團隊根據多年的實踐經驗， 出版《雲原生應用架構實踐》一書，
網易雲解決方案團隊則根據知識體系， 結合內部真實案例， 輸出了如下培訓課程與諮詢方案。
對於某個特定的客戶， 網易雲有完善的知識輸出流程。
通過和這個客戶多次交流， 根據客戶的實際情況， 網易雲總結出了針對金融行業的微服務改造方案和規劃， 在這裡分享給大家。
第一步：專案工程化
專案工程化是指整個業務流程和上線流程必須要能夠自動化，實現持續集成。如果不能做到這一點，盲目地去拆微服務，是十分危險的。這個客戶最初工程化做得不是特別好，僅實現了部分的自動化。
微服務拆分的過程中會進行大規模的代碼改動，改動的時候能否遵循代碼規範是一個疑問，所以如果沒有第二個步驟——代碼審核，會使得代碼品質失控。另一方面是單元測試的覆蓋率太低，而且沒有自動化的測試，微服務拆完之後功能還是不是原來的功能，如果沒有足夠的測試用例，很難證明。要做到自動化，環境部署和自動化部署又會成為一個問題。這個客戶目前用腳本實現了自動化部署，在隔離性、埠衝突上都有一些問題。
第二步：框架的選擇
目前有兩個主流的微服務框架：Spring Cloud和Dubbo。Dubbo誕生較早，所以用的人也更多，而Spring Cloud目前的關注度更高。
劉超認為應該從以下幾個角度去考慮技術的選型：
業務相關性；
文檔與社區支持，目前由於Dubbo熱度的下降，社區的支持也在慢慢減少，從這個角度來說劉超更推薦Spring Cloud；
可擴展性；
許可證；
學習曲線；
框架流行度，如果你採用流行的框架會獲取兩個先天優勢：容易招人，遇到問題也更容易在社區得到答案。
但是這個客戶最終還是選擇了Dubbo，因為他們的技術負責人對Dubbo很熟悉。劉超也特別強調了這一點：在專案管理中，不論選擇哪個開發的框架，都要保證團隊中至少有一個人對這個框架很熟，這會大幅度降低風險。
另外，服務間的調用，Spring Cloud採用的是Restful API，Dubbo採用預設的RPC方式。劉超建議用Restful API的方式，因為如果用RPC會存在一個問題：用戶端的調用方和被調用方要共用一個Jar包，負責對資料進行封裝和解封裝。但當微服務拆得非常多的時候，Jar包的維護會變得非常困難，經常出現衝突。而Restful API基於Jason，是一種松耦合的架構方式，相對來說可以比較好的解決Java中Jar包衝突的問題。
第三步：API和UI介面的隔離
可能很多人覺得這是不必要的，實際上更好的設計方式是：
UI層所有的展現方式都去調用後面的API層來做，API層要儘量的原子化，這樣的好處是可以在API層實現自動化測試；
API層的認證鑒權；
UI層靜態頁面和動態頁面分離，使用物件存儲和CDN進行加速。
第四步：去狀態化
容器化可以解決部署過程中的埠衝突問題，容器化的前提是實現去狀態化。劉超拜訪了多家金融客戶後發現，大部分都已經實現了去狀態化，可以直接進行後續的容器化。
第五步：容器化
容器有一個好處就是鏡像可以分層，如果團隊也按照分層來進行分工的話，可以提高整個團隊的效率。比如，核心人員可以做偏向內核的鏡像開發，外層人員基於內層做好的鏡像，把Jar放進去就好了。這時只需要核心人員掌握容器的核心技術即可，降低了學習成本。
第六步：基於容器的持續集成
這個階段暫時並不需要一個容器的管理平臺，原來是用腳本來部署應用，現在用容器編排的方式來部署，原來在一台機器上啟動20個進程，所有埠都是衝突的；現在啟動20個容器所有埠都不衝突，每個Tomcat都可以用8080埠，可以相互調用，就可以進行自動化的測試，整個運維也會非常簡單。並且容器使得整個開發、測試和生產的環境是一致的。
第七步：資料庫讀寫分離與使用緩存
資料庫永遠是應用最關鍵的一環，資料庫必須要高可用，同時越到高併發階段，資料庫往往成為瓶頸，如果資料庫表和索引不在一開始就進行良好的設計，則後期資料庫橫向擴展，分庫分表都會遇到困難。資料庫往往寫少讀多，所以性能優化的第一步就是讀寫分離。
在高併發場景下，需要通過緩存來減少資料庫的壓力，使得大量的訪問進來能夠命中緩存，只有少量的需要到資料庫層。由於緩存基於記憶體，可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計，緩存的設計時必不可少的一環。
第八步：API Gateway
在拆分之前，建議使用API Gateway，如果有了服務閘道，後面的服務不論怎麼拆分與合併，對於用戶端來講都是透明的，方便後續的服務拆分。
第九步：服務拆分與服務發現
開發獨立: 代碼耦合度比較高，修改代碼通常會對多個模組產生影響，操控難度大，風險高；
上線獨立: 單次上線需求列表多，上線時間長，影響面大；
簡化擴容: 由於業務多，每一次擴容需要增加的配置比較雜。一些不起眼的小業務雖然不是擴容的主要目的，也需要慎重考慮；
容災降級:核心業務與非核心業務耦合，在關鍵時候互相影響。
第十步：使用容器管理平臺實現服務編排
例如一個應用包含四個服務A,B,C,D，她們相互引用，相互依賴，如果使用了kubernetes，則服務之間的服務發現就可以通過服務名進行了。例如A服務調用B服務，不需要知道B服務的IP位址，只需要在設定檔裡面寫入B服務服務名就可以了。如果中間的節點宕機了，kubernetes會自動將上面的服務在另外的機器上啟動起來。容器啟動之後，容器的IP位址就變了，但是不用擔心，kubernetes會自動將服務名B和新的IP位址映射好，A服務並無感知。這個過程叫做自修復和自發現。如果服務B遭遇了性能瓶頸，三個B服務才能支撐一個A服務，也不需要特殊配置，只需要將服務B的數量設置為3，A還是只需要訪問服務B，kubernetes會自動選擇其中一個進行訪問，這個過程稱為彈性擴展和負載均衡。
第十一步：統一日誌收集
當單體應用拆分為多個微服務之後，不能再單獨查看每個服務的日誌，因為工作量太大。必須將日誌彙集到統一的日誌中心進行統一的管理，查詢，排錯，視圖等。
第十二步：配置中心
應用多了就希望實現配置的集中下發，將配置放到統一的consul中，配置只要在代碼中提交了，就可以自動下發。
第十三步：水準擴展
第十四步：基於代碼倉庫的持續集成
線上的每一個環境都應該對應代碼中的一個分支，不提倡也不允許用戶在環境中進行手動修改，容易忘也不容易交接，所有操作都應該放在代碼中做，通過提交代碼，代碼做自動發佈，自動部署，使得新的配置或新的許可權都能發佈到新的環境。
第十五步：部署依賴與發佈依賴
當單體應用拆分為多個微服務之後，服務的部署，更新，升級，回滾變的非常複雜。網易給出的方案是將編排檔保存在Git裡面，在編排檔中維護不同服務之間的部署依賴和發佈依賴，例如一次性發佈100個應用其中的5個應用，可以通過在修改Git中編排檔中的5個服務進行，並在發現異常的時候，可通過Git回滾一個提交的方式，將5個應用一次性回滾。
最後，劉超介紹了網易雲容器平臺的優勢：
1.安全隔離：不同租戶主機隔離，內核隔離，虛擬網路隔離
2. 高性能：網路和存儲無二次虛擬化，保證高輸送量
3. 大規模單容器集群，統一由雲平臺運維，使用者僅僅需要關注應用
4. 大規模容器集群統一APM，監控，日誌ELK
以上由網易企業資訊化服務提供者，湖南領先網路科技整理發佈。
網易企業服務（qiye163.co）是網易憑藉其20年品牌優勢與經驗在企業郵箱的基礎上，為進一步佈局企業市場而打造的企業級產品矩陣，致力於提供一站式企業資訊化解決方案。湖南領先網路科技是網易企業產品授權經銷商，專業為企業提供網易企業郵箱、網易辦公套件等一站式企業資訊化專業解決方案。辦理網易企業郵箱及旗下企業產品相關業務，就找湖南領先網路科技。
專案工程化是指整個業務流程和上線流程必須要能夠自動化，實現持續集成。如果不能做到這一點，盲目地去拆微服務，是十分危險的。這個客戶最初工程化做得不是特別好，僅實現了部分的自動化。
微服務拆分的過程中會進行大規模的代碼改動，改動的時候能否遵循代碼規範是一個疑問，所以如果沒有第二個步驟——代碼審核，會使得代碼品質失控。另一方面是單元測試的覆蓋率太低，而且沒有自動化的測試，微服務拆完之後功能還是不是原來的功能，如果沒有足夠的測試用例，很難證明。要做到自動化，環境部署和自動化部署又會成為一個問題。這個客戶目前用腳本實現了自動化部署，在隔離性、埠衝突上都有一些問題。
第二步：框架的選擇
目前有兩個主流的微服務框架：Spring Cloud和Dubbo。Dubbo誕生較早，所以用的人也更多，而Spring Cloud目前的關注度更高。
劉超認為應該從以下幾個角度去考慮技術的選型：
業務相關性；
文檔與社區支持，目前由於Dubbo熱度的下降，社區的支持也在慢慢減少，從這個角度來說劉超更推薦Spring Cloud；
可擴展性；
許可證；
學習曲線；
框架流行度，如果你採用流行的框架會獲取兩個先天優勢：容易招人，遇到問題也更容易在社區得到答案。
但是這個客戶最終還是選擇了Dubbo，因為他們的技術負責人對Dubbo很熟悉。劉超也特別強調了這一點：在專案管理中，不論選擇哪個開發的框架，都要保證團隊中至少有一個人對這個框架很熟，這會大幅度降低風險。
另外，服務間的調用，Spring Cloud採用的是Restful API，Dubbo採用預設的RPC方式。劉超建議用Restful API的方式，因為如果用RPC會存在一個問題：用戶端的調用方和被調用方要共用一個Jar包，負責對資料進行封裝和解封裝。但當微服務拆得非常多的時候，Jar包的維護會變得非常困難，經常出現衝突。而Restful API基於Jason，是一種松耦合的架構方式，相對來說可以比較好的解決Java中Jar包衝突的問題。
第三步：API和UI介面的隔離
可能很多人覺得這是不必要的，實際上更好的設計方式是：
UI層所有的展現方式都去調用後面的API層來做，API層要儘量的原子化，這樣的好處是可以在API層實現自動化測試；
API層的認證鑒權；
UI層靜態頁面和動態頁面分離，使用物件存儲和CDN進行加速。
第四步：去狀態化
容器化可以解決部署過程中的埠衝突問題，容器化的前提是實現去狀態化。劉超拜訪了多家金融客戶後發現，大部分都已經實現了去狀態化，可以直接進行後續的容器化。
第五步：容器化
容器有一個好處就是鏡像可以分層，如果團隊也按照分層來進行分工的話，可以提高整個團隊的效率。比如，核心人員可以做偏向內核的鏡像開發，外層人員基於內層做好的鏡像，把Jar放進去就好了。這時只需要核心人員掌握容器的核心技術即可，降低了學習成本。
第六步：基於容器的持續集成
這個階段暫時並不需要一個容器的管理平臺，原來是用腳本來部署應用，現在用容器編排的方式來部署，原來在一台機器上啟動20個進程，所有埠都是衝突的；現在啟動20個容器所有埠都不衝突，每個Tomcat都可以用8080埠，可以相互調用，就可以進行自動化的測試，整個運維也會非常簡單。並且容器使得整個開發、測試和生產的環境是一致的。
第七步：資料庫讀寫分離與使用緩存
資料庫永遠是應用最關鍵的一環，資料庫必須要高可用，同時越到高併發階段，資料庫往往成為瓶頸，如果資料庫表和索引不在一開始就進行良好的設計，則後期資料庫橫向擴展，分庫分表都會遇到困難。資料庫往往寫少讀多，所以性能優化的第一步就是讀寫分離。
在高併發場景下，需要通過緩存來減少資料庫的壓力，使得大量的訪問進來能夠命中緩存，只有少量的需要到資料庫層。由於緩存基於記憶體，可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計，緩存的設計時必不可少的一環。
第八步：API Gateway
在拆分之前，建議使用API Gateway，如果有了服務閘道，後面的服務不論怎麼拆分與合併，對於用戶端來講都是透明的，方便後續的服務拆分。
第九步：服務拆分與服務發現
開發獨立: 代碼耦合度比較高，修改代碼通常會對多個模組產生影響，操控難度大，風險高；
上線獨立: 單次上線需求列表多，上線時間長，影響面大；
簡化擴容: 由於業務多，每一次擴容需要增加的配置比較雜。一些不起眼的小業務雖然不是擴容的主要目的，也需要慎重考慮；
容災降級:核心業務與非核心業務耦合，在關鍵時候互相影響。
第十步：使用容器管理平臺實現服務編排
例如一個應用包含四個服務A,B,C,D，她們相互引用，相互依賴，如果使用了kubernetes，則服務之間的服務發現就可以通過服務名進行了。例如A服務調用B服務，不需要知道B服務的IP位址，只需要在設定檔裡面寫入B服務服務名就可以了。如果中間的節點宕機了，kubernetes會自動將上面的服務在另外的機器上啟動起來。容器啟動之後，容器的IP位址就變了，但是不用擔心，kubernetes會自動將服務名B和新的IP位址映射好，A服務並無感知。這個過程叫做自修復和自發現。如果服務B遭遇了性能瓶頸，三個B服務才能支撐一個A服務，也不需要特殊配置，只需要將服務B的數量設置為3，A還是只需要訪問服務B，kubernetes會自動選擇其中一個進行訪問，這個過程稱為彈性擴展和負載均衡。
第十一步：統一日誌收集
當單體應用拆分為多個微服務之後，不能再單獨查看每個服務的日誌，因為工作量太大。必須將日誌彙集到統一的日誌中心進行統一的管理，查詢，排錯，視圖等。
第十二步：配置中心
應用多了就希望實現配置的集中下發，將配置放到統一的consul中，配置只要在代碼中提交了，就可以自動下發。
第十三步：水準擴展
第十四步：基於代碼倉庫的持續集成
線上的每一個環境都應該對應代碼中的一個分支，不提倡也不允許用戶在環境中進行手動修改，容易忘也不容易交接，所有操作都應該放在代碼中做，通過提交代碼，代碼做自動發佈，自動部署，使得新的配置或新的許可權都能發佈到新的環境。
第十五步：部署依賴與發佈依賴
當單體應用拆分為多個微服務之後，服務的部署，更新，升級，回滾變的非常複雜。網易給出的方案是將編排檔保存在Git裡面，在編排檔中維護不同服務之間的部署依賴和發佈依賴，例如一次性發佈100個應用其中的5個應用，可以通過在修改Git中編排檔中的5個服務進行，並在發現異常的時候，可通過Git回滾一個提交的方式，將5個應用一次性回滾。
最後，劉超介紹了網易雲容器平臺的優勢：
1.安全隔離：不同租戶主機隔離，內核隔離，虛擬網路隔離
2. 高性能：網路和存儲無二次虛擬化，保證高輸送量
3. 大規模單容器集群，統一由雲平臺運維，使用者僅僅需要關注應用
4. 大規模容器集群統一APM，監控，日誌ELK
以上由網易企業資訊化服務提供者，湖南領先網路科技整理發佈。
網易企業服務（qiye163.co）是網易憑藉其20年品牌優勢與經驗在企業郵箱的基礎上，為進一步佈局企業市場而打造的企業級產品矩陣，致力於提供一站式企業資訊化解決方案。湖南領先網路科技是網易企業產品授權經銷商，專業為企業提供網易企業郵箱、網易辦公套件等一站式企業資訊化專業解決方案。辦理網易企業郵箱及旗下企業產品相關業務，就找湖南領先網路科技。