Istio 作为 Service Mesh 解决方案事实上的标准,解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。Istio 提供了对整个服务网格的行为洞察和操作控制的能力,以及一个完整的满足微服务应用各种需求的解决方案。
但是Istio 对 Kubernetes 有着强依赖,整个服务注册发现都依赖Kubernetes 自身服务发现机制。但是在实际公司落地过程中,稍具规模的公司都会有自己的服务注册中心,比如Consul,Eureka 等。另外k8s service 负载均衡在大规模和大流量的情景下,也很难满足要求。所以Kubernetes 只是用来作为一种应用部署形式,和serverless,vm差不多。此时,Istio 想被广泛采用,必须支持集成第三方服务注册中心。
Istio 给出的解决方案是 Mesh Configuration Protocol (MCP)。尽管特定的服务和原型定义不同,但MCP基于XDS并在概念上与之保持一致。
MCP是什么?
MCP是基于订阅的配置分发API。配置消费者(即sink)请求更新来自配置生产者(即source)的资源集合。添加,更新或删除资源时,source会将资源更新推送到sink。如果sink接受,则回复ACK,如果被拒绝则是NACK,例如因为资源无效。一旦对先前的更新进行了ACK/NACK,则source可以推送其他更新。该source一次只能运行一次未完成的更新(每个集合)。
MCP是一对双向流gRPC API服务(ResourceSource和ResourceSink)。
- 当source是服务器而sink是客户端时,将使用
ResourceSource