Istio：用于微服务的服务啮合层

Google、IBM和Lyft开源了微服务管理、保护和监控框架Istio。Istio为希腊语，意思是“启航”。

微服务简化了开发，它将创建复杂系统的任务切分为数十乃至上百个小服务，这些小服务易于被小型的软件工程师团队所理解和修改。但是微服务并未真正地消除复杂性，而是将复杂性迁移到对大量服务的连接、管理和监控上。其中涉及对上百个服务的管理、处理部署问题、版本控制、安全、故障转移、策略执行、遥测和监控等，实现它们并非易事。Istio力图去解决这些问题。

按Google的提法，Istio是“架构的一层，处于服务和网络间”，它“通常连同服务部署一起，统称为服务啮合层（Service Mesh）”。在Istio网站上，详细解释了“服务啮合层”这一概念：

如果我们可以在架构中的服务和网络间透明地注入一层，那么该层将赋予操作人员对所需功能的控制，同时将开发人员从编码实现分布式系统问题中解放出来。通常将该统一的架构层与服务部署一起，统称为一个“服务啮合层”。由于微服务有助于分离各个特性团队（Feature Team），因此服务啮合层有助于将操作人员从应用特性开发和发布过程中分离出来。通过系统地注入代理到微服务间的网络路径中，Istio将迥异的微服务转变成一个集成的服务啮合层。

Istio可在任何云上或私有的环境中运行。虽然首个测试版（即0.1版）是运行于Kubernetes上的，但并非必须如此。Istio的主要特性包括：

HTTP、gRPC和TCP网络流量的自动负载均衡； 提供了丰富的路由规则，实现细粒度的网络流量行为控制； 流量加密、服务间认证，以及强身份声明； 全范围（Fleet-wide）策略执行； 深度遥测和报告。

Istio的底层使用了Envoy。Envoy是Lyft于去年九月份开源的一种服务代理和通信总线，已用于生产系统中，“管理了上万台虚拟机间的一百多个服务，每秒可处理近两百万次请求”。在近期的GlueCon 2017大会上，来自IBM的Shriram Rajagopalan和来自Google的Louis Ryan介绍了Istio的技术细节（PDF）。下图给出了系统的高层图解：

Envoy实现了过滤和路由、服务发现、健康检查，提供了具有弹性的负载均衡。它在安全上支持TLS，在通信方面支持gRPC，支持MongoDB和DynamoDB分析器对数据库访问统计信息的采集，以及更多功能。Envoy用C++ 11编写实现，并测试了使用C++、Go、Java、PHP和Python编写的微服务，也支持使用其它的语言。Istio还实现了应用和网络的监控，可在Prometheus和Grafana中查看。Istio还可以集成Zipkin，对延迟问题进行诊断。

Istio支持团队计划将其与Google Cloud Endpoints和Apigee集成。此外，Red Hat、Pivotal、Weaveworks、Tigera和Datawire也有兴趣将自身的产品与Istio集成。在Istio的路线图中，给出了未来将提供功能的更多细节。Istio 1.0版计划于今年下半年发布。

本文转自d1net（转载）

基于阿里云 ASK 的 Istio 微服务应用部署初探 本文会通过在 ASK 上试用 Istio 部署微服务应用的方式，来验证 ASK 对标准 Kubernetes 的兼容性。Istio 作为 Service Mesh（服务网格）的领导解决方案，一方面本身足够复杂具有代表性，另一方面它也代表了云原生时代微服务架构的趋势具有参考意义。
Istio 从懵圈到熟练：二分之一活的微服务 Istio 的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。