華為雲微服務引擎的前世今生
華為從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是多執行個體部署，這時候又需要在多個服務執行個體中找一個最合适的執行個體來處理請求，那麼這就涉及到第二個問題：負載均衡，後面還有服務調用失敗了要考慮服務容錯，還有服務限流、服務降級、分布式事務等等諸多複雜的分布式技術問題，如果我們把這些問題都留給業務開發人員，顯然業務開發是快不起來的，這就是微服務化之後面臨的第一個問題：如何基于微服務架構高效開發和上線。
- 如何在不可預期的流量下如何保證業務的高可靠運作
從一個單體應用拆分成多個獨立運作的微服務應用，從理論上來說，系統的故障點是增多的，使用者請求的每一跳都有可能出錯，特别是在資源受限的大規模流量沖擊下，這又引入微服務化後的第二個問題：如何在不可預期的流量下如何保證業務的高可靠運作。
- 在複雜的微服務系統中如何實作問題快速定位與恢複
而微服務系統的運維是個更顯而易見的問題，一般傳統的單體應用問題定位過程是這樣的：首先登入到出故障的應用節點，然後找到應用的相關日志檔案，導出到本地後就可以使用各種文本工具進行日志分析和問題定位，整個過程很簡單，人工就能搞定。
但在微服務系統中，特别是在動辄上百個微服務和執行個體部署的場景下，一個業務請求很可能跨越了多個微服務多個執行個體多個節點，别說定位問題，就是先搞定問題定界都很難，這時候如果沒有一個自動化的工具或平台來支撐，靠人力是不可能完成的任務。
- 傳統架構下的遺留系統如何向微服務架構低成本遷移
最後是一個非常現實的問題，特别是在傳統企業裡面，都會有一些遺留的資産或運作中的業務系統，不可能把這些都推倒重來，不僅成本太高，而且業務風險也大。如何将傳統架構下的遺留系統低成本的向微服務架構遷移也是微服務解決方案需要系統考慮的。
同時真正要實施好微服務，對企業的組織架構、業務流程以及人的素質模型都提出了新的要求，是以向微服務轉型是一個企業系統性的變革活動。