认真考虑构建现代软件的人会在应用产品组合的某个部分使用微服务，而且还急需能够更轻松地运行微服务的工具和创新。正是这两条评述让Istio广受欢迎。
Istio是一个开源项目，1.0.0版本刚刚发布。Pivotal是这项技术的忠实粉丝，并为Istio做出了贡献，我们在各种开源项目以及我们的旗舰级商业产品中将Istio用作核心组件。
1.0.0版是一个非常重要的里程碑，促使我们反思。本文将详细介绍Istio及其解决的问题，以及Pivotal与Istio之间的紧密关系。
微服务：所有生活问题的原因和解决方案
微服务是一种复杂的模式，然而它却非常普及。其原因何在？微服务能够实现工程团队努力渴求的目标，即上线速度、可扩展性和灵活性。微服务增加的复杂性通常物有所值。
开源社区对于微服务的兴起也是贡献良多。社区里有上百个项目确保微服务采用者的工作变得更轻松。Istio用于简化微服务的连接、管理和保护，是社区里最突出的项目之一。
原因显而易见。网络连接通常是微服务最棘手的环节。毕竟，基于IP的网络架构和微服务的架构是背道而驰的。为了填补两者之间的缺口，开发人员必须自己实施服务发现、部署断路器、并使其他模式生效。他们必须添加健康检查、处理内部安全性，并实施策略控制。当然，自从NetflixOSS于2011年发布后，在Java中执行这些任务变容易了。（最近，Steeltoe对.NET.也起到了同样的作用。）但仍有额外的依赖关系需要处理，而且如果使用其他语言（比如Node.js和Go）要怎么办呢？
这正是Istio的用武之地。它可以利用进程外代理处理这些功能。您不需要更改应用的代码。此外，Istio支持多语言。任何语言都可以通过这个服务网格获益。我们来深入了解一下它的工作原理。
为何使用服务网格？因为我们无法更改网络
当代网络使得微服务的实现趋于复杂。（这就是为何Spring Cloud Netfix和其它工具如此有用。）Istio另辟蹊径，简化了微服务——它使用Sidecar代理将更高级别的逻辑推送到网络。使用Istio，就是让代理和网络为您完成工作！
我们用三张简单的图片来说明具体情况。
现状：直接通信
下面是当今微服务的通信模式。各个服务在微服务工具的帮助下直接通信。
资料来源：利用Istio连接所有抽象
Sidecar代理
现在好戏开始了。我们推出了Sidecar代理(SC)，该代理“诱使”服务觉得它们在进行直接通信。但实际上，它们在与代理通信。这样一来，网络可以完成安全保障、服务发现和其他开发人员在直接模式中所担心的任务。这个代理网就是您的新数据平面。
资料来源：利用Istio连接所有抽象
Istio（即控制平面）管理代理和您的业务逻辑
现在，我们让这些代理与服务同时运行。只需一个控制平面，即可管理它们。这就是Istio。
资料来源：利用Istio连接所有抽象
想要进一步了解Istio的过去、现在、未来？请观看这个由 Pivotal 的Ramiro Salas和谷歌的Laurent Demailly带来的讲座。
Istio对您的意义
之前，我们提到Istio是一种用于连接、管理和保护微服务的开放式方法。我们在谷歌的朋友介绍了Istio如何提供帮助：
借助跟踪、监控和日志记录等功能，Istio让您了解所有服务的性能及其影响其他进程的方式，使您能够迅速检测并解决问题。它还提供了审计和合规所必需的深度日志记录和可见性。
Istio让您能够管理和控制各个服务之间的流量和API调用，同时让您了解流量的状况。这意味着您可以提前识别并解决问题，提高调用的可靠性和网络的稳健性。无论您面临哪些情况，都可以放心无虞。
Istio首先具有强大的身份验证能力，该能力基于不可重复的身份，可防止来自被破解系统的重播攻击。Istio提供灵活的授权策略，基于身份或IP等任意请求属性实现微分段。此外，Istio还让安全管理员能够利用策略在传输过程中实施加密，不需要对应用做出任何更改。因此，利用Istio，安全管理员可以提供强有力的安全保障，同时开发人员可以专注于应用逻辑。
听起来不错，对吧？如何在日常工作中使用Istio呢？平台运维人员需要花时间管理控制平面。但如果我们在Pivotal做好工作，开发人员就不必详细了解Istio，甚至不必知道它的存在。
Istio可以帮助您利用软件实现更好的业务成果。但这应是您无需担心的实施细节。正如Casey West所言，您的首席执行官不会说“服务网格用得不错！”
我在#oscon伦敦的演讲幻灯片中说到过，“首席执行官永远都不会说：云中的事情不重要”https://t.co/9WOwoQob8k
——
Casey West (@caseywest) 2016年10月17日
Pivotal将Istio添加到重要的抽象
最棒的科技都是无形的。这正是抽象的强大之处。对于Istio和服务网格，您只希望微服务尽可能少地处理琐碎的工作。因此，只要条件允许，您的微服务所用的抽象中就应该嵌入Istio。这样一来，您就可以受益于服务网格，无需处理管道工作。
这就是Pivotal正在做的事情。我们将Istio视为重要开源项目和我们旗舰级商业版产品的核心，并且把它嵌入所有对现代企业来说至关重要的抽象：应用平台和Kubernetes以及函数。
Cloud Foundry中的Istio
关于我们如何将Istio嵌入应用平台，共有四个议题。
这于2月在Cloud Foundry(CF)中完成，此后不久便添加到了Pivotal Cloud Foundry。负责Cloud Foundry中路由的项目经理Shannon Coen描述了成果：
Cloud Foundry将为每个容器自动生成必要的证书，定期轮换证书，并使用它们为来自Gorouter的流量明晰地终止TLS。这项工作代表了我们与Envoy的首次集成，（Envoy是在Lyft开发的一个功能丰富的代理，最近贡献给了CNCF），并为将来在Cloud Foundry中以Istio为导向的多语言服务网格功能奠定了基础。启用此功能后，Cloud Foundry在每个应用容器中运行一个Envoy代理来终止TLS，提高容器资源配额，避免对应用产生任何影响。
Shannon继续解释了这项功能为何很重要：
安全性增强：
Gorouter将通过TLS对进入应用容器的流量进行加密。
恢复能力增强：
Gorouter将忽略应用路由的TTL，从而保证在路由控制平面出现故障时，您的应用仍可使用。
一致性增强：
Gorouter将使用TLS握手中提供的证书，在转发HTTP请求之前验证应用实例的身份。优化可用性增加了错误路由的风险，原因在于，健康的Diego会继续重新创建容器以保证应用的正常运行，而端口重复使用的可能性又非常大；因而此机制增强了对错误路由的防护。
而这一切都不会增加应用开发人员的负担！
我最喜欢的是最后一点。就像其他平台技术一样，Istio应该正常运转。
如果您想了解更多技术详情，不要错过Eric Malm的优秀文章，这篇文章将带您了解实施的核心：
最近收到了大量关于@PivotalCF如何将@EnvoyProxy用于透明的TLS（一直到应用容器）的问题，为此我写了一篇博客文章：https://t.co/xZVaVSkgkk pic.twitter.com/hXYSdyIbYp
——Eric Malm (@emalminator) 2018年4月5日
议题1已经完成。现在，CF路由团队将在Cloud Foundry中使用Istio和Envoy增强入口路由（即南北向流量）。这项工作将帮助我们满足客户的几个需求。（请参阅OSS提案了解全面的总结）。
您将看到这项工作带来的第一个功能是权重路由。开发人员可以轻松为一个路由控制发送到“已映射”应用的请求百分比。使用权重路由可以轻松完成新版本发布，测试新版本的流量。这在一定程度上是对A/B测试和蓝绿部署进行更高级别的控制。期待接下来几个月在开源Cloud Foundry中看到这些功能。
第2个议题还包含将Istio试点项目用于路由更新。到目前为止，您可能想知道Istio和Envoy能否在Cloud Foundry的现有路由层取得成功。答案是一定可以！
随着时间推移，Istio和Envoy最终将取代现有路由组件Gorouter、NATS、TCP Router和路由API。但在近期，基于Istio的新方法和现有机制将实现共存。
东西向流量也可以从Istio中获益。应用到应用和应用到服务的流量将结合mTLS使用Envoy。我们还将使用Istio和Envoy Sidecar提供平台托管及客户端的负载均衡。此模式无需应用开发人员为这些函数处理麻烦的代码库（比如Ribbon）。
思考安全策略时，您可能会想到几件事。基于IP的简单规则。身份和访问管理(IAM)。PCF可帮助您利用应用安全组和容器网络连接管理网络策略。单点登录服务可为您的用户锁定应用访问权限。但如果拓展思路会怎样？
Istio可以提供可能性非常诱人，因此策略可能变得更有意义。利用Istio，我们关于策略的定义可以扩展为基于复杂的自定义业务逻辑的访问权限监管。例如，您可以轻松地限制一组员工在特定时间段内对特定应用的访问权限。或者，您可以实施方法级别的安全性。在这种情况下，您将控制谁可以针对RESTful API执行GET、PUT、POST和DELETE操作。
Istio提出了策略系统可插性的承诺。但常言道，能力越大，责任越大。Pivotal的使命是在Istio中提供“刚刚好”的策略语法，既可以适合企业场景，又不会增加冗余的复杂性。我们正积极研究如何最好地做到这一点。但别搞错：Istio将是Pivotal在微服务和平台本身上执行安全策略的核心。敬请关注！
Pivotal以及我们对Istio的贡献
在集成Istio和Cloud Foundry上的所有工作使Pivotal看到了做出重要贡献的机会。这涉及两个方面。
网关资源
网关使您能够在面临不同于上述Sidecar场景的要求时配置边缘网关路由器。Istio团队已经在考虑这个概念，CF路由团队只是加快了此功能的交付。
针对Istio试点项目的网格控制协议(MCP) API即将推出
针对试点项目的MCP API的作用就是简化配置。此API让跨Istio组件部署配置变得更加简单。此外，MCP API通过Kubernetes API的替代方案让配置试点项目变得更加简单。因此，CF和Istio的集成变得更快、更简单。事实上，Cloud Foundry社区成员可以更新MCP兼容的集成组件而无需更改试点项目。MCP将与Galley一起运行。
为什么会这样呢？Istio社区希望将Galley用于配置。他们注意到CF社区成员为试点项目贡献了一批代码，以满足Cloud Foundry的特定需求。Istio团队随即决定推出我们都可以使用的API。这是正确的策略。CF路由团队称赞了这一想法，主动提出帮助实施。
网格控制协议(MCP)是一个标准API，可供Cloud Foundry、Kubernetes和Istio团队使用。MCP可跨多个平台，管理多重组件的多个配置文件。您可以随时在各种抽象上使用相同的模式，这对社区和企业开发人员来说是巨大的胜利。（例证如下：Open Service Broker API。）
展望未来：Kubernetes和Knative中的Istio
Kubernetes和Pivotal 容器服务
开发人员可能会自然而然地将Istio和Kubernetes结合使用，但这种额外的运维负担是有代价的。除非您的核心业务是构建和销售平台，否则就是在浪费时间和金钱。最优秀、最聪明的工程师应该带来独特的业务价值，而不是连接开源组件。（这就是我们提防DIY途径的原因。）
当然，Pivotal的业务就是构建和销售平台。我们让Pivotal Container Service中的Kubernetes群集为Istio做好准备（PKS是Pivotal推出的Cloud Foundry Container Runtime商业发行版）。以下是具体方式。
Pivotal在PKS的CI/CD中随附了Istio。每个新版本PKS（1.1.1、1.1.2等）都将帮助您创建“Istio就绪”的Kubernetes群集。这是一项基本功能，能够让PKS用户随时间推移获得更多Istio功能。
Knative、riff和Pivotal 函数服务
新鲜问世！Knative是一个新的开源项目，由来自谷歌、Pivotal和其他行业领导企业的工程师发起。它是一个扩展Kubernetes和Istio的组件集合。该项目旨在简化在云上运行函数的方式。
此项目刚刚被Google Cloud Next推出（在这里和这里阅读全部内容）。请参阅这张由谷歌的Mark Chmarny提供的有用图片：
资料来源：在Kubernetes上使用Knative构建、部署和管理现代无服务器工作负载
在商业版方面，即将推出的Pivotal Function Service (PFS)将采用Knative和riff。
一些riff组件迁移到了Knative，另外一些组件保持独立
这些开源和商业版产品还处于初期阶段。但无论哪种情况，都不难看出Istio的功能是如何从开发人员中抽离的。工程师可以高兴地专注于业务逻辑，让Knative、riff和PFS完成其余工作。
成果，更多的成果
2018年分布式系统采用的技术已然不同于2008年的技术。企业领导者的使命就是与合适的战略伙伴合作，以帮助您了解风云变幻的云计算世界。即使随时间推移，底层技术不断发展和变化，提供更高级别的抽象，始终希望获得卓越的业务成果。
这正是Pivotal为客户提供的优势，也是我们为何看好Istio和Envoy的未来。我们热衷于让它成为我们产品的核心，以便您可以集中精力编写出色的软件。
本文分享自微信公众号 - LFAPAC（gh_8442c14fe49e）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4254703/blog/4610652