如今Cloud Native，也就是雲原生，這個技術名詞提的真是不少，但對於企業與開發者來說，具體的平臺架構部署以及未來發展等諸多問題卻還在探討的過程中。

　　正所謂Cloud Native時代下，容器、微服務以及DevOps怎樣用才能又快又好？中小企業體量不大，個人開發者勢單力薄，Cloud Native應用實踐還將如何開展？當然還有大家夥兒普遍關心的一點，如今火爆的Cloud Native究竟未來路在何方？

　　——總之，關於Cloud Native，開發者們迫切想要“一探究竟”心情纔是關鍵所在。

　　對此，日前京東雲特別在京舉辦了主題爲“Cloud Native時代的應用之路與開源創新”的沙龍活動，重點聚焦雲原生時代下，容器、微服務、Serverless以及數據庫等技術應用與開源創新，同時高度結合京東雲在Cloud Native以及開源領域的核心技術與一系列成功實踐爲開發者們現場答疑解惑！

　　沙龍現場座無虛席

　　會上，京東雲專家架構師劉俊輝爲與會開發者帶來了有關“Kubernetes的興起”的主題分享。作爲首位進行技術分享的嘉賓，劉俊輝將介紹的詳細內容做了大致總結，主要涉及虛擬化的起源以及其應用的驅動力量，內容涵蓋從虛擬機到容器的技術進化過程；其中比較重要的一部分則是關注Kubernetes的興起以及針對雲原生平臺未來發展的預測性解析。

　　談及虛擬化，他表示在很早時期，爲了解決物理服務器的種種弊端，虛擬化就已經被髮明，只是並沒有得到很廣泛的應用，伴隨互聯網應用的大規模出現，這種狀態才被改變。在虛擬化爲王的時代，代表的應用架構還只是單一應用的一體化架構，最主要的技術是Hypervisor，那時的頂級玩家title被一家名爲VMware的企業輕鬆取得，從物理機到虛擬機的架構遷移則完成了第一次虛擬化運動的主要內容。

　　京東雲專家架構師 劉俊輝

　　“有一就會有二，對於技術圈子來說，第二次虛擬化運動的主要驅動力聚焦於提高資源利用率、應用的啓動速度以及減少操作系統的開銷等，這才促成了基礎設施從虛擬機向容器方向的平滑轉移，其中最重要的就是微服務架構，這局技術升級的贏家則爲Docker。”劉俊輝進一步表示。

　　如果簡要總結下容器的特徵，其實可以概括爲是適應微服務發展的一個恰當的虛擬化平臺。其具備的獨立封裝性，意味着自身就包含了完整的依賴關係，就算變換位置也不會帶來功能性的影響，部署的隨心所欲是吸引大衆的首要因素。

　　換句話說，當我們在糾結虛擬機的內存、CPU的數量、資源如果閒置將如何高效分配給他人使用的諸多問題時，容器已經替代性地實現了更小的資源分配，將計算部署到有能力被運行的地方；更重要的一點，較小的開銷讓企業不再躊躇是否需要“揹負”一個操作系統的價格；一定程度的隔離，對於單租戶或者應用下層的安全保障來說，絕對在接受範圍之內。此外，在微服務的架構下，應用的快速以及靈活性也讓容器優於虛擬機，有機會廣泛發揮作用。

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

　　關於這一點，據瞭解，Kubernetes缺省的應該是flannel，但是各大雲廠商包括京東雲在內，都爲Kubernetes提供了自己的網絡插件，其中存儲的插件是Kubernetes比較新的一個插件接口，可以提供給容器一個持久化存儲卷，而至於這個持久化的存儲卷究竟是分佈式存儲還是文件系統，抑或是定項存儲提供，完全由插件來決定，而接口只負責存儲卷的特性。

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

　　”關於Kubernetes服務，其實京東雲所做的實踐被叫做JCS Kubernetes，並且已經通過CNCF的一致性認證，這表示在其他已經通過一致性認證的Kubernetes平臺所部屬的業務，可以百分百部署在京東雲Kubernetes集羣服務商，無須關心平臺運維，只要細心把控應用即可。“他補充道。

　　除了上述提及的插件系列之外，關於計算、網絡以及存儲的基礎設施服務部分，還有一些其他的通用應用服務在列，例如數據庫服務；基於身份、基於租戶認證以及訪問權限的管理；涉及監控、告警以及跨雲部署等方面，其中高效完成業務在不同平臺之間的遷移工作也十分關鍵。

　　在過去的十年間，微服務的理念以及架構被大量採用，王碧波作爲長期從事服務基礎架構相關研發工作的技術專家，目前主要負責京東雲分佈式服務框架、API網關等產品以及京東內部服務治理框架等技術內容，對此一點兒也不陌生。

　　看似熟悉的微服務架構應該具備哪些能力？常見的微服務架構各有什麼特點？服務網格的概念和發展狀況如何？他來解答最合適。這不，王碧波作爲本次沙龍的第二位分享嘉賓就進行了一場主題爲“雲原生與微服務架構”的技術演講。

　　分享初始，王碧波就拋出了問題一枚：一個好的微服務架構應該具備哪些功能？”其實總結來看主要包括四個方面能力，關乎整個生命週期的過程管理；微服務場景下功能實現的輔助；功能之間相互調用的能力以及在整個微服務系統中做運行觀測的能力等。”

　　比方說爲了系統的考慮，大家都希望有些設計可以服務本地，在本地部署緩存；但是當數據發生變更的時候，本地緩存的機制更新如何被設計就是個問題，也是經常容易出現bug的地方，這種事情就是微服務框架應該着重思考的。

