istio概述，与微服务、云原生、k8s的关系

1.1简单介绍istio
与k8s紧密结合，适用于云原生场景，service mesh形态，服务治理的开放平台
服务治理，包括：连接、安全、策略执行和可观察性。
连接：通过配置的流量规则控制服务间的流量和调用，实现负载均衡，熔断，故障注入，重试，重定向等服务治理
安全：提供认证机制、通道加密、服务访问授权等，增强服务访问的安全性
策略执行：通过可动态插拔，可扩展的策略，实现访问控制，速率限制，配额管理，服务计费等能力
可观察性:动态获取服务运行数据和输出，提供强大的调用链，监控，和调用日志收集与输出的能力。

1.2istio使用示例
istio通过配置实现灰度发布的实例：
apiVersion: networking.istio.io/vlalpha3
kind: VirtualService
metadata:
name: recommendation
spec:
hosts:
- recommendation
http:
- match:
- headers:
cookie:
exact: "group=dev"
route:
- destination:
name: v2
- route:
- destination:
name: v1
含义：
group是dev的流量转发到recommendation服务的v2版本，其他用户访问v1版本，从而实现灰度。

1.3 istio与服务治理
服务治理，比如一般经常提到的微服务治理，实际上只要有服务与访问就可以治理。

1.3.1 关于微服务
为什么出现微服务：
1）发布成本变高，如编译更多的代码，某一个小的点修改，要发布整个项目
2）合作成本变高，如代码冲突增加
3）服务之间相互影响，如某个服务发生OOM，导致所有的服务不可用

微服务的本质：化繁为简分而治之

微服务带来的好处：
开发：服务内聚，微服务内易于设计和扩展，可以采用不同的语言和开发工具
运维：每个服务可以自运维；迭代速度快，上线风险小
组织管理：微服务角度切分小组，利于敏捷开发

引入的问题：
服务注册、发现、调用、负载均衡，跨进程的分布式调用栈和链式追踪。

解决上面的问题就需要服务治理。

1.3.2 服务治理的形态演变
第一种形态：在应用程序中包含治理逻辑，如rpc服务调用、重试机制等。
特点：简单，但会有大量重复代码，业务代码和治理逻辑耦合，后期难以维护。

第二种形态：治理逻辑独立的代码
sdk模式：即把治理的公共逻辑抽象成一个公共库，让所有的微服务使用这个公共库。典型的框架爱就是springCloud
特点：代码上解耦了业务和治理的逻辑，但是两者还是在一个进程内，存在如下问题：
1）业务代码必须和SDK是同一种语言
2）因为多个服务分别引用治理的sdk，所以治理逻辑升级时需要整个服务一起升级
3）sdk有一定的学习门槛

第三种形态：治理逻辑是独立的进程
业务和治理代码彻底解耦。
评价：对开发语言无限制，原服务也无需做任何修改，可以对老系统渐进式升级改造。

从三个形态整体来看：服务治理组件的位置在持续下沉，对应用的侵入主键减少

1.3.3 istio与微服务关系
微服务是一种架构风格，是一种方法论。istio是一种服务治理的完整实践，但istio绝不是微服务方法论的落地。
场景上，istio管理的大部分对象是微服务过的，但是也可以管理单体应用。特别适用于传统行业的用户业务需要在容器化后进行的服务治理。
能力上，istio包含微服务情调的负载均衡、熔断、限流等治理能力，还包含可插拔的服务安全、控制策略、服务运行的可观察性等更广泛的能力。

谈论istio和微服务的关系，不如关注istio和k8s的关系。k8s和云原生实际上已经改变和重新定义了软件开发的很多方面。

1.4 istio与服务网格
服务网格的特点
基础设施：处理服务间通信的基础设施
云原生：适用于云原生场景下的服务间的通信
网络代理：轻量级的网络代理来执行治理逻辑
对应用透明：应用程序网络代理部署在一起，但应用感知不到代理的存在

1.4.1 为什么会选择服务网格
为什么服务网格这么火？
1）进入了云原生时代，服务剧增，应用间的访问拓扑更加复杂，治理需求越来越多。与应用代码混合或进程混合的服务治理方式已经不再可以满足要求
2）单个应用上，对应用完全无侵入，与开发语言无关
3）全局来看，关注的是sideCar组成的网格，对网格间的服务访问进行管理，应用还是按照原本的方式进行互相访问。
4）sidecar是网格动作的执行体，全局的管理规则和网格内的元数据通过一个统一的控制面实现，应用感知不到sideCar。

从forecast访问recommendation看sidecar导致的问题
如图：

需要先经过forecast服务的sidecar拦截outbound流量执行治理动作，再经过recommendation服务的sidecar拦截inbound流量执行治理工作。
从上图可以看出，会引入如下问题：
1）服务间访问增加了两跳，则增加了两处延迟和可能的故障点解决：加大计算资源投入保证转发代理的轻量和高性能，降低延迟
2) 多出来的两跳对整体可靠性和复杂度都带来了新的挑战。解决：基础设施层面的可靠性、可维护性范畴，服务网格产品自身可以满足

1.4.2 为什么选择istio
控制面上，基于xDs协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。全新的设计，采用了gRPC协议，功能强大。
数据面上，采用了envoy，采用c++语言实现的轻量高性能的代理；支持更多协议，有服务发现、健康检查、高级LB、前端代理等能力；架构上是一个可高度定制化的程序，提供了高度扩展性，支持热重启，模块化编码，已与测试。
大厂支持上，istio由ibm和谷歌共同推出，定位上，将容器作为核心，k8s作为管理容器的编排系统，istio管理容器上服务之间的交互。

