国产69操逼,东京热欧美,91夜夜未满十八勿入爽爽影院,日韩无码高清视频,床戏做爰呻吟声,亚洲国产精品国自产拍社区,国产成人午夜视频,女生被艹在线观看

云原生的技術體系看似紛亂繁雜，但在不同視角都體現(xiàn)著“牽一發(fā)而動全身”的主線。從時間線來看，容器技術的發(fā)展催生了云原生思潮，在底層解決了資源供給問題，隨后開源的 Kubernetes成為容器編排的標準規(guī)范，當基于 Kubernetes 可擴展能力的開放應用平臺逐漸豐富，使其成為了云原生生態(tài)最重要的基石。隨后 Service Mesh、Serverless 技術的核心思想更偏重在業(yè)務側實現(xiàn)價值——將更多的能力下沉到基礎設施，為應用的輕量化、上云提供可能。

從技術需求的角度來看，微服務架構是解決單體復雜度問題的首選方式，卻帶來整個系統(tǒng)的整體復雜度大幅增加，容器技術和 Kubernetes 分別解決了微服務架構下大量應用的部署、以及容器的管理和調度問題，同時，Kubernetes 也為 Service Mesh 提供了更好的底層支撐，也帶來了底層基礎設施的 Serverless 云原生化和中間件能力的進一步下沉。

容器

容器是將進程有效地劃分一個獨立空間，以便在獨立的空間之間平衡資源使用沖突的技術。本質上，容器是一種特殊的進程，其核心功能是通過約束和修改進程的動態(tài)表現(xiàn)創(chuàng)造出一個“邊界”，此外，其資源限制能力、以及基于鏡像功能表現(xiàn)出的“強一致性”，都使得容器技術成為云原生最關鍵的底層技術之一。

Docker 容器因具有和虛擬機相似的隔離效果，而常常被稱為”輕量級“虛擬化技術，但這樣的說法并不嚴謹。在虛擬機中，Hypervisor是最主要的部分，它通過硬件虛擬化功能，模擬出 CPU、內存、I/O設備等各類硬件，之后在這些虛擬的硬件上安裝了一個新的操作系統(tǒng)，即 Guest OS，在虛擬的操作系統(tǒng)中運行的應用進程被相互隔離。

Docker 與虛擬機的差異體現(xiàn)在進程隔離方式的不同，Docker 通過為應用附加額外設置的Namespace參數(shù)實現(xiàn)進程的隔離，并沒有一個真正的”Docker容器“運行在宿主機中，這樣的“障眼法”操作讓進程仿佛運行在一個與世隔絕的“容器”里面，使得容器減少了額外的資源消耗和占用，在敏捷和高性能方面具有很大優(yōu)勢。

此外，容器的核心功能還包括基于Cgroups的資源限制能力，以及鏡像功能。Cgroups的作用是限制一個進程組能夠使用的資源上限，包括 CPU、內存、磁盤、網絡帶寬等資源。鏡像功能使得容器技術表現(xiàn)出“強一致性”，即在任何地點下載的鏡像內容完全一致，完全復現(xiàn)鏡像制作者當初的完整環(huán)境，這打通了“開發(fā) - 測試 - 部署”等流程的各個環(huán)節(jié)，使得容器技術成為軟件的主流發(fā)布方式。

Kubernetes

當容器鏡像成為應用分發(fā)的工業(yè)標準，能夠定義容器組織和管理規(guī)范的“容器編排”技術便成為了整個容器技術棧上的關鍵價值節(jié)點。主要的容器編排工具包括Docker公司的Compose+Swarm組合、Mesosphere 公司的 Mesos+Marathon 組合、Google與RedHat公司共同主導的Kubernetes項目，以及基于Kubernetes構建的 OpenShift和Rancher項目。最終，Kubernetes項目憑借優(yōu)秀的開放性、可擴展性以及活躍開發(fā)者社區(qū)，在容器編排之戰(zhàn)中脫穎而出，成為分布式資源調度和自動化運維的事實標準。

Kubernetes項目的主要設計思想在于，從更宏觀的角度，以統(tǒng)一的方式來定義任務之間的各種關系，并且為將來支持更多種類的關系留有余地。從功能的角度來看，Kubernetes更擅長按照用戶的意愿和整個系統(tǒng)的規(guī)則，自動化地處理好容器之間的各種關系，即容器的編排，包括部署、調度和節(jié)點集群間擴展等主要功能。而Mesos、Swarm等項目擅長把一個容器，按照某種規(guī)則，放置在最佳節(jié)點運行起來，即容器的調度。這也是Kubernetes項目最終脫穎而出的重要原因。

Kubernetes 核心能力：