　　京東雲專家架構師 王碧波

　　談及最近紅火的服務網格，王碧波表示服務網格最大的特點就是，所有的策略調整都以一個動態的配置變更方式來實現，而不是採用變動代碼的方式，進而實現一種業務邏輯與服務治理徹底被切分的狀態。

　　舉例來說，Kong Mesh就是服務網格的具體實現。在控制面中，涉及到一個管理集羣，有關微服務的相關治理策略都會通過配置的方式寫入數據庫中，而每個服務旁都會部署一個Kong的代理服務，會到數據庫中讀取配置好的服務治理邏輯然後加以處理。

　　據瞭解，之前的Kong相當於本身就是一個有關API網關的開源項目，後來被應用到服務網格中，所以據實測其網格調用的服務能力非常強悍；另外Kong的系統組建十分簡單，表現爲依附，架構簡單且實踐起來較爲便捷，本身又是基於openresty。

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

　　談及微服務架構的典型項目，所知數量不少，例如Prometheus這個完整的監控方案。對此他總結道，這款監控方案將數據查詢、預警報警等全部整合在其中，與其他監控方案存在差別的地方主要集中在部署、SDK等方面。

　　首先從部署層面來說，監控方案本身就是一個TSDD，自帶數據庫降低了部署難度；此外提供的SDK，很容易產生符合規範的商標數據；更重要的一點，其他監控方案主要採用主動上報的方式，而Prometheus以拉取形式爲主，即一旦產生符合規範的數據，只要具備一個可供拉取的地址就可以完成服務端拉取的策略，比較實時性。

　　作爲技術人，究竟應該如何擁抱微服務呢？針對此問題，王碧波對現場的開發者們說，擁抱微服務，最關鍵的一點還是應該積極適應Kubernetes。目前這是過去十年間在軟件領域比較革命性的”發明創造“，儘管線上服務確實會因爲Kubernetes產生很多風險，但不斷向其靠攏的心還是要有的。

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

　　據瞭解，京東雲在微服務架構方面有一些產品十分值得提及，例如關於全生命週期管理的Kubernetes的集羣；具備超級彈性伸縮、高可用還滿足雲部署等需求的DevOps；在功能實現方面主要包括函數服務、消息隊列、對象存儲等產品組件；如果着眼運行觀測，日誌服務、監控、調用鏈關係以及調用服務等更是必不可少。

　　分享過後，現場開發者還針對企業層面對微服務的觀念以及何時“上馬”微服務架構等諸多問題展開了深入探討。

　　現如今究竟什麼是Serverless?

　　應該如何打造自己的Serverless服務，有哪些標準或者範式可以參考？

　　Serverless的現在和未來走向哪裏？

　　雲原生給Serverless帶來了什麼？

　　開發者們談及針對Serverless的疑問或許比想法還要多，來自京東雲的技術專家張金柱卻又自己的一番見解。

　　“這是雲時代的一種架構思想。如今給大家提供了非常豐富的開發框架以及技術組件，時代很贊；此外雲計算將大量的社會資源，例如計算以及存儲資源集中到一起形成規模效應，這兩點確實成就了Serverless。”

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

　　京東雲架構師 張金柱

　　在有關Serverless的分享中，張金柱還對其架構特點進行了總結可以概括爲運維無負擔、極強的彈性伸縮能力以及按需付費的原則。

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

　　精彩的現場互動

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

　　雲計算基本上會以更加專業的方式去提供組件，包含一種趨勢；伴隨雲計算產生，會有一些人去解決基礎的技術問題，還有一些人去解決業務問題，分工不同。關於Serverless的挑戰和未來，引用伯克利給出的兩個重要總結，其實現在的Serverless有兩大退步：忽略了數據，或者說數據處理的要求；天然的無狀態對於分佈式並不友好，例如一致性問題以及事務性問題等。

　　精彩分享仍在繼續，現場氣氛始終火熱不減。

　　開發者們熱情不減

　　當前，雲原生時代下開源數據庫究竟有何突破發展？針對此問題，重度的開源愛好者劉奇也來到現場，針對數據庫發展趨勢，探討了雲計算爲開源數據庫帶來的機遇與挑戰，並結合數據庫在功能創新以及用戶體驗升級方面深入探究了雲原生、雲計算以及開源之間密切的技術關聯。

　　PingCAP 聯合創始人兼 CEO 劉奇

　　在“雲原生時代數據庫的發展趨勢 ”的分享中，劉奇表示，TiDB目前做的一些關於Computing的實踐，很有意思的點就是每一層都可以做成Computing。如果綜合去看其中的差異，其實TIDB是被當成計算上的Computing來實現支持，相當於被做成插件，如此形式在計算層可以，在存儲層也可以，而存儲層實現多個插件，這樣一來整體結構的靈活性就會體現的非常好。

　　針對圖數據庫是不是將來發展的趨勢，以及關係數據庫選擇的問題，劉奇認爲最主要的還是依靠場景的差異性來判斷使用。有些場景需要圖數據庫，而有些場景則需要關係數據庫，例如風控領域圖數據庫就會應用的比較多。圖數據庫中快速索引關係會非常快，相對而言關係數據庫則是更加方便選擇，主要還是依照業務需求。

　　儘管京東雲針對雲原生的精彩分享已暫時告一段落，但關於微服務、容器、無服務器以及開源數據庫等技術探討依舊在火熱進行中，敬請關注京東雲技術沙龍的後續活動。