雲原生java的那些事兒

內容來源：2017年12月16日，京東金融數據研發負責人張亮在「數人云Meetup | 下一代微服務：ServiceMesh Is Coming」進行《雲原生java的那些事兒》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2512 | 7分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/4NIdmt

摘要

在微服務概念大行其道的今天，Java無疑是相關生態體系最爲完善開發語言。但云原生概念的出現，更增強調異構語言的無差別化開發。那麼Java的強大生態體系該如何與雲原生對接，又應該作哪些取捨，最終的發展趨勢如何？本次將分享一些個人見解。

技術的演化緣由

規模的增加是帶來技術演化的最主要緣由，由此也帶來了各方面的變化。原來適應小規模的架構設計、開發框架、運維模式，在規模逐漸增大的現狀下都須要進行從新的規劃。

技術的演化方向

在架構設計上咱們一開始關注的是分層，思考的是如何在開發中將業務系統進行分層，使得業務可以解耦，易於維護。再進一步就是SOA，將原先的系統變爲服務化的系統，由系統內部的訪問變成跨系統的服務訪問。而如今更多使用的是微服務，將服務拆分的更加複雜，經過微服務去提供系統之間的交互和架構設計。

開發框架則由原來的單體式過分爲分佈式，到如今的雲時代，大部分互聯網公司都在使用混合雲或者公有云，雲原生的開發框架也就應運而生。

運維模式從最開始的腳本化，只是在Linux上去寫shell，而後上線部署基礎原件。以後發展到了工具化，經過一些工具進行更加自動化的處理。到如今徹底自動化已被實現。

單體式架構 -> 分佈式架構

上圖表示是由阿里開源出來的Dubbo，是一個SOA的服務化框架，它能夠完成從單體式框架到垂直擴展的框架再到徹底的分佈式服務的拆分。

Dubbo是點對點的服務框架，全部的服務都會註冊到一個註冊中心，由註冊中心負責服務發現，而後由服務的消費者去作負載均衡。其實Dubbo的服務者和消費者只要互相發現了對方就會直接的去創建一個點對點的鏈接，因此有很高的性能。

Dubbo的另外一個優點就是徹底透明化的調用，在本地調用方法和在Dubbo中調用時徹底看不出區別的，所以無需去關注本地化仍是透明化。

雲原生首映——Spring Cloud

Spring Cloud提供了整套的服務化技術棧，它和Dubbo的關注點不同，做爲一個服務治理框架所包含範圍比Dubbo更廣。而Dubbo是有着服務治理功能的RPC框架，關注的重點是RPC和通訊這塊。

因爲Spring Cloud的關注點並無在點對點的鏈接上，而是使用Rest API這樣的APP形式調用，所以在性能上會稍微低一些，但在服務治理方面的性能就要強不少。

運維模式改變 – 容器+編排（K8S）

K8S被分爲master和node節點，實際幹活的是node，master則是用來控制執行。Spring Cloud所涉及的部分，Kubernetes都會包含。這其中進程的隔離Kubernetes能經過容器去完成，而Spring Cloud對這方面就無能爲力，另外環境和資源的管理Spring Cloud也沒法處理。

能夠看出Kubernetes更多的是偏向於運維，它將運維的模式集成的更自動化。

雲原生是一種模式

雲原生實際上是一種模式，它要求更高的可用性和伸縮性，也就是要求應用永遠不會掛掉，而且可以自動的針對流量進行擴容。另外還須要實現自動化的部署和管理，好比定時的代碼上線之類的，無需運維手動的去執行腳本。最後要求達到效率提高和隨處運行的目標。

雲原生十二要素

因爲不是全部的程序都可以無縫的在雲平臺運行，因此作雲原生的程序就要知足雲原生的十二要素。這些要素不會對程序進行本質上的修改，而是從另外一方面進行提高，使得程序可以更容易的解除無狀態的應用，同時方便隨處部署和擴容。

雲原生全景圖

編排領域

這一層所作的首先是調度，就是決定資源和應用的組合，當應用得到資源後纔會真正的去運行。另外一方面是編排，也就是將調度按照本身的指望去運行。

服務治理領域

上圖中linkerd是最早提出來的Service Mesh概念的產品。而GRPC是一個跨語言而且是徹底基於HTTP2協議RPC的框架，它經過雙向不受干擾的長鏈接進行交互。

Service Mesh – Linkerd

Linkerd的全部服務再也不是由中心節點去控制，而且它也不和服務部署在一塊兒。從上圖咱們能夠看出全部的服務都是經過代理方式訪問，好比要經過A去訪問B時，不會像Dubbo同樣去直連，而是由A訪問本機的Linkerd，再由這個Linkerd去鏈接B上的Linkerd，最後由B上的Linkerd去轉發給B。這個過程當中全部的代理都是由Linkerd控制，它可以將全部的流量都控制住，而且它仍是徹底跨語言的。

Service Mesh – Istio

Istio將服務治理分爲了兩部分，一部分是數據面板，另外一部分是控制面板。數據面板主要是處理服務治理、服務發現以及網絡之間的調用，也就是真正用來幹活的。而控制面板又被分爲3大塊，pilot是用來進行任務調度用的，Mixer可以經過簡單的編程接口去實現一些功能，好比黑白名單之類的，Istio-Auth則是一個權限的控制，可以將網絡流量徹底控制在控制面板內。

開發和運維模式的改變

運維模式向自動化和可視化發展，無需再手動進行操做而且能經過控制面板直接查看到流量的大體狀況。開發模式則會更關注業務自己勝於功能性需求，調試模式也發生了改變，開發人員沒法再直接的登陸到線上環境查看應用狀態，而只能經過遙感的方式操做。

將來的趨勢

單機的操做系統將會被拋棄，取而代之的是容器調度加編排的雲操做系統。裸機或者虛擬機的運行時也將會被容器取代。通訊方面將會使用Service Mesh。