當當網是全球知名的綜合性網上購物商城，涵蓋圖書、電子書、聽書、服裝、百貨等品類。在數字化已經成為社會經濟發展趨勢的背景下，電商行業也在數字化的驅動下加速更新換代，銷售內容、社交模式、消費體驗全面升級，同時也要支撐應對突發流量、新業務快速上線等需求，一套高可靠性、高可擴展性、性能強大的IT架構就成為了必需。

日前，記者采訪了當當網云原生實驗室負責人李志偉，對當當網近年來的數字化轉型之路做了梳理。

[[426177]]
當當網云原生實驗室負責人李志偉

一步跨入Kubernetes，開啟云原生之路

前些年，當當網的大多數業務都運行在物理機上，運維自動化水平不高，系統架構多種多樣，錯綜復雜，計算資源的利用率不足 20%。當有突發流量的時候，水平擴展和遷移非常困難。同時，因為歷史原因，當當網的老舊服務很多，需要有一個新的平臺平滑遷移過去。

根據當時的情況，當當網認為首先應該構建自己的私有云平臺，然后一步一步的進行轉型。但是在接觸到了Kubernetes 平臺之后，當當網認為可以直接進入到容器云平臺。

Kubernetes是微服務架構最佳的運行平臺之一，如果把當當網現有的業務按照微服務架構思想全部改造，大約需要幾年的時間。當當網最終決定基于現有的應用基礎做平滑遷移，在半年左右的時間把所有業務都遷移過來，第一步就是用 Kubernetes實現一個高可用的、高度自動化的運維平臺，一個高效的服務編排平臺。

事實證明，Kubernetes真正改造了當當網的研發流程，真正實現了一次構建就可以運行在多個運行環境中。Kubernetes 遵循 Borg 的架構思想，規范了現有的系統架構設計，實現自動化運維。并且，使用 Kubernetes 可以不被云廠商鎖定，在不同的服務商之間快速遷移。

Kubernetes雖然有諸多優勢，但是開發者使用它的門檻很高，起初，當當網使用Jenkins，Helm, Chart來簡化CI/CD流程，但配置及運維管理依然復雜。開發人員不僅要關注容器構建、縮擴容，還要關注流量控制的實現細節，急需一種簡單有效的服務編排標準來解決開發與運維管理復雜度問題。此外，Kubernetes本身并沒有解決低頻使用的服務資源占用問題，依然有大量服務、作業即使很少被使用，但依然占據著CPU和內存資源，導致計算資源的使用率較低。

Knative，把Serverless變得簡單易用

在云原生時代，Kubernetes和Istio的引入給微服務的開發和部署提供了完整的解決方案，同時也帶來了更高的維護復雜度，Knative作為新一代無服務架構平臺提供了一套簡潔的方案來解決微服務的管理問題。

Serverless（無服務器架構）指的是由開發者實現的業務邏輯運行在無狀態的計算容器中，它由事件觸發，完全被第三方管理，其業務層面的狀態則被存儲在數據庫和其他存儲資源。Serverless不代表不需要服務器，而是開發者不用過多考慮服務器的問題，計算資源作為服務而不是服務器的概念出現。Serverless是一種構建和管理基于微服務架構的完整流程，允許開發者在服務級別而不是服務器級別來管理應用部署，這大大降低了軟件開發的復雜度，使得開發者可以快速迭代，更快速地開發軟件。

雖然Serverless擁有無需管理基礎設施、按用付費、事件驅動、自動化構建部署等優勢。但是當前各廠商的Serverless標準不統一，軟件不能跨廠商遷移，客觀上存在廠商鎖定問題，這是制約Serverless發展的最主要因素。正因為如此，谷歌發起了Knative項目。Knative 是谷歌發起的基于kubernetes平臺的Serverless 開源項目, 將Serveless的服務管理，事件驅動，構建部署進行了標準化。它不僅可以以托管服務形式運行在公有云中，也可以部署在企業內部的數據中心，很好地解決了多云部署以及供應商鎖定問題。

Kubernetes作為基礎設施，解決了應用編排和運行環境問題。Isito作為通信基礎設施層，可以保證服務的運行可檢測、可配置、可追蹤。Knative使用應用模板和統一的運行環境來標準化服務的構建、部署和管理。

Knative 將kubernetes和istio的復雜度進行抽象和隔離，解決了繁瑣的構建，部署，服務治理步驟，并且基于開放標準使得服務變得可移植。

Knative作為開源僅兩年多的項目，各項特性還在快速發展演進過程中，出于穩妥考慮，當當網選擇了相對成熟的Serving組件，應用到業務形態相對獨立的單品API服務進行了實踐。

單品API服務是當當網基礎平臺中核心的基礎服務之一，由一系列與商品相關的API服務構成，單品API為所有相關上游服務提供高效可靠的底層服務支持。

當當網搭建了一套完整的運行環境：首先編寫用戶容器對應的dockerfile，然后編寫對應的Tekton task及taskrun文件，構建代碼打包運行時容器推送到私有鏡像倉庫，編寫Knative的service.yaml 配置文件并完成部署。

在運維工具方面，Knative直接使用了Kubernetes平臺上的解決方案，避免了重復建設。

從測試結果來看，對比Kubernetes原生的部署方案，Knative的引入帶來了27ms的延遲和10%的TPS損失。

Knative Serving支持縮容到零，極大提高了低頻應用的資源占用，為了解決冷啟動的問題，當當網采用保留服務最小副本數的方法，在資源占用和服務響應延遲之間進行平衡。對于可預見的高并發場景可以為服務預設預期最小所需副本數，這樣避免了突發高并發請求導致大量請求積壓；為服務預設最大所需副本數可以避免資源過度分配；為服務的每個POD設置最大并發請求數上限保障每個服務的可用性。

從當當網的Knative應用案例可見，Knative對于Serverless平臺的標準化意義重大。Knative的發展前景廣闊，有望成為未來的主流無服務架構平臺。同時，Knative還在逐步走向成熟的階段，大規模應用還需要進一步完善。

受訪人：李志偉，當當網云原生實驗室負責人，《Knative實戰》作者。2016年加入當當網，期間擔任數字業務產品線技術總監，架構部、云原生實驗室負責人。一直致力于推廣和實施云原生技術在當當平臺的應用。2018年實現了當當云閱讀產品線的全面容器化，完成了Kubernetes的平臺的整體方案設計和實施工作。