1、ServiceMesh介绍
ServiceMesh：服务网格，网上的这种文章一大堆，我也不去重新整理这些东西了，感兴趣的可以直接百度下。简单来说，可以理解为微服务模式下面的TCP/IP协议，让开发同学只需要潜心研究业务代码，而无需注重传统微服务框架的使用与理解。
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明，且他们都是基于sidecar
模式的。
白话：传统模式是A服务调用B服务的话，直接A->B，或者加网关啥的，ServiceMesh呢，是A->A的代理->B的代理->B。
必知：
ServiceMesh
是服务网格；ServiceMesh
本身是一个概念，并不真的是一个产品或者服务，可不要去搜索ServiceMesh
如何搭建部署哈；解决了网络层面的问题，将其单独抽离了出来。
产品：
上面说了，
servicemesh
是一个概念，那么就需要有产品将这个概念落地；
Linkerd
；istio
；
Linkerd
和istio
哪个好？为什么用istio
？或者为什么用Linkerd
？我觉得吧，这个没法直接说谁好用，谁更强，各自有各自的优点，到底要选择什么要看你的使用情况来做选择，这里我们简单列个图自行对比下：
那可能又有同学要问了，那你为什么选择istio
呢？因为俺喜欢呀~~~
2、istio介绍
这个介绍是引用了官网的部分文章内容。
Istio
是一个开源服务网格，它透明地分层到现有的分布式应用程序上。Istio
强大的特性提供了一种统一和更有效的方式来保护、连接和监视服务。Istio
是实现负载平衡、服务到服务身份验证和监视的路径——只需要很少或不需要更改服务代码。它强大的控制平面带来了重要的特点，包括：
使用 TLS 加密、强身份认证和授权的集群内服务到服务的安全通信； 自动负载均衡的 HTTP, gRPC, WebSocket，和 TCP 流量； 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制； 一个可插入的策略层和配置 API，支持访问控制、速率限制和配额； 对集群内的所有流量(包括集群入口和出口)进行自动度量、日志和跟踪；
Istio
是为可扩展性而设计的，可以处理不同范围的部署需求。Istio
的控制平面运行在Kubernetes
上，您可以将部署在该集群中的应用程序添加到您的网格中，将网格扩展到其他集群，甚至连接VM
或运行在Kubernetes
之外的其他端点。
3、istio模型
在k8s中，也就是对于每一个pod进行代理，甚至你可以理解为下面的情况；
4、istio架构图
千言万语不如实操一次，不解释，当你实操完毕之后，我觉得你会很清楚。
5、istio解决了什么问题
以下这些问题，我们应该遇到过很多次，或者说很熟悉，那么istio是不是能帮助我们解决这个问题呢？拭目以待吧。
（1）故障排查
可以清楚的看到整个集群的调用以及流量情况。
可以准确定位到是哪个环节出了问题，不需要像传统的微服务架构中，除非你能根据报错来定位到是哪个服务，否则就要一个一个服务来排查，难以第一时间定位到问题； 为什么用户请求中断了，是哪个节点出超时了？还是什么别的情况？ 系统访问缓慢，是哪个组件耗时最长。
（2）应用容错性
当单个服务的报错率没有降低的情况下，使用微服务架构整体的报错率会提升。
如果超时时间配置错误，或者未配置，会导致应用“卡住”； 因为偶发性的网络波动，或者其他原因，直接把报错返回给了客户； 如果某个节点响应过长， istio
自动“绕开”该节点；
（3）应用升级发布
如果能智能处理的话，该多好。
新版本升级，一旦出错了，影响较大； 无法进行A/B测试，希望可以根据用户属性访问不同版本； 流量控制，访问不同的版本；
（4）系统安全
大多数服务，尤其是内部调用都是 http
的，而不是https
的;流量限制，大多数都不配置白名单功能，任何人都可以对服务发起攻击；
至此，本文结束，下一篇我们就开始在k8s
中部署istio
。
往期推荐
