談談華為微服務解決方案與實踐

華為云微服務引擎的前世今生

華為從12年開始在很多創新項目里應用微服務技術，在14年隨著微服務框架技術越來越成熟，工具越來越完善，公司各個產品線開始基于微服務框架做云化產品，16年的時候公司為了更好的進行能力共享，決策把散落在公司各個產品線的一些與微服務相關的工具、平臺、框架和團隊統一整合成華為公司級paas平臺重要組成的一部分，專門負責微服務平臺的交付和技術演進，統一支撐整個華為公司產品微服務化轉型，在17年隨著云BU的成立，公司就把這個內部微服務能力以云服務的形式放到華為云上開放出來，這樣可以讓業界更多的企業和開發者能更方便的使用微服務技術，少走彎路。截止當前華為無線、云核心網、消費者云等基于此微服務框架都已完成云化及商用。

微服務在業界的使用狀況

下面這張圖是著名的開源軟件Nginx，在官網面向全球開發者做的一次關于微服務使用情況的調研，從這份數據可以看到，目前接近70%的開發者正在使用或試用微服務技術，其中接近30%的企業已經在生產環境中使用微服務， 也就是說微服務早已經過

了概念炒作階段，已經是實實在在地進入到了成熟商用階段。其實，從華為內部看，微服務解決方案目前已廣泛應用于華為消費者云、無線產品線5G、企業智能EI、內部流程IT、云核大視頻等等核心產品領域，是公司業務全面云化的基座。

為什么要用微服務

在講為什么要用微服務前，先看看企業的原始業務訴求有哪些？隨著云化和互聯網技術的發展，企業的it部門從原來的成本中心轉變成生產中心，如何將客戶需求和軟件價值更快的交付到客戶手中成為企業的核心競爭力之一，以前是大魚吃小魚，現在是快魚吃慢魚；現代軟件應用的領域越來越廣，無論是工作，生活還是娛樂，這些應用（特別是消費類應用）有些會有明顯的流量波峰波谷，例如游戲一般在工作日和白天玩的少，而在休息日和晚上玩的多，還有一些應用無法預期流量，可能大部分時間流量一直穩定，而一個意外事件的發生就會導致流量指數級增長，無論是哪一種場景，都要求應用架構能具備更好的彈性能力來保證業務的可用性；經過這么一波互聯網技術洗禮之后，行業邊界正變得越來越模糊，很多企業特別是傳統行業都希望通過業務創新獲取新的增長點，而我們都知道業務創新九死一生，那么低成本的快速試錯是迫切追求的，怎么樣低成本，其實從IT部門視角來看，如果能基于團隊已有的技能，重用企業已有的技術資產（比如投資了很貴的技術平臺軟件），這就是節省成本，另外一點，不同行業不同領域都有不同技術棧，舉個對程序員最能理解的例子，開發語言沒有絕對的好壞，例如java，c++，python，go等都有它最適合的場景，大多企業的技術決策者都希望能用最合適的技術去匹配業務，所以在選擇能支撐未來業務持續發展的基礎性框架和平臺產品時，對技術開放性的考量也是至關重要的。

另外，從很多客戶（包括華為內部的業務團隊，以及外部的合作伙伴和各種類型的企業客戶），還反饋了這樣一些訴求，例如：高可用性、容錯性、可管理性、可替代性、可測試性、組織擴張、架構彈性。。。。。。其實從這些反饋不難看出，業界對微服務的訴求不僅僅是需要某個單點問題或一個工具套件，而更多的是希望通過微服務這種新的研發理念來改變整個研發活動的方方面面，包括技術、組織和流程的變革。

從最終的業務視角來看，我們認為微服務的價值可以簡單總結為三個詞，即：更快、更穩、更經濟。微服務的本質是化繁為簡，分而治之，從而加快企業創新。

更快，是指業務上線的速度，使用微服務能把業務上線周期從年降到月、周，甚至是隨時上線；更穩，是指系統可用性，基于微服務構建的系統能把系統SLA從3個9提升到4個9、5個9，甚至永不斷服；更經濟，是指業務的資源成本，基于微服務更細粒度的彈性，能實現業務規模擴張與資源支出的最佳平衡。

