关于Service Mesh，数人云之前给大家分享了敖小剑老师的《Qcon2017实录|Service Mesh：下一代微服务》那么它对于容器相比传统模式都有哪方面的优势呢？同作为Service Mesh的新生代，Istio v0.2都有哪些添加与改进？本文见分晓！
容器仍然是目前极度火热的话题，一些人称，通过容器他们正处于崛起的边缘，成为数据中心的主宰，另外一些人则认为容器只适用于云计算，还有一些人在耐心地等待着看容器是不是应用程序基础设施的SDN，一些权威人士在极力吹捧，但其实很少在生产中付诸实践。
通过一些研究和调查可以看到容器确实在吸引着人们的注意：
-
32%的公司每年花费50万美元或更多的资金用于容器技术的授权和使用费（Portworx的年度容器采用率调查）
-
采用容器技术的公司在9个月内将其容器数量增加5倍（Datadog 8个令人惊讶的事实，关于Docker的采用。
-
容器的密度为平均每台主机10个容器（Sys Docker 使用报告2017）
-
2017年，Docker的使用率飙升至35%（2017年云计算报告）
-
5%的企业希望采用容器来部署传统的网络托管应用服务（F5 Networks State of Application Delivery 2017）
如大多数的基础设施——无论是应用还是网络——在可预见的未来，容器都将与日常运行在大型机和Midranges Alike上的应用程序共存，这是应用基础设施最重要的转变，当WEB堆栈上升到主导地位时，它并没有消除Fat Client-Server应用程序，至少在一段时间内，它们是一同运行的。
然而，它所做的都是迫使我们改变这些应用的规模，WEB应用程序对网络及其服务器施加了巨大的压力，需要新的方式来扩展容量和确保可用性，使用容器来部署应用程序——特别是那些使用微服务体系结构的应用。
在容器化环境和传统WEB应用程序中使用的扩展模式之间存在着显著的差异。
传统模式
无论在云端（公有云、私有云）还是数据中心，传统的模式都采用了相当标准的模式，它使用固定的“池”资源，配置和行为最终基于端口和IP地址。
负责实际扩展应用程序的软件（无论部署在特定的目的硬件和是COTS上）都是在一个相当独立的操作前提下执行的，从算法到可用的资源，所有的一切都是按照比例服务的。
同时也包括这些资源的状态，在传统的模式中，通常是扩展应用，跟踪资源的健康状况，并在不可用的情况下进行轮转。
传统的规模模式依赖于命令式的配置模式，并且只有很少的明显例外（如状态）变化是由配置事件驱动的，这意味着一个操作符或外部脚本已经发布了一个非常特定的命令——通过API、CLI或GUI——来更改配置。
The Cloud Half-Step
当“自动扩展”的概念出现时，云计算开始影响这个模式，于大多数容器化的环境中，自动伸缩是传统模式和服务网格模式之间的一个半步，它融合了环境变化的概念，比如增加需求出发配置更改，比如添加或删除资源，然而，模式仍然是一个“推”模式，这意味着对规模负责的系统仍然必须被隐式地告知需要进行的更改。
服务网格模式
容器的管理通常由一些外部系统实现，比如Kubernetes或Mesos或Open Shift，通过一个类似于容器集群的命令和控制中心的“主”控制器，它的职责是管理容器，并将其保存到最新的目录中。
对于给定服务（或应用程序）可用资源的“池”是动态的，很多东西都是由一个特定容器的实际寿命所做而成，但事实是，跟它们的前辈虚拟机的几周或者几个月的寿命相比，可能只有几分钟或几个小时。
这种速度是不可能手动进行跟踪了，这也是为什么服务注册中心存在的原因——为了保存一个实时列表，列出哪些资源可用，以及它们属于什么服务。
这是服务网格模式避免将应用程序和服务紧密耦合到IP地址和端口的原因之一，当然，它们仍然被使用，但波动性（以及网络属性的重要）要求应用程序和服务必须由其他东西来表示——比如标签。
然后，真个系统中的所有配置和行为都是基于这些标记的，它们与FQDNs很相似。
通过DNS映射到IP地址。
所有这些都导致了需要一个更加协作的操作前提，负责扩展容器化应用和服务的软件，与传统的模式有很大不同，它们的前提是“我需要其他服务的信息来决定，而我的目的可能在另一个地方”。
但是不能期望主控制器通知每一个更改的组件，这种集中式控制不考虑系统中的组件数量，记住，它不只是容器，除了用于监控和报告业务以及操作分析所需要的远程数据守护进程之外，还存在诸如服务和规则之类的构造，但扩展软件仍然需要，知道什么时候改变（或者资源转移）。
在服务网格模式中，更改是由其他地方发布的操作事件所驱动，扩展软件的职责是拉出这些更改并对它们进行操作，而不是通过脚本或人工操作来实现特定的配置更改。
这意味着更改必须与实现无关，更改不可能是特定的API调用或需要实现的命令，他们必须是“什么”而非“如何”。这是一种声明式的配置模式，而不是与传统的规模模式相关的命令式模式。
这就意味着：
- 这些变化对网络的流量产生了相当大的影响
- 传统的模式可以被看做是一个交通信号灯系统
- 固定的配置
- 限定方向
- 路线预定义
另一方面，一个服务网格模式更类似于现代的交通管理系统：
- 基于实时条件的动态
- 路径变量
- 路线灵活
接受这个模式最困难的部分，从作者的个人经验来看，是在一个服务的设备中有多少移动的部件，这使得很难从一端（客户端），到另一端（应用程序）跟踪数据路径，服务于主控制器和服务注册中心的服务依赖于对路由请求的依赖，因为它们对于路由请求的重要性，就像ARP映射表在核心网络中路由数据包一样重要。
服务网格模式在那些采用容器的用户中获取了极大的兴趣和新引力，在墙的另一边，要了解它对网络的影响，并准备好管理它。
Istio v0.2
Istio是Google/IBM/Lyft联合开发的开源项目，2017年5月发布第一个release 0.1.0， 官方定义为:
Istio：一个连接，管理和保护微服务的开放平台。
按照Isito文档中给出的定义:
Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。
——敖小剑《万字解读:Service Mesh服务网格新生代--Istio》
Istio v0.2添加很多新的功能以及改建，下面来谈一谈，Istio v0.2让人激动的5大改进：
Automatic Sidecar Injection
对于自定义资源和初始化器的支持，Istio v0.2要求Kubernetes1.7.4或更新，如果集群中启用了I nitializer Alpha特性，建议安装Istio初始化器，它为所有想要的Istio管理的微服务部署注入了自动的Sidecar。IBM Bluemix容器服务集群在1.7.4或更新时自动运行，这与Istio初始化器很好地工作，由于仍然是Istio开发总体方案中的一个Alpha特性，所以建议谨慎使用。
Traffic Management Improvement
在Istio v0.1中，用户可以使用Ingress路由规则来制定想要通过微服务进入的流量，现在，还可以使用e外出路由规则来制定想要从微服务中获得哪些类型的流量，以及服务可以与哪些外部服务进行通信，例如，用户可以轻松地配置服务，与IBM Cloud中的IBM Watson服务之一进行对话，从而为用户的服务提供人工智能功能。
Improved Telemetry
作为Istio用户，无需做任何事情去启动各种度量或跟踪，这非常简便，用户可以部署微服务应用，让Istio进行管理，而不需要任何应用程序或部署。Yaml文件，Zipkin的跟踪为应用提供了详细的跟踪信息，Zipkin的进一步追踪让人可以深入到每一个请求中，以查看流量子啊服务网格中如何技术，如果用户更喜欢Jaeger，也提供支持。
多环境支持
Istio的最初目标之一就是进行多环境的支持，在微服务体系结构中，无法要求所有的工作负载都在Kubernetes中运行，用户的一些应用程序可能在Kubernetes中运维，而另外一些可能在Docker Swarm或者VM中运行，在Istio v0.2中，引入了早期对VM的支持，并与一些更流行的服务发现系统进行了集成，Istio已经被扩展支持到其他运行时环境，这是让人兴奋的一件事。
在Kubernetes环境中使用Kubectl与Istio进行交互
本文作者最喜欢的一项是Istio v0.2更新了配置的模式，并使用Kubernetes的自定义资源定义，这意味着用户现在可以在Kubernetes环境中使用Kubectl与Istio进行交互，如果有自动的Sidecar注入，在Kuberentes环境中与Istio互动时，就无需Istioctl了，当用户想要首都注入Sidecar或与诸如控制台和VM等多环境交互时，Istioctl就变得有用了。
原文作者：DevCentral 原文链接：https://www.tuicool.com/articles/uE3uyyV
来源：oschina
链接：https://my.oschina.net/u/2552756/blog/1558903