1. 是什么？

Istio是一个用于服务办理的敞开平台。

服务办理触及衔接（Connect）、安全 （Secure）、战略执行（Control）和可调查性（Observe）

• 衔接：Istio 经过会集装备的流量规矩操控服务间的流量和调用，完成负载均衡、熔断、毛病注入、重试、重定向等服务办理功用。
• 安全：Istio 供给通明的认证机制、通道加密、服务拜访授权等安全才能，可增强服务拜访的安全性。
• 战略执行：Istio 经过可动态插拔、可扩展的战略完成拜访操控、速率限制、配额办理、服务计费等才能。
• 可调查性：动态获取服务运转数据和输出，供给强壮的调用链、监控和调用日志收集输出的才能。配合可视化工具，可便利运维人员了解服务的运转状况，发现并处理问题。

Istio 0.1 发布时 ，官方强调了Istio供给的重要才能。

• 服务运转可调查性：监控运用及网络相关数据，将相关目标与日志记录发送至恣意收集、聚合与查询体系中以完成功用扩展，追寻剖析功能热门并对分布式毛病方式进行确诊。
• 弹性与效率：供给了一致的办法装备重试、负载均衡、流量操控和断路器等来处理网络可靠性低所造成的各类常见毛病，更轻松地运维高弹性服务网格。
• 研制人员出产力：保证研制人员专心于根据已选择的编程言语构建事务功用，不必在代码中处理分布式体系的问题，从而极大地提高出产才能。
• 战略驱动型运营：解耦开发和运维团队的作业，在无须更改代码的前提下提高安全性、监控才能、扩展性与服务拓扑水平。运营人员能够不依赖开发供给的才能准确操控出产流量。
• 默认安全：答应运营人员装备TLS双向认证并保护各服务之间的一切通讯，而且开发人员和运维人员不必保护证书，以应对分布式计算中常常存在的大量网络安全问题。
• 增量适用：答应团队依照自己的节奏和需求逐渐运用各项功用，例如先调查服务运转情况再进行服务办理等。

2.示例

以天气预报运用中forecast服务对recommendation服务的拜访为例。

在forecast服务的代码中经过域名拜访recommendation服务，在两个服务中都不必包含任何服务拜访办理的逻辑。

而Istio在其中都做了什么：

• 主动经过服务发现获取recommendation服务实例列表，依据负载均衡战略选择一个服务实例；
• 对服务双方启用双向认证和通道加密；
• 如果某个服务实例连续拜访犯错，则能够将该实例阻隔一段时间，以提高拜访质量；
• 设置最大衔接数、最大恳求数、拜访超时等对服务进行保护；
• 限流；
• 对恳求进行重试；
• 修改恳求中的内容；
• 将必定特征的服务重定向；
• 灰度发布；
• 主动记录服务拜访信息；
• 记录调用链，进行分布式追寻；
• 依据拜访数据形成完好的运用拜访拓扑；

这些功用都只需在 Istio 的操控面做些装备，而且动态收效。以灰度发布为例，经过简单装备即可完成，其中心作业是完成两个版别同时在线，并经过必定的流量战略将部分流量引到灰度版别上。无须修改事务代码，只需简单写一个装备就能够对恣意一个服务进行灰度发布了

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - match:
    - headers:
      cookie:
        exact: "group-dev"
    route:
    - destination:
        name: v2
  - route:
    - destination:
        name: v1

Istio采用了与K8s相似的语法风格：将 group 是 dev 的流量转发到 recommendation服务的 v2版别，其他用户仍是拜访 v1版别，从而到达从 v1版别中切分少部分流量到灰度版别 v2的效果。

3. 与服务办理

Istio是一个服务办理平台，办理的是服务间的拜访，只需有拜访就能够办理，不在乎服务是不是微服务，也不要求跑在其上的代码是微服务化的。单体运用不满足微服务的若干哲学，用Istio 办理也是完全能够的。提起“服务办理”，咱们最早想到的必定是“微服 务的服务办理”，就让咱们从微服务的服务办理说起。

3.1 关于微服务

“微服务是以一组小型服务来开发单个运用的办法，每个服务都运转在自己的进程中，服务间采用轻量级通讯机制（通常用 HTTP 资源API）。这些服务环绕事务才能构建并可独立布置，还共用一个最小型的会集式办理，可用不同的言语开发，并运用不同的数据存储技术”。微服务在本质上仍是分而治之、化繁为简的哲学的表现。

微服务将复杂的单体运用分解成若干小的服务，服务间运用轻量级的协议进行通讯。这种方法有许多好处：

• 开发视角：每个微服务的功用更内聚，能够在微服务内设计和扩展功用，而且采用不同的开发言语及开发工具；
• 运维视角：在微服务化后，每个微服务都在独立的进程里，能够自运维；更重要的是，微服务化是单一改变的基础，迭代速度更快，上线风险更小；
• 组织办理视角：将团队依照微服务切分为小组替代服务大组也有利于灵敏开发。

但微服务化也给开发和运维带来很大的挑战：事务自身的规模和复杂度变多。

