雲原生java的那些事兒

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

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

開發框架則由原來的單體式過度為分散式，到現在的雲時代，大部分網際網路公司都在使用混合雲或者公有云，雲原生的開發框架也就應運而生。

運維模式從最開始的指令碼化，只是在Linux上去寫shell，然後上線部署基礎原件。之後發展到了工具化，通過一些工具進行更加自動化的處理。到現在完全自動化已被實現。

上圖表示是由阿里開源出來的Dubbo，是一個SOA的服務化框架，它可以完成從單體式框架到垂直擴充套件的框架再到完全的分散式服務的拆分。

Dubbo是點對點的服務框架，所有的服務都會註冊到一個註冊中心，由註冊中心負責服務發現，然後由服務的消費者去做負載均衡。其實Dubbo的服務者和消費者只要互相發現了對方就會直接的去建立一個點對點的連線，所以有很高的效能。

Dubbo的另一個優勢就是完全透明化的呼叫，在本地呼叫方法和在Dubbo中呼叫時完全看不出區別的，因此無需去關注本地化還是透明化。

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

由於Spring Cloud的關注點並沒有在點對點的連線上，而是使用Rest API這樣的APP形式呼叫，因此在效能上會稍微低一些，但在服務治理方面的效能就要強很多。

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

可以看出Kubernetes更多的是偏向於運維，它將運維的模式整合的更自動化。

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

由於不是所有的程式都能夠無縫的在雲平臺執行，所以做雲原生的程式就要滿足雲原生的十二要素。這些要素不會對程式進行本質上的修改，而是從另一方面進行提升，使得程式能夠更容易的解除無狀態的應用，同時方便隨處部署和擴容。

這一層所做的首先是排程，就是決定資源和應用的組合，當應用獲得資源後才會真正的去執行。另一方面是編排，也就是將排程按照自己的期望去執行。

上圖中linkerd是最先提出來的Service Mesh概念的產品。而GRPC是一個跨語言並且是完全基於HTTP2協議RPC的框架，它通過雙向不受干擾的長連線進行互動。

Linkerd的所有服務不再是由中心節點去控制，並且它也不和服務部署在一起。從上圖我們可以看出所有的服務都是通過代理方式訪問，比如要通過A去訪問B時，不會像Dubbo一樣去直連，而是由A訪問本機的Linkerd，再由這個Linkerd去連線B上的Linkerd，最後由B上的Linkerd去轉發給B。這個過程中所有的代理都是由Linkerd控制，它能夠將所有的流量都控制住，並且它還是完全跨語言的。

Istio將服務治理分為了兩部分，一部分是資料皮膚，另一部分是控制皮膚。資料皮膚主要是處理服務治理、服務發現以及網路之間的呼叫，也就是真正用來幹活的。而控制皮膚又被分為3大塊，pilot是用來進行任務排程用的，Mixer能夠通過簡單的程式設計介面去實現一些功能，比如黑白名單之類的，Istio-Auth則是一個許可權的控制，能夠將網路流量完全控制在控制皮膚內。

運維模式向自動化和視覺化發展，無需再手動進行操作並且能通過控制皮膚直接檢視到流量的大致情況。開發模式則會更關注業務本身勝於功能性需求，除錯模式也發生了改變，開發人員無法再直接的登入到線上環境檢視應用狀態，而只能通過遙感的方式操作。

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