讓 Cloud Native 飛，Pick 乾貨，看這裡、看這裡！

TA，被稱為技術群中的」當紅炸子雞「，絲毫不為過；

TA，幫助企業部署新業務特性，迅雷不及掩耳；

TA，應用中充斥」彈性、調度、伸縮性「等眾優勢，秒秒鐘征服you；

TA，站在技術前沿，身邊全是以一當十的」弄潮兒「，例如微服務、容器、Serverless……

pick一下，我們發現，如今符合上述特徵的，很明顯就是Cloud Native嘛！

這不，就在前不久剛剛結束的京東雲技術沙龍活動中，多位技術大咖面對面針對Cloud Native進行了深入探討，涉及容器、開源資料庫等諸多技術層面，乾貨滿滿。

沙龍現場座無虛席

此外，現場超百位開發者熱情參與了交流與互動，尤其對容器、微服務、Serverless等技術應用與開源創新十分關注。想必這些探討也將為雲計算、架構等相關領域的從業者們提供借鑒與新思路，十分值得廣大開發者們認真學習與總結！

Kubernetes的興起（京東雲專家架構師 劉俊輝）

開場初始，京東雲專家架構師劉俊輝在「Kubernetes的興起」的主題分享中表示，其實眾所周知的「虛擬化」在很早時間就已經被「發明」出來，主要是為了解決物理伺服器的種種弊端；但礙於實際情況，並沒有得到廣泛應用，伴隨著互聯網應用的大規模出現，這種情況才得以根本改變。

我們了解到，在虛擬化「稱王稱霸」的時代，典型的應用架構還只是單一應用的一體化架構，涉及的技術主要是Hypervisor，從物理機到虛擬機的架構遷移完成了第一次虛擬化運動的主要內容，但是人們關注的是資源利用率的提高以及硬體升級維護的便利性等層面。

隨著技術的更新迭代以及企業級需求的不斷變化，第二次虛擬化運動閃亮登場！人們聚焦於提高資源利用率、應用的啟動速度以及減少操作系統的開銷等，果斷促成了基礎設施從虛擬機向容器方向的平滑轉移，其中最重要的就是微服務架構，這局技術升級的贏家則為Docker。

劉俊輝簡單舉例說明了有關微服務架構的要點，比較大型的網站設置有web伺服器，但是其中佔用的內存資源甚至比操作系統佔用的還要多；但如果將大型網站切割成小部分，儘管做到了每個部分只佔用很小有限的內存與資源，可如此讓每個系統背負更多顯然是不值得的，在這種情況下如果使用微服務架構就另當別論了。

如果更進一步來講，根據企業應用的差異性，為了達成更高的隔離性以及安全性，對資源的隔離性要求明顯不同。具體來說，如果您是單一租戶或者單一應用的話，劉俊輝強調，僅僅線程的隔離或者基於進程的隔離也就足夠了；但如果是多租戶或者對安全性要求較高，就需要花額外的資源進行更多的隔離，所以確定在微服務的場景下，容器被認為是使用較為恰當的虛擬化平台。

如果簡要總結下容器的特徵，其具備的獨立封裝性，意味著自身就包含了完整的依賴關係，就算變換位置也不會帶來功能性的影響，部署的隨心所欲是吸引大眾的首要因素。

此外需要著重明確的一點，微服務架構可以被認為是小的、獨立的積木搭建而來，但並不是一個簡單的堆疊，這主要取決於服務架構的動態性以及相互關聯的關係，所以基於微服務應用，需要做到除了創建大量服務之外，很重要的一點則是對微服務進行全面有效的管理，也就是編排（orchestration）。

據了解，目前這種管理會涉及到全生命周期的應用，例如創建時間、刪除時間等；另外還有可靠性管理以及可用性管理，例如服務出現問題是否可以做到自動恢復、通過怎樣的機制保證其可用性等。

