史上最牛逼的微服务架构学习笔记，原来可以这么轻松的就学会了( 五 ) _微服务

并且Istio天生的支持Kubernetes，这也弥合了应用调度框架与Service Mesh之间的空隙。
关于Conduit的资料较少，从官方介绍看它的定位和功能与Istio类似。
Kubernetes + Service Mesh = 完整的微服务框架
Kubernetes已经成为了容器调度编排的事实标准，而容器正好可以作为微服务的最小工作单元，从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计，它们的出现补足了Kubernetes在微服务间服务通讯上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架，但是它们或多或少都会和具体语言或应用场景绑定，并只解决了微服务Dev层面的问题。若想解决Ops问题，它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架做结合：

文章插图

但是这种结合又由于初始设计和生态，有很多适用性问题需要解决。
Kubernetes则不同，它本身就是一个和开发语言无关的、通用的容器管理平台，它可以支持运行云原生和传统的容器化应用。并且它覆盖了微服务的Dev和Ops阶段，结合Service Mesh，它可以为用户提供完整端到端的微服务体验。
所以我认为，未来的微服务架构和技术栈可能是如下形式：

文章插图

多云平台为微服务提供了资源能力（计算、存储和网络等），容器作为最小工作单元被Kubernetes调度和编排，Service Mesh管理微服务的服务通信，最后通过API Gateway向外暴露微服务的业务接口。
我相信未来随着以Kubernetes和Service Mesh为标准的微服务框架的盛行，将大大降低微服务实施的成本，最终为微服务落地以及大规模使用提供坚实的基础和保障。

【史上最牛逼的微服务架构学习笔记，原来可以这么轻松的就学会了】