【.com原稿】随着互联网技术的不断发展，各大互联网公司的系统越来越复杂，传统的系统架构越来越不能满足业务需求需求，取而代之的是微服务架构。目前比较流行的微服务架构有阿里的Dubbo、SpringCloud、苏宁的RSF框架。虽然以上技术已经比较成熟，可以很好的管理微服务系统，但是在使用以上框架管理微服务时，需要在业务代码中加入微服务治理相关的代码，导致业务人员无法专注于业务开发。还需要考虑微服务治理的解决方案，并将解决方案集成到其业务系统中。并且随着微服务治理方案的升级，相关业务代码也需要修改，这会增加相关业务开发人员的工作量。为了解决以上问题，Buoyant公司提出了ServiceMesh（服务网格）的概念。并于2016年1月15日发布，业界首个ServiceMesh项目（Linkerd）。服务网格是服务和底层网络之间的专用基础设施层。它让业务系统完全不用关心微服务的治理，只需要关注自己的业务逻辑。随着ServiceMesh技术的不断发展，越来越多的ServiceMesh产品层出不穷。在所有ServiceMesh产品中，Google/IBM联合开发的开源项目Istio是最好的ServiceMesh产品。接入Istio服务网格后，现有业务系统无需改动任何代码，即可具备流量管理、路由控制、服务降级等功能。sito服务网格的架构stio服务网格在逻辑上分为数据平面和控制平面。数据平面由一组智能代理（Envoy）组成，并作为边车部署，以调解和控制微服务之间的网络通信。控制面板负责管理和配置代理以路由流量。此外，控制面板配置Mixers以执行策略和收集数据。下图显示了构成每个面板的不同组件：Pilot为Envoysidecar提供服务发现，为智能路由提供路由管理。Pilot可以向每个Envoysidecars下发路由规则，通过Envoysidecars控制系统路由。此外，Pilot还公开了用于服务发现、负载平衡池和路由表动态更新的API。这些API使Envoy摆脱了平台特定的细微差别，简化了设计并提高了跨平台的可移植性。Mixer负责在服务网格上实施访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级别的属性，这些属性被发送到Mixer进行评估。Mixer包括一个灵活的插件模型，使Istio能够插入各种主机环境和基础设施后端，从这些细节中抽象出Envoy代理和Istio管理的服务。Citadel通过内置身份和证书管理提供强大的服务间身份验证和最终用户身份验证。Citadel可以升级服务网格中的未加密流量，并为运营商提供基于服务身份而非网络控制来执行策略的能力。Istio使用Envoy代理的扩展版本，这是一种用C++开发的高性能代理，可控制服务网格中所有服务的入站和出站流量。Istio利用了Envoy的许多内置功能：动态服务发现负载平衡TLS终止HTTP/2和gRPC代理断路器健康检查基于百分比的流量拆分故障注入丰富的指标文件并解压缩。添加到环境变量PATH，Istio的运行路径。确保需要的镜像已经下载并部署到集群中的机器上，安装前需要确保机器上已经安装了Docker环境。并确保部署文件istio.yaml或istio-auth.yaml中的镜像名称与下载的镜像一致。通过以下两种方式之一启动istio。在sidecar之间启用TLS双向认证（我们使用这种方法）：【运行命令】：kubectlapply-finstall/kubernetes/istio-auth.yaml禁用双向认证：【运行命令】：kubectlapply-finstall/kubernetes/istio.yaml5.安装验证istio启动成功后，启动其基本服务组件，包括istio-ingress、istio-mixer和istio-pilot，查看启动的istio服务：【运行命令】：kubectlgetsvc-nistio-system确认对应的pod部署成功，所有容器都启动运行：【运行命令】：kubectlgetpods-nistio-systemIsito服务网格的优势随着微服务的不断发展，Istio服务网络网格的使用场景越来越多。通过Istio服务网格的接入，解决了以下问题。随着公司业务的不断发展，公司内部出现了大量的Web应用。在不想修改代码的前提下，他们想加入面向服务的大家庭，享受各种服务管理能力。随着新技术的不断涌现和公司业务的快速发展，公司内部不同的业务系统会根据不同的场景选择不同的语言进行业务开发，比如Node.js、Go等不同的语言需要访问服务大家庭并享受管理各种服务的能力。随着业务的发展，微服务架构必须不断升级。基于Istio架构的微服务，业务系统和微服务架构是解耦的。因此，当微服务架构升级时，业务部门不需要做任何修正，从而减少业务部门的工作量。Istio在Pilot中配置路由规则，然后将路由规则发送给Envoy。Envoy根据路由规则，可以在不修改应用的情况下，实现应用灰度发布、熔断、扩缩容、故障注入等功能。这减少了开发和运维的工作量。通过Mixer的配置，Istio可以在不修改应用的情况下，为服务添加白名单和ACL检查，从而控制服务的访问。Istio的Citadel通过内置的身份和证书管理来保护服务之间的所有通信，而不会给开发人员带来繁琐的证书管理负担。作为基础设施层，Istio服务网格将微服务的治理与业务系统完全分离。从此，业务开发人员可以完全专注于业务系统的开发，而无需考虑微服务治理等问题。大大提高了业务开发人员的工作效率。同时，由于Istio是基础设施层，是轻量级高性能网络代理，对应用透明，运维人员可以依靠统一的规则进行维护，大大提高了运维人员的生产效率。同时也降低了业务开发人员和运维人员之间的沟通成本。Isito服务网格的不足虽然istio降低了应用服务与服务治理之间的耦合度，但用户可以专注于具体业务功能的实现，而无需过多考虑服务治理（如流量控制、负载均衡、故障处理等），提高了开发效率，而Istio通过高度的抽象和良好的设计，以一致的方式解决了灰度发布的问题。通过Pilot发布路由，然后Envoy处理流量转发，大大提高了运维的生产力。但是Istio还有一个很大的痛点，就是在高并发访问的时候，吞吐量无法满足苏宁大促的需求。上图中的模型用于对Istio进行压力测试，以验证Istio的吞吐量和稳定性。在高并发的情况下，Istio顶住了压力，充分保证了访问的正确性，没有出现丢包、请求失败、路由混乱等错误。然而，Istio的吞吐量并不理想。当通过HTTP访问服务时，吞吐量特别低。通过GRPC接入服务虽然性能有所提升，但仍不能完全满足苏宁大促期间的高并发需求。Istio在微服务治理方面的功能特性和灵活性，让Istio的魅力格外璀璨。目前，Istio也是开源社区最活跃的开源项目。苏宁将继续为Istio的发展贡献力量。相信在不久的将来，Istio在吞吐量方面的痛点可以被突破，满足苏宁大促的需求。Isito服务网格的引入目前，为适应新技术发展，提高资源利用率，苏宁正在大力推进公司内部系统从虚拟机向Kubernetes+Docker的结构转型。通过引入Kubernetes+Docker，为Istio提供了所需的基础设施。因此，我们将以此为契机，加快Istio系统在苏宁内部的推广，先在非大促系统推广。在社区和我们的共同努力下，当性能能够满足大促的需求时，Istio系统将被推广到大促。推广系统，让公司的所有系统都纳入到Istio的管理中。通过Istio的接入，群组内的所有服务都可以在不做任何修改的情况下享受各种服务治理能力。并且通过Istio的推广，在提升集团开发和维护效率的同时，也降低了业务上线出错的概率。[参考资料][1]https://istio.io/docs/reference/作者：林正国，苏宁易购IT总部数据云公司中间件研发中心高级技术经理，一直从事基础中间件的研发工作，拥有超过10年的中间件研发经验。目前主要负责苏宁基础中间件的开发和维护工作。深知基础中间件稳定性对电商平台的重要性，苏宁正努力不断提升苏宁中间件的稳定性和效率。【原创稿件，合作网站转载请注明原作者和出处为.com】
