什么是lstio?
今天聊聊lstio这个感觉高大尚的服务网格到底为啥这么受欢迎？
顺便看看官方1.7.1的版本都解决了哪些bug以及功能稳定性上的提升
看官方如何定义lstio的，它是这么说的：它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用中。它也是一个平台，可以与任何日志、遥测和策略系统进行集成。lstio多样化的特性让你能够成功且高效的运行微服务架构，并提供保护、连接和监控微服务的统一方法。
这个定义看起来比较长，我们可以抽取其中比较重要的，比如
1、它依然是一个服务网格产品
2、它就是拥有服务网格的基本特性，也就是对应用层是透明的
3、它是为微服务架构来服务的
4、它的核心功能，可以连接、控制、保护、观测微服务
它们为什么要用lstio来命名呢，我找到答案，这个词它并不是一个英语单词，而是它是源于希腊语，它的意思是扬帆起航，可以看出它的标志是一个帆，那么由此你可能会联想起另外一个很著名的产品kubernetes,这个词其实也起源于希腊语，它的意思跟它的logo是一样的，就是舵手的意思，google为什么用lstio来给这个产品命名,其实是非常有深意的，它的意思你不仅有kubernetes这个舵，还有有lsitio的帆，由它们一起驾驶着你的云原生应用，扬帆起航，驶向彼岸，说的比较方言了。。。
另外lstio还有一个非常重要的特性，它被称作是第二代的Service Mesh,在原有的数据平面的基础上，增加了控制平面，它为现代的Service Mesh的产品定义了一个新的形态
lstio为什么一推出就变得大红大紫？
17年的时候你可能不知道lstio是什么，现在可以说是头号网红了，红的原因也可想而知，
我们可以看它的版本历史周期
1、它的发布时间(20170501）发布0.1版本
它是在17年的5月份发布了0.1版本，那么第一个service mesh产品叫Linkerd，你们也许早就听说过，它是17年4月份发布的，那么lstio在紧接着Linkerd发布之后，立刻就发布了0.1版本，你想它的意图很明显，就是希望能够尽快的阻击Linked稳步的发展，希望让大家都知道有lstio这个产品的产生
2、三巨头光环加身
另外没错人家还有三个巨头加深，可以说是两个巨头分别是，lyft这家公司明显是抱大腿的
google、IBM、lyft
那么这三家公司为istio作为背书，不仅他们的研发资源，研发投入以及社区影响力。都是linkerd这样的初创公司无法比拟的，因此一经推出就拥有了大量的粉丝，有这样的光环可想而知
3、属于第二代的service mesh产品
毋庸置疑第二代要比第一代有碾压优势
4、envoy的加入让istio如虎添翼
本来envoy和linkerd它都是一个基于数据平面的产品，没有控制平面
istio本身也没有开发自己的数据平面，所以它直接联合了lyft公司，直接使用envoy作为自己默认的数据平面，envoy本身就经历了一年多的开发，非常的稳定性能也非常的可靠，它对linkerd还是有比较大的优势的，envoy的加入直接让istio拥有了一个可以和linkerd抗衡的数据平面，省去了自己的开发的麻烦，对于lyft公司其实也有一个很大的好处，可以抱着IBM和google着两条大粗腿，为自己的产品保驾护航，反过来这两家公司也可以不劳而获，直接可以使用envoy作为自己的数据平面，可以说是一个双赢的策略
5、istio的本身的功能也非常强大
可以在它的发布列表中看到令人眼花缭乱的这样的功能点，同时istio也受到了一些厂商的支持，包括IBM和google自家的云平台的支持，以及像redhat、还有oracle这样的公司主动站出来支持，由此可见受到了非常多的追捧，以上都是它的一些优点，有人认为它们是过度营销，linkerd的创始人也就是buoyant公司的CEO williamMorgan,曾经说过这样的话，目前来说service mesh有一些处于不幸的状态，有一些产品过度的营销，导致市场超过了技术本身，那我们可以认为williamMorgan这些话是针对istio来说的，毕竟是它最重要的竞争对手，因此它说这句话也无可后非，那么至于是不是过度营销的情况产生。不管怎么样，istio已经站稳了C位，对于它自己来说是一个件好事。
为什么使用Istio?
学习lstio最好的就是官方，看看istio是如何营销自己的
首先它说有两大优势
1、可以轻松的构建服务网格
我们其实不要以为service mesh是一个非常高深离你很远的技术，你去构建一个mesh是非常容易的。
2、它对应用代码是透明的，不需要去修改自己的应用代码
其实它说的这个两个优势都是service mesh本身的优势
其他的产品也能做到这几点
当然它提供的功能还是非常强大的
而lstio的核心功能就是service mesh的功能,主要有以下四个方面
一、流量控制
1、第一点路由我们经常听到的灰度发布，像蓝绿发布、AB测试这些都可以把它归纳到路由这一点
2、第二点就是流量的转移
3、第三点是为网络增加弹性的能力，比如说超时、重试熔断这样的机制
4、最后它还提供了一些调试网格的一些特性，比如说故障注入，还有流量镜像的功能
二、安全
1、lstio对认证授权两方面，提供了一些安全机制
三、可观察性
1、在这一点lstio是安装比较经典的可观察性三方面提供了功能，分别是指标、日志、追踪
四、策略
像限流黑白名单这样的功能，在1.5的版本里把这个功能去掉了，因为是废弃了一个负责功能的模块叫Mixer,它把一些功能都转移到envoy功能里面去了，后续策略相关功能也会逐步发布出来
说说目前的版本发布，关注2020年的lstio的版本变化的话，你就知道lstio今年可是变化的真快
lstio从17年5月进行发布开始，可以归列为四个重要的版本以及三个阶段
首先看看都有哪四个版本
第一个版本就是17年5月的0.1版本，像世人宣告lstio产生，第二个版本是18年的7月份发布了1.0版本，号称是可以应用于生产环境，第三个版本是1.1版本，它跟前一个版本间隔了有半年多的时间，原因是进行对底层架构的一个重构，这个版本宣称是企业级可用，最后一个版本是前不久2020年8月21号发布的1.7.1版本
而前不久2020年5月21日，情人节那天在1.6版本发布，版本更新了不少功能
比如
1、版本引入了lstiod
这个新模块，通过组合多个服务的功能来减少Istio安装中的组件数量。而在Istio 1.6中，已完成此过渡，并将功能完全移至Istiod。这使能够删除Citadel，Sideca的injector和Galley来实现单独部署。
2、生命周期的优化
而在命令行工具istioctl可提供更好的诊断信息，更简单的安装命令，甚至提供彩色状态！
升级Istio的功能也得到了改善。首先，现在支持Istio控制平面本身的金丝雀。这意味着可以在现有版本旁边安装新版本的控制平面，并有选择地让代理使用新版本。当然官方也给出了示例博客
比如使用Canary Control Plane部署安全地去升级Istio
https://istio.io/latest/blog/2020/multiple-control-planes/
还有一条istioctl upgrade命令可以在集群中执行就地升级（仍然可以控制自己更新代理）
3、可观察性分布式应用程序
许多公司仅采用Istio是为了更好地观察分布式应用程序，因此在这块也进行了投资。比如会看到更多的可配置性，更好地控制跟踪采样率的能力，并更新Grafana仪表盘
4、WorkloadEntry工作负载
https://istio.io/latest/docs/reference/config/networking/workload-entry/
当然这里官方也给出了示例
对于那些将非Kubernetes工作负载添加到网格的人员（例如，部署在VM上的工作负载），新资源比以往任何时候都更容易实现。创建了API，目的是为非Kubernetes工作负载提供表示，它将VM或裸机工作负载提升到与Kubernetes相同的级别，而不仅仅是具有IP地址的端点。现在甚至可以定义由Pods和VM支持的服务。
为什么这样有用？比如现在可以将同一服务的部署（VM和Pods）混合在一起使用，从而提供了一种绝佳的方式，可以将VM工作负载迁移到Kubernetes集群，而不会中断往返于该集群的流量。
当然小版本都是一些bug的修复，这里大家可以去官网查看
1.7.1版本中的变化
当然这次更新的发行版还是继续按照路线图中概述的方向导航，从而提高了可用性，安全性，可靠性，尤其是在VM（非Kubernetes）用例上进行了改进，这样注意的是，在虚拟机的层面上增加了改进
以下是此版本的一些要点
安全增强
1、确保目标规则证书可以通过文件挂载，也可以通过SDS（尤其是自动循环）获得安全秘密分发，这是重要的安全性的一个最佳实践
2、上面的项目适用于网关网格。这是现在可以为 那些TLS出口网关/ MTLS起源于提供客户端证书的密钥
3、还改进了信任域验证来验证TCP流量。以前只有HTTP流量经过验证。目前新版本资源中现在也支持“信任域验证trustDomainAliases ” “config"
4、如使用ECC加密还有助于在提供高安全性的同时提高效率。增加了使用ECC的证书颁发机构进行通信的功能。
5、最佳实践安全性的重要组成部分是不要以超出其所需权限的权限运行进程，例如，防止混淆的副***。因此，还将Gateway部署修改为默认情况下以非root用户身份运行。
6、如果使用的是基于源主体的安全策略，则Istio Gateway和mTLS可能存在一个错误，这个需要知道
易于使用的改进
1、Istio这样的系统，易于很大一部分人去使用，尤其是在帮助发现潜在问题的能力方面。增加了非常有用的istioctl分析工具的功能：
2、警告可能不安全的DestinationRule配置
3、警告已弃用的Mixer资源使用情况
4、对于istioctl的频繁用户，自定义默认配置可能有用，而不是每次都键入它。增加了将个人默认值放入主目录的功能。
5、易于阅读的文本比数字更容易-这就是我们拥有DNS的原因！因此还为端口号添加了它。现在可以使用如http的助记符（而不是80）来指定端口类型。
6、另外还添加了 “ istioctl x卸载”以使其变得非常容易。
生产可操作性的改善
鉴于Istio在生产系统中的广泛使用，另外对可用性进行了一些改进：
1、可以将应用程序启动延迟到Sidecar启动。这提高了部署的可靠性，在该部署中，应用程序需要在启动时立即通过其代理访问资源。
2、有时，陈旧的端点可能会使Pilot变得不健康，另外对这块也进行了改善于修复
3、Istio操作是安装Istio一个伟大的方式，因为它可以配置数量。金丝雀控制面的部署也很重要。它们允许对Istio进行超安全的升级。不幸的是，直到现在都不能一起使用它们。
4、Istio-agent公开了指标，因此可以观察它的运行情况。
5、对Prometheus指标管道进行了多项改进，以一种更轻松，更有效的方式在那里获取了更多数据。
虚拟机支持，增加了安全性
1、自Istio成立以来，社区一直致力于将VM上的工作负载合并到服务网格中的支持。尽管现在有多个版本的用户都在使用它，但在Istio 1.7中，倾向于添加一些改进。请注意，这仍然是Alpha功能。
2、Istio最常用的功能之一是其安全功能集。其核心是以短期证书的形式为每个工作负载分配一个强大的身份。在此版本中，确保网格中VM上运行的工作负载具有安全的自举过程以及自动证书轮换。
例如，拥有一个Kubernetes集群，该集群托管无状态Web服务（前端），该服务提供来自Kubernetes外部VM中运行的有状态数据库（后端）的数据。你仍然希望使用mTLS加密前端对这些后端的访问。通过此更改，可以轻松地做到这一点。此外，这是以“零信任”方式完成的，其中一个前端或后端的妥协不允许模仿或损害其他前端或后端，因为自举和证书轮换遵循着最佳实践。
3、还扩展了istioctl以便能够验证基于VM的工作负载的代理状态，以前验证仅适用于基于Kubernetes的工作负载。
4、最后，添加了正式的RPM软件包以及已经存在的Debian软件包。这应该使在基于Red Hat的映像上进行安装非常容易。
其他修复
1、删除了一些无效的控制平面指标，并 默认情况下停止安装遥测插件。
2、解决了SNI路由的问题。
Istio现在可以与无头服务更好地协作，因为它将不再将mTLS流量发送到没有sidecar的无头服务上面。
lstio会成为下一个kubernetes的吗？
那么我们想一想目前lstio已经这几年的变化，它会不会成为下一个现象级的kubernetes产品，我们可以来分析一下
首先第一点来看看lstio产生了哪些意义？
1、lstio的出现实际上让你重新定义了微服务的开发方式，让你可以轻松的在你的微服务架构中注入service Mesh技术
2、它可以大幅降低微服务应用的开发门槛，让你只关注业务本身
不用考虑如何添加很多网络控制的相关功能或者类库
3、它用统一的运维和开发方式，来简化微服务的开发流程
那么Istio一经推出，实际上是背负了这几家公司的使命，而对于IBM和google的这样的云厂商来说，lstio是一个战略级产品，它的推出为这两家厂商的云平台，提供一个杀手级的特性
它可以延续google的云原生市场上一个战略布局，我们可以在这张图可以看到在容器层面google已经有了kubernetes,那么在通讯层面已经有了google grpc的协议，而微服务这个层面，google也就是打算使用lstio这样的一个产品来占领市场，整个这三方面组成了google的一个云原生的战略，另外lstio还受到了很多云厂商的支持，包括自家的G cloud,IBM的cloud,以及国内的现几大厂商，它们现在的产品也都是基于lstio二次开发的，另外它可能还会受到一些其他厂商的阻击，比如说亚马逊的AWS使用的自己的app Mesh这样的产品，比如微软自己的云平台Azure,它也有自己的service mesh产品，可能在未来云平台的生态闭环，可能会有不同的service mesh产品并存，目前还不能直接看出lstio一家独大。