截至2019年7月份，盒馬鮮生累計開了177家店，幾乎每三天開一家店，支撐盒馬鮮生對外輸出能力背後的框架就是新零售服務開放框架NBF（New-Retail Business Framework），其中最核心的能力則是 Serverless 的架構設計和深度實踐。在近期召開的QCon上海2019大會現場，InfoQ採訪了阿里巴巴高級技術專家馮微峯（諸葛瑾），瞭解支持了盒馬、天貓超市、阿里健康等10個BU，30天調用百億次的NBF框架的Serverless核心能力。
Serverless不是一種技術，而是一種架構
2009 年，伯克利以獨特的視角發佈了一篇文獻，定義了雲計算，十年過去了，這篇文章被引用無數，其中的觀點更是當下最好的見證，比如按需計算的表現形式、消除雲用戶的前期承諾、根據需要在短期內支付使用計算資源的能力等。
2019 年，伯克利又以新的視角發佈了一篇文獻：將雲中的編程變得簡單：伯克利視角下的 Serverless 計算。 觀點同樣讓人眼前一亮：
Serverless 所提供的接口，簡化了雲計算的編程，其代表了程序員生產力的又一次的變革，一如編程語言從彙編時代演變爲高級語言時代。
伯克利對 Serverless 的預言是什麼？伯克利認爲：Serverless 將會在接下來的十年迅速被採用，這將會得到飛速發展。然而， 國內目前真正將Serverless應用實踐的開發者並不多，有些甚至收到了不太好的反饋，比如 CardGames.io 的開發者想更改下API，同時嘗試一下Serverless框架，結果發現費用貴了八倍，運行效率還慢了15%，最後承認Serverless不適合自己的用例。
那麼，Serverless到底有沒有價值？應該如何理解呢？
“Serverless不是一種技術，而是一種架構”，馮微峯在採訪中如是說道。他表示，目前的NBF框架使用的是阿里內部容器提供的彈性擴縮容能力，換句話說，Serverless不是一個具體的技術，不是通過一個框架和底層能力就可以輕鬆實現的，它是一種架構，一種可以提升研發效能和降低開發門檻的架構，而不僅僅是提供快速彈性擴縮容能力，但是具體如何實現要看各自的業務特點。
在馮微峯看來，Serverless架構是一個很好的方向。因爲其帶來的技術紅利非常明顯了。首先，從原來的DevOps到之後的NoOps，研發可以更加關注寫代碼本身，容器穩定性和中間件通訊等都可以通過底層基礎設施平臺搞定；其次，資源也得到了極大釋放；最後，基於Serverless的研發模式和交互模式將會更加簡單，當技術體系從Kubernetes到ServiceMesh，再發展到Serverless的過程中，底層很多基礎設施都一層層封裝起來了，比如把一些中間件的能力以Sidecar的形式下沉到了容器裏面。
雖然Serverless對不少問題提出了很好的解決方案，但也要看基於什麼樣的維度來理解這一概念，如果單純基於CPU、內存等系統維度來理解這一概念，可能會導致一些業務場景的不適用，畢竟很多業務場景是有狀態的，其資源的瓶頸可能並不在機器上，而是在DB上，那機器擴容的越多，DB可能掛得越快，因爲更多的請求流量打到DB上了，因此Serverless也是要區分場景使用的，否則不會得到很好的效果，反而提升了整個的使用成本。
FaaS的適用場景
在目前關於Serverless的探索中，FaaS基本被認爲是最佳範例，這與其自身特點有關。FaaS非常輕量級，且無狀態，運行很快，對於純粹的無狀態應用特別合適，雖然在冷啓動層面存在一些瓶頸，但這種架構帶來的紅利還是解決了很多問題。
採訪中，馮微峯表示，關於冷啓動問題，在NBF中，FaaS的主要功能是實現極速的服務發佈。FaaS引擎本身常駐在容器中，快速啓動時只需要加載一個Jar包就可以了，服務發佈時間就等於Bundle的加載時間（Bundle是OSGI的概念，以Jar包形式存在的模塊單元），這比傳統的發佈方式要快很多，傳統發佈方式需要容器啓動和鏡像加載等。而且NBF-FaaS也在準備與阿里JVM團隊合作，嘗試使用JIT和AOT的相關技術，進一步減少冷啓動時間。以最簡單的Hello World程序爲例，NBF-FaaS的發佈時間可以做到毫秒級別。
此外，FaaS的啓動時間也與代碼編寫息息相關，如果啓動代碼中有大量的外部依賴，調用一個遠程服務就需要幾秒鐘，整體啓動時間也會被延長，當然這不是一個技術框架可以解決的問題，而是代碼設計的問題了。
新零售服務開放的Serverless架構
2016年初，盒馬在北京開了第一家店，用了大半年的時間，當時對於盒馬最核心的訴求就是標準化定義一個新零售自動化開店的鏈路流程，然後基於這個鏈路流程做快速複製，最終保證門店的開店速度。截至2019年7月份，盒馬已經開了177家店，幾乎可以做到每三天一家店，這背後的技術能力就是基於NBF(New-Retail Business Framework)——新零售服務開放框架實現的。
馮微峯表示，傳統應用要解決的問題是研發流程複雜，整個研發過程需要創建應用、構建、打包和部署，NBF的Serverless能力可以做到沉浸式開發，提供了一整套的idea插件，研發人員基本感知不到運維平臺的存在；其次，傳統研發的運維流程複雜，要關注容器的健康狀況和容量規劃，NBF的目標是做到NoOps；最後，服務資源隔離和機器資源的合理利用其實是Serverless的典型優勢，這也非常適用於盒馬的錯峯場景。
如上圖所示，NBF的雲原生Serverless架構底層是容器服務，藉助了阿里集團的底層基礎設施。其上的Serverless又分爲兩部分，一部分是Serverless容器，另一部分是容器裏的OSGI框架，管理Bundle的生命週期。再往上一層是沙箱環境，Bundle運行在沙箱環境中，彼此隔離。NBF容器是一個雲原生的容器，實現了對Bundle沙箱容器的託管，在沙箱容器中可以使用阿里的內部容器(pandora,sofa,webx等)，也可以用業界標準容器(springboot、tomcat等)。也就是說Bundle無論代碼怎麼寫，NBF容器都可以充分支持。最後，NBF正在打造一套雲研發平臺和雲原生SDK，統一對外輸出NBF的雲原生能力。
在此基礎上構建出的Serverless架構主要提供三大服務能力：
1.極速發佈能力
- 開發態：基於idea插件寫了一整套研發流程的插件，研發人員可以基於此插件完成整個開發流程。
- 運行態：基於NBF-FaaS能力動態加載Bundle，實現毫秒級極速發佈
2.靈活的服務路由能力：可實現多態路由和降級路由。
3.強大的服務運維能力：可實現毫秒級彈性擴容和極速回滾。
其中，服務路由主要解決了開放問題，得以讓大潤發等合作伙伴的Bundle服務能快速接入到新零售體系中來，其核心功能分爲三部分：服務發現、服務路由和流量管控。服務路由主要有兩個典型場景：多態路由和降級路由。
舉例來說，一個業務系統需要基於業務身份調用其中一個採配服務，常見的方法是通過Gateway實現，這其實會讓原來的兩層架構變爲三層，穩定性會變差，Gateway很可能成爲單點或者瓶頸，代碼複雜度變高，可能還要做代碼發佈和變更。NBF的Broker是一個SDK，與業務在一起，完全可視化配置就可以實現服務發現和服務路由，整個過程是低代碼和配置化的方式。
另一種是降級路由，盒馬履約從最開始生成訂單，到調用集單算法再到生成履約批次，一共需要經歷這三個過程。其中，調用集單算法主要目的是降低整個配送成本，可以基於配送時間片和用戶地址等來實現。由於盒馬履約是C端鏈路上非常核心的節點，大促期間需要對集單算法進行容災降級，原來的降級代碼需要通過開關方式完成，降級代碼和業務代碼深度耦合、代碼複雜度很高，現在可以通過NBF-Broker完成，一個降級bundle就可以實現被動降級和主動熔斷，具體場景如下：
在服務運維方面，NBF通過Fast Cold Start、Fast Auto-Scaling和Fast Hot Start實現毫秒級彈性擴容和保障服務可用。
- Fast Cold Start：冷啓動優化，減少種子機器的啓動時間
- Fast Auto-Scaling：毫秒級彈性擴容
- Fast Hot Start：通過NBF容器的HooK能力，保障擴容機器的服務可用
NBF進行了一系列Serverless深度實踐，在今年女王節的時候，秒殺的QPS從4000飆到了12萬，機器數從2臺到5臺、10臺再回降到2臺。馮微峯表示，在未來NBF-Serverless對於長尾應用和非核心應用可以縮容到0臺，當第一次請求過來的時候再進行機器擴容，如果業務方可以接受第一次機器擴容的延遲(幾十毫秒)。
如今，NBF支持了10個BU，運行在NBF上有1137個SPI，1555個Bundle和5655個方法，一共託管了3570臺機器，12000核CPU，在30天內調用已達百億次，未來計劃幫助業務實現無縫上雲和出海，支持一份代碼發佈多個環境。
嘉賓介紹：
馮微峯（諸葛瑾），阿里巴巴高級技術專家。2014 年加入阿里巴巴集團，2015 年作爲技術初創員工加入盒馬，負責訂單履約等中臺系統架構設計和研發，作爲核心研發人員深度參與了盒馬中臺體系從 0 到 1 的架構演進。從 2016 年開始基於盒馬的複雜業務場景架構設計新零售服務開放框架—NBF（New-Retail Business Framework），從最開始的流程中心衍生到目前 NBF 的六大中心體系，形成了一整套比較完整的服務開放能力。2019 年帶領 NBF 團隊迴歸阿里巴巴供應鏈中臺，向包括盒馬在內的 25 個新零售 BU 及合作伙伴統一輸出 NBF 生態開放的能力。
更多國內外一線技術大咖分享請持續關注QCon全球軟件開發大會，訪問官網與技術大咖面對面交流實踐心得。