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

華為從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是多例項部署，這時候又需要在多個服務例項中找一個最合適的例項來處理請求，那麼這就涉及到第二個問題：負載均衡，後面還有服務呼叫失敗了要考慮服務容錯，還有服務限流、服務降級、分散式事務等等諸多複雜的分散式技術問題，如果我們把這些問題都留給業務開發人員，顯然業務開發是快不起來的，這就是微服務化之後面臨的第一個問題：如何基於微服務架構高效開發和上線。

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

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

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

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