談談華爲微服務解決方案與實踐（上）

華爲雲微服務引擎的前世此生

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

微服務在業界的使用情況

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

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

爲何要用微服務

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

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

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

更快，是指業務上線的速度，使用微服務能把業務上線週期從年降到月、周，甚至是隨時上線；

更穩，是指系統可用性，基於微服務構建的系統能把系統SLA從3個9提高到4個九、5個9，甚至永不斷服；

更經濟，是指業務的資源成本，基於微服務更細粒度的彈性，能實現業務規模擴張與資源支出的最佳平衡。

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

微服務帶來哪些新的挑戰

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

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

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

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

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

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