視頻課程 | 雲原生與微服務架構

京東雲開發者社區在3月底於北京舉行了以「Cloud Native時代的應用之路與開源創新」爲主題的技術沙龍，現場多位技術大咖與開發者們面對面就Cloud Native進行了深刻交流，探討涉及容器、開源數據庫等諸多技術層面的問題。

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

咱們將整理後的視頻及內容資料在這裏分享給你們，沒能到場的小夥伴能夠經過這些資料來學習和了解課程內容。

沙龍內容概要

沙龍活動重點聚焦雲原生時代下，容器、微服務、Serverless以及數據庫等技術應用與開源創新，同時高度結合京東雲在Cloud Native以及開源領域的核心技術與一系列成功實踐爲開發者們進行答疑解惑！

如下是沙龍第二部分分享的所有內容，但願能給各位開發者帶來幫助：

雲原生與微服務架構

—— 京東雲專家架構師   王碧波——

（建議在Wi-Fi環境下觀看）

https://v.qq.com/x/page/t0856s6qgbg.html?start=undefined

01微服務架構概述

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

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

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

02

常見微服務架構

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

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

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

另外還有一種，名叫Spring Cloud。具有統一的規範以及接口，背後支持多種不一樣且具體的服務，且自己與Kubernetes沒有任何衝突。

談及最近紅火的服務網格，王碧波認爲，服務網格最大的特色就是經過引入網絡代理，時業務活力和服務治理完全切分；而且，全部的策略調整都以一個動態的配置變動方式來實現，而不是採用變更代碼的方式，進而實現一種業務邏輯與服務治理完全被切分的狀態，目前能夠說起的Kong Mesh就是服務網格的具體架構實現，也是表明性的微服務架構之一。

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

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

03雲原平生臺的將來

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

「簡單介紹下Envoy。使用者衆多；大量項目集成的對象，比方說最火的服務網格Istio；本質上是一個網絡代理，你可能會疑惑，現在最知名的網絡代理明明是Nginx，爲何還須要Envoy這呢？最關鍵的在於在服務網格時代，人們但願全部的配置均可以達成動態下發，而不是去手動修改代碼再統一上線操做，Envoy基於API動態配置剛好實現了這個想法。」

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

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

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

04擁抱微服務

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

談及微服務架構的選擇，根據企業狀況不一樣主要能夠歸爲幾種：首先是徹底自研的選擇，比較適合基礎架構研發能力特別強的大型公司；其次直接上手一些開源的框架，這對於大多數公司都是比較適合的；第三種選擇，使用公有云提供的微服務框架；另外，開源/資源+公有云結合的方式也是很是不錯的一種選擇。

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

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

*以上爲沙龍第二部分的內容！Enjoy

歡迎點擊「連接」瞭解更多精彩內容

點擊下方「閱讀原文」得到完整PPT

·END·

閱讀原文