借用赤壁之戰這個耳熟能詳的典故，可以更形象的理解微服務與傳統單體架構的區別：如果一千多年以前曹操不把自己的百萬大軍用鐵鏈連成一個像單體應用一樣的整體，而是讓每條船像微服務一樣，能獨立指揮獨立作戰，也許就不會被孫劉的一把火燒的這么狼狽。

微服務帶來哪些新的挑戰

任何事務都有兩面性，微服務也不例外。從我們經歷的這么多實踐項目來看，微服務主要帶來的挑戰如下：

微服務本身也屬于分布式技術的一種，分布式系統對編程的門檻其實是很高的，傳統的單體應用因為是單進程，組件A與組件B的進程內調用只需使用編程語言的語法，一行簡單的代碼就能搞定，根本就不用考慮服務發現、負載均衡、限流容錯等等技術，但是在微服務系統里，服務A調服務B時，首先要找到服務B在哪里，有可能服務A和B部署在同一個節點上，也有可能服務A部署在深圳，而服務B部署在北京的一個機房，所以服務的注冊發現是微服務應用開發人員需要解決的第一個問題，找到服務B以后，有可能服務B是多實例部署，這時候又需要在多個服務實例中找一個最合適的實例來處理請求，那么這就涉及到第二個問題：負載均衡，后面還有服務調用失敗了要考慮服務容錯，還有服務限流、服務降級、分布式事務等等諸多復雜的分布式技術問題，如果我們把這些問題都留給業務開發人員，顯然業務開發是快不起來的，這就是微服務化之后面臨的第一個問題：如何基于微服務架構高效開發和上線。

從一個單體應用拆分成多個獨立運行的微服務應用，從理論上來說，系統的故障點是增多的，用戶請求的每一跳都有可能出錯，特別是在資源受限的大規模流量沖擊下，這又引入微服務化后的第二個問題：如何在不可預期的流量下如何保證業務的高可靠運行。

而微服務系統的運維是個更顯而易見的問題，一般傳統的單體應用問題定位過程是這樣的：首先登錄到出故障的應用節點，然后找到應用的相關日志文件，導出到本地后就可以使用各種文本工具進行日志分析和問題定位，整個過程很簡單，人工就能搞定，但在微服務系統中，特別是在動輒上百個微服務和實例部署的場景下，一個業務請求很可能跨越了多個微服務多個實例多個節點，別說定位問題，就是先搞定問題定界都很難，這時候如果沒有一個自動化的工具或平臺來支撐，靠人力是不可能完成的任務。

最后是一個非常現實的問題，特別是在傳統企業里面，都會有一些遺留的資產或運行中的業務系統，不可能把這些都推倒重來，不僅成本太高，而且業務風險也大。如何將傳統架構下的遺留系統低成本的向微服務架構遷移也是微服務解決方案需要系統考慮的。

同時真正要實施好微服務，對企業的組織架構、業務流程以及人的素質模型都提出了新的要求，所以向微服務轉型是一個企業系統性的變革活動。

華為微服務解決方案是什么

華為微服務產品包含一套微服務開發框架、一站式微服務監控與治理平臺以及一系列配套的微服務開發工具，主要功能如下：

l?? 基于契約(Open API)的開發模式：讓微服務的開發、測試、文檔、協作和管控活動標準化、自動化

l?? 高性能REST/RPC微服務開發框架：打包了微服務注冊、發現、通信和治理等基礎能力，開箱即用

l?? 一站式微服務治理控制臺：提供微服務負載均衡、限流、降級、熔斷、容錯、錯誤注入等治理能力

l?? 非侵入式微服務：提供Mesher服務，可實現多語言微服務解決方案，以及遺留系統零改造微服務化

l?? 多樣化微服務安全管控能力：提供認證鑒權、黑白名單等能力保障微服務訪問安全

l?? 灰度發布支持業務平滑升級：支持使用接口任意參數（例如用戶群組、用戶類別、用戶所屬區域等等）定義微服務灰度發布規則

l?? 微服務調用追蹤：提供微服務實例和接口級吞吐量、時延和成功率的實時監控及調用鏈分析

