摘要： Istio 1.0 发布，加速Service Mesh概念落地
Istio 1.0 于北京时间8月1日0点正式发布！虽然比原本官网公布的发布时间晚了9个小时，但这并未影响到Istio在社区的热度。
Istio 是 Service Mesh概念的具体实现。2018年被称为 Service Mesh 元年，誉为新一代的微服务架构，有了Service Mesh，像Docker和Kubernetes标准化部署操作一样来标准化我们的应用程序运行时的操作便成为可能。Istio是其中最成熟和被广泛接受的开源项目。它是连接、管理和保护微服务的开放平台。今天发布的1.0 版本是一个重要的里程碑。这意味着Istio的所有核心功能都已经可以落地部署，不再只是演示版了。
本文来自阿里巴巴中间件事业部硅谷团队 Istio 技术专家 Andy在 Istio上的实践和对1.0版本的解读，Andy长期关注Service Mesh，在Cloud Foundry，Kubernetes，Envoy上有着丰富的实践和开发经验。
Istio 新功能简介
1.0版本中的新功能大致如下：
» 网络
• 使用 Virtual Service 进行 SNI 路由
• 流式 gRPC 恢复
• 旧版本（v1alpha1）的网络 API 被移除
• Istio Ingress 被gateway替代
» 策略和遥测
• 属性更新
• 缓存策略检查
• 遥测缓冲
• 进程外适配器
• 客户端遥测
» Mixer 适配器
• SignalFX
• Stackdriver
» 安全
• RPC 级授权策略
• 改进的双向 TLS 认证控制
• JWT 认证.
几个重要的改变
在众多的改变中，下面几点和之前版本相比，有较大的增强和改动，在这里我们展开介绍下：
» IstioGateway 替代 IstioIngress
在 istio 1.0 之前，Istio Ingress 直接使用 Kubernetes Ingress，因此受到 Kubernetes 的 Ingress 本身只有 L7 的网络控制功能的限制，很多功能无法实现。这些功能包括：
• L4-L6的LB
• 对外的mTLS
• 对SNI（服务器名称指示）的支持
• 以及其它在Pilot已经实现的对内部网络的功能，比如Traffic splitting,fault injection, mirroring, header match等。
为了解决这些问题，Istio 在 1.0 版本提出了 Istio Gateway 的概念，从而摆脱了对 Kubernetes Ingress 的依赖，可以实现更多的功能，例如： L4-L6的LB，对外的mTLS，对SNI（服务器名称指示）的支持等。
如果我们希望给一个 Kubernetes 的 guestbook ui Service 做一个 Istio Ingress 的话，在 0.8 版本以前我们需要如下定义一个 Istio Ingress Resourse：
这里面是我们对 L7 的策略配置。但是可以看到，基于这种 Ingress 并不能支持 mTLS 等高级功能。现在在 Istio 1.0 版本，我们可以使用新的 Istio Gateway 来完成类似的配置。这种配置会分两部分：
• L4-L6 的配置在 Gateway 这种资源中；
• L7 的配置在绑定的 Virtual Services 配置资源中。
对于上面同样的例子，Istio Gateway 资源的定义是这样的：
通过 Gateway 这种资源，我们提供了对mTLS的支持。为了完成对 HTTP path 的匹配和对 Virtual Host 的支持，我们需要定一个新的 VirtualService 资源并且将它Gateway 资源绑定。Virtual Services很像以前的 Virtual Host，它可以允许同一个IP对应不同的域名，所以即使同样的路径也不会产生重复。
它的配置和与 Gateway 的绑定如下：
» Mixer 进程外适配器
适配器是让第三方用户来扩展Mixer功能的，比如和自己的 Logging 系统集成。以前的适配器，是与 Mixer 主进程在一起的。这样有些问题，比如如果适配器有用户的认证信息，那么上传的时候所有人都知道了。另外，如何对这些适配器做健康检查（health check）呢? 它们在同一个进程里。
新的版本，适配器在 Mixer 主进程之外，用户不但可以决定是否要把适配器上传，而且运行时也可以进行外部健康检查了。
不过由于适配器 和 Mixer 主进程不在同一个进程，需要进行进程间通讯，因此适配器要和主进程通讯会依赖 RPC。这里 Mixer 选用了比较流行的标准 RPC 框架 gRPC作为实现。
有了这个功能，在 Istio 的 Mixer 中开发外适配器功能只需要如下三个步骤：
• 编译适配器源代码
• 生成适配器模版
• 部署适配器镜像
如果有兴趣更深入的了解适配器的开发和使用，请参考这两个教程
（第一部分）
（第二部分）
支持可以使用身份验证策略配置的 JWT 身份验证
JWT（JSON Web Token）是一种基于token的鉴权机制。JWT很流行的原因主要是它的简单易用，特别是采用JSON格式，是大部分编程语言支持的。所以尽管出现的时间不长，但却是很多编程人员的鉴权首选。因此 Istio 对 JWT 进行了支持。
例如我们创建一个 JWT token payload来庆祝 Istio 1.0 GA ：
用户调用时，需要把 JTW token 来编码后，以 Bearer 形式进行传递：
Istio 就用这个Bearer来作最终用户认证。是不是很简单呢？Istio 之前就支持基于 JWT 的Authentication。新的版本开始支持 Authorization。对用户来说，只是在同一个Authentication policy 的资源上扩展一部分而已。
Istio的 Authorization 是基于角色的访问控制，它提供命名空间级别, 服务级别和 method-level 的访问控制。
要实现Authorization，只需要如下几步：
• 首先要开启允许授权；
• 开启了特定级别（如：命名空间）的授权；
• 创建这个级别的访问控制策略。
更详尽的内容，可以参考 Istio 安全文档：
三、阿里巴巴对 Istio 生态的支持
以上是关于Istio 1.0的简单介绍。如果大家感兴趣的话，可以通过以下的教程进行实践。
阿里巴巴中间件技术团队会持续关注和参与Service Mesh的开发和推广活动。并提供一系列关于Service Mesh和 Istio 的解读、实践和教程，详细介绍 Istio新版本中的概念、功能以及未来最新的动态。我们也正计划在Dubbo 2.7的版本中加入对Istio的集成，充分利用Service Mesh的理念，进一步简化微服务的管理。
本文作者：中间件小哥
阅读原文
本文为云栖社区原创内容，未经允许不得转载。