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 通常被译为服务网格,其是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,而对应用程序透明

PS: eShopOnContainers就是采用了Linkerd作为Service Mesh,基于其易于安装和设置的特性。感兴趣的同学,可访问链接一探究竟。

Service Mesh 通过在请求调用的路径中增加Sidecar,将原本由客户端完成的复杂功能下沉到Sidecar 中,实现对客户端的简化和服务间通信控制权的转移,当系统中存在大量服务时,服务间的调用关系表现为网状,这也是服务网格名称的由来。

Service Mesh就是通过Sidecar模式将业务需求与非业务需求进行隔离,解决侵入性问题。其中Sidecar主要就是用来处理诸如服务发现、负载均衡、请求熔断等一系列非业务需求,应用在部署时动态插入Sidecar,以对用户透明的方式改变应用行为。以下是Service Mesh的核心流程:

4. Istio (帆)

主流的 Service Mesh 开源软件包括 Linkerd、Envoy 和 Istio。Linkerd 和 Envoy 都 直 接 体 现 了Service Mesh 的核心理念,在功能上较为相似,即实现服务发现、请求路由、负载均衡等功能,解决服务之间的通信问题,使得应用对服务通信无感知。而 Istio 站在了更高的角度,将 Service Mesh 分为了 Data Plane 和 Control Plane, 由 Data Plane负责微服务间的所有网络通信,而 Control Plane负 责 管 理 Data Plane Proxy, 且 Istio 天 然 支 持Kubernetes,这也弥合了应用调度框架与 ServiceMesh 之间的空隙。

Istio的官方定义:
它是一个完全开源的服务网格,作为透明的一层接入到现有的分布式应用程序里。它也是一个平台,拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。

从定义中可以梳理出Istio提供了以下核心特性:

  1. 连接:请求路由、服务发现、负载均衡、流量管理、灰度发布及A/B测试

  2. 保护:托管的认证授权,及通信加密

  3. 控制:策略定义

  4. 观测:日志、追踪、指标及监控

目前的Istio已经更新到1.8版本了,其架构也从最开始的复杂版本逐渐简化。现在的架构图如下所示:

从图中可以看出主要包含两大平面:

  1. 数据平面(Data plane):由Envoy Proxy 充当的Sidecar组成。

  2. 控制平面(Control plane):主要包含三大核心组件,Pilot、Citadel、Galley组成。
    2.1. Pilot:主要是管理部署在Istio服务网格中的Envoy代理实例,为它们提供服务发现、流量管理以及弹性功能,比如:A/B测试、金丝雀发布、超时、重试、熔断等。
    2.2. Citadel:Istio的核心安全组件,负责服务的密钥和数字证书管理,用于提供自动生成、分发、轮换及撤销密钥和数据证书的功能。
    2.3. Galley:负责向Istio的其它组件提供支撑功能,可以理解为Istio的配置中心,它用于校验进入网络配置信息的格式内容正确性,并将这些配置信息提供给Pilot。

以上就是Istio的核心概念,关于Istio流量控制、安全及可观察性的应用,这里就先不展开了,后续就结合Demo,再和大家分享了。

5. 最后

讲真,通过翻阅资料,完成了对云计算、云原生、Service Mesh等概念的追本溯源,加深了云原生理念的认知,拓展了自己的架构视野,也大致了解了后续自己的学习和研究方向。希望本文对你或多或少也有所帮助,感谢阅读!

写就本文,参考了很多资料,参考资料见文末,在此对原作者表示感谢!另外这里再向大家推荐两份关于云原生和Service Mesh的PPT,梳理的非常完整,感兴趣的同学可关注【微服务知多少】公众号,回复”云原生“即可获取。

参考资料

  1. 未来已来:云原生 Cloud Native

  2. 畅谈云原生(上):云原生应用应该是什么样子?

  3. Service Mesh:下一代微服务?

  4. What's Istio?

  5. InfoQ:云原生的技术探索与落地实践 | 研究报告

  6. CNCF Cloud Native Definition v1.0

相关推荐

网友评论(0)