這套微服務產品完全是從公司各條業務戰線上提煉而來，自始至終貫徹易用、開放、多場景和企業級的理念進行設計和演進的：因為要服務于內部數萬微服務開發者，這些開發者的能力參差不齊，如果不易用門檻不放低，使用和推廣成本就會非常高；因為要服務于內部各種不同類型的業務，如運營商、企業、消費者、流程IT等，如果架構不開放就無法做到基于一套框架靈活定制按需使用；因為除了要滿足新業務開發、也要滿足老業務平滑遷移、還要滿足和三方系統方便集成，如果不能適應多場景，不考慮平滑演進，應用范圍就會非常的窄；因為公司基本上所有業務都是全球交付，在性能、可用性、安全性上不做到企業級就根本沒法商用。同時基于華為聚焦微服務技術領域多年的持續投入，目前已在多個方面做到了業界或國內首創，例如：面向國內提供了首個多語言微服務框架，首個商業版Service Mesh產品，并大規模應用于生產環境；業界首個進入Apache開源社區的微服務框架ServiceComb。

另外，我們也有一個專業的微服務評估（參考下圖，已在華為云上開放自助評估服務）和咨詢團隊，能幫助企業完成從微服務適用性評估、服務劃分到落地實施（平臺和工具使用支撐）等微服務化轉型端到端的解決方案。

華為微服務框架與開源框架的區別

可能還有很多人會有這樣的疑問：我之前用開源框架好好的為什么華為還要重復造個輪子？這個就要回顧華為微服務框架的發展歷程了，起初華為也是拿開源框架改吧改吧就用了，但是在支撐公司內部各種業務的過程中發現了不少問題，簡單羅列幾點，一是語言綁定，當前開發語言層出不窮，其本身就說明業務對開發語言是有訴求的（不同的業務需要合適的語言來開發），同時特別是在云服務生態里，對不同語言開發的微服務能夠方便的互通成了基本要求；二是協議支持單一，基本要么只支持RPC，要么只支持REST，而實際有的場景仍然在使用或需要傳統的Web Service（例如SOAP等等）協議，有的場景為追求極致的性能都有自己深度定制的私有協議，有的場景面向不同接入方式需要同時發布多種協議的服務接口；三是性能和易用性問題，例如Spring Cloud把微服務的各種能力（列如注冊發現，路由管控，能力接入等等）都拆分成了獨立的部件由使用者根據實際場景來組合使用，其本身確實提供了極大的靈活性，但靈活性的背面是復雜性，對人員能力的要求較高，同時其性能（例如并發量和時延）并不樂觀，在一些要求苛刻的場景顯得力不從心。

總之，太多經驗表明，把一堆開源軟件包變成可用，再到可商用，中間有太多的坑需要填平，華為就是這樣填著填著，后來發現基本變成了一個新的東西。事實上，我們在開源基礎上提供了十多項關鍵能力的增強，這些也都是從我們經歷過的一些活生生的經驗教訓，交了無數學費后總結而來。

對比項

華為云微服務引擎

基于開源Spring Cloud自建

管理界面

提供一站式微服務管理控制臺，包含服務目錄、服務治理、服務配置、事務看板及新服務創建等簡單易用的Web操作界面

需自行開發UI控制臺，代碼量2萬多行

開發語言

支持JAVA、Go、PHP、.NET、Python、NodeJS及其他多種主流開發語言

只支持JAVA

通信協議

REST/RPC/gRPC/可擴展

REST

Service Mesh

提供商業版Mesher，支持一鍵式部署

無

易用性

只需導入華為微服務SDK即可享受各種服務治理和管控能力，包括負載均衡、故障隔離、容錯機制、流量控制、調用鏈跟蹤和服務狀態儀表盤等，這些功能與業務代碼完全解耦，用戶只需專注業務開發

基于Spring Boot/Cloud組件構建，需要集成驗證Hystrix、Ribbon、Zipkin、Prometheus等大量三方組件，門檻高，學習周期長

服務注冊

提供了對微服務靜態元數據豐富的管理能力，例如支持應用>微服務>實例的層次關系管理、版本管理、tag管理、灰度發布以及服務拓撲，同時提供了對大規模企業級微服務管理

提供Eureka組件，需自行開發封裝成服務使用，僅是管理動態路由數據

動態配置