除此之外就是策略管理，即那些管理可以無條件訪問哪些 服務，這是對安全性的基本保障；最後一方面則是性能管理，涉及到資源的種類以及如何被提供等細節。

「關於編排的最後一點就是彈性，可以伴隨負載進行擴展以及收縮，這企業應用十分關心的問題之一。作為應用開發人員，如果過度關注這方面以及運維工作，很大程度上就無法集中注意力在應用研發的其他領域，這也是微服務架構甚至是容器著力改變的現實之一。」他補充道。

從微服務到容器再過渡到具體的Kubernetes，劉俊輝對開發者們表示，之所以如此風靡，主要還是解決了兩個十分關鍵的問題：首先將用戶對基礎設施的關心與應用的構建完全剝離開，Kubernetes完全可以承擔對基礎設施的管理；此外整個應用過程的動態性很好地被Kubernetes掌控以及概括，為用戶提供了最終狀態的保證。

大家都知道，容器以動態、可靠以及彈性著稱，具體來說Kubernetes又是如何通過分離平台和應用來顯示以上這些優勢的？關於此類問題，劉俊輝認為：」完成這樣的部署，主要歸功於提供了開放的標準介面與基礎設施對接。據了解，目前比較流行的開放介面CRI，也就是Container Runtime Interface。儘管目前比較標準的Kubernetes都使用Docker Runtime，但可以把它換成任何的Runtime，完全沒問題；此外如今在Kubernetes的生態圈中網路插件的資源十分豐富，選擇較多。「

從演講中我們得知，目前來看雲原生平台發展的趨勢可以被概括為幾個方面，分別是全託管的Kubernetes服務以及更多的Kubernetes開放的介面；還有面向特定領域的雲原生平台等。

類比一下，我們知道如今的高開發級語言可不止是JAVA以及Python，為什麼會有這麼多語言呢？主要還是因為不同的語言在特定的場景下會顯示出特定的優勢。

針對特定領域的應用平台，不同的應用領域需要專門的能力，例如IOT和邊緣計算，本身就與大規模的網站應用、互聯網應用是完全不同的；上個月發布的K3S平台，主要應用於跟蹤Kubernetes並對其進行一些精簡，如果將其應用在邊緣計算等資源受限的場景中就會比較適合。

」關於Kubernetes服務，其實京東雲所做的實踐被叫做JCS Kubernetes，並且已經通過CNCF的一致性認證，這表示在其他已經通過一致性認證的Kubernetes平台所部屬的業務，可以百分百部署在京東雲Kubernetes集群服務商，無須關心平台運維，只要細心把控應用即可。「他補充道。除了上述提及的插件系列之外，關於計算、網路以及存儲的基礎設施服務部分，還有一些其他的通用應用服務在列，例如資料庫服務；基於身份、基於租戶認證以及訪問許可權的管理；涉及監控、告警以及跨雲部署等方面，其中高效完成業務在不同平台之間的遷移工作也十分關鍵。

雲原生與微服務架構（京東雲專家架構師 王碧波）

聊畢容器，王碧波作為本場沙龍的第二位分享嘉賓，為開發者們現場帶來了主題為「雲原生與微服務架構」的技術演講。從微服務的基本概念著眼，王碧波簡要總結道，微服務通俗點兒來說就是提倡一個服務系統中不要被迫容納太多功能，最好是比較獨立的一組，將開發、部署、擴展等定義為一個單元來進行操作，整體來看很簡單。

咋一看，這樣的構想以及操作很簡易，但實際上遠不是想像的那樣，在服務運行的過程中會產生很依賴，此外調用關係需要十分細緻的梳理，關於服務狀態以及生命周期管理也會一併變得極為複雜。

由此痛點引申到一個好的微服務架構應該具備哪些功能？」其實總結來看主要包括四個方面能力，關乎整個生命周期的過程管理；微服務場景下功能實現的輔助；功能之間相互調用的能力以及在整個微服務系統中做運行觀測的能力等。」比方說為了系統的考慮，大家都希望有些設計可以服務本地，在本地部署緩存；但是當數據發生變更的時候，本地緩存的機制更新如何被設計就是個問題，也是經常容易出現bug的地方，這種事情就是微服務框架應該著重思考的。

