云原生Istio基本介绍 1

微服务错综复杂，要完成其业务目标，连接问题是首要问题。连接存在于所有服务的整个生命周期中，用于维持服务的运行，算得上重中之重。
相对于传统的单体应用，微服务的端点数量会急剧增加，现代的应用系统在部分或者全部生命周期中，都存在同一服务的不同版本，为不同的客户、场景或者业务提供不同的服务。同时，同一服务的不同版本也可能有不同的访问要求，甚至产生了在生产环境中进行测试的新方法论。错综复杂的服务关系对开发者来说都是很严峻的考验。

从不同的外部用户的角度来看，他们访问的都是同一服务端口，但实际上会因为不同的用户识别，分别访问服务A的不同版本；在网格内部，服务A的版本1可能会访问服务B的两个版本，服务A的版本2则只会访问服务B的版本1；服务B的版本1需要访问外部的云服务，版本2则无此需求。
在这个简化的模型中，包含了以下诉求：
◎ 网格内部的调用（服务A→服务B）；
◎ 出站连接（服务B→外部云服务）；
◎ 入站连接（用户→服务A）；
◎ 流量分割（A服务跟B服务只负责与自己相关流量请求）；
◎ 按调用方的服务版本进行路由（服务A的版本1分别调用了服务B的版本1和版本2）；
◎ 按用户身份进行路由。
这里除了这些问题，还存在一些潜在需求，如下所述。
（1）在网格内部的服务之间如何根据实际需要对服务间调用进行路由，条件可能包括：
    ◎ 调用的源和目的服务；
    ◎ 调用内容；
    ◎ 认证身份。
（2）如何应对网络故障或者服务故障。
（3）如何处理不同服务不同版本之间的关系。
（4）怎样对出站连接进行控制。
（5）怎样接收入站连接来启动后续的整个服务链条。
这些当然不是问题的全部，其中，与流量相关的问题还引发了几个关键的功能需求，如下所述。
（1）服务注册和发现：要求能够对网格中不同的服务和不同的版本进行准确标识，不同的服务可以经由同一注册机构使用公认的方式互相查找。
（2）负载均衡策略：不同类型的服务应该由不同的策略来满足不同的需要。
（3）服务流量特征：在服务注册发现的基础之上，根据调用双方的服务身份，以及服务流量特征来对调用过程进行甄别。
（4）动态流量分配：根据对流量特征的识别，在不同的服务和版本之间对流量进行引导。
连接是服务网格应用过程中从无到有的最重要的一个环节。

安全也是一个常谈常新的话题，在过去私有基础设施结合单体应用的环境下，这一问题并不突出，然而进入容器云时代之后，以下问题出现了。
（1）有大量容器漂浮在容器云中，采用传统的网络策略应对这种浮动的应用是比较吃力的。
（2）在由不同的语言、平台所实现的微服务之间，实施一致的访问控制也经常会因为实现的不一致而困难重重。
（3）如果是共享集群，则服务的认证和加密变得尤为重要，例如：
    ◎ 服务之间的通信要防止被其他服务监听；
    ◎ 只有提供有效身份的客户端才可以访问指定的服务；
    ◎ 服务之间的相互访问应该提供更细粒度的控制功能。
总之，要提供网格内部的安全保障，就应具备服务通信加密、服务身份认证和服务访问控制（授权和鉴权）功能。
上述功能通常需要数字证书的支持，这就隐藏了对CA的需求，即需要完成证书的签发、传播和更新业务。
除了上述核心要求，还存在对认证失败的处理、外部证书（统一 CA）的接入等相关支撑内容。

Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理等功能使得资源在消费者之间公平分配
在Istio中使用Mixer作为策略的执行者，Envoy的每次调用，在逻辑上都会通过Mixer进行事先预检和事后报告，这样Mixer就拥有了对流量的部分控制能力；在Istio中还有为数众多的内部适配器及进程外适配器，可以和外部软件设施一起完成策略的制定和执行。

随着服务数量的增加，监控和跟踪需求自然水涨船高。在很多情况下，可观察的保障都是系统功能的重要组成部分，是系统运维功能的重要保障。
随着廉价服务器（相对于传统小型机）的数量越来越多，服务器发生故障的频率也越来越高，人们开始产生争论：我们应该将服务器视为家畜还是宠物？家畜的特点：是有功能、无个性、可替换；而宠物的特点：是有功能、有个性、难替换。
我们越来越倾向于将服务器视为无个性、可替换的基础设施，如果主机发生故障，那么直接将其替换即可；并且，我们更加关注的是服务的总体质量。因此，微服务系统监控，除了有传统的主机监控，还更加重视高层次的服务健康监控。
服务的健康情况往往不是非黑即白的离散值，而是一系列连续状态，例如我们经常需要关注服务的调用成功率、响应时间、调用量、传输量等表现。
而且，面对数量众多的服务，我们应该能对各种级别和层次的指标进行采样、采集及汇总，获取较为精密、翔实的运行数据，最终通过一定的方法进行归纳总结和展示。
与此同时，服务网格还应提供分布式跟踪功能，对服务的调用链路进行跟踪。
观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题。

在微服务化的过程中，将服务拆分后会发现一堆麻烦事儿，连基本的业务连通都成了问题。在处理一些治理逻辑，比如怎么找到对端的服务实例，怎么选择一个对端实例发出请求，都需要自己写代码来实现。这种方式简单，对外部依赖少，但会导致存在大量的重复代码。所以，微服务越多，重复的代码越多，维护越难；而且，业务代码和治理逻辑耦合，不管是对治理逻辑的全局升级，还是对业务的升级，都要改同一段代码。

在解决第1种形态的问题时，我们很容易想到把治理的公共逻辑抽象成一个公共库，让所有微服务都使用这个公共库。在将这些治理能力包含在开发框架中后，只要是用这种开发框架开发的代码，就包含这种能力，非常典型的这种服务治理框架就是Spring Cloud。这种形态的治理工具在过去一段时间里得到了非常广泛的应用。
SDK模式虽然在代码上解耦了业务和治理逻辑，但业务代码和 SDK还是要一起编译的，业务代码和治理逻辑还在一个进程内。这就导致几个问题：业务代码必须和 SDK 基于同一种语言，即语言绑定。例如，Spring Cloud等大部分治理框架都基于Java，因此也只适用于 Java 语言开发的服务。经常有客户抱怨自己基于其他语言编写的服务没有对应的治理框架；在治理逻辑升级时，还需要用户的整个服务升级，即使业务逻辑没有改变，这对用户来说是非常不方便的。

SDK模式仍旧侵入了用户的代码，那就再解耦一层，把治理逻辑彻底从用户的业务代码中剥离出来，这就是前面提过的Sidecar模式。显然，在这种形态下，用户的业务代码和治理逻辑都以独立的进程存在，两者的代码和运行都无耦合，这样可以做到与开发语言无关，升级也相互独立。在对已存在的系统进行微服务治理时，只需搭配 Sidecar 即可，对原服务无须做任何修改，并且可以对老系统渐进式升级改造，先对部分服务进行微服务化。

比较以上三种服务治理形态，我们可以看到服务治理组件的位置在持续下沉，对应用的侵入逐渐减少。
微服务作为一种架构风格，更是一种敏捷的软件工程实践，说到底是一套方法论；与之对应的 Istio 等服务网格则是一种完整的实践，Istio 更是一款设计良好的具有较好集成及可扩展能力的可落地的服务治理工具和平台。
所以，微服务是一套理论，Istio是一种实践。