提供多維數據建模的方式組織配置信息，對于配置信息的描述能力更強，擴展能力更好。另外同時支持了push和pull的配置變更通知方式，實時性更好

提供Spring Cloud Config組件，需自行開發封裝成服務使用，配置描述能力弱，且實時性不好

服務治理

支持更細粒度（接口級）的服務治理能力。并且實現了實例訪問錯誤重試和隔離、多數據中心間服務發現的優先級等其他治理能力。另外，對于這些開源庫提供的原生治理方式進行了妥善的封裝，可以通過配置的方式進行使用而不必再進行編碼

僅提供Hystrix等開源組件，需自行開發封裝成服務使用，只支持服務粒度隔離

輕量級網關

支持Restful請求匯聚及轉發，支持服務映射、請求解析、加密解密、鑒權等自定義能力，網關服務本身也可被治理

基于Zuul構建網關，性能是短板，治理能力需要業務集成大量三方件來實現

灰度發布

支持按權重和接口參數（例如用戶群組或用戶所屬區域等等）定義微服務灰度發布規則

無

儀表盤

提供基于微服務>實例>接口多層次的應用級指標監控，如吞吐量、平均時延、請求等等

無

部署

即開即用（秒級）

需基于開源組件自行開發和部署服務中心、配置中心、治理中心以及控制臺，費時費力

擴容

通過控制臺自助式升降規模（秒級）

需要手工進行實例擴容，數據遷移等等

異地容災

支持AZ基本高可靠

搭建難度大，技術要求高，需自行開發HA

華為微服務Service Mesh解決方案

Service Mesh是當前業界比較火的一個熱點技術，華為也是國內最早把這個技術落地，推出商業版產品，并大規模應用于生產環境的云服務提供商。其實技術歸技術，真正要有用還是要用它來真正解決現實問題，目前主要用來解決客戶的兩類問題：第一類是那種使用一些語言（如php、.net、nodejs、python等）開發微服務，但業界沒有合適的微服務框架能直接使用，所以只能使用這種代理方式來解決微服務的注冊發現及路由管控等問題；第二類是那種有一大堆遺留應用，一行代碼不想改，又希望能使用微服務的高級治理能力，如灰度發布、限流降級等等，這時候通過這種非侵入的技術就能很方便的搞定。

另外，再補充一點關于微服務SDK與Service Mesh技術之爭，目前業界有些聲音認為Service Mesh是下一代微服務技術，會替代SDK模式。從當前實際的業務訴求看來，這兩者在微服務功能上確實有些重合，例如在微服務的路由管理、遙測和安全這些方面的能力，兩種方式都可以實現，但SDK本身還有另外一個職責，就是標準化微服務的團隊交付方式，例如：標準化了微服務的打包方式（軟件包定義、編譯設置、依賴管理）；標準化了微服務的發布方式（服務定義、如何注冊配置監控、通信協議、安全認證等等）；標準化了微服務接口的定義方式（數據模型定義、操作模型定義）；標準化了微服務公共能力的開發方式（動態配置、日志記錄、監控埋點、事務協調、文件存儲、數據庫/緩存/消息中間件訪問）。標準化的目標是為了規范化和自動化，而這兩者是提高團隊研發效率的基本手段。當然，一個作坊式軟件開發團隊，人數少，業務規模小，管理沒那么復雜，隨便怎么干影響也不大，但當你的研發團隊增長到近百人，甚至上千規模時，標準化的開發方式是支撐團隊高效工作的基本要求。

華為微服務流水線解決方案

微服務的交付過程跟以前其實沒什么區別，都是從coding、編譯、打包、測試、部署到上線這些基本的交付活動，但是微服務模式下卻比以前更加需要流水線這么一個自動化的工具平臺來支撐，主要是微服務的數量太多了（動輒幾十上百），交付活動中的任何一個環節無法自動化就會對整個業務上線效率造成很大的影響，很容易導致業務微服務化之后不僅沒快起來，反而比以前更慢，別小看這一點，我們所經歷過的大部分微服務轉型項目都掉過這個坑。大家都知道，提升效率的最好辦法就是盡可能自動化，而能自動化的前提是先把業務或者活動進行建模并標準化，微服務流水線看上去是一套工具平臺，本質上是對團隊開發活動中各個環節進行了一系列標準化，從微服務編寫第一行代碼開始，包括微服務的開發方式，如微服務的定義、接口的定義、周邊依賴集成方式等，也包括微服務的交付過程活動，如編譯、打包、測試和部署模板、腳本和環境配置都進行了標準化，這樣能讓開發人員聚焦業務本身邏輯的開發，以及簡化團隊之間的協作，最終實現整體交付效率的提升。