進一步說明，目前市面上常見的微服務架構首先要數Dubbo。它本質上是一個高性能的RPC框架，並不算是完整的微服務框架，功能上比較偏重於RPC調用相關的一些能力，如果選擇採用Dubbo，實際上還需要在周邊擴充很多其他項目進入才能起到一個完整微服務架構的作用。

第二個代表性的則是騰訊開源的微服務架構叫Tars。相比而言，它的功能要比Dubbo完整很多，可以看到Registry，即關於路由和流量的管理；patch，關於微服務一些部署發布，還涉及到配置、日誌、調用統計等詳細信息。

此外，它本身也支持多種開發語言以及架構，算是一個比較完整的服務治理框架，從功能上來說基本各個維度都有考慮涉及，直接使用可以解決不少問題，但與目前的開源框架以及開源生態相融合、相比較就作用一般化了。

另外還有一種，名叫Spring Cloud。具備統一的規範以及介面，背後支持多種不同且具體的服務，且本身與Kubernetes沒有任何衝突。

談及最近紅火的服務網格，王碧波認為，服務網格最大的特點就是通過引入網路代理，時業務活力和服務治理徹底切分；並且，所有的策略調整都以一個動態的配置變更方式來實現，而不是採用變動代碼的方式，進而實現一種業務邏輯與服務治理徹底被切分的狀態，目前可以提及的Kong Mesh就是服務網格的具體架構實現，也是代表性的微服務架構之一。

Kong Mesh是一個比較簡單的服務網格實現。Kong Mesh在控制面中涉及到一個管理集群，有關微服務的相關治理策略都會通過配置的方式寫入資料庫中，而每個服務旁都會部署一個Kong的代理服務，會到資料庫中讀取配置好的服務治理邏輯然後加以處理。據了解，之前的Kong相當於本身就是一個有關API網關的開源項目，後來被應用到服務網格中，所以據實測其網格調用的服務能力非常強悍；另外Kong的系統組建十分簡單，表現為依附，架構簡單且實踐起來較為便捷，本身又是基於openresty相關，易於開發擴展。

但王碧波強調，這並不代表高可用的Kong沒有缺陷。一方面，控制面的能力並不豐富；另一方面，生態圈本身不強大，主要還是以Kubernetes插件的方式擴展，開源生態十分欠缺。

開發者們普遍感興趣一點，未來雲原生在微服務方面究竟會有怎樣的考量與部署？值得肯定的是，雲原生天然就是作用於微服務架構的，可以視作一個服務微服務架構的生態系統，而其中會以容器的編排作為重要的手段之一。具體著眼於幾個重點項目的情況，會涉及例如Kubernetes服務彈性的管理、Prometheus監控、envoy服務調用的代理、CoreDNS服務發現以及containerd運行環境等。

「簡單介紹下Envoy。使用者眾多；大量項目集成的對象，比方說最火的服務網格Istio；本質上是一個網路代理，你可能會疑惑，如今最知名的網路代理明明是Nginx，為什麼還需要Envoy這呢？最關鍵的在於在服務網格時代，人們希望所有的配置都可以達成動態下發，而不是去手動修改代碼再統一上線操作，Envoy基於API動態配置恰好實現了這個想法。「

另外關於Prometheus這個完整的監控方案，他總結道，這款監控方案將數據查詢、預警報警等全部整合在其中，與其他監控方案存在差別的地方主要集中在部署、SDK等方面。首先從部署層面來說，監控方案本身就是包含一個TSDDTSDB，自帶資料庫降低了部署難度；此外提供的SDK，很容易產生符合規範的商標指標數據；更重要的一點，其他監控方案主要採用主動上報的方式，而Prometheus以拉取形式為主，即一旦產生符合規範的數據，只要具備一個可供拉取的地址就可以完成服務端拉取的策略，比較實時性；關於Opentracing，實際就是API規範等。

