摘要:

為什么有了 Linkerd 和 Envoy 之后,還會(huì)進(jìn)一步進(jìn)化出 Istio 和 Conduit。它們相對(duì)于老的 serive mesh 框架最大的特點(diǎn)就是基于 Kubernetes 設(shè)計(jì),補(bǔ)足了Kubernetes在微服務(wù)間服務(wù)通訊上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務(wù)框架,但是它們或多或少都會(huì)和具體語(yǔ)言或應(yīng)用場(chǎng)景綁定,并只解決了微服務(wù)Dev層面的問(wèn)題。若想解決Ops問(wèn)題,它們還需和諸如Cloud Foundry、Mesos、或Kubernetes這類資源調(diào)度框架做結(jié)合。云平臺(tái)(或者自建機(jī)房) 為微服務(wù)提供了資源能力(計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等),容器 作為最小工作單元被 Kubernetes 調(diào)度和編排,Service Mesh 管理微服務(wù)的服務(wù)通信,最后通過(guò) API Gateway 向外暴露微服務(wù)的業(yè)務(wù)接口。
閱讀全文