引子
这几天拜读了灵雀云出品的一篇文章：《从“鸿沟理论”看云原生》，其中有两段关于 Istio 的陈述，我深感赞同：
- 在 Control Plane，Istio 是最具光环的明星级项目。它正在引领 Service Mesh 创造出一个全新的市场，不过从传播周期看现在还没有跨过技术鸿沟，处于 Early adopters 阶段。
- 在开源领域，并不存在对Istio有实质性威胁的竞品。可能在经历了 Kubernetes 之后，以及 Istio 早期迅猛的发展和在社区中巨大的影响力之下，很少有开源项目愿意在 Control Plane 和 Istio 正面交锋。
按照我对 Istio 的理解，正如该文所说，正处于鸿沟一侧，正是从早期采用者到早期大众之间关键阶段。然而这一系统的情况又比较特殊，Service Mesh 的饼，虽说是 Linkerd 画出来的，然而真正把饼变大的，正是 Istio。Istio 画了硕大无朋的饼之后，就步步泥潭，功能薄弱、进度拖沓，让包括我在内的众多用户大摇其头。然而，画饼的另一面，就是挖坑——Istio 放出的漫天卫星，极大的吊起了各种用户的胃口，可以说是用先声夺人的方式，强行提高了门槛，要想赶超 Istio，首先就要接班，完成 Istio 的各种承诺，才能满足用户心目中对 Service Mesh 的“基本”期待。
Istio 1.1
Istio 自然还是在努力的完成满足早期用户要求的基础上，加强对早期大众的吸引。自 2018 年 7 月发布 1.0 之后，经过近 8 个月的漫长等待，千呼万唤的 1.1 又做出了什么样的变化，来帮助 Istio 来达成这样的目标呢？下面会介绍一些我所关注的 Istio 1.1 新特性。
缺省关闭 Mixer 策略检查
从 Istio 的早期版本开始，关于如何关闭 Mixer 策略检查的讨论就没有停止过，现在社区已经达成共识，绝大多数场景中，对性能的需求，其重要性是大于对预检功能的需求的，因此 1.1 版本中，缺省安装会关闭 Mixer 的这一功能。
缺省开放 Egress 通信
新增 global.outboundTrafficPolicy.mode 参数，用于定制 Egress 通信的缺省行为，目前的缺省值为 ALLOW_ANY，即允许全部 Egress 通信。
新增 Sidecar 资源
目前版本中，Sidecar 会包含整个网格内的服务信息，在 1.1 中，新建了 Sidecar 资源，通过对这一 CRD 的配置，不但能够限制 Sidecar 的相关服务的数量，从而降低资源占用，提高传播效率；还能方便的对 Sidecar 的代理行为做出更多的精细控制——例如对 Ingress 场景中的被代理端点的配置能力。
ExportTo
多个路由管理对象加入了这一字段，用于指定该资源的生效范围。
路由的区域感知能力
新增了对 AZ/Region 等的区域感知能力，降低跨区请求造成的性能损耗。
对 TCP 服务提供鉴权支持
在既有的 HTTP/gRPC 之外，又为 TCP 服务提供了 RBAC 功能。
引入 SDS 完成证书流程
弃用原有的 Citadel->Secret->Sidecar 的证书流程，改用 Secret Discovery Service 完成。从而降低了安全风险，并且更新证书也无需重新启动了。