1.5 istio与k8s
k8s：管理容器的平台

1.5.1 istio是k8s的好帮手
k8s提供的功能：应用负载的部署、升级、扩容等运行管理能力
k8s中的service机制可以实现服务注册、发现和负载均衡，并通过服务名访问服务实例
k8s中的pod部署微服务也很合适，解决了微服务的互访互通的问题。

k8s的不足（为什么引入istio）：
无法管理服务间的访问，如服务的熔断限流动态路由调用链追踪等

istio实现的简单说明
k8s的service基于节点的kube-proxy从kube-apiserver上获取service和endpoint信息，将对service的请求经过负载均衡后转发到对应的endpoint上。但无法基于应用层的信息进行负载均衡、无法进行流量管理、无法进行指标和调用链的跟踪。

istio复用了k8s service的定义，istio的服务发现就是中kube-apiserver中获取service和endpoint，然后将其转换成istio服务模型的service和serviceInstance，但是其数据面组件不再是kupe-proxy，而是每个pod里面部署的sidecar，可以看做是每个服务实例的proxy。所以proxy的粒度更细，通过拦截Pod的流量，并在sidecar上解析各种应用层协议，提供真正的应用层治理、监控和安全等能力。

1.5.2 k8s是istio的好基座
1.数据面
sidecar运行在k8s的pod中，应用完全无感知。
2.统一服务发现
istio的服务发现机制非常完美的基于k8s的域名访问机制构建而成。不需要新搭注册中心，且避免了服务发现中的数据不一致的问题
3.易于k8s CRD描述规则
istio的所有路由规则和控制策略都是通过k8s CRD实现的，因此各种规则策略对应的数据也被存储在kube-apiserver中

1.6 总结
微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上的匹配
k8s在容器编排领域已经称为无可争辩的事实标准
istio与k8s的天然融合且基于k8s构建，也补充了k8s的治理能力

云原生采用k8s的服务编排能力，采用istio的服务治理能力，将逐渐称为企业转型的标准配置。

istio概述，与微服务、云原生、k8s的关系相关推荐

新星计划【Java微服务+云原生】赛道开启！
前排提醒:这里是新星计划2023[微服务+云原生]学习方向的报名入口,一经报名,不可更换. ↓↓↓报名入口:新星计划2023[微服务+云原生]学习方向报名入口!-CSDN社区一.关于本学习方向导师 ...
低代码开发平台如何支撑微服务/云原生架构
目前"低代码"."微服务"这两个IT词汇很流行,国内主流的低代码开发平台很多:宜搭.简道云.明道云.云程.氚云.伙伴云.道一云.JEPaaS.华炎魔方.搭搭云. ...
【每周Java技术】2022.05.16 周一 ~ 2022.05.22 周日(Srping Boot | 二叉树 | Docker | 微服务/云原生)
文章目录 01. 05.16 周一 1.1)Spring Boot 1.1.1) Spring Boot的组成部分 1.1.2) 了解自动配置的实现原理 1.2)数组降序 02. 05.19 周四 1 ...
rabbitmq 查询版本_Hyperf 发布 v2.0.14 版本 | 企业级的 PHP 微服务云原生协程框架
更新内容本周主要新增了 hyperf/scout hyperf/resource 和 hyperf/resource-grpc 三个组件,并修复了一些组件的 Bug,继续提升 Hyperf 的稳定性 ...
dubbo k8s 服务发现_将Dubbo微服务迁移到k8s集群环境中前的思考与落地
将Dubbo微服务迁移到k8s中的思考与落地说到容器化,不得不提kubernetes这个集群编排系统,它是一个开源系统,用于容器化应用的自动部署.扩缩和管理. Kubernetes 将构成应用的容器 ...
【云原生|K8s系列第1篇】：K8s的基础概念、组件架构及实战安装
云原生|K8s系列第1篇目录 1.先从K8s不是什么讲起 2.K8s是什么及核心基础概念 2.1 Container容器 2.2 Pod 2.3 Node 2.4 Label 2.5 Annotati ...
SpringCloud微服务云架构构建B2B2C电子商务平台简介
Spring Cloud是一系列框架的有序集合.利用Spring Boot的开发模式简化了分布式系统基础设施的开发,如服务发现.注册.配置中心.消息总线.负载均衡.断路器.数据监控等(这里只简单的列了 ...
关于SpringCloud微服务云架构构建B2B2C电子商务平台之- Spring Cloud集成项目简介（三）...
2019独角兽企业重金招聘Python工程师标准>>> Spring Cloud集成项目有很多,下面我们列举一下和Spring Cloud相关的优秀项目,我们的企业架构中用到了很多的 ...
大型互联网分布式企业微服务云架构
2019独角兽企业重金招聘Python工程师标准>>> 第一篇文章简单给大家介绍了Spring Cloud架构,我这边结合了当前大部分企业的通用需求,包括技术的选型比较严格.苛刻,不 ...
使用“微服务+云架构”轻松应对系统扩容！
不知道大家打开本文,有没有留意文章所在的分类节点:云计算.其实我的本意,是要将微服务跟云架构归类在一起.因为他们都有着一个相同的存在目的:方便扩容! 扩容.对于遇到过系统瓶颈,需要扩容的系统,恭喜你, ...

istio概述，与微服务、云原生、k8s的关系

istio概述，与微服务、云原生、k8s的关系相关推荐

最新文章

热门文章