應(yīng)用 & 容器 &?Pod 的關(guān)系
應(yīng)用部署在容器中，一般情況下一個(gè)應(yīng)用只部署在一個(gè)容器中；
一個(gè) Pod 下可以包含一個(gè)或多個(gè)容器，一般情況下一個(gè) Pod 只建議部署一個(gè)容器。下列場(chǎng)景除外：
side car；
一個(gè)容器的運(yùn)行以來(lái)與本地另外一個(gè)容器。如一個(gè)容器下應(yīng)用負(fù)責(zé)下載數(shù)據(jù)，另外一個(gè)容器下應(yīng)用向外提供服務(wù)。
Service
如果一些 Pods 提供了一些功能供其它的 Pod 使用，在 Kubernete 集群中是如何實(shí)現(xiàn)讓這些前臺(tái)能夠持續(xù)的追蹤到這些后臺(tái)的？答案是：Service 。
Kubernete Service 是一個(gè)定義了一組 Pod 的策略抽象，這些被服務(wù)標(biāo)記的 Pod 一般都是通過(guò) label Selector 決定的。Service 抽象了對(duì) Pod 的訪問(wèn)。
默認(rèn)的 Service ，通過(guò)一個(gè)集群 IP 獲取 A Record 。但是有時(shí)需要返回所有滿足條件的 Pod IP 列表，這時(shí)候可以直接使用 Headless Services 。
參考：https://kubernetes.io/
推薦書(shū)籍：[kubernetes in action]
RPC 介紹和分析
隨著微服務(wù)的普及，應(yīng)用之間的通信有了足夠多的成熟方案。
Dubbo 在 2011 年開(kāi)源之后，被大量的中小型公司采用；
在 Spring Boot 推出之后，Spring 逐漸煥發(fā)出第二春，隨即 Spring Cloud 面世，逐漸占領(lǐng)市場(chǎng)，在中國(guó)市場(chǎng)中，和 Dubbo 分庭抗?fàn)帲?br />
gRPC 是 Google 推出的基于 Http2 的端到端的通信工具，逐漸在 K8s 市場(chǎng)上占據(jù)統(tǒng)治地位，如 etcd，Istio 等都采用 gRPC 作為通信工具；
Service Mesh 從開(kāi)始概念上就火熱，現(xiàn)在逐漸走向成熟；
Istio Envoy (其他 sidecar )逐漸開(kāi)始走上舞臺(tái)。
應(yīng)用開(kāi)發(fā)者視角
從功能層面來(lái)說(shuō)，對(duì)開(kāi)發(fā)者有感知的功能有：
服務(wù)實(shí)現(xiàn)
服務(wù)暴露(注解或配置)
服務(wù)調(diào)用(注解或配置)
服務(wù)治理等
從選型角度會(huì)關(guān)注以下幾點(diǎn)：
易用性(開(kāi)發(fā)易用性和開(kāi)箱即用)
性能
功能
擴(kuò)展性等
框架開(kāi)發(fā)者視角
關(guān)鍵流程：
服務(wù)暴露
服務(wù)注冊(cè)
服務(wù)發(fā)現(xiàn)
服務(wù)調(diào)用
服務(wù)治理
關(guān)鍵知識(shí)點(diǎn)：
序列化
網(wǎng)絡(luò)通信
服務(wù)路由
負(fù)載均衡
服務(wù)限流
熔斷
降級(jí)等服務(wù)治理
主流技術(shù)實(shí)現(xiàn)
Dubbo / HSF
Dubbo 提供了面向接口的遠(yuǎn)程方法調(diào)用。應(yīng)用開(kāi)發(fā)者定義接口，編寫(xiě)服務(wù)并暴露；
Client 端通過(guò)接口進(jìn)行調(diào)用；
Dubbo 注冊(cè)服務(wù)的維度是接口維度，每個(gè)接口會(huì)在注冊(cè)中心寫(xiě)入一條數(shù)據(jù)；
Dubbo 支持條件路由，腳本路由，Tag 路由等。這些路由規(guī)則都是強(qiáng)依賴于 IP 地址。
備注：Dubbo 和 HSF 的大部分機(jī)制都是相似的，所以下面都以 Dubbo 作為方案進(jìn)行討論。
SpringCloud
Spring Cloud 通過(guò) Rest 形式進(jìn)行網(wǎng)絡(luò)調(diào)用。應(yīng)用開(kāi)發(fā)者可以自己編寫(xiě)暴露 Rest 服務(wù)，如 springmvc 。
Spring Cloud 里的服務(wù)注冊(cè)是應(yīng)用維度( Eureka )，Client 端和 Server 端通過(guò)約定的方式進(jìn)行通信。
Spring Cloud 提供了一套標(biāo)準(zhǔn) API ，而其中 Netflix 是其中的佼佼者，對(duì)這套 API 進(jìn)行了實(shí)現(xiàn)，對(duì)大部分開(kāi)發(fā)者來(lái)說(shuō)，可以回直接依賴和使用 Netflix ，所以可以說(shuō)是 Netflix 提供成了 Spring Cloud 的核心。但是作為商業(yè)公司對(duì)開(kāi)源投入往往會(huì)多變，如 Eureka 已經(jīng)體制維護(hù)。
gRPC
gRPC 是一個(gè)基于 HTTP/2 協(xié)議設(shè)計(jì)的 RPC 框架，它采用了 Protobuf 作為 IDL。gRPC 作為端到端的通信方案，可以解決現(xiàn)在的多語(yǔ)言問(wèn)題。
gRPC 本身不提供服務(wù)注冊(cè)，服務(wù)治理的功能。但現(xiàn)在可以看到 gRpc 有趨勢(shì)往這方面擴(kuò)展的野心。
K8s
K8s 體系里暫時(shí)沒(méi)有公允的通信框架，一般推薦 gRPC 作為 RPC 框架。
K8s 體系的默認(rèn)情況下， Pod 的 IP 是變化的，所以 Pod 和 Pod 之間需要通信的話，有幾種方式：
Service dns：新建一個(gè) Service ，可以通過(guò)標(biāo)簽選擇到一組 Pod 列表，這個(gè) Service 對(duì)應(yīng)一個(gè)不變的集群 IP ；Client 端通過(guò) DNS 方式或者直接訪問(wèn)集群 IP。這個(gè)集群 IP ，約等于實(shí)現(xiàn)了負(fù)載均衡 ( iptable 方式)；
headless service：headless service 和上面的 service 的區(qū)別是，它不提供集群 IP ，通過(guò)主機(jī)名的形式獲取一組 IP 列表，Client 端自己決定訪問(wèn)哪個(gè) Pod。
Istio Envoy
Istio 的控制層會(huì)向 K8s 的 Api server 請(qǐng)求并監(jiān)聽(tīng) pod 信息，service 信息等信息。這樣 Istio 中就有了完整的 K8s 集群中的 pod，service 等的完整信息。如果 K8s 集群中有信息變更，Istio 中也可以得到通知并更新對(duì)應(yīng)的信息。
Envoy 作為 Proxy 一個(gè)最常見(jiàn)的實(shí)現(xiàn)，以 Envoy 作為例子簡(jiǎn)單介紹。Envoy 通過(guò)查詢文件或管理服務(wù)器來(lái)動(dòng)態(tài)發(fā)現(xiàn)資源。對(duì)應(yīng)的發(fā)現(xiàn)服務(wù)及其相應(yīng)的 Api 被稱作 xDS 。協(xié)議內(nèi)容包括 LDS、RDS、CDS 等等。
參考資料：
Service Mesh 介紹：https://www.infoq.cn/article/pattern-service-mesh[Istio]
路由規(guī)則：https://istio.io/docs/tasks/traffic-management/request-routing/
備注：上述知識(shí)是通過(guò)查閱資料( Istio 官網(wǎng))，以及和集團(tuán) Service Mesh 同學(xué)溝通獲得。如有問(wèn)題，歡迎指正。
小結(jié)
遇到的問(wèn)題和挑戰(zhàn)
Spring Cloud 和 Dubbo 的共生
Dubbo 默認(rèn)是基于 TCP 通信，Spring Cloud 大部分基于 Rest 請(qǐng)求。在阿里云實(shí)施商業(yè)化過(guò)程中，發(fā)現(xiàn)大量公司需要 Spring Cloud 應(yīng)用和 Dubbo 進(jìn)行通信，社區(qū)主要依靠 Dubbo 上增加一層網(wǎng)關(guān)來(lái)解決。
是否有方案進(jìn)行統(tǒng)一服務(wù)注冊(cè)發(fā)現(xiàn)，以及服務(wù)調(diào)用呢？
基礎(chǔ)理論可以參考：
https://yq.aliyun.com/articles/585461
Dubbo 在 K8s 場(chǎng)景下的挑戰(zhàn)
K8s 下 Pod 的 IP 是變化的 (默認(rèn))，Dubbo 的服務(wù)治理高度依賴 IP 。
K8s 的服務(wù)注冊(cè)通過(guò) Pod 定義完成，服務(wù)發(fā)現(xiàn)其實(shí)是尋找 Pod 的過(guò)程。Pod 和應(yīng)用有一定的對(duì)應(yīng)關(guān)系，和 Dubbo 里的接口維度的服務(wù)注冊(cè)發(fā)現(xiàn)模型不是很匹配。
Dubbo?在?Service Mesh 場(chǎng)景下的生存空間
Dubbo 需要進(jìn)行支持裁剪，Dubbo 的大部分功能都可以交由 sidecar ( proxy )來(lái)完成。
如果公司已經(jīng)在部署 RPC 框架，這時(shí)候如果需要實(shí)施?Service Mesh ，有什么好的過(guò)渡方案嗎？
問(wèn)題梳理
服務(wù)定義
服務(wù)怎么定義呢？需要從應(yīng)用開(kāi)發(fā)者角度看待怎么定義服務(wù)。
服務(wù)在功能維度對(duì)應(yīng)某一功能，如查詢已買訂單詳情。在 Dubbo 中，對(duì)應(yīng)某個(gè)接口下的方法；在 Spring Cloud 和 gRPC 對(duì)應(yīng)一個(gè) http 請(qǐng)求。
如果從面向函數(shù)編程角度，一個(gè)服務(wù)就是一個(gè) function 。在 Java 語(yǔ)言中，class 是一切編程的基礎(chǔ)，所以將某些服務(wù)按照一定的維度進(jìn)行聚合，放到某個(gè)接口中，就成了一個(gè)接口包含了很多的服務(wù)。
從 Dubbo 角度來(lái)解釋下：Dubbo 是面向接口編程的遠(yuǎn)程通信，所以 Dubbo 是面向服務(wù)集的編程，你如果想調(diào)用某個(gè)服務(wù)，必須通過(guò)接口的方式引入，然后調(diào)用接口中的某個(gè)服務(wù)。Dubbo Ops 中提供的服務(wù)查詢功能，其實(shí)不是查詢單個(gè)服務(wù)，而是通過(guò)查詢接口(服務(wù)集)之后獲得具體的方法(服務(wù))。
而在 Spring Cloud 的世界里，服務(wù)提供方會(huì)將自己的應(yīng)用信息( Ip port )注冊(cè)成應(yīng)用下的一個(gè)實(shí)例，服務(wù)消費(fèi)方和服務(wù)提供方按照約定的形式進(jìn)行 Rest 請(qǐng)求。每個(gè)請(qǐng)求對(duì)應(yīng)的也是一個(gè)服務(wù)。
和 K8s 里的 Service 的區(qū)別
K8s 里的 Service 其實(shí)是對(duì)應(yīng)到一組 pod port 列表，和 DNS 聯(lián)系緊密；用通俗易懂的方式表達(dá)：維護(hù)了 pod 集合的關(guān)系映射。和上面講的服務(wù)是屬于不同場(chǎng)景下的兩個(gè)概念。
按照這個(gè)方式定義服務(wù)，服務(wù)治理的粒度其實(shí)也是按照服務(wù)粒度，可以針對(duì)每個(gè)服務(wù)設(shè)置超時(shí)時(shí)間，設(shè)置路由規(guī)則等等。但是服務(wù)注冊(cè)的粒度和服務(wù)有什么關(guān)系呢？
服務(wù)注冊(cè)粒度
一個(gè)應(yīng)用下包含了很多接口，一個(gè)接口下包含了很多服務(wù)( Dubbo )；或者一個(gè)應(yīng)用包含了很多的服務(wù)( Spring Cloud )。分析下應(yīng)用維度注冊(cè)和接口維度注冊(cè)的優(yōu)缺點(diǎn)。會(huì)有一篇獨(dú)立的文章來(lái)闡述應(yīng)用維度注冊(cè)的方案。
接口維度注冊(cè)
優(yōu)點(diǎn)：
服務(wù)查詢按照接口維度查詢非常方便，實(shí)現(xiàn)難度低；
應(yīng)用拆分或者合并的時(shí)候， Client 端(消費(fèi)者)無(wú)需關(guān)心，做到了讓用戶無(wú)感。
缺點(diǎn)：
和 K8s 等主流平臺(tái)的模型對(duì)應(yīng)關(guān)系不匹配；
注冊(cè)的數(shù)據(jù)量非常大，有一定的性能風(fēng)險(xiǎn)。
應(yīng)用維度
優(yōu)點(diǎn)：
和 K8s，Spring Cloud 等模型對(duì)應(yīng)關(guān)系一致；
性能上可以得到很大緩解。
缺點(diǎn)：
應(yīng)用拆分或者合并的時(shí)候，Client 端需要感知 (如果想做到不感知,需要框架開(kāi)發(fā)者維護(hù)一份接口和應(yīng)用映射關(guān)系的存儲(chǔ))；
如果想對(duì)用戶保持 Dubbo 原有的接口維度的查詢，需要較多的工作量來(lái)保證；
對(duì)用戶透明度有所減少，需要在 OPS 上提供其他一些工具。如供應(yīng)用開(kāi)發(fā)者可以查看具體某個(gè) IP 是否提供了某個(gè)服務(wù)等等。
Dubbo 和 Spring Cloud
目標(biāo)：
Dubbo 和 Spring Cloud 的服務(wù)發(fā)現(xiàn)進(jìn)行統(tǒng)一；
Dubbo 和 Spring Cloud 可以互相調(diào)用。
服務(wù)發(fā)現(xiàn)統(tǒng)一
Dubbo 改造成應(yīng)用維度的服務(wù)注冊(cè)。（具體不展開(kāi)，后面文章說(shuō)明）
打通調(diào)用
Dubbo 實(shí)現(xiàn)中，支持將以 Rest 協(xié)議進(jìn)行暴露，并且讓 Spring Cloud 識(shí)別。
Dubbo K8s
在 K8s 已經(jīng)闡述過(guò)，下面的內(nèi)容也是假設(shè)一個(gè)應(yīng)用部署在一個(gè)容器里，一個(gè)容器部署在一個(gè) pod 里。
接下來(lái)方案的討論，互相之間其實(shí)是有關(guān)聯(lián)的，如服務(wù)治理可能會(huì)影響到服務(wù)注冊(cè)發(fā)現(xiàn)，服務(wù)查詢也不能依賴于服務(wù)注冊(cè)的內(nèi)容。整個(gè)設(shè)計(jì)的過(guò)程是不斷優(yōu)化的過(guò)程。下面所說(shuō)的內(nèi)容，以 Dubbo 來(lái)舉例說(shuō)明。
服務(wù)治理
Dubbo 原有體系里的服務(wù)治理是強(qiáng)依賴于 IP ，當(dāng)配置了一套服務(wù)治理規(guī)則的時(shí)候，最后都是基于一個(gè)或多個(gè) IP 地址。
到 K8s 體系下之后，要考慮的是 Pod 的 IP 不是固定的。所以當(dāng)前的路由規(guī)則不能滿足條件，而且會(huì)產(chǎn)生很多規(guī)則垃圾數(shù)據(jù)。K8s 體系下，通過(guò) service 查找 Pod ，是基于 label selector ；通過(guò) deployment 管理 Pod ，其實(shí)也是基于 Pod label selector 。所以 pod label selector 是在 K8s 習(xí)題中比較通用的解決方案。
以路由規(guī)則為例，需要支持一種新的路由規(guī)則：label 路由。通過(guò)一定條件匹配之后，將結(jié)果定位到以 label selector 查詢到的 Pod 列表里，而非原來(lái)的 ip 列表。
要支持 label 路由，client 端需要獲取到 client 端自己的 Pod label 信息，還需要獲取到 server pod 列表中每個(gè) Pod 的 label 信息。
應(yīng)用獲取當(dāng)前 Pod 的信息方式
Pod 定義環(huán)境變量，應(yīng)用獲取；Dubbo 提供對(duì)環(huán)境變量讀取的支持，Pod 中需要按照 Dubbo 定義的環(huán)境變量設(shè)置具體的 pod 信息。
通過(guò) Downward API 傳遞 Pod 信息；Dubbo 需要提供對(duì) Downward 的目錄讀取，Pod 中需要定制 downward 的對(duì)應(yīng)配置。
通過(guò) API Server 獲取數(shù)據(jù)；最強(qiáng)大的方式，但是應(yīng)用需要強(qiáng)依賴于 API Server 。
應(yīng)用獲取其他 Pod 的信息方式
通過(guò)調(diào)用其他 Pod 的服務(wù)獲取；依賴于應(yīng)用能獲取自身的 Pod 信息，同時(shí)將自身的 Pod 信息暴露成服務(wù)( rest 或 dubbo 協(xié)議)。client 端通過(guò)調(diào)用對(duì)用的 Pod 獲取到對(duì)應(yīng) Pod 的完整信息。
通過(guò) Api server 獲取數(shù)據(jù)；很強(qiáng)大，但增加了對(duì) Api server 的依賴。
服務(wù)注冊(cè)和發(fā)現(xiàn)
K8s 體系下，RPC 服務(wù)發(fā)現(xiàn)有以下幾種方式:
注冊(cè)機(jī)制：將 IP 寫(xiě)入注冊(cè)中心，用心跳保持連接；當(dāng)心跳停止，從注冊(cè)中心刪除；
利用 Service DNS ：新建一個(gè) Service ，可以通過(guò)標(biāo)簽選擇到一組 Pod 列表，這個(gè) Service 對(duì)應(yīng)一個(gè)不變的集群 IP ；Client 端通過(guò) DNS 方式或者直接訪問(wèn)集群 IP 。這個(gè)集群 IP ，約等于實(shí)現(xiàn)了負(fù)載均衡 ( iptable 方式)；
利用 headless service(DNS) ：headless service 和上面的 service 的區(qū)別是，它不提供集群 IP ，通過(guò)主機(jī)名的形式獲取一組 IP 列表，Client 端自己決定訪問(wèn)哪個(gè) Pod ；
api server ：Client 端直接請(qǐng)求 api server ，獲取到 pod 的列表， Client 自己決定訪問(wèn) pod 的邏輯。同時(shí)獲取的時(shí)候增加 watch ，api server 會(huì)將 pod 的變化信息同步 Client 。
通過(guò)拿到 Server 端的 IP 或者 host ，Client 端就可以發(fā)起? http 或者其他協(xié)議的請(qǐng)求。
下面介紹符合 Dubbo 的可行方案：
1. Dubbo Zookeeper pod cluster (HSF CS cluster)
這是最簡(jiǎn)單的方式，Dubbo 本身不需要做任何改造。帶來(lái)的問(wèn)題是增加了 Zookeeper 的維護(hù)，同時(shí)這個(gè)方案很不云原生，和 K8s 的體系沒(méi)有任何關(guān)系。
腦暴
上面方案是將 ZooKeeper 作為注冊(cè)中心，那么是否可以將 K8s 里 service 作為注冊(cè)中心呢？Dubbo 里每個(gè)接口去建立一個(gè) service ，每個(gè)應(yīng)用實(shí)例啟動(dòng)過(guò)程中去更新 Endpoint 信息，建立 Service-> Endpoint-> IP 列表的關(guān)系。
這種方案中 K8s service 的定義被改造了，而且定義了過(guò)多的 service ，service 的維護(hù)管理是個(gè)難題。
基于 K8s 的場(chǎng)景
在傳統(tǒng)的 RPC 領(lǐng)域，服務(wù)分成服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)。在 K8s 領(lǐng)域 pod 和應(yīng)用是一對(duì)一的關(guān)系，K8s 本身就提供了 pod 查找的能力，所以一定程度上服務(wù)注冊(cè)其實(shí)可以不存在，而只需要服務(wù)發(fā)現(xiàn)。但是這個(gè)其實(shí)需要一個(gè)前提：
Dubbo 需要將服務(wù)注冊(cè)發(fā)現(xiàn)的粒度改造成應(yīng)用維度。> 在運(yùn)維層面，將 app=xxx (應(yīng)用名)寫(xiě)入到 pod 的 label 中。
2. Dubbo K8s DNS
如果 K8s service 提供了cluster ip ，那么 Dubbo 只負(fù)責(zé)調(diào)用該集群 Ip ，路由和負(fù)載均衡的邏輯則交給了 K8s 的 proxy 來(lái)完成。此方案削減了 Dubbo 的核心能力。接下來(lái)討論 headless service 提供的能力。
通過(guò)請(qǐng)求 <service>.<ns>.svc.<zone>. ?IN A ?的方式發(fā)起請(qǐng)求獲取 IP 列表，但是需要輪詢方式不斷獲取更新的 IP 列表。
服務(wù)治理相關(guān)的功能，需要在上述服務(wù)治理部分中獨(dú)立支持。
參考：https://github.com/kubernetes/dns/blob/master/docs/specification.md#24—records-for-a-headless-service
3. Dubbo Api Server
Pod 的容器中部署的 Dubbo 應(yīng)用，服務(wù)注冊(cè)流程可以直接刪除，服務(wù)發(fā)現(xiàn)功能通過(guò)和 Api Server 進(jìn)行交互，獲取 Pod 和 service 信息，同時(shí) watch pod 和service 的變更。通過(guò)這種方式之后，服務(wù)治理相關(guān)的信息也可以通過(guò) Api Server 直接獲取。
4. Dubbo Istio Envoy
Dubbo 可以直接使用指定 ip 端口 的方式調(diào)用同一個(gè) pod 下 Envoy ?(也可能是同一個(gè)node的Envoy)。Dubbo 將路由規(guī)則，負(fù)載均衡，熔斷等功能交給 Istio 和 Envoy。Envoy 需要支持 Dubbo 協(xié)議的轉(zhuǎn)發(fā)。
所以 Dubbo 需要完成兩個(gè)事情：本地 IP 直連(現(xiàn)有功能)， 多余功能裁剪(暫未實(shí)現(xiàn))。
5. Dubbo Istio
Dubbo 應(yīng)用不再依賴 Envoy 作為 sidecar ，而是直接和 Istio 進(jìn)行交互，把 Istio 作為注冊(cè)中心，作為服務(wù)治理的配置中心；
Dubbo 需要提供類似的 xDS 協(xié)議，在pilot將service的instance轉(zhuǎn)換成dubbo的協(xié)議格式；
Dubbo 還需要去適配 istio 的一些功能，如健康檢查，安全相關(guān)的邏輯。具體實(shí)現(xiàn)可以參考 Envoy 的實(shí)現(xiàn)。
6. Dubbo 和 Istio 在 K8s 體系下共存這個(gè)可選擇的方案較多，我提供兩種思路，供大家思考：
所有的服務(wù)注冊(cè)通過(guò)k8s的機(jī)制完成，所有的服務(wù)發(fā)現(xiàn)通過(guò) Headless service 完成。sidecar 在創(chuàng)建過(guò)程中，需要對(duì)原有的 K8s service 進(jìn)行 update；
Nacos 作為 Dubbo 的注冊(cè)中心，并且需要將 K8s 中的數(shù)據(jù)進(jìn)行部分中轉(zhuǎn)。Dubbo 應(yīng)用，將服務(wù)注冊(cè)以應(yīng)用維度注冊(cè)到 Nacos ，Istio Pilot 需要識(shí)別 Nacos 數(shù)據(jù)；Istio 的運(yùn)行機(jī)制基本不變，需要將 K8s service instance 的數(shù)據(jù)寫(xiě)入到 nacos ，供 Dubbo 調(diào)用。
7. 云上和云下環(huán)境共存 & 云上多集群環(huán)境
Istio 提供了跨集群和云上云下的解決方案， kubeFed 作為 K8s 的跨集群解決方案也能起到一定作用。
這個(gè)課題的復(fù)雜度更加高，心中有了一些答案，期望大家通過(guò)上文也有一定的思考。
服務(wù)查詢
拋出三種方式，供大家思考。
Dubbo 原有方式
Dubbo 原有的服務(wù)查詢是針對(duì)接口的查詢，每個(gè)接口會(huì)有版本號(hào)和組別。接口名 版本號(hào) 組別確定唯一的服務(wù)集合，這個(gè)服務(wù)集下有對(duì)應(yīng)的服務(wù)提供者和服務(wù)消費(fèi)者(接口級(jí)依賴)，服務(wù)提供者是一組 ip port 列表，服務(wù)消費(fèi)者也是一組 ip port 列表。
當(dāng)做了改造成應(yīng)用級(jí)別的服務(wù)注冊(cè)或者直接使用 K8s 自帶的 Pod 發(fā)現(xiàn)機(jī)制的話，需要做一些改造，這部分改造，和前面提到的一樣，放到其他文章里單獨(dú)說(shuō)明。
只支持應(yīng)用查詢
和 Spring Cloud 類似，支持應(yīng)用維度的查詢。查詢到具體應(yīng)用之后，應(yīng)用詳情下包含了 ip port 列表，每個(gè) ip port 其實(shí)就是一個(gè)應(yīng)用的實(shí)例。點(diǎn)擊開(kāi)每個(gè)應(yīng)用實(shí)例，可以查看每個(gè)應(yīng)用的詳細(xì)信息，詳細(xì)信息包含了該實(shí)例提供了哪些服務(wù)。
接口 應(yīng)用查詢均衡
在原來(lái)只支持應(yīng)用查詢的基礎(chǔ)上，增加一步：支持查詢某個(gè)接口對(duì)應(yīng)的應(yīng)用列表，而大部分接口只屬于一個(gè)應(yīng)用。
再點(diǎn)擊應(yīng)用列表下具體的應(yīng)用之后，會(huì)跳到應(yīng)用詳情。
總結(jié)
上述討論的是開(kāi)源的方案，所以相對(duì)歷史包袱比較少。對(duì)一些大公司想從原有的 RPC 方案切換到云原生的支持，需要考慮更多兼容性和性能，需要付出更大的代價(jià)。
云原生的趨勢(shì)已經(jīng)勢(shì)不可擋，在 RPC 領(lǐng)域究竟哪種方案最終能夠勝出，現(xiàn)在還言之過(guò)早。我相信 Service Mesh 和傳統(tǒng)的 RPC ?(Dubbo/ gRPC)? 都會(huì)有自己的一席之地，一切讓時(shí)間給我們答案吧。
“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。”
更多關(guān)于云服務(wù)器，域名注冊(cè)，虛擬主機(jī)的問(wèn)題，請(qǐng)?jiān)L問(wèn)三五互聯(lián)官網(wǎng)：m.shinetop.cn