再說說近兩年特別火的Istio。之前多次提及」服務網格「，Istio本身就是一個非常完整的服務網格方案，也分為數據面以及控制面。數據面也是服務旁會設置一個代理來接管流量；而控制面會區分細緻，其中Pilot，主要負責流量管理策略以及管理下發；Mixer的核心在於，調用之前判斷是否有許可權；流量真正調用之後完成與此有關的信息收集等；另外還涉及到Citadel，主要用作調用安全方面相關項目，主要在於證書管理。

王碧波強調，目前關於服務治理層面，所存在的最大問題其實是一種糾結：現在究竟要不要」上馬「服務網格呢？需要明確的一點，服務網格確實可以將業務邏輯和服務治理完全獨立，並促使服務治理、變成動態分配的情況，這一點 的實現同語言以及架構均無關係；但架構複雜性以及性能損耗等是不容忽視的問題。

所以是否採用服務網格，他提出了幾點判斷：首先還是自身在基礎架構方面是否有比較強悍的技術能力；」上馬「服務網格是好事兒，但需要綜合考慮服務治理能力提升的緊迫性以及所帶來的業務架構的複雜度；更重要的一點，這種動態的治理能力與服務的處理性能哪個比較關鍵，也是亟需明確的事兒非常重要的權衡角度。

談及微服務架構的選擇，根據企業情況不同主要可以歸為幾種：首先是完全自研的選擇，比較適合基礎架構研發能力特彆強的大型公司；其次直接上手一些開源的框架，這對於大多數公司都是比較適合的；第三種選擇，使用公有雲提供的微服務框架；另外，開源/資源 公有雲結合的方式也是非常不錯的一種選擇。

據了解，京東雲在微服務架構方面有一些產品十分值得提及，例如關於全生命周期管理的Kubernetes的集群；具備超級彈性伸縮、高可用還滿足雲部署等需求的DevOps；在功能實現方面主要包括API網關、函數服務、消息隊列、對象存儲等產品組件；如果著眼運行觀測，日誌服務、監控、調用鏈關係以及調用服務等更是必不可少。另外，京東雲分散式服務框架產品旨在整合微服務相關的各種產品模塊提供統一的微服務平台。

分享尾聲，王碧波還未現場開發者解說了利用京東雲現提供的組件來搭建自己的微服務架構所涉及的詳盡過程。」首先服務如果能夠被外部調用，需要經過API網關完成一些關於介面安全以及管控的事情；隨後流量通過負載均衡服務進入VPC中；當服務需要部署的時候，可以通過雲部署的方式將服務部署在高可用組上，完成後會下發一些與分散式服務相關的配置到應用中；之後就會自動關聯到京東雲的註冊中心，去做服務發現，進而就可以採用京東雲的配置中心去完成配置並管理數據等。「

現場精彩分享仍在繼續，開發者互動氣氛活躍。話說，Serverless的官方定義是啥？為什麼Serverless這麼火？有什麼突出之處？究竟應該如何打造自己的Serverless服務，有標準或者範式可以參考嗎？

在關於Serverless的分享中，京東雲技術專家張金柱提到，「這是雲時代的一種架構思想。如今給大家提供了非常豐富的開發框架以及技術組件，時代很贊；此外雲計算將大量的社會資源，例如計算以及存儲資源集中到一起形成規模效應，這兩點果斷成就了Serverless。」

雲原生下的Serverless淺談（京東雲技術專家 張金柱）

此外他還認為，從IaaS過渡到微服務以及現在的Serverless，雲計算讓業務人員不用過多擔心技術，而是專註業務；如果從軟體架構發展的角度，單體結構發展到微服務以及分散式，這都是必然的技術迭代。「我們可以簡單認定一點，Serverless是雲SaaS，是一種抽象。得益於底層的標準化，讓Serverless成為一種可能。」他進一步補充道。