華為微服務灰度發布解決方案

在互聯網行業，特別是一些業務創新場景都強調要快速試錯，很多面向消費者的優秀應用并不是從一開始就設計好的，而是通過不斷的快速迭代、快速試錯，逐步進化而來的。我們理解快速試錯其實包含兩種場景：其一，不得不承認無論怎么加強測試，因為各種因素（例如環境差異、場景差異、人的差異等等）是軟件都會有一些bug成為漏網之魚，如果無法避免這些bug，那我們希望當這些bug出現時盡可能影響最小化；其二，我們會很高頻率的上線一些小的特性，這些特性有的來自于部分客戶的需求，有的來自于行業洞察，有的來自于愿景規劃，但這些新的特性是不是所有用戶都喜歡的，或者還有哪些改進點，我們希望這個發布過程能管控起來，灰度發布就是一個很好的解決途徑，我們可以通過對新版本的發布范圍、使用對象、甚至使用場景進行細粒度控制，這樣就能最大化降低發布風險。

當然，灰度發布的適用場景并不局限于此。曾經遇到過有個客戶的應用場景挺有意思，他們運營著一個物業電梯管理的SaaS應用，發現每個客戶對都有些不同程度的定制訴求，一開始沒想太多反正定制工作量也不大，就為每個客戶定制一個版本然后各自部署一套，張三就訪問張三的那一套，李四就訪問李四的那一套，相安無事挺好，可是后來他們發現這樣搞資源太浪費了，因為這些系統其實90%以上的功能都一樣，而各自部署的服務器資源利用率都很低，于是后來他們做了一件事，把面向不同客戶的定制部分抽出來做成獨立的微服務，然后通過配置灰度規則，讓不同用戶訪問到各自定制版微服務上，通用功能只部署一套，這樣就大大節省了資源，而且還減少了維護工作量。

華為微服務治理解決方案

在微服務系統上線之后，我們要盡可能的做到運維的自動駕駛，因為靠傳統那種手拉肩扛的運維方式是不可能運維好復雜的微服務系統的，這里更大的挑戰是對微服務運行時各種指標的監控和及時響應都提出了非常高的要求。

微服務的治理措施有很多，例如負載均衡、黑白名單、服務限流/降級/容錯/熔斷、故障預測/自愈等等，我們可以根據實際的應用場景選擇相應的治理措施，例如：

負載均衡：這不是一個新技術，但這里重點說一下在微服務系統里負載均衡的應用方式有什么不同，傳統的應用架構一般是分層的，例如從外到里有接入層、展示層、業務邏輯層、持久化層，我們一般在系統的最外層加一個F5或Nginx作為負載均衡器，來確保入口處的流量被均勻的分配到后端的處理服務上。但是在微服務系統里，由于服務粒度小了很多之后，整個架構并沒有明確的層次之分，更多的像個網狀結構（如下圖），

每個微服務都可能多實例部署，這時候每個微服務之間的訪問也需要負載均衡，如果用傳統的方式在每個微服務之間加一個F5或者Nginx，這是不可能的，首先成本就受不了，所以需要從微服務框架就要支持這種能力。負載均衡的策略可以有多種，例如輪詢、隨機、會話粘滯（如果用戶請求第一次訪問了某個實例，則后續該用戶的所有請求都訪問這個實例）、實例負載（根據當前所有實例的負載，例如CPU使用率來判斷閑或者忙，再來決策路由到合適的實例）、響應權值（根據所有實例歷史處理請求的響應延時情況，來選擇滿足SLA的實例）等等。

