金融創新業務基於容器雲的微服務化實踐
此文已由作者劉超授權網易雲社群釋出。
歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。
雲計算髮展至今，從普通的虛擬化到 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 個應用一次性回滾。
容器服務是網易雲提供的無伺服器容器服務，讓企業能夠快速部署業務，輕鬆運維服務。容器服務支援彈性伸縮、垂直擴容、灰度升級、服務發現、服務編排、錯誤恢復及效能監測等功能。點選可免費試用。
更多網易技術、產品、運營經驗分享請點選。
相關文章：
【推薦】 用SolrJ操作Solr做搜尋（上篇）
【推薦】 教育產品-元件化視覺設計實踐