服務發(fā)現(xiàn)和負載均衡：通過Service資源展現(xiàn)各種應用服務，結合DNS和多種負載均衡機制，支持容器化應用之間的相互通信。
存儲編排：通過plungin的形式支持多種存儲，如本地、nfs、ceph、公有云塊存儲等。
資源調度：設置pod調度的所需資源和資源限制，支持應用的自動發(fā)布和應用回滾，管理應用的相關配置。
自動修復：監(jiān)測集群中所有宿主機，自動發(fā)現(xiàn)和處理集群內異常，更換需重啟的pod節(jié)點，使容器集群運行在用戶的期望狀態(tài)。
密鑰和配置管理：通過secret存儲敏感信息，通過configmap存儲應用的配置文件，避免將配置文件固定在鏡像中，增加容器編排的靈活性。
橫向擴展功能：實現(xiàn)基于CPU利用率或基于平臺級的彈性伸縮，如自動增加、刪除nodes節(jié)點。

Kubernetes項目由控制節(jié)點Master和計算節(jié)點Node組成。Master作為控制管理的節(jié)點，由三個緊密協(xié)作的獨立組件組成：kube-apiserver負責API服務，kube-scheduler負責資源調度，kube-controller-manager負責容器編排。另外，集群的持久化數(shù)據(jù)由kube-apiserver處理后保存在Etcd中，如Pod、Service等對象信息。計算節(jié)點Node作為項目的工作負載，kubelet組件是其最核心的部分，負責Pod對應的容器的創(chuàng)建、啟停等任務，同時與Master節(jié)點密切協(xié)作，實現(xiàn)集群管理的基本功能。

如今，Kubernetes項目不僅是容器技術的事實標準，更成為整個云原生體系發(fā)展的基石，重新定義了基礎設施領域對應用編排與管理的各種可能。在整個云原生生態(tài)中，Kubernetes項目起到了承上啟下的作用。對上，Kubernetes暴露出基礎設施能力的格式化數(shù)據(jù)抽象，如 Service、Ingress、Pod、Deployment，都是Kubernetes本身原生API為用戶暴露出來的能力。而對下，Kubernetes提供了基礎設施能力接入的標準接口，如 CNI、CSI、DevicePlugin、CRD，讓云能夠作為能力提供商，通過標準化的方式把能力接入到Kubernetes的體系中。伴隨著微服務、DevOps等技術理念的發(fā)展，基于Kubernetes可擴展能力的開放應用平臺將取代PaaS成為主流，而云的價值會回歸應用本身，越來越多的開源項目會以云原生理念去開發(fā)、部署和運維，最后直接演進成為一種云服務。

微服務

微服務是服務架構演進的產物，在歷經單體架構、垂直架構、面向服務的架構（SOA）之后，微服務架構（MSA）可視為SOA架構的分布式實現(xiàn)方式。隨著業(yè)務發(fā)展與需求不斷增加，單體應用功能愈發(fā)復雜，應用迭代效率由于集中式研發(fā)、測試、發(fā)布、溝通模式而顯著下滑。

微服務架構本質上是通過承受更高的運維復雜度來換取更好的敏捷性，其優(yōu)勢在于小而治之、去中心化，但也導致基礎架構的需求、成本和復雜性激增。

目前為止，微服務并沒有統(tǒng)一的標準定義，結合Martin Fowler的描述：微服務架構是一種架構模式 / 架構風格，將單獨的應用程序開發(fā)為一套小服務并獨立運行在自己的進程中，相互之間使用HTTP API等輕量級機制通信。這些服務圍繞著具體業(yè)務進行構建，通過完全自動化部署機制來獨立部署，并可使用不同的編程語言書寫，以及不同數(shù)據(jù)存儲技術，并保持最低限度的集中式管理。

Dubbo 和 Spring Cloud 走向融合，更多的功能將被下沉到基礎設施

Spring Cloud

Spring Cloud是第一代微服務架構的翹楚，為實現(xiàn)微服務架構提供了一站式解決方案，作為一個全家桶式的技術棧，為開發(fā)者提供了快速構建分布式系統(tǒng)的通用模型的工具，包括配置管理、服務發(fā)現(xiàn)、熔斷器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領導選舉、分布式會話、集群狀態(tài)等。

Dubbo

Dubbo作為由阿里巴巴開源的分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及 SOA服務治理方案。核心部分包含：遠程通訊、集群容錯、自動發(fā)現(xiàn)等。

近年來Dubbo生態(tài)不斷完善，2019年5月，Dubbo-go正式加入Dubbo官方生態(tài)，隨后實現(xiàn)了REST協(xié)議以及 gRPC的支持，打通了Spring Cloud和gRPC生態(tài)，Go項目與Java&Dubbo項目的互通問題得到了有效解決。時至今日，由于Spring Cloud Alibaba的出現(xiàn)，Dubbo將無縫整合Spring Cloud生態(tài)的各種周邊產品。