容錯熔斷：任何微服務之間的任何一次調用都有可能會失敗，但我們的系統又必須做到更好的SLA，這就要求架構師在微服務的設計之初就要考慮到各種失敗場景和應對措施，當然把這種工作都交給業務開發人員來處理，門檻會非常高，好在我們已經在微服務框架里內置了一些容錯能力，例如調用一個實例失敗了可以嘗試重試幾次，也可以選擇路由到另一個正常的實例，當所有實例都失敗可以啟用自定義的預案措施，同時對于后續的調用可以快速失敗返回，以防止交通堵塞。熔斷的場景就類似于我們家里用于電路上的保險絲，當發現某個微服務的負載較大時，系統會自動把到該服務的流量掐掉，直到監測到負載正常時再恢復。

限流降級：任何微服務的容量（處理的最大請求量）都不是無限的，所以要進行限流的治理，以保證微服務不被無論正常還是惡意的流量搞垮，另外一個場景，我們可以根據請求方的消費級別（例如鉑金用戶、黃金用戶、普通用戶等）來分配不同的流量限制，以實現差異化的商業服務。降級主要應用在兩種場景：其一，有些時候當系統中的某些服務掛掉了，為了防止故障蔓延，可以把對故障服務的調用降級掉，以保證系統的其他功能還能用，例如不可能因為商品廣告服務出故障而導致整個電商網頁打不開，可以把廣告服務降級，讓用戶至少可以打開首頁瀏覽商品；其二，在一些資源受限的場景，可以主動降級掉系統中一些非關鍵服務來保證核心服務的資源訴求，例如在電商促銷活動之前，可以把非關鍵的日志服務、評論服務或者推薦服務等等通過降級的方式先關掉，把資源調配給核心的商品列表、下單、支付等服務。

黑白名單：我們有很多企業客戶為了在內部實現數據共享和能力共用，來提升公司運作效率，會把一些內部企業支撐系統通過微服務的方式發布出來，但是有些數據會比較敏感不適合在太大的范圍公開，因此對處理這一類數據的微服務自然而然就有了安全管控的要求，通過黑白名單管理就可以很方便的控制微服務的訪問范圍。

還有很多有用的治理手段，這里就不一一列舉，有效的治理措施取決于對微服務系統運行狀態精確的監控，我們需要做到對微服務360度監控，例如：微服務所在集群和節點的CPU、內存、磁盤和網絡等資源指標的監控，微服務本身的吞吐量、時延和錯誤率等應用指標的監控，以及微服務所依賴的數據庫、緩存、消息、網關等中間件指標的監控，跟就醫看病一樣，只有對病情有足夠的診斷，才能開出最合適的藥方。

華為微服務開源進展和路標

2017年6月，在由Linux Foundation主辦的LinuxCon + ContainerCon + CloudOpen（LC3）開源峰會上，華為宣布開源微服務框架ServiceComb，開源后的ServiceComb將幫助廣大開發者快速開發云原生應用，共同推進構建行業云生態。

又于同年11月，開源社區 Apache 軟件基金會孵化器項目管理委員會 ASF IPMC宣布華為云開源的 ServiceComb 項目全票通過進入 Apache 孵化器。這也是華為繼 CarbonData 之后，第二個進入 Apache 孵化的開源項目。

進入 Apache 孵化器，也意味著 ServiceComb 社區將遵循Apache Way,社區將更加開放、中立及多樣化，也歡迎更多的廠商及個人開發者參與社區。

華為開放微服務框架的邏輯也很簡單：其一，這確實是一個經過內部廣泛實踐驗證過的好東西，捐獻出來希望能進一步促進行業更快的向微服務轉型；其二，微服務的生態很大，華為不可能也沒有能力涉獵各行各業，所以希望拋磚引玉，聯合大家一起完善生態；其三，微服務框架是業務開發的基礎組件，全部開源出來也可以打消很多華為客戶擔心被技術綁定的疑慮，華為提供的微服務相關商業產品也都是基于這套開源版本構建的。

華為微服務案例

從賣光盤到賣服務：一個PHP語言系統微服務化的案例