Serverless，作為雲計算進入深水期的表現，被譽為如見架構發展的必然結果，談及落地應用，張金柱總結道，主要體現之一在於應用後端，例如物聯網。

比方說在風力發電的場景中，風車會伴隨天氣、風向等因素產生差異，為了達到更高的發電效率就需要調整風車方向。」風扇上傳的數據到雲端是固定頻率的，其中包括數據處理部分模型，如果此時使用Function來處理，基本上符合Serverless適用的場景。首先讀取存在的數據；假設當地空氣、風向的數值，再根據當前的風向去做一個調整並發出指令，傳回終端；完成實時的數據處理，例如一些大文件處理以及流數據處理等。「

又例如AI場景中針對視頻和圖片的分析和處理，這可能會涉及圖片建模以及壓縮手段。一張圖片，需要根據設備不同來調整大小甚至形狀，這樣的需求在過去的基礎架構上很難完成，過程複雜。但在Serverless中，只需要將圖片上傳至對象存儲，然後去處理預先定義好的Function，按照需求剪裁成不同設備所需要的尺寸並回傳存儲，這個過程需要避免死循環出現，會有一些執行時間的限定。

此外，FaaS作為Serverless架構實現的方式之一，首先是無狀態的，能夠無狀態中實現水平擴展，相對來講更容易一些。這時FaaS像強力膠水一樣，連接各種雲上服務，讓用戶更輕鬆構建自己的業務系統，實現高可用、可擴展、經濟實用的架構。而其中被定義的BaaS，會作為FaaS層的外置狀態，或者持久化數據基本組件，例如原來需要資料庫或者一些消息隊列需求等，現在可以統統交給雲廠商或者第三方服務，這些服務基本上多以API方式提供，用戶無需關心底層的擴容、縮容問題。

不可避免，Cloud Native確實對Serverless產生了影響，對於Serverless這個只屬於雲時代的架構思想，規模化以及更加標準的方式、所提供的無上限的資源為其彈性的伸縮提供了基礎。此外，雲計算將一些基礎細節加以隱藏，這不單單是應用架構方面，當然還涉及到PaaS服務。

」談到Serverless的標準和範式的時候，主要由於其標準和架構層面的很多問題均處於探討之中，甚至還沒有方法論，所以也就談不上標準以及範式了。「他說。

最後關於Serverless的挑戰和未來，張金柱引用了伯克利給出的兩個重要總結，其實現在的Serverless有兩大退步：忽略了數據，或者說數據處理的要求；天然的無狀態對於分散式並不友好，例如一致性問題以及事務性問題的出現等。

雲原生時代資料庫的發展趨勢（PingCAP 聯合創始人兼 CEO 劉奇）

在有關「雲原生時代資料庫的發展趨勢 」的主題分享中，劉奇認為如今的Cloud Native定義的關鍵在於用容器去Package everything，還有就是使用微服務。

此外，存儲與計算分離的思想在針對TiDB的技術實踐中也有所印證。TiDB目前做的一些關於Computing的實踐，很有意思的點就是每一層都可以做成Computing。如果綜合去看其中的差異，其實TiDB是被當成計算上的Computing來實現支持，相當於被做成插件，如此形式在計算層可以，在存儲層也可以，而存儲層實現多個插件，這樣一來整體結構的靈活性就會體現的非常好。

需要強調的一點，採用何種技術改變，其核心的思想主要在於用戶關注的是更高級別的業務層面，因為這個因素會左右最後的選擇。

雲原生從技術角度看不免涉及計算、存儲、網路等範圍甚廣、學習以及實踐的難度不小，但卻可以發揮重要作用。從產業角度看，可以顯著提升傳統企業的IT部署效率，助力數字化升級，為企業贏得快速發展的機遇，好處頗多……京東雲技術沙龍關於雲原生的探討雖然暫時告一段落，但企業關於K8S、無伺服器、開源等的深入探索似乎才剛剛開始！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！