原来使用的istio对应的版本为0.8，还只是在kubernetes没有落地的环境下使用，可以解决现在微服务框架下的服务注册与发现、身份验证与授权，熔断（过载保护），降级，流量控制等功能。

有人说“有了ISTIO，你的服务就不再需要任务微服务开发框架（springcloud ,dubbo的框架对服务治理，需要自己手动写程序处理）了！”

现在已发布了istio v1.0版本，并且官方说可以直接使用于生产环境，又基于我使用的是kubernetes环境，并且一直以为它是对kubernetes支持*好的，真是欣喜甚慰！

istio = 微服务框架 + 服务治理

istio的关键特性：

  • HTTP/1.1,HTTP/2,gRPC和TCP流量的自动区域感知和故障切换；
  • 路由规则丰富，容错和故障注入，对流行为提供细粒度控制；
  • 支持访问控制，速率限制和配额的可插拔和配置API；
  • 集群内所有流量的自动量度，日志和跟踪，包括 集群INGRESS和ENGRESS;
  • 安全的服务到服务身份验证；

没有service mesh前，微服务对运维带来了什么？

解耦的各个服务，可能多达几十上百个，怎么管理各个服务之间的连接，部署，版本控制，安全，故障转移，微略执行，遥测和和监控等，更不说常见的A/B测试。金丝雀发布 ，限流，访问控制，端对端认证。

痛点：

“找个Spring Cloud或者Dubbo的成熟框架，直接搞定服务注册，服务发现，负载均衡，熔断等基础功能。然后自己开发服务路由等高级功能， 接入Zipkin等Apm做全链路监控，自己做加密、认证、授权。 想办法搞定灰度方案，用Redis等实现限速、配额。 诸如此类，一大堆的事情， 都需要自己做，无论是找开源项目还是自己操刀，*后整出一个带有一大堆功能的应用程序，上线部署。然后给个配置说明到运维，告诉他说如何需要灰度，要如何如何， 如果要限速，配置哪里哪里。”—转载自数人云

service mesh是基础设施层，轻量级高性能网络代理，对应用透明。

 

%title插图%num

然，Istio也可以视为是一种服务网格。

  • 数据面板由一组智能代理（Envoy）组成，代理部署为边车（sidecar），调解和控制微服务之间所有的网络通信。
  • 控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。

istio的架构图如下：

 

%title插图%num

它让开发专注于业务逻辑的处理和实现！

关于对envoy,pilot,mixer,auth的各个模块的介绍，可去数人云了解。