消費者雲CSE微服務實踐

內容來源：2017年11月9日，華爲架構師李林鋒在「華爲ServiceComb在線」進行《消費者雲ServiceComb微服務實踐》演講分享。IT 大咖說（id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2229 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT：suo.im/1hapHt

摘要

華爲架構師李林鋒分享華爲消費雲CSE的微服務實踐。

華爲消費者雲業務簡介

華爲消費者雲業務包括華爲應用市場、華爲視頻、華爲錢包、華爲運動健康等服務，爲華爲和榮耀手機提供精品雲服務，提高用戶體驗。

微服務框架技術選型——業務服務化目標

系統解耦，功能內聚，提高需求交付效率：經過業務的拆分和解耦，讓系統敏捷起來，快速、小批量的交付價值需求，提高業務的交付效率。

踐行API First：經過服務化，讓服務提供者和消費者之間經過微服務API創建契約，利用Swagger OpenAPI規範，最終將微服務API規範化、標準化、在線化。系統從傳統單體應用的黑盒調用（本地Java方法調用）轉變成透明的API契約調用。

服務自治：經過在線的微服務治理結合雲平臺，能夠實現微服務的彈性伸縮、故障自動遷移、降級熔斷等，保障微服務的運行質量，提高業務SLA。

創建服務化團隊：隨着業務的不斷拆分，大的研發團隊也會被拆分紅2-Pizza Team，微服務團隊由3-5人組成，負責整個微服務的設計、開發、測試、部署運維和治理，經過全功能團隊的建設，讓業務真正敏捷起來。

微服務框架技術選型——支持多語言

儘管如今以Java和GO語言爲主，可是從架構演進角度考慮，將來會根據消費者業務自身的特色引入更適合的語言。

服務框架不要綁定具體的語言實現，例如內部通訊協議使用某種語言特定的序列化機制、發佈泛型、抽象接口等。

微服務框架技術選型——靈活和輕量級架構

當前業務服務端都是非Web應用，因此不須要運行在Web容器中，須要相似Main函數能夠直接拉起來的Standalone模式。

服務框架要足夠輕量級，能夠按需加載類庫，防止不當前業務的三方庫發生衝突。

啓停速度要快（秒級彈性伸縮）、資源佔用要合理。

微服務框架技術選型——微服務安全

有些業務場景對微服務調用安全要求較高，須要微服務框架支持SSL傳輸、API鑑權和認證等。

對於一些敏感信息，例如用戶帳號、金額等，在記錄日誌等落盤和採集時須要作脫敏處理、資源佔用要合理。

敏感運維操做，須要記錄安全日誌，例如服務上線和下線、服務的流控閾值修改等。

微服務框架技術選型——服務治理能力

服務框架不能只單單解決分佈式RPC調用、服務註冊&發現和路由問題，更重要的是業務微服務上線以後，須要提供實用和豐富的在線治理能力。

流量控制、開發控制、超時控制、服務降級、服務熔斷、路由權重調整…

經常使用的服務治理能力要內置到服務框架中，業務領域強相關、非通用能力能夠經過擴展點實現。

微服務框架技術選型——易集成

當前業務使用Spring MVC等傳統的單體架構，但願能夠較平滑、低成本的遷移到微服務架構上。

從業務接受度上，但願不要翻天覆地的改變業務開發習慣，最好可以兼容原Spring MVC開發模式；從集成角度看，但願能夠靈活的與Spring Boot等框架集成。

微服務框架技術選型——高性能、低時延

雖然硬件成本已是白菜價，但軟件性能依然很重要。消費者雲業務服務集羣規模大，單點的性能提高可以帶來巨大收益。從用戶體驗看，端到端時延很是重要，分佈式以後帶來的時延增長，是一個很大的挑戰。

不是全部業務都有苛刻的性能需求，不一樣業務對性能的訴求不一樣，能夠按需選擇協議和傳輸方式，服務與傳輸協議、序列化方式解耦。

微服務框架技術選型——成熟

微服務框架採用的技術應該是通過驗證、業界主流的技術，例如網絡傳輸採用Netty。微服務框架自己要成熟，通過不一樣業務、較長時間的驗證，商用發佈的特性要穩定。不管是社區開源版本，仍是購買的商用軟件，或者本身構建，技術支持和保障必定要到位。

微服務框架技術選型——結果

咱們評估了業界主流的各類分佈式/微服務框架，最後選型了CSE，CSE可以很好的知足咱們的業務選型訴求。且CSE有更專業、簡單、安全、高效的商業版華爲雲微服務引擎，和一個充滿活力、人才雲集的與商業版同源的ServiceComb開源社區。

仔細閱讀了CSE的主要模塊代碼，包括網絡通訊、線程調度模型等，代碼質量很是高，對細節的把握比較好。

選型試用時，你們對CSE的接受度比較高，使用CSE改造已有的Spring MVC代碼相對較容易些。

華爲內部的平臺，不管是新需求接納，仍是技術支撐，各方面保障都比較給力。

天生支持Docker容器與華爲公有云，下降業務雲化成本。

CSE在消費者雲業務的實踐——可靠性

一、分佈式服務化自己引入的潛在故障點：

二、微服務第三方依賴潛在故障點：

CSE的可靠性設計：

集羣容錯，自動路由；

服務中心、配置中心無狀態集羣，宕機不影響已有業務；

支持服務級故障隔離；

支持多鏈路和鏈路級故障隔離；

支持服務熔斷和降級，以及第三方故障隔離（集成Hystrix）。

CSE在消費者雲業務的實踐——服務調用高性能

CSE的高性能設計：提供Rest和Highway RPC兩種通訊協議，知足不一樣業務場景。

高性能的Rest：集成Vertx,底層基於Netty，性能比傳統Servlet NIO性能高X倍。

HighwayRPC：採用Netty + PB，既支持多語言，又保證高性能。

高性能開發設計：線程綁定技術，網絡I/O線程綁定後端的服務調度線程，最大限度減小鎖競爭。採用鏈接池機制，重用已有的鏈接。

CSE在消費者雲業務的實踐——服務治理能力

爲何須要服務治理：隨着業務的發展，服務愈來愈多，如何協調線上運行的各個服務，保障服務的SLA，對服務架構和運維人員是一個很大的挑戰。

線上業務發生故障時，須要對故障業務作服務降級、流量控制、流量遷移等，快速恢復業務。

隨着開發團隊的不斷擴大，服務的上線愈來愈隨意，上線容易下線難，爲了規範服務的上線和下線，在服務發佈前，須要走服務預發佈流程，由架構師或者項目經理對須要上線的服務作發佈審覈，審覈經過的纔可以上線。

服務治理目的：知足服務上下線管控、保障微服務的高效、健康運行。

部分服務治理配置項：

今天的分享就到這裏，歡迎你們關注ServiceComb社區使用（http://servicecomb.io/cn/https://github.com/ServiceComb），也可到商業版華爲雲微服務引擎上進行體驗（http://www.huaweicloud.com/product/cse.html）。