IBM, Google和Lyft微服务管理框架Istio

Istio，这是一种开放技术，提供了一种连接和管理不同微服务器平台的统一方式。Istio是IBM，Google和Lyft联合合作的结果，Istio能够支持微服务之间的流量管理、访问策略实施和数据的聚合。如果你的微服务是建立在IBM，Google和Lyft的早期平台上，无需要开发人员对代码进行任何变动。Istio目前可运行在Kubernetes平台，其设计并不针对特定的平台。Istio开源项目计划包括对CloudFoundry，VM在内的其他平台的支持。为什么建立Istio我们看到越来越多的开发人员在构建应用程序时转向微服务。该策略允许开发人员将大型应用程序分解成更小，更易于管理的部件。微服务方法还特别适合在云中进行大规模，连续可用的软件开发。随着我们的大型企业客户迁移到云端，我们亲眼见证了这一趋势。随着微服务动态扩展，诸如服务发现，负载平衡和故障恢复等问题的统一解决变得越来越重要。各个开发团队独立管理和更改其微服务，又难以将所有微服务作为单个统一应用程序放在一起工作。随着服务数量增加，形成复杂的微服务网格，微服务的管理面临越来越难的挑战，包括服务发现, 负载平衡, 失败恢复, 度量和监视。 甚至还有更复杂的需要如A/B厕时, canary版本发布, 速率限流, 访问控制和端到端授权.在合作之前，IBM，Google和Lyft一直在各自独立解决这些问题，但是工作是互补的。IBM的Amalgam8项目是去年创建和开放的统一服务网格，为流量布线架构提供了可编程控制平面，以帮助其内部和企业客户进行A / B测试，并系统地测试他们的服务是成功或失败。Google的服务控制除了从各种服务和代理收集数据之外，还提供了一个控制服务的功能，专注于实施ACL，速率限制和身份验证等策略。Lyft开发了 Envoy proxy，以帮助他们的微服务旅程，将他们从一个单一的应用程序带到一个生产系统，可跨越10,000个VM，处理100多个微服务器。Envoy的能力表现以及开发商与社区合作的意愿给人印象深刻。通过Istio能够在Envoy中创建路由和策略管理的变得易于控制，IBM还向Envoy贡献了几项功能，例如跨服务版本的流量分流，Zipkin的分布式请求跟踪和故障注入。Google强化了Envoy的安全性，性能和可扩展性有关的几个方面。Istio如何工作？提高了应用程序的流入和流出数据的可见性，无需大量配置和重新编程。Istio通过引入可编程路由和共享管理层，将不同的微服务转换为综合业务网格。通过将Envoy代理服务器注入到服务之间的网络路径中，Istio提供了复杂的流量管理控制，如负载平衡和细粒度路由。这种路由网格还能够提取关于流量行为的有关大量度量，可用于执行特定策略决策，例如细粒度访问控制和运营商可配置的速率限制。这些相同的指标也发送到监控系统。这样，它可以更好地了解应用程序数据的流入和流出，无需进行大量配置和重新编程，以确保应用程序的所有部件平稳而安全地工作。一旦我们控制了服务之间的通信，我们就可以在任何一对通信服务之间实施认证和授权。自动证书管理可通过相互TLS认证对通信自动保护。目前正在努力增加对常见授权机制的支持。Istio关键功能：1. HTTP / 1.1，HTTP / 2，gRPC和TCP流量的自动区域感知负载平衡和故障切换。2. 通过丰富的路由规则，容错和故障注入，对流行为进行细粒度的控制。3.支持访问控制，速率限制和配额的可插拔策略层和配置API。4. 集群内所有流量的自动量度，日志和跟踪，包括集群入口和出口。5.安全的服务与服务身份验证，在集群中的服务之间具有强身份标识声明。主要特点：1.流量管理. 控制服务之间的流量和API调用，使得服务调用更加可靠, 面对各种不良条件使得网络更加通信更健壮。2.可观察性. 能够清晰洞察各种服务调用依赖关系和流量的流向。3.策略增强. 能够将制定好的系统策略统一应用于服务之间交互，增强访问策略，保证资源能够被使用者公平分布使用，策略改变可通过配置网格实现，不需要改变应用代码。比如指定源调用者：destination: ratings.default.svc.cluster.localmatch: source: reviews.default.svc.cluster.local下面是在服务之间划分流量分配, v2版本25%流量，v1版本75%流量:destination: reviews.default.svc.cluster.localroute:- tags: version: v2 weight: 25- tags: version: v1 weight: 75下面是服务调用timeout和重试次数配置：destination: "ratings.default.svc.cluster.local"route:- tags: version: v1httpReqTimeout: simpleTimeout: timeout: 10sdestination: "ratings.default.svc.cluster.local"route:- tags: version: v1httpReqRetries: simpleRetry: attempts: 3下面是简单断路器实现：destination: reviews.default.svc.cluster.localtags: version: v1circuitBreaker: simpleCb: maxConnections: 1004.服务标识和安全. 为网格中服务提供可验证的身份标识，提供保护服务流量的能力。设想有一个三层应用程序，其中有三个服务：照片前端，照片后端和数据存储。照片前端和照片后端服务由照片SRE团队管理，而数据存储服务由数据存储SRE团队管理。照片前端可以访问照片后端，照片后端可以访问数据存储。但是，照片前端无法访问数据存储。在这种情况下，集群管理员创建3个命名空间：istio-ca-ns，photo-ns和datastore-ns。管理员可以访问所有命名空间，每个团队只能访问自己的命名空间。照片SRE团队创建了2个服务帐户，以分别在命名空间照片中运行照片前端和照片后端。数据存储SRE团队创建1个服务帐户以在命名空间datastore-ns中运行数据存储服务。此外，我们需要强制执行Istio Mixer中的服务访问控制，以使照片前端无法访问数据存储。在上述设置中，Istio CA能够为所有命名空间提供密钥和证书管理，并将微服务部署隔离开来。Istio架构一个Istio服务网格(service mesh)逻辑分为数据计划data plane和控制计划control plane.1. data plane是一系列智能代理(Envoy)，能够控制微服务之间的网络通信。2. control plane负责管理和配置代理的路由流量，能够在运行时动态运行各种策略。

