內容來源：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在消費者雲業務的實踐——可靠性
1、分散式服務化本身引入的潛在故障點：
2、微服務第三方依賴潛在故障點：
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）。