Istio守护微服务，下一代守护者知多少？

1. 引言 在写完eShopOnContainers 知多少[12]：Envoy gateways后，就一直想进一步探索Service Mesh，最近刚在极客时间上学完《Service Mesh入门》，又大致浏览了一遍官方文档，对Istio也算有了基本的认识。下面就根据自己的理解对Istio进行简单的梳理，算是对知识的总结吧。 2. Cloud Native（云原生） 在介绍Istio之前，我们得先了解下Service Mesh，而Service Mesh 又是云原生的产物。因此，本着追本溯源的精神，我们得先了解下云原生。云原生（Cloud Native）这个概念是在2015年提出的，听的人多，真正能讲清楚的人少，我也一样。综合多方资料，下面尝试解读一下。 云原生，虽然字都认识，但真不好解释。一般讲云原生，其实是讲云原生应用，多了应用二字，就更具象了。从字面上直译：云，代表云端；原生：原本就生长在那里；连起来就是原本就生长在云端的应用。 应用怎么会原本就生长在云端呢？云又是怎么发展而来呢？别急，我们先来看下云计算的发展来解答下云的由来。 我们知道传统的应用都是跑在本地服务器上，随着虚拟化技术的发展，拉开了云计算的序幕，一大批云计算厂商基于虚拟机技术，提供了IaaS，PaaS和SaaS等产品心态，极大的提高资源的利用率。企业本着降本增效的目的，逐步将应用迁移到云上的Paas平台上。而这一阶段，被称为云计算的虚拟机时代，而这个时间节点在2013年之前，运行在云端虚拟机上的应用，还不叫云原生应用。 2013年，Docker开源，正式开启了容器技术时代，重新定义了 PaaS 的全新容器化思路。在容器技术的基础上，“云”得到了极大的发展，2014年谷歌开源Kubernetes，旨在解决容器的编排问题（部署、伸缩和管理）。2017年容器编排大战尘埃落定，Kubernetes成为最大赢家，标志着K8S成为分布式资源调度和自动化运维的事实标准。Kubernetes 也逐渐体现出云原生时代底层操作系统的特征，向下封装资源、向上支撑应用。这个阶段，可以称为云计算的容器时代。也正是在这个阶段，云原生的概念被提出，其标志事件就是2015年CNCF（云原生计算基金会）的成立，云原生这个词才被大家熟知。 现在我们知道，云原生是在容器时代提出的概念。那为什么会提出云原生这个概念呢？别急我们来看下云计算发展过程中后端架构的演进。 从上图可知，后端架构从单体到分布式，再逐步演进到微服务架构。采用微服务架构，就必须解决服务治理、流量控制、应用观察等问题。其中2014年由Netflix 推出的Spring Cloud体系就是通过提供服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能，一度成为微服务的最佳实践。但是却有一个很大的缺点就是其对应用有很强的侵入性，应用代码中会包含大量的 SpringCloud 模块。这时的应用模型如下图所示： 那如何解决侵入性的问题呢？这个问题在容器编排技术成熟之前，似乎没有好的答案。但随着K8S的成熟，这个问题有了新的解法。Kubernetes的出现就是为了解决 SpringCloud 的问题，不侵入应用层，在容器层解决问题。这就是理想的应用开发模型，应用依托于“云”，最大化发挥“云”的优势，专注于业务需求的实现。 那应用如何依托于“云”，最大化发挥“云”的优势呢？云原生就是为了解决这一问题而提出的。其建立在“未来的软件一定生长于云”的核心假设之上提出的，云原生本质上是一套指导软件架构设计的思想，依托该思想而设计的应用：首先，应用本身“生于云、长于云”；其次，这样的应用能够天然集成“云”环境，进而释放“云”的最大价值。 云原生定义了一条能够让应用最大程度利用云能力、发挥云价值的最佳路径。具体来说，参考云原生计算基金会（CNCF）对云原生的定义，云原生包括容器化封装、自动化管理、面向微服务、服务网格、声明式 API。符合云原生架构的应用程序应该是：采用开源堆栈（Kubernetes+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。 那如何实现云原生呢？Service Mesh交出了自己的答卷。 3. Service Mesh（服务网格） 先来看下Service Mesh的提出者，也就是第一代Service Mesh 产品Linkerd的CEO，对Service Mesh的定义： Service Mesh 通常被译为服务网格，其是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。