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

今天,IBM和Google宣布推出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.local
match:
source: reviews.default.svc.cluster.local

下面是在服务之间划分流量分配, v2版本25%流量,v1版本75%流量:


destination: reviews.default.svc.cluster.local
route:
- tags:
version: v2
weight: 25
- tags:
version: v1
weight: 75

下面是服务调用timeout和重试次数配置:


destination: "ratings.default.svc.cluster.local"
route:
- tags:
version: v1
httpReqTimeout:
simpleTimeout:
timeout: 10s


destination: "ratings.default.svc.cluster.local"
route:
- tags:
version: v1
httpReqRetries:
simpleRetry:
attempts: 3

下面是简单断路器实现:


destination: reviews.default.svc.cluster.local
tags:
version: v1
circuitBreaker:
simpleCb:
maxConnections: 100

4.服务标识和安全. 为网格中服务提供可验证的身份标识,提供保护服务流量的能力。

设想有一个三层应用程序,其中有三个服务:照片前端,照片后端和数据存储。照片前端和照片后端服务由照片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响应健康检查来积极减轻负担。在这种情况下,服务实例将立即从调用者的负载平衡池中删除。

Istio


[该贴被banq于2017-05-25 20:18修改过]