下面谈谈Istio如何在服务网格中的服务实例之间平衡流量实现负载平衡的：服务注册： Istio假定已经存在服务注册表以跟踪应用程序中服务的pod / VM。它还假设服务的新实例自动注册到服务注册表，并且不健康的实例将被自动删除（也就是说Istio需要借助外界如Kubernete服务注册功能）。诸如Kubernetes，Mesos等平台已经为基于容器的应用程序提供了这样的功能。为基于虚拟机的应用程序提供了大量的解决方案。服务发现： Istio-Manager从服务注册表中消费信息，并提供与平台无关的服务发现文凭界面。网格中的Envoy实例执行服务发现，并相应地动态更新其负载均衡池。网格中的服务使用其DNS名称彼此访问。绑定到服务的所有HTTP流量都会自动通过Envoy重新路由。Envoy分布在负载平衡池中的实例之间的流量。虽然Envoy支持几种复杂的负载平衡算法，但Istio目前允许三种负载平衡模式：循环，随机和加权最小请求。除了负载平衡外，Envoy还会定期检查池中每个实例的运行状况。Envoy遵循断路器风格模式，根据健康检查API调用的失败率将实例分类为不健康或健康。换句话说，当给定实例的健康检查失败次数超过预定阈值时，它将从负载平衡池中弹出。类似地，当通过的健康检查数超过预定阈值时，该实例将被添加回负载平衡池。服务可以通过使用HTTP 503响应健康检查来积极减轻负担。在这种情况下，服务实例将立即从调用者的负载平衡池中删除。