此文已由作者劉超授權網易雲社群釋出。
歡迎通路網易雲社群，了解更多網易技術産品營運經驗。
雲計算發展至今，從普通的虛拟化到 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 進行加速。
第四步：去狀态化
容器化的前提是實作去狀态化。所謂去狀态化，就是将 Session 資料，檔案資料，結構化資料儲存在後端統一的存儲中，進而實作跨機房遷移和彈性伸縮。拜訪了多家金融客戶後發現，大部分都已經實作了去狀态化，可以直接進行後續的容器化。
第五步：容器化
容器有一個好處就是鏡像可以分層，如果團隊也按照分層來進行分工的話，可以提高整個團隊的效率。比如，核心人員可以做偏向核心的鏡像開發，外層人員基于内層做好的鏡像，把 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 中，配置隻要在代碼中送出了，就可以自動下發。
第十三步：水準擴充
一旦容器化了之後，就可以實作全架構的彈性伸縮。
應用層因為無狀态可以進行橫向彈性擴充，從 5 個節點隻要改一個數字就能變成 50 個節點。
緩存層可以通過叢集機制進行橫向擴充。資料庫層可以通過分布式資料庫 DDB 進行橫向擴充。
第十四步：基于代碼倉庫的持續內建
線上的每一個環境都應該對應代碼中的一個分支，不提倡也不允許使用者在環境中進行手動修改，容易忘也不容易交接，所有操作都應該放在代碼中做，通過送出代碼，代碼做自動釋出，自動部署，使得新的配置或新的權限都能釋出到新的環境。
第十五步：部署依賴與釋出依賴
當單體應用拆分為多個微服務之後，服務的部署，更新，更新，復原變的非常複雜。網易給出的方案是将編排檔案儲存在 Git 裡面，在編排檔案中維護不同服務之間的部署依賴和釋出依賴，例如一次性釋出 100 個應用其中的 5 個應用，可以通過在修改 Git 中編排檔案中的 5 個服務進行，并在發現異常的時候，可通過 Git 復原一個送出的方式，将 5 個應用一次性復原。
容器服務是網易雲提供的無伺服器容器服務，讓企業能夠快速部署業務，輕松運維服務。容器服務支援彈性伸縮、垂直擴容、灰階更新、服務發現、服務編排、錯誤恢複及性能監測等功能。點選可免費試用。
免費體驗雲安全(易盾)内容安全、驗證碼等服務
更多網易技術、産品、營運經驗分享請點選。
相關文章：
【推薦】 網易雲易盾朱浩齊：視聽行業步入強監管和智能時代
【推薦】 盤點大資料在遊戲行業中的應用
【推薦】 為何要在網站上設定的驗證碼