华尔街见闻Istio生产实践

随着见闻业务不断增加，所涉及语⾔也越来越多。由于微服务化的引入，就需要为不同语言开发各自的服务发现、监控、链路追踪等组件，更新运维成本较高。同时应用的灰度部署也是见闻在着⼒解决的问题。Istio通过下沉基础设置，很好的解决了组件跨语言兼容问题， 同时带来了智能路由、服务熔断、错误注入等重要的特性。整个搭建过程中也遇到了很多坑和经验，希望和大家分享。
见闻开发团队以Golang为主，同时存在Python，Java服务，这就需要SRE提供更容易接入的微服务基础组件，常见的方案就是为每种语言提供适配的微服务基础组件，但痛点是基础组件更新维护的成本较高。
为了解决痛点，我们将目光放到服务网格，它能利用基础设施下沉来解决多语言基础库依赖的问题，不同的语言不需要再引入各种不同的服务发现、监控等依赖库，只需简单的配置并运行在给定的环境下，就能享有服务发现、流量监控、链路追踪等功能，同时网络作为最重要的通信组件，可以基于它实现很多复杂的功能，譬如智能路由、服务熔断降级等。
我们调研了一些服务网格方案，包括Istio、Linkerd。
对比下来，Istio拥有更多活跃的开源贡献者，迭代速度快，以及Istio架构可行性讨论，我们选择Istio作为实践方案。
服务网格架构图：
这张图介绍了华尔街见闻典型的服务网格架构，左半图介绍了用户请求是如何处理，右半图介绍运维系统是如何监控服务。

架构可行性

通过架构图，我们拆分出以下关键组件，经过评估，Istio高度模块化、可拓展，各个组件的可用性、拓展性都有相应的策略达到保障，我们认为Istio是具有可实施性的。
Istio Ingress高性能，可拓展
性能：Istio Ingress用来处理用户入流量，使用Envoy实现，转发性能高。
可用性：保证实例数量并使用服务探活接口保证服务可用性。
拓展性：挂载在负载均衡后，通过增加实例实现可拓展。
Istio Proxy随应用部署，轻微性能损耗，可随应用数量拓展
Istio Proxy以Sidecar形式随应用一起部署，增加2次流量转发，存在性能损耗。
性能：4核8G服务器，上面运行Proxy服务和API服务，API服务只返回ok字样。（此测试只测试极限QPS）
单独测试API服务的QPS在59k+，平均延时在1.68ms，CPU占用4核。通过代理访问的QPS6.8k+，平均延时14.97ms，代理CPU占用2核，API服务CPU占用2核。
CPU消耗以及转发消耗降低了QPS，增加了延时，通过增加机器核数并增加服务部署数量解决该问题，经过测试环境测试，延时可以接受。
可用性：基于Envoy，我们认为Envoy的可用性高于应用。依赖Pilot Discovery进行服务路由，可用性受Pilot Discovery影响。
拓展性：Sidecar形式，随应用数拓展。
Istio Policy服务可拓展，但同步调用存在风险
Istio Policy需要在服务调用前访问，是同步请求，会增加服务调用延时，通过拓展服务数量增加处理能力。属于可选服务，华尔街见闻生产环境未使用该组件。
性能：未测试。
可用性：若开启Policy，必须保证Policy高可用，否则正常服务将不可用。
拓展性：增加实例数量进行拓展。
Istio Telemetry监控收集服务
性能：从监控上观察Report 5000qps，使用25核，响应时间p99在72ms。异步调用不影响应用的响应时间。
可用性：Telemetry不影响服务可用性。
拓展性：增加实例数量进行拓展。
Pilot Discovery
性能：服务发现组件（1.0.5版本）经过监控观察，300个Service，1000个Pod，服务变更次数1天100次，平均CPU消耗在0.04核左右，内存占用在1G以内。
可用性：在服务更新时需要保证可用，否则新创建的Pod无法获取最新路由规则，对于已运行Pod由于Proxy存在路由缓存不受Pilot Discovery关闭的影响。
拓展性：增加实例数量可以增加处理量。