無論是Dubbo還是Spring Cloud，都或多或少限定于特定的應用場景和開發(fā)環(huán)境，缺少對通用性和多語言性的支持，并只解決了微服務Dev層面的問題，缺少DevOps的整體解決方案，這些都為Service Mesh 的興起創(chuàng)造了條件。

作為微服務管理和通訊的完整解決方案，Dubbo和Spring Cloud將長期共存并走向融合，但其提供的部分功能將逐漸被基礎設施所取代。如部署在kubernetes集群上的微服務，利用kubernetes的服務注冊和發(fā)現(xiàn)的功能會更加簡單；再如使用Istio架構，流量管理和circuit breaker等功能將轉移到envoy代理，越來越多的功能會從應用程序剝離并下沉到基礎設施。

Service Mesh

Service Mesh通常被譯為服務網格，在云原生應用復雜的服務拓撲結構中，Service Mesh作為基礎設施層，負責在這些拓撲結構中實現(xiàn)請求的可靠傳遞。Service Mesh通過在請求調用的路徑中增加Sidecar，將原本由客戶端完成的復雜功能下沉到Sidecar 中，實現(xiàn)對客戶端的簡化和服務間通信控制權的轉移，當系統(tǒng)中存在大量服務時，服務間的調用關系表現(xiàn)為網狀，這也是服務網格名稱的由來。

我們可以從以下幾個特征對Service Mesh的定義給出概括和總結：

抽象： Service Mesh將通信功能從應用中剝離出來，形成一個單獨的通信層，并將其下沉到基礎設施層。
功能： Service Mesh負責實現(xiàn)請求的可靠傳遞，從功能上來說和傳統(tǒng)的類庫方式并無不同。
部署： Service Mesh在部署上體現(xiàn)為輕量級網絡代理，以Sidecar模式和應用程序一對一部署，兩者之間的通信通過Localhost遠程調用。
透明： Service Mesh的功能實現(xiàn)完全獨立于應用程序，可以獨立部署升級、擴展功能、修復缺陷，應用程序無須關注Service Mesh的具體實現(xiàn)細節(jié)，即對應用程序是透明的。

Service Mesh的核心價值不只體現(xiàn)在其功能和特性，更在于實現(xiàn)業(yè)務邏輯和非業(yè)務邏輯的分離。非業(yè)務邏輯將被從客戶端SDK剝離，以Proxy獨立進程運行，從而將原來存在于SDK中的各種能力下沉到基于容器、Kubernetes或 VM的基礎設施，實現(xiàn)云上的托管、應用的輕量化，以幫助應用云原生化。

主流的Service Mesh開源軟件包括Linkerd、Envoy和Istio。Linkerd和Envoy都直接體現(xiàn)了Service Mesh的核心理念，在功能上較為相似，即實現(xiàn)服務發(fā)現(xiàn)、請求路由、負載均衡等功能，解決服務之間的通信問題，使得應用對服務通信無感知。而Istio站在了更高的角度，將Service Mesh分為了Data Plane和Control Plane，由Data Plane負責微服務間的所有網絡通信，而Control Plane負責管理Data Plane Proxy，且Istio天然支持Kubernetes，這也彌合了應用調度框架與Service Mesh之間的空隙。

微服務落地需要一套完整的基礎設施，當容器成為微服務的最小工作單元，Kubernetes作為通用的容器管理平臺，能夠發(fā)揮微服務架構的最大優(yōu)勢，使其成為云計算的新一代操作系統(tǒng)。Kubernetes不僅能夠支持運行云原生和傳統(tǒng)的容器化應用，并且覆蓋Dev和Ops階段，與Service Mesh的結合可以為用戶提供完整端到端的微服務體驗。

Serverless

Serverless將Service Mesh的應用場景泛化，不僅僅局限于服務間的同步通信，而是推廣到有網絡訪問、通過客戶端 SDK 實現(xiàn)的更多場景，包括計算、存儲、數(shù)據(jù)庫、中間件等各種服務。如在螞蟻金服的Serverless實踐中，Mesh模式還延伸到了Database Mesh（數(shù)據(jù)庫訪問）、Message Mesh（消息機制）、Cache Mesh（緩存）等場景。

目前，Serverless通常被看作是FaaS（函數(shù)即服務）、BaaS（后端即服務）的集合，但Serverless只定義了一種用戶體驗，而不是某種技術，F(xiàn)aaS、BaaS 都只是Serverless的一種實現(xiàn)方式。隨著Serverless技術的不斷成熟，越來越多使用kubernetes服務的應用將轉化成為Serverless應用。

云原生中間件?