在分布式体系中，网络可靠性、通讯安全、网络时延、网络拓扑改变等都是要关注的内容。别的，微服务带来了大量的作业，比如服务怎么恳求方针服务，需求引进服务发现和负载均衡等，以及对跨进程的分布式调用栈进行分布式调用链 追寻，等等。

这需求一些工具来做一些通用的作业，包含服务注册、服务发现、负载均衡等。在未微服务化时，单体运用的多模块之 间不需求进程间通讯，也不需求服务发现。所以这些工具集仅用于处理微服务化带来的新问题，却并没有带来更多的事务收益。

3.2 服务办理的三种形状

1. 在事务代码中包含办理逻辑，服务越多，重复代码越多
2. 笼统成公共库，但仍是对事务进程有侵入
3. 以sidecar的方式进行：将办理逻辑放在独自进程内

4. 与服务网格

• 基础设施：服务网格是一种处理服务间通讯的基础设施层。
• 云原生：服务网格特别适用于在云原生场景下协助运用程序在复杂的服务拓扑间可靠地传递恳求。
• 网络署理：服务网格一般是经过一组轻量级网络署理来执行办理逻辑的。
• 对运用通明：轻量网络署理与运用程序布置在一起，但运用感知不到署理的存在，仍是运用原来的方法作业。

天下没有免费的午饭，sidecar在服务的拜访链路上多引进的两跳也是不容回避的问题。

从forecast服务到recommendation服务的一个拜访必需要经过forecast的 Sidecar阻拦 Outbound流量执行办理动作；再经过 recommendation的 Sidecar阻拦Inbound流量，执行办理动作。这就引进两个问题：

1. 增加了两处推迟和或许的毛病点；
2. 多出来的这两跳关于拜访功能、整体可靠性及整个体系的复杂度都带来了新的挑战。

后者本来就归于基础设施层面可保护性、可靠性的范畴，产品都用各自的方法在保证。而前者引进的功能和资源损耗，经过保证转发署理的轻量和高功能降低时延影响，而后端运用一般比署理更重，叠加署理并不会显着影响运用的拜访功能

5. 与k8s

5.1 istio：k8s的好帮手

K8s供给了十分强壮的运用负载的布置、晋级、扩容等才能。它的 Service 机制也现已能够做服务注册、服务发现和负载均衡，支撑经过服务名拜访到服务实例。它自身是支撑微服务的架构，在Pod中布置微服务很适宜，也处理了微服务的互访互通问题，但对服务间拜访的办理如服务的熔断、限流、动态路由、调用链追寻等都不在K8s的才能范围内。那怎么供给一套从底层的负载布置运转到上层的服务拜访办理端到端的处理方案？现在最完美的答案就是在K8s上叠加Istio

K8s的Service根据每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的恳求经过负载均衡转发到对应的 Endpoint 上。但K8s只供给了4层负载均衡才能，无法根据运用层的信息进行负载均衡，更不会供给运用层的流量办理，在服务运转办理上也只供给了基本的探针机制，并不供给服务拜访目标和调用链追寻这种运用的服务运转确诊才能。

Istio复用了Service的界说，在完成进步行了更细粒度的操控 。 Istio的服务发现就是从 Kube-apiserver 中获取 Service 和 Endpoint ，将其转换成 Istio 服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里布置的 Sidecar，也能够将其看作每个服务实例的 Proxy。这样 Proxy 的粒度就更细了，和服务实例的联络也更严密了，能够做更多更细粒度的服务办理。

经过阻拦Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种运用层协议，Istio能够供给真正的运用层办理、监控和安全等才能。

5.2 k8s：istio的好基座

Istio最大化地利用了K8s这个基础设施，与之形成了一个更强壮的用于进行服务运转和办理的基础设施，并供给了更 通明的用户体验。

1. 数据面
   数据面Sidecar运转在K8s的Pod里，作为一个Proxy和事务容器布置在一起。在服务网格的界说中要求运用程序在运转时感知不到Sidecar的存在。而根据K8s的一个 Pod 多个容器的优异设计使得布置运维对用户通明，用户乃至感知不到布置 Sidecar的过程。
   用户仍是用原有的方法创立负载，经过 Istio 的主动注入服务，主动给指定的负载注入Proxy。
2. 一致服务发现
   Istio的服务发现机制十分完美地根据K8s的域名拜访机制构建而成，省去了再搭一个注册中心的费事，更避免了在 K8s 上运转时服务发现数据纷歧致的问题。
3. 根据K8s CRD描绘规矩
   Istio的一切路由规矩和操控战略都是经过 K8s CRD完成的，因而各种规矩战略对应的数据也被存储在 Kube-apiserver 中，不需求别的的 APIServer 和后端的装备办理。能够说Istio 的APIServer就是K8s的APIServer，数据也自然地被存在了对应 K8s的etcd中。 Istio奇妙地运用了K8s这个基座，根据其已有才能来构建自身功用，避免了数据纷歧致和用户运用体验的问题。

Istio不只数据面Envoy跑在K8s的Pod里，其操控面也运转在K8s 集群中，操控面组件自身存在的方式也是K8s Deployment和 Service，根据K8s扩展和构建

总结