在生产中使用Istio，咱们学到了什么？

首先，给你们简单介绍一下Istio，Istio是一个Service Mesh的开源框架，来自Google，大部分使用Go语言来开发，是Service Mesh的集大成者。

Istio数据层面主要使用envoy，Istio开发了一些 filter 扩展envoy的功能，这些功能主要集中在mixer上。Istio是新鲜出炉的技术，2017年5月0.1 release版本横空出世，不过版本更新迭代很快，最新的版本是今年3月发布的，1.1.3版。

Istio简介

Istio在逻辑架构上由数据平面和控制平面组成。数据平面是经典的实现方式，由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理能够调节和控制微服务及 Mixer 之间全部的网络通讯。

在每个容器中注入了一个sidecar，Istio的sidecar称之为Istio proxy，至关于envoy 加上Istio开发的envoy filter。Istio proxy能够拦截整个容器的入口和出口流量。根据sidecar从数据层面接受到的规则和策略，进行一系列对于网络流量的配置和管理，好比路由管理，加密，遥测数据收集。控制平面负责管理和配置代理来路由流量，此外，控制平面还配置 Mixer 以实施策略和收集遥测数据。

Istio有几大块功能，首先是流量控制，这个基本上是经过Istio里的pilot组件来实现的。从图上咱们能够看到，rules api就是pilot提供的抽象API，用户经过api来配置相应的规则。Paltform Adapter主要是兼容不一样的平台。用户针对不一样的平台实现服务发现等功能。基于用户的规则和从平台收集的数据，经过envoy api把具体的规则下发到各个容器的Istio proxy。 这里实现了大部分咱们须要的流量管理功能，例如负载均衡策略，路由控制。咱们能够把原本发给服务A的请求，都导向另外一个服务。 故障注入，为测试进行模拟。以及熔断，url重写，重试，超时等等。

Istio的第二块，主要是安全机制。咱们能够对网格内的微服务通信进行tls加密。在发起请求的Istio proxy对请求使用tls证书加密，在接受请求的Istio proxy对这个请求解密，这对于应用的开发者是无感的。Istio最优秀的地方就是对于业务开发者的基本无感。这些网络调用相关的功能和策略被抽离出来，不用再放在应用的代码里。

Istio还提供了相似k8s rbac的权限实现方式。在servicerole定义使用service api的权限，经过service role binding绑定在k8s service account上，而后当应用经过service accout启动后, 该应用就有service role里定义的访问其余服务的权限。

下面一块是策略和遥测，这个是Istio中争议很是大的一个功能。好的方面是设计很是干净。Istio proxy只须要把它收集到的attribute发给mixer，mixer的Adapter基于attribute来作相应的操做。一类attribute用来作策略检查，例如Qouta，另外一类用来作遥测数据收集，如promothues。 这其中体验很差之处就在策略检查上面。由于每一个请求都须要作这个检查，这个检查目前看来会影响总体的性能。1.1开始，Istio提供了简单的方式能够关闭全局这个检查。若是你对性能要求比较高，目前最好仍是先关闭。

Istio 1.1的发布对性能进行了大幅优化。官方提供的数据是：1000 k8s service， 2000个sidecar，每秒70000个请求在这个mesh网格中。这时候每一个proxy使用0.6个CPU，50M内存来支持每秒1000个请求。Istio的遥测，就是mixer须要0.6个cpu来支持每秒1000次的请求。这个地方并无说是否是包括策略检查。我感受是不包含的。pilot须要1个cpu和1.5G的内存来作服务下发。最后，Istio proxy对服务间调用的性能影响是tp90 8ms。

微服务体系带来的问题

原来的微服务体系中都面临哪些难题呢？

首当其冲是定位和调试困难。当遇到bug或者性能问题，原来的方式基本都是逐级排查，从客户遇到问题的地方开始。由于一个深层次的微服务会引发一系列的上层微服务出现问题。若是发现两个服务直接之间的总体调用性能很差，这个时候哪怕你找到某一次性能差的日志或数据，基于这个数据和日志找出来的缘由不必定是root cause。这种排查问题的方式就像烽火台，你只看到了最近的烽火台，并不知道起点在哪。

第二，测试时数据会有遗漏，缺乏完整的测试数据。