傳統(tǒng)中間件類似于城市中的輸水管道，推動并管理數(shù)據(jù)從一個應用流向另一個應用，其業(yè)務耦合度高、不能為用戶帶來直接價值。進入云時代，軟件的異構現(xiàn)象、互聯(lián)需求顯著增加，中間件被賦予了新的功能定義，即功能獨立、耦合度低、組件模塊化，并被下沉到基礎設施，成為實現(xiàn)高性能、高可用、高伸縮性和最終一致性的分布式應用開發(fā)架構的關鍵組成部分。

從功能定義來看，中間件是一類連接軟件組件和應用的計算機軟件，它包括一組服務，以便于運行在一臺或多臺機器上的多個軟件通過網絡進行交互，屬于可復用軟件范疇。云原生中間件包括API、應用服務器、TP、RPC、MOM，也可以承擔數(shù)據(jù)整合、應用整合的作用，任何位于內核和用戶應用之間的軟件都可以理解為中間件。

伴隨 IoT、云計算技術的快速發(fā)展，EDA（事件驅動架構）正在被越來越多的企業(yè)采納，通過事件的抽象、異步化，來提供業(yè)務解耦、加快業(yè)務迭代，也正在從支持垂直行業(yè)轉向通用關鍵業(yè)務應用架構，應用在打包應用、開發(fā)工具、業(yè)務過程管理和監(jiān)視等領域。

EDA 往往通過消息中間件實現(xiàn)，消息中間件旨在利用高效可靠的消息傳遞機制進行平臺無關的數(shù)據(jù)交流，通過提供消息傳遞和消息排隊模型，實現(xiàn)在分布式環(huán)境下擴展進程間的通信，并基于數(shù)據(jù)通信進行分布式系統(tǒng)的集成。常見的消息中間件包括ActiveMQ、RabbitMQ 、RocketMQ 、Kafka 等，可應用在跨系統(tǒng)的數(shù)據(jù)傳遞、高并發(fā)的流量削峰、數(shù)據(jù)異步處理等場景。

進入云計算時代，云廠商提供更加貼近業(yè)務的封裝，多采用自身的 Serverless 服務來運行事件負載，中間件的能力很容易通過云服務來實現(xiàn)，包括阿里云 Function Compute、Azure Function、AWS Lambda 都集成了事件處理。

未來，應用中間件將不再是能力的提供方，而是能力接入的標準界面，這個標準界面將通過HTTP、 gRPC 協(xié)議進行構建，并通過 Sidecar 解耦整個服務的接入層與應用業(yè)務邏輯，這與 Service Mesh 的思想一致。更進一步的，Sidecar 模型能夠應用在所有的中間件場景，從而將中間件能力“下沉”到 Kubernetes 能力的一部分。

DevOps

伴隨云原生開源生態(tài)不斷完善，以及復雜功能不斷下沉到云，基本統(tǒng)一了軟件部署和運維的基本模式。在 DevOps 之前，從業(yè)人員使用瀑布模型或敏捷開發(fā)模型進行軟件項目開發(fā)。DevOps 作為Development和Operations 的組合，被定義為實現(xiàn)軟件開發(fā)和 IT 團隊之間流程自動化的一組實踐，這些實踐建立在團隊之間協(xié)作文化的基礎上，填補了開發(fā)端和運維端之間的信息鴻溝，以便更快、更可靠地構建、測試和發(fā)布軟件，目前已經成為主流的軟件開發(fā)交付模式。

總體來看，DevOps包含了開發(fā)、測試和運維三部分。具體看來，它由多個階段組成：持續(xù)開發(fā)、持續(xù)集成、持續(xù)測試、持續(xù)反饋、持續(xù)監(jiān)測、持續(xù)部署、持續(xù)運維，統(tǒng)稱為DevOps生命周期。

DevOps功能的分與合在信息流轉層面得到了充分體現(xiàn)，在開發(fā)交付測試、測試回饋、交付發(fā)布等階段，各類信息的提供方、接收方使用優(yōu)質的工具系統(tǒng)，進而實現(xiàn)順暢精準的傳輸信息和高效的執(zhí)行機械化操作。

從上述發(fā)展理念來看，DevOps的思想源于基礎設施層不夠強大、不夠標準化，所以業(yè)務側需要一套工具來黏合研發(fā)、運維人員和相應的基礎設施。但隨著Kubernetes和基礎設施越來越復雜，云原生生態(tài)會做出相應的抽象和分層，每一層的角色只和屬于自己的數(shù)據(jù)抽象去交互，即開發(fā)側和運維側的關注點分離。不斷泛化的Serverless也將成為DevOps的一種思想導向和組成部分。在能力側，“輕運維”、“NoOps”、“自助式運維能力”會成為應用運維的主流方式。在應用側，應用描述會廣泛地進行用戶側的抽象，事件驅動和Serverless理念被拆分和泛化，可以被應用于FaaS之外的多樣化的場景中。