深圳网站制作哪里济南兴田德润简介,wordpress主题偷,残疾人无障碍网站怎么做,怎么攻击网站Service Mesh新秀#xff0c;初出茅庐便声势浩荡#xff0c;前有Google#xff0c;IBM和Lyft倾情奉献#xff0c;后有业界大佬俯首膜拜#xff0c;这就是今天将要介绍的主角#xff0c;扛起Service Mesh大旗#xff0c;掀起新一轮微服务开发浪潮的Istio#xff01; 今天… Service Mesh新秀初出茅庐便声势浩荡前有GoogleIBM和Lyft倾情奉献后有业界大佬俯首膜拜这就是今天将要介绍的主角扛起Service Mesh大旗掀起新一轮微服务开发浪潮的Istio 今天的主角名叫 Istio估计很多同学在此之前可能完全没有听过这个名字。请不必介意没听过很正常因为Istio的确是一个非常新的东西出世也才四个月而已。 今天的内容将会分成三个部分: 介绍 让大家了解Istio是什么以及有什么好处以及Istio背后的开发团队 架构 介绍Istio的整体架构和四个主要功能模块的具体功能这块内容会比较偏技术 展望 介绍Istio的后续开发计划探讨未来的发展预期 一、介绍 Istio是什么Istio是Google/IBM/Lyft联合开发的开源项目2017年5月发布第一个release 0.1.0 官方定义为: Istio一个连接管理和保护微服务的开放平台。 按照isito文档中给出的定义: Istio提供一种简单的方式来建立已部署的服务的网络具备负载均衡服务到服务认证监控等等功能而不需要改动任何服务代码。 简单的说有了Istio你的服务就不再需要任何微服务开发框架典型如Spring CloudDubbo也不再需要自己动手实现各种复杂的服务治理的功能很多是Spring Cloud和Dubbo也不能提供的需要自己动手。只要服务的客户端和服务器可以进行简单的直接网络访问就可以通过将网络层委托给Istio从而获得一系列的完备功能。 可以近似的理解为Istio 微服务框架 服务治理 名字和图标 Istio来自希腊语英文意思是”Sail” 翻译为中文是“启航”。它的图标如下: 可以类比Google的另外一个相关产品Kubernetes名字也是同样起源于古希腊是船长或者驾驶员的意思。下图是Kubernetes的图标 后面会看到Istio和Kubernetes的关系就像它们的名字和图标一样 可谓”一脉相传”。 主要特性 Istio的关键功能: HTTP/1.1HTTP/2gRPC和TCP流量的自动区域感知负载平衡和故障切换。 通过丰富的路由规则容错和故障注入对流行为的细粒度控制。 支持访问控制速率限制和配额的可插拔策略层和配置API。 集群内所有流量的自动量度日志和跟踪包括集群入口和出口。 安全的服务到服务身份验证在集群中的服务之间具有强大的身份标识。 这些特性在稍后的架构章节时会有介绍。 为什么要使用Istio 在深入Istio细节之前先来看看为什么要使用Istio它可以帮我们解决什么问题? 微服务的两面性 最近两三年来微服务方兴未艾 可以看到越来越多的公司和开发人员陆陆续续投身到微服务架构 让一个一个的微服务项目落地。 但是在这一片叫好的喧闹中 我们还是发觉一些普遍存在的问题虽然微服务对开发进行了简化通过将复杂系统切分为若干个微服务来分解和降低复杂度使得这些微服务易于被小型的开发团队所理解和维护。但是复杂度并非从此消失。微服务拆分之后单个微服务的复杂度大幅降低但是由于系统被从一个单体拆分为几十甚至更多的微服务 就带来了另外一个复杂度微服务的连接、管理和监控。 试想 对于一个大型系统 需要对多达上百个甚至上千个微服务的管理、部署、版本控制、安全、故障转移、策略执行、遥测和监控等谈何容易。更不要说更复杂的运维需求例如A/B测试金丝雀发布限流访问控制和端到端认证。 开发人员和运维人员在单体应用程序向分布式微服务架构的转型中 不得不面临上述挑战。 服务网格 Service Mesh服务网格也有人翻译为”服务啮合层”。这貌似是今年才出来的新名词在2017年之前没有听过虽然类似的产品已经存在挺长时间。 什么是Service Mesh服务网格 Service Mesh是专用的基础设施层轻量级高性能网络代理。提供安全的、快速的、可靠地服务间通讯与实际应用部署一起但对应用透明。 为了帮助理解 下图展示了服务网格的典型边车部署方式 图中应用作为服务的发起方只需要用最简单的方式将请求发送给本地的服务网格代理然后网格代理会进行后续的操作如服务发现负载均衡最后将请求转发给目标服务。当有大量服务相互调用时它们之间的服务调用关系就会形成网格如下图所示 在上图中绿色方块为服务蓝色方块为边车部署的服务网格蓝色线条为服务间通讯。可以看到蓝色的方块和线条组成了整个网格我们将这个图片旋转90°就更加明显了服务网格呈现出一个完整的支撑态势将所有的服务”架”在网格之上 服务网格的细节我们今天不详细展开 详细内容大家可以参考网上资料。或者稍后我将会推出一个服务网格的专题单独深入介绍服务网格。 Istio也可以视为是一种服务网格 在Istio网站上详细解释了这一概念 如果我们可以在架构中的服务和网络间透明地注入一层那么该层将赋予运维人员对所需功能的控制同时将开发人员从编码实现分布式系统问题中解放出来。通常将这个统一的架构层与服务部署在一起统称为“服务啮合层”。由于微服务有助于分离各个功能团队因此服务啮合层有助于将运维人员从应用特性开发和发布过程中分离出来。通过系统地注入代理到微服务间的网络路径中Istio将迥异的微服务转变成一个集成的服务啮合层。 Istio能做什么? Istio力图解决前面列出的微服务实施后需要面对的问题。Istio 首先是一个服务网络但是Istio又不仅仅是服务网格: 在 Linkerd Envoy 这样的典型服务网格之上Istio提供了一个完整的解决方案为整个服务网格提供行为洞察和操作控制以满足微服务应用程序的多样化需求。 Istio在服务网络中统一提供了许多关键功能(以下内容来自官方文档) 流量管理控制服务之间的流量和API调用的流向使得调用更可靠并使网络在恶劣情况下更加健壮。 可观察性了解服务之间的依赖关系以及它们之间流量的本质和流向从而提供快速识别问题的能力。 策略执行将组织策略应用于服务之间的互动确保访问策略得以执行资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 服务身份和安全为网格中的服务提供可验证身份并提供保护服务流量的能力使其可以在不同可信度的网络上流转。 除此之外Istio针对可扩展性进行了设计以满足不同的部署需要 平台支持Istio旨在在各种环境中运行包括跨云 预置KubernetesMesos等。最初专注于Kubernetes但很快将支持其他环境。 集成和定制策略执行组件可以扩展和定制以便与现有的ACL日志监控配额审核等解决方案集成。 这些功能极大的减少了应用程序代码底层平台和策略之间的耦合使微服务更容易实现。 Istio的真正价值 上面摘抄了Istio官方的大段文档说明洋洋洒洒的列出了Istio的大把大把高大上的功能。但是这些都不是重点理论上说任何微服务框架只要愿意往上面堆功能早晚都可以实现这些。那关键在哪里 不妨设想一下在平时理解的微服务开发过程中在没有Istio这样的服务网格的情况下要如何开发我们的应用程序才可以做到前面列出的这些丰富多彩的功能? 这数以几十记的各种特性如何才可以加入到应用程序? 无外乎找个Spring Cloud或者Dubbo的成熟框架直接搞定服务注册服务发现负载均衡熔断等基础功能。然后自己开发服务路由等高级功能 接入Zipkin等Apm做全链路监控自己做加密、认证、授权。 想办法搞定灰度方案用Redis等实现限速、配额。 诸如此类一大堆的事情 都需要自己做无论是找开源项目还是自己操刀最后整出一个带有一大堆功能的应用程序上线部署。然后给个配置说明到运维告诉他说如何需要灰度要如何如何 如果要限速配置哪里哪里。 这些工作相信做微服务落地的公司基本都跑不掉需求是现实存在的无非能否实现以及实现多少的问题但是毫无疑问的是要做到这些绝对不是一件容易的事情。 问题是即使费力做到这些事情到这里还没有完运维跑来提了点要求在他看来很合理的要求比如说简单点的加个黑名单 复杂点的要做个特殊的灰度将来自iPhone的用户流量导1%到Stagging环境的2.0新版本…… 这里就有一个很严肃的问题 给每个业务程序的开发人员: 你到底想往你的业务程序里面塞多少管理和运维的功能? 就算你hold的住技术和时间你有能力一个一个的满足各种运维和管理的需求吗 当你发现你开始疲于响应各种非功能性的需求时就该开始反省了: 我们开发的是业务程序它的核心价值在业务逻辑的处理和实现将如此之多的时间精力花费在这些非业务功能上 这真的合理吗? 而且即使是在实现层面微服务实施时最重要的是如何划分微服务如何制定接口协议你该如何分配你有限的时间和资源 Istio 超越 spring cloud和dubbo 等传统开发框架之处 就在于不仅仅带来了远超这些框架所能提供的功能 而且也不需要应用程序为此做大量的改动 开发人员也不必为上面的功能实现进行大量的知识储备。 总结: Istio 大幅降低微服务架构下应用程序的开发难度势必极大的推动微服务的普及。个人乐观估计随着isito的成熟微服务开发领域将迎来一次颠覆性的变革。后面我们在介绍Istio的架构和功能模块时, 大家可以了解到Istio是如何做到这些的。 开发团队 在开始介绍Istio的架构之前, 我们再详细介绍一下Istio的开发团队, 看看背后的大佬。首先Istio的开发团队主要来自 Google IBM和Lyft摘抄一段官方八股 基于我们为内部和企业客户构建和运营大规模微服务的常见经验GoogleIBM和Lyft联手创建Istio希望为微服务开发和维护提供可靠的基础。Google和IBM相信不需要介绍了, 在Istio项目中这两个公司是绝对主力举个例子,下图是 Istio Working Group的成员列表 数一下, 总共18人10个google8个IBM。注意这里没有Lyft出现因为Lyft的贡献主要集中在Envoy。 Google Istio来自鼎鼎大名的GCP/Google Cloud Platform, 这里诞生了同样大名鼎鼎的 App Engine, Cloud Engine等重量级产品。 Google为Istio带来了Kubernetes和gRPC, 还有和Envoy相关的特性如安全性能和扩展性。 八卦: 负责Istio的GCP产品经理Varun Talwar 同时也负责gRPC项目, 所以关注gRPC的同学比如我自己可以不用担心Istio对gRPC的支持必然是没有问题的。 IBM IBM的团队同来来自IBM云平台, IBM的贡献是: 除了开发Istio控制面板之外, 还有和Envoy相关的其他特性如跨服务版本的流量切分, 分布式请求追踪(Zipkin)和失败注入。 Lyft Lyft的贡献主要集中在Envoy代理这是Lyft开源的服务网格基于C。据说Envoy在Lyft可以管理超过100个服务跨越10000个虚拟机每秒处理2百万请求。本周最新消息Envoy刚刚加入CNCF成为该基金会的第十一个项目。 最后 在Isito的介绍完成之后, 我们开始下一节内容Istio的架构。 二、架构 整体架构 Istio服务网格逻辑上分为数据面板和控制面板。 数据面板由一组智能代理Envoy组成代理部署为边车调解和控制微服务之间所有的网络通信。 控制面板负责管理和配置代理来路由流量以及在运行时执行策略。 下图为Istio的架构详细分解图 这是宏观视图可以更形象的展示Istio两个面板的功能和合作 以下分别介绍 Istio 中的主要模块 Envoy/Mixer/Pilot/Auth。 Envory 以下介绍内容来自Istio官方文档 Istio 使用Envoy代理的扩展版本Envoy是以C开发的高性能代理用于调解服务网格中所有服务的所有入站和出站流量。 Istio利用了Envoy的许多内置功能例如动态服务发现负载均衡TLS terminationHTTP/2gRPC代理熔断器健康检查基于百分比流量拆分的分段推出故障注入和丰富的metrics。 Envoy实现了过滤和路由、服务发现、健康检查提供了具有弹性的负载均衡。它在安全上支持TLS在通信方面支持gRPC。 概括说Envoy提供的是服务间网络通讯的能力包括(以下均可支持TLS) HTTP1.1 HTTP/2 gRPC TCP 以及网络通讯直接相关的功能 服务发现从Pilot得到服务发现信息 过滤 负载均衡 健康检查 执行路由规则(Rule): 规则来自Polit,包括路由和目的地策略 加密和认证: TLS certs来自 Istio-Auth 此外, Envoy 也吐出各种数据给Mixer: Metrics Logging Distribution Trace: 目前支持 Zipkin 总结: Envoy是Istio中负责”干活”的模块,如果将整个Istio体系比喻为一个施工队,那么 Envoy 就是最底层负责搬砖的民工所有体力活都由Envoy完成。所有需要控制决策管理的功能都是其他模块来负责然后配置给Envoy。 Istio架构回顾 在继续介绍Istio其他的模块之前我们来回顾一下Istio的架构前面我们提到, Istio服务网格分为两大块数据面板和控制面板。 刚刚介绍的Envoy在Istio中扮演的就是数据面板而其他我们下面将要陆续介绍的Mixer、Pilot和Auth属于控制面板。上面我给出了一个类比Istio中Envoy (或者说数据面板)扮演的角色是底层干活的民工而该让这些民工如何工作由包工头控制面板来负责完成。 在Istio的架构中这两个模块的分工非常的清晰体现在架构上也是经纬分明 MixerPilot和Auth这三个模块都是Go语言开发代码托管在Github上三个仓库分别是 Istio/mixer, Istio/pilot/auth。而Envoy来自Lyft编程语言是c 11代码托管在Github但不是Istio下。从团队分工看Google和IBM关注于控制面板中的MixerPilot和Auth而Lyft继续专注于Envoy。 Istio的这个架构设计将底层Service Mesh的具体实现和Istio核心的控制面板拆分开。从而使得Istio可以借助成熟的Envoy快速推出产品未来如果有更好的Service Mesh方案也方便集成。 Envoy的竞争者 谈到这里聊一下目前市面上Envoy之外的另外一个Service Mesh成熟产品基于Scala的Linkerd。 Linkerd的功能和定位和Envoy非常相似而且就在今年上半年成功进入CNCF。而在 Istio 推出之后Linkerd做了一个很有意思的动作Linkerd推出了和Istio的集成实际为替换Envoy作为Istio的数据面板和Istio的控制面板对接。 回到Istio的架构图将这幅图中的Envoy字样替换为Linkerd即可。另外还有不在图中表示的Linkerd Ingress / Linkerd Egress用于替代Envoy实现 k8s的Ingress/Egress。 本周最新消息 Nginx推出了自己的服务网格产品Nginmesh功能类似比较有意思的地方是Ngxinmesh一出来就直接宣布要和Istio集成替换Envoy。 下面开始介绍 Istio 中最核心的控制面板。 Pilot 流量管理 Istio最核心的功能是流量管理前面我们看到的数据面板由Envoy组成的服务网格将整个服务间通讯和入口/出口请求都承载于其上。 使用Istio的流量管理模型本质上将流量和基础设施扩展解耦让运维人员通过Pilot指定它们希望流量遵循什么规则而不是哪些特定的pod/VM应该接收流量。 对这段话的理解, 可以看下图假定我们原有服务B部署在Pod1/2/3上现在我们部署一个新版本在Pod4在希望实现切5%的流量到新版本。 如果以基础设施为基础实现上述5%的流量切分则需要通过某些手段将流量切5%到Pod4这个特定的部署单位实施时就必须和ServiceB的具体部署还有ServiceA访问ServiceB的特定方式紧密联系在一起. 比如如果两个服务之间是用Nginx做反向代理则需要增加Pod4的IP作为Upstream并调整Pod1/2/3/4的权重以实现流量切分。 如果使用Istio的流量管理功能, 由于Envoy组成的服务网络完全在Istio的控制之下,因此要实现上述的流量拆分非常简单. 假定原版本为1.0新版本为2.0只要通过Polit 给Envoy发送一个规则2.0版本5%流量剩下的给1.0。 这种情况下我们无需关注2.0版本的部署也无需改动任何技术设置, 更不需要在业务代码中为此提供任何配置支持和代码修改。一切由 Pilot 和智能Envoy代理搞定。 我们还可以玩的更炫一点, 比如根据请求的内容来源将流量发送到特定版本 后面我们会介绍如何从请求中提取出User-Agent这样的属性来配合规则进行流量控制。 Pilot的功能概述 我们在前面有强调说Envoy在其中扮演的负责搬砖的民工角色而指挥Envoy工作的民工头就是Pilot模块。 官方文档中对Pilot的功能描述 Pilot负责收集和验证配置并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节为他们提供独立于底层平台的用户服务的抽象表示。此外流量管理规则即通用4层规则和7层HTTP/gRPC路由规则可以在运行时通过Pilot进行编程。 每个Envoy实例根据其从Pilot获得的信息以及其负载均衡池中的其他实例的定期健康检查来维护 负载均衡信息从而允许其在目标实例之间智能分配流量同时遵循其指定的路由规则。 Pilot负责在Istio服务网格中部署的Envoy实例的生命周期。 Pilot的架构 下图是Pilot的架构图 Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy Envoy提供服务发现负载均衡池和路由表的动态更新的API。这些API将Istio和Envoy的实现解耦。(另外也使得Linkerd之类的其他服务网络实现得以平滑接管Envoy) Polit定了一个抽象模型以从特定平台细节中解耦为跨平台提供基础 Platform Adapter则是这个抽象模型的现实实现版本, 用于对接外部的不同平台 最后是 Rules API提供接口给外部调用以管理Pilot包括命令行工具Istioctl以及未来可能出现的第三方管理界面 服务规范和实现 Pilot架构中, 最重要的是Abstract Model和Platform Adapter我们详细介绍。 Abstract Model是对服务网格中”服务”的规范表示, 即定义在istio中什么是服务这个规范独立于底层平台。 Platform Adapter这里有各种平台的实现目前主要是Kubernetes另外最新的0.2版本的代码中出现了Consul和Eureka。 来看一下Pilot 0.2的代码pilot/platform 目录下: 瞄一眼platform.go 服务规范的定义在modle/service.go中: 由于篇幅有限代码部分这里不深入, 只是通过上面的两段代码来展示Pilot中对服务的规范定义和目前的几个实现。 暂时而言(当前版本是0.1.6, 0.2版本尚未正式发布)目前 Istio 只支持K8s一种服务发现机制。 备注: Consul的实现据说主要是为了支持后面将要支持的Cloud FoundryEureka没有找到资料。Etcd3 的支持还在Issue列表中看Issue记录争执中。 Pilot功能 基于上述的架构设计Pilot提供以下重要功能 请求路由 服务发现和负载均衡 故障处理 故障注入 规则配置 由于篇幅限制今天不逐个展开详细介绍每个功能的详情。大家通过名字就大概可以知道是什么如果希望了解详情可以关注之后的分享。或者查阅官方文档的介绍。 Mixer Mixer翻译成中文是混音器, 下面是它的图标 功能概括Mixer负责在服务网格上执行访问控制和使用策略并收集Envoy代理和其他服务的遥测数据。 Mixer的设计背景 我们的系统通常会基于大量的基础设施而构建这些基础设施的后端服务为业务服务提供各种支持功能。包括访问控制系统遥测捕获系统配额执行系统计费系统等。在传统设计中, 服务直接与这些后端系统集成容易产生硬耦合。 在Istio中为了避免应用程序的微服务和基础设施的后端服务之间的耦合提供了 Mixer 作为两者的通用中介层 Mixer 设计将策略决策从应用层移出并用配置替代并在运维人员控制下。应用程序代码不再将应用程序代码与特定后端集成在一起而是与Mixer进行相当简单的集成然后 Mixer 负责与后端系统连接。 特别提醒: Mixer不是为了在基础设施后端之上创建一个抽象层或者可移植性层。也不是试图定义一个通用的Logging API通用的Metric API通用的计费API等等。 Mixer的设计目标是减少业务系统的复杂性将策略逻辑从业务的微服务的代码转移到Mixer中, 并且改为让运维人员控制。 Mixer的功能 Mixer 提供三个核心功能 前提条件检查。允许服务在响应来自服务消费者的传入请求之前验证一些前提条件。前提条件包括认证黑白名单ACL检查等等。 配额管理。使服务能够在多个维度上分配和释放配额。典型例子如限速。 遥测报告。使服务能够上报日志和监控。 在Istio内Envoy重度依赖Mixer。 Mixer的适配器 Mixer是高度模块化和可扩展的组件。其中一个关键功能是抽象出不同策略和遥测后端系统的细节允许Envoy和基于Istio的服务与这些后端无关从而保持他们的可移植。 Mixer在处理不同基础设施后端的灵活性是通过使用通用插件模型实现的。单个的插件被称为适配器它们允许Mixer与不同的基础设施后端连接这些后台可提供核心功能例如日志监控配额ACL检查等。适配器使Mixer能够暴露一致的API与使用的后端无关。在运行时通过配置确定确切的适配器套件并且可以轻松指向新的或定制的基础设施后端。 这个图是官网给的列出的功能不多我从Github的代码中抓个图给大家展示一下目前已有的Mixer Adapter Mixer的工作方式 Istio使用属性来控制在服务网格中运行的服务的运行时行为。属性是描述入口和出口流量的有名称和类型的元数据片段以及此流量发生的环境。Istio属性携带特定信息片段例如 请求处理过程中属性由Envoy收集并发送给MixerMixer中根据运维人员设置的配置来处理属性。基于这些属性Mixer会产生对各种基础设施后端的调用。 Mixer设计有一套强大(也很复杂, 堪称Istio中最复杂的一个部分)的配置模型来配置适配器的工作方式设计有适配器、切面、属性表达式选择器、描述符manifests 等一堆概念. 由于篇幅所限今天不展开这块内容这里给出两个简单的例子让大家对Mixer的配置有个感性的认识: 1、这是一个IP地址检查的Adapter实现类似黑名单或者白名单的功能 2、metrics的适配器,将数据报告给Prometheus系统 3、定义切面, 使用前面定义的 myListChecker 这个adapter 对属性 source.ip 进行黑名单检查。 Istio-Auth Istio-Auth提供强大的服务到服务和终端用户认证使用交互TLS内置身份和凭据管理。它可用于升级服务网格中的未加密流量并为运维人员提供基于服务身份而不是网络控制实施策略的能力。 Istio的未来版本将增加细粒度的访问控制和审计以使用各种访问控制机制包括基于属性和角色的访问控制以及授权钩子来控制和监视访问您的服务API或资源的人员。 Auth的架构 下图展示Istio Auth架构其中包括三个组件身份密钥管理和通信安全。 在这个例子中, 服务A以服务帐户“foo”运行, 服务B以服务帐户“bar”运行, 他们之间的通讯原来是没有加密的. 但是Istio在不修改代码的情况, 依托Envoy形成的服务网格, 直接在客户端Envoy和服务器端Envoy之间进行通讯加密。 目前在Kubernetes上运行的 Istio使用Kubernetes service account/服务帐户来识别运行该服务的人员。 未来将推出的功能 Auth在目前的Istio版本(0.1.6和即将发布的0.2)中功能还不是很全未来则规划有非常多的特性 细粒度授权和审核 安全Istio组件Mixer, Pilot等 集群间服务到服务认证 使用JWT/OAuth2/OpenID_Connect终端到服务的认证 支持GCP服务帐户和AWS服务帐户 非http流量MySqlRedis等支持 Unix域套接字用于服务和Envoy之间的本地通信 中间代理支持 可插拔密钥管理组件 需要提醒的是这些功能都是不改动业务应用代码的前提下实现的。 回到我们前面的曾经讨论的问题如果自己来做完成这些功能大家觉得需要多少工作量要把所有的业务模块都迁移到具备这些功能的框架和体系中需要改动多少而Istio未来就会直接将这些东西摆上我们的餐桌。 三、未来 前面我们介绍了Istio的基本情况还有Istio的架构和主要组件。相信大家对Istio应该有了一个初步的认识。需要提醒的是Istio是一个今年5月才发布 0.1.0 版本的新鲜出炉的开源项目目前该项目也才发布到0.1.6正式版本和 0.2.2 pre release版本. 很多地方还不完善希望大家可以理解有点类似于最早期阶段的Kubernetes。在接下来的时间我们将简单介绍一下Istio后面的一些开发计划和发展预期。 运行环境支持 Istio目前只支持Kubernetes, 这是令人比较遗憾的一点. 不过 istio 给出的解释是istio未来会支持在各种环境中运行只是目前在 0.1/0.2 这样的初始阶段暂时专注于Kubernetes但很快会支持其他环境。 注意: Kubernetes平台除了原生Kubernetes, 还有诸如 IBM Bluemix Container Service和RedHat OpenShift这样的商业平台。 以及google自家的 Google Container Engine。这是自家的东西, 而且现在k8s/istio/gRPC都已经被划归到 Google cloud platform部门, 自然会优先支持. 另外isito所说的其他环境指的是: Mesos: 这个估计是大多人非K8s的Docker使用者最关心的了, 暂时从Github上的代码中未见到有开工迹象, 但是Istio的文档和官方声明都明显说会支持, 估计还是希望很大的. Cloud foundry: 这个东东我们国内除了私有云外玩的不多, Istio对它的支持似乎已经启动. 比如我看到代码中已经有了Consul这个服务注册的支持, 从Issue讨论上看到是说为上Cloud foundry做准备, 因为Cloud foundry没有k8s那样的原生服务注册机制。 VM: 这块没有看到介绍, 但是有看到Istio的讨论中提到会支持容器和非容器的混合(Hybrid)支持 值得特别指出的是目前我还没有看到Istio有对Docker家的Swarm有支持的计划或者讨论, 目前我找到的任何Istio的资料中都不存在Swarm这个东东。我只能不负责任的解读为有人的地方就有江湖有江湖就自然会有江湖恩怨。 路线图 按照Istio的说法他们计划每3个月发布一次新版本我们看一下目前得到的一些信息 0.1 版本2017年5月发布,只支持Kubernetes 0.2 即将发布,当前是0.2.1 pre-release, 也只支持Kubernetes 0.3 roadmap上说要支持k8s之外的平台, “Support for Istio meshes without Kubernetes.”, 但是具体哪些特性会放在0.3中,还在讨论中 1.0 版本预计今年年底发布 注: 1.0版本的发布时间官方没有明确给出我只是看到官网资料里面有信息透露如下: “we invite the community to join us in shaping the project as we work toward a 1.0 release later this year.” 按照上面给的信息简单推算应该是9月发0.2, 然后12月发0.3, 但是这就已经是年底了, 所以不排除1.0推迟发布的可能或者0.3直接当成 1.0 发布。 社区支持 虽然Istio初出江湖乳臭未干但是凭借google和IBM的金字招牌还有Istio前卫而实际的设计理念目前已经有很多公司在开始提供对Istio的支持或者集成这是Istio官方页面有记载的 Red HatOpenshift and OpenShift Application Runtimes PivotalCloud Foundry WeaveworksWeave Cloud and Weave Net 2.0 TigeraProject Calico Network Policy Engine DatawireAmbassador project 然后一些其他外围支持, 从代码中看到的: eureka consul etcd v3: 这个还在争执中,作为etcd的坚定拥护者, 我对此保持密切关注 存在问题 Istio毕竟目前才是0.2.2 pre release版本毕竟才出来四个月因此还是存在大量的问题集中表现为 只支持k8s而且要求k8s 1.7.4因为使用到k8s的 CustomResourceDefinitions 性能较低从目前的测试情况看0.1版本很糟糕0.2版本有改善 很多功能尚未完成 给大家的建议可以密切关注Istio的动向提前做好技术储备。但是最起码在年底的1.0版本出来之前别急着上生产环境。 结语 感谢大家在今天参与这次的Istio分享由于时间有限很多细节无法在今天给大家尽情展开。如果大家对 Istio 感兴趣可以之后自行浏览 Istio 的官方网站我也预期会在之后陆陆续续的给出Istio相关的文章和分享。 作者简介敖小剑十五年软件开发经验微服务专家专注于基础架构Cloud Native拥护者敏捷实践者。曾在亚信、爱立信、唯品会和ppmoney任职, 现任数人云资深架构师本文转自数人云微信公众号由数人云授权发布。