最好的测试数据是线上的真实数据。可是线上的请求采集下来还须要独立开发相应的程序，总体实现很麻烦。另外，若是测试微服务的错误处理，对于QA的黑盒测试来讲，这还须要一个可配置的错误生成器。这点对于测试也是一个独立的工做。

第三，缺乏上线流程。

咱们原来使用独立的微服务做为开关，来判断是否加载新功能。在新的功能代码外层加上调用该微服务的代码，根据返回值来判断是否执行新功能代码，上线完成后再把开关代码删掉，的确有点麻烦。上线前须要修改源码增长控制，上线完成后还须要在源码中删除这些逻辑。没有简单、无侵入的金丝雀和灰度发布的实现方式。

第四，微服务间的网络调用策略配置不灵活。

不一样的客户环境须要使用不一样的网络策略，例如重试，超时等等设置，若是对应的设置没有经过配置文件暴露出来，就只能对代码进行修改。并且这些代码在业务代码里，统一的维护和升级都须要独立的流程。

灵雀云ASM如何解决上述问题？

灵雀云从去年就开始有针对性地在ASM产品中解决这些问题。下面是咱们ASM的整体架构图：

ASM controller是咱们开发的K8s controller，主要处理咱们本身定义的crd，以及作一些自动化的K8s资源处理；Dablo是ASM的前端界面；controller和diablo都会直接和K8s api server来通信；Istio gateway是Istio用来服务南北流量的接口，主要用来暴露集群里的微服务；jaeger分为collector和query；collector直接从Istio proxy收集上报的调用链路数据，目前数据格式仍是用的zipkin，jqeger query是用来显示调用链路的；为了作namespace的数据隔离，咱们对jaeger的组件都作了相应的改造；存储方式是ES；遥测数据用prometheus来存储，数据从mixer收集而来；diablo经过直接调用prometheus api来获取。

关于定位和调试，灵雀云主要经过两方面来解决：一方面使用promothues里的遥测数据来绘制实时的拓扑图。展现调用关系，以及调用数据，包括流量，性能，错误率等。另外一方面，经过jaeger的调用链来解决。咱们能够查看完整的调用链路，具体到某次调用的时候，请求的内容，以及返回的状态码。

下面是咱们预览版产品中的一些截图。这个截图来自于灵雀云PaaS平台的数据。咱们能够看到整个平台全部组件之间的调用关系，右边是某两个组件之间的调用数据，包含调用次数，rps，以及响应时间这样的性能指标。这些能够帮助咱们快速作定性的判断。

后面两张图是咱们嵌入的jaeger query组件。当前面作了定性判断后，这里能够查询具体的问题是什么，经过过滤条件来缩小范围，而后具体看某一个请求的详细信息。

为了使用Istio这些功能，须要作些什么配置呢？
1．全部的微服务中注入sidecar；
2．pod里的container声明了本身监听的端口，保证可以拦截入口流量；
3．pod的label须要app和version两个key；

1. K8s service里声明的port都必须包含name字段，根据使用的协议name的格式有必定的规则。例如使用是http协议，name能够为http或者以“http-”开头；

5．服务调用的代码须要作稍微的改造，须要获取上一个请求header里的一些字段，包括request id,trace_id, span_id。把他们设置在header中传递给下一个调用。这个在Istio官方的文档里能够找到。
除了最后须要对代码作少量的修改，前面都只是须要修改服务部署的yaml。

经过Istio提供的流量镜像功能，咱们能够很容易的使用生产环境来测试新的代码。只须要把测试代码经过一个独立的应用直接发布到生产环境，而后经过配置把流量拷贝一份调用这个测试代码的应用就行了。

Istio的错误注入功能很容易模拟返回错误的状态码，增长请求返回的延迟。

在安全上线方面，在生产环境同时发布新、老版本，经过拓扑图和调用链的数据，来观测新版本是否能够正常工做。咱们经过流量的权重来实现灰度发布，经过一些规则设置来实现金丝雀发布。加上前面的生产环境测试，对于安全上线提供了很大的保证。

最后，灵活的网络策略。经过istio的Virtual Service和Destination Rule这两种资源，实现灵活的配置微服务间的网络访问策略。终于不用把这些策略的配置写到咱们的代码里来，Istio的virtual service和destiinatio rule就彻底实现了。