這是一家國內知名的軟件開發商，他們開發了一個樓宇的物業管理系統（一個單體應用），最開始的商業模式是賣光盤，和某個小區簽一個合同就過去給他們安裝一套軟件，基本是一錘子買賣的生意，后來他們想按SaaS模式去賣，先把這套軟件部署到云上，簽一個合同就為開通一個賬號，這樣一來就有了客戶粘性，后續可以持續升級賣服務。這種商業模式的變化其實也悄悄的對軟件架構帶來了一些影響，例如以前一個地方部署一套，業務的流量不會很大，系統的性能是遠遠過剩的，但是以SaaS這種方式去面對多客戶，隨著業務量越來越大，單體應用的性能就會越來越吃不消，這也促使他們不得不把系統向微服務架構改造。后來他們在啟動改造開發的時候，又發現當前業界還沒有合適的PHP語言微服務框架，而當前他們開發人員的技術棧都是PHP的，這時候要換語言或者換人都是成本比較高的，于是他們找到了華為通過Mesher來解決微服務化的問題。

Mesher不限制語言，而且提供了完備的微服務治理能力，如服務注冊發現、路由管理、灰度發布、流水線等等，這樣不僅僅支撐他們完成了微服務架構轉型，通過彈性解決了系統性能瓶頸問題，還額外獲得了業務上線效率提升的收益。

傳統企業的微服務化之路：一個大型遺留系統向微服務架構遷移的案例

這是一家地產行業的公司，他們有一個古老的CRM系統，這個系統有一部分功能是面向潛在購房者的，例如客戶服務、機會服務、房源服務、代理服務等等，受一些互聯網營銷的影響，他們也把樓盤放在網上開盤銷售，前幾年房地產行業比較火爆，經常也會有秒光盤，這時候在搶房瞬間的流量壓力這種場景下，他們的CRM系統就扛不住了，導致系統體驗不好，影響企業品牌和形象。于是找到華為希望做微服務改造，但這個項目最大的困難是當前的CRM系統太龐大了，而且很多地方都是日積月累的不敢隨意去動。后來我們針對性能做了深入分析，發現瓶頸主要是搶房這塊相關的功能，于是我們把這塊功能拆解出來單獨做了微服務化改造，其他系統功都不動，只在邊界部分做一個和新微服務交互的簡單適配，這樣把抽出來的業務繁忙的這些微服務做適當的彈性就解決了性能問題，而且通過這種微服務粒度按需的彈性還大大提升了資源利用率（以前必須整個CRM系統大顆粒的彈性）。

在超大規模用戶和流量場景下的微服務應用案例

如果讀者用的是華為手機，手機上的應用市場、瀏覽器、音樂、支付、負一屏、運動健康、智能家具等等背后都是運行在這套微服務框架之上，目前華為消費者云超過4億用戶。舉這個例子主要是想說明華為的這套微服務解決方案也是經歷超大規模流量這種應用場景洗禮過的，所以無論多大業務量規模，在性能、安全和可靠性上沒有任何問題。

一個由基于Spring Cloud自建微服務系統最終向華為云CSE遷移的案例

這是一家物聯網領域的創業公司，主要為城市、公園、園區等提供專業的智慧路燈服務，并在此基礎上結合監控、傳感器等其他物聯網終端，提供各種創新應用場景，如尋人尋物、犯罪線索提供等，原系統基于Spring Cloud微服務構建，開源軟件的特點就是功能很多很靈活，但是真正要吃透用好是門檻挺高的，創業公司本來投入資源就有限，化大量的人力物力來維護這些基礎的技術組件是不值得的，他們也是在用了好久之后實在是維護不下去，才找到華為幫他們提供商業級微服務解決方案。因為CSE本身是兼容Spring Cloud的，所以這次的切換很快，一周完成框架切換并上線，將原來全職投入的框架維護人員全部釋放出來投入到業務開發中。

一所高校所經歷的微服務轉型之路

這是一家坐落在上海的985高校，其實學校也有很多系統有類似互聯網這種有明顯波峰波谷的應用場景，例如在每學期的開學階段，有新生報到、課程安排、在線選課等等事務，在學期末階段又會有集中性的考試、答辯、結業等等事務，處理這些事務背后的IT系統其實也就在這幾個階段會忙一點，其它時間基本閑置，很多學校的痛點就是資源準備少了不夠用，撐不住那幾個時間點的流量，準備多了又浪費，于是希望把傳統的這些教務系統微服務化，能充分的利用彈性和公有云的能力，來降低成本的同時還能解決業務波峰波谷的性能瓶頸問題。

微服務 微服務引擎 CSE

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。