架构不止-严选Service Mesh架构的持续演进

​

Maslow/王育松（网易严选技术团队）

同严选的业务同样，在下层承载它的IT系统架构同样要生存、呼吸、增加和发展，不然过期的、僵化的IT系统架构会使咱们的组织和业务陷入停顿，没法面对新的机遇和挑战。 这些年业界的服务端架构理念一直在持续演进，从单体模块化架构，到SOA，再到微服务，最后到Service Mesh。严选服务端架构的演化正是它的一个缩影，在某些方面咱们甚至还领先于业界的发展。

前言

同严选的业务同样，在下层承载它的IT系统架构同样要生存、呼吸、增加和发展，不然过期的、僵化的IT系统架构会使咱们的组织和业务陷入停顿，没法面对新的机遇和挑战。

这些年业界的服务端架构理念一直在持续演进，从单体模块化架构，到SOA，再到微服务，最后到Service Mesh。严选服务端架构的演化正是它的一个缩影，在某些方面咱们甚至还领先于业界的发展。

架构成熟度

虽然业界没有一种通用的架构成熟度模型能够用来度量，但从单体模块化、到SOA、再到微服务、最后到Service Mesh的架构成熟度级别毋容置疑是逐步上升的。

每一个级别都有一系列本身的问题，这些问题须要在下一级别来解决。

不一样级别有不一样的复杂性，不一样级别也有不一样的侧重点。

​

• 单体模块化架构

  强调业务逻辑按模块划分，高内聚低耦合。模块间通讯经过同进程内的方法调用进行。

• 面向服务的架构(SOA)

  强调业务逻辑在应用粒度的复用，收口和归一散落的业务逻辑，能够理解为是业务逻辑的水平拆分。服务间通讯经过企业服务总线进行,总线上会耦合少许业务逻辑。

• 微服务架构

  强调业务逻辑在应用粒度的解耦，能够理解为高内聚低耦合业务逻辑的垂直拆分。服务间通讯经过RPC进行。

• Service Mesh

  强调业务逻辑与服务治理逻辑的分层及解耦，这是另一种层面的分层和解耦，在业务逻辑和基础实施逻辑间划分出清晰的边界。Service Mesh架构下，服务间通讯经过网格进行代理。

  全部这些架构模式无一不在强调解耦和复用，而Service Mesh是全部架构模式中解耦和复用最完全的，它不只仅强调业务逻辑的解耦和复用，更强调基础设施的解耦和复用。

什么是Service Mesh

先来看Service Mesh的定义，这个定义是Service Mesh的先驱公司Linkerd的CEO William提出来的。

Service Mesh是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格一般实现为一组轻量级网络代理，它们与应用程序部署在一块儿，而对应用程序透明。

这个是Service Mesh比较早期的定义，如今Service Mesh涵盖的范围更大更广。在微服务体系里面，除了服务自己以外，其它的服务相关的可管理可治理的的部分均可以理解为是Service Mesh的范畴。

因此Service Mesh归根结底是一个服务治理平台，它基本上包含了服务治理的全部方面。

这些经过Spring Cloud这种全家桶的方式也能实现，可是与业务逻辑耦合在一块儿，部署、运维都耦合了微服务自己的操做。好比一个RPC框架的bugfix会引起全部微服务旷日长久的升级发布，同时带来业务开发人员开发、测试、回归、发布的巨大重复工做量。

Service Mesh经过将与业务逻辑无关的服务治理逻辑下沉，让业务开发人员与基础技术开发人员关注点分离，各司其职，大大提高了研发效能。

业务开发人员更关注的是对业务的理解、建模，他们的核心价值体如今业务实现上。Spring Cloud/Service Mesh之类的服务治理平台对于他们来讲只是工具和手段，而不是终极目标。在这些工具的学习和使用上耗费大量时间和精力成本对他们来讲得不偿失。

基础技术开发也能专一于本身的技术领域，不须要为了推进技术的升级换代而去理解、学习业务，不须要耗费大量时间精力去协调和推进业务的变动，不须要共担业务线上变动的风险和压力。

​

第一代-基于Consul+Nginx的严选版Service Mesh

严选/邮件版Service Mesh(也即Consul+Nginx,后简称cNginx)诞生之时，Service Mesh的概念尚未提出，你们也没想到当初作的那些事情居然让他们成为Service Mesh的先行者。

当初的想法很简单：为跨语言业务应用提供无侵入性的基于Consul的服务路由功能。并利用 Nginx 的原生特性，在高性能的前提下提供负载均衡、集群容错等机制。

当时所作的主要工做是对consul与nginx的扩展开发，把这2个组件的能力融合在一块儿，以解决咱们遇到的问题。

严选版Service Mesh总体架构

​

• 数据面

  以consul client+cNginx 组成咱们的sidecar,这里的sidecar模式是单向的client sidecar模式，当时咱们关注的问题单sidecar的模式已经彻底能解决。

  在数据面实现的服务治理能力主要以nginx为基础。

  • 负载均衡

  • timeout治理

  • 重试

  • FailOver

• 控制面

  控制面也即咱们的consul admin管理平台，有3大模块，分别实现各自职责边界内的服务治理能力。

  • 流量调度

    对流量进行调度、路由、流量权重、泳道隔离等操做。

  • 服务注册/发现

    对服务实例进行上线、下线、剔除、健康检查等操做

  • 限速&熔断

    对服务调出在调用方进行速率限制或直接熔断。

架构收益

经过融合Consul+Nginx的功能，咱们建设了简单服务治理能力，落地了简版的Servcie Mesh。

cNginx对业务应用透明，由基础技术团队统一开发、部署和运维，其实现的服务治理功能不须要各个业务方重复去建设或从第三方引入，能够将更多时间专一于本身的业务逻辑。

同时在跨语言的多个应用之间，咱们建设了统一的通讯层，保证了通讯策略的一致性落地。

成本方面，咱们也节省了框架性中间件(好比RPC框架)的研发和投入，下降了中间件与业务代码之间额外的耦合成本。

第二代-基于istio的Service Mesh

随着业务的快速发展，cNginx实现的简版服务治理能力已经不能知足咱们日益增加的需求。

而云基础设施的成熟让云原生架构愈来愈具备普适性，严选也在基于轻舟落地咱们的容器云战略，cNginx没法与k8s、docker等云基础设施有效融合，必须选择新的Service Mesh平台进行替换。

毫无疑问，咱们的最终的选择的是istio,当前Service Mesh的事实标准。

istio总体架构

​

istio在架构上一样分为数据面和控制面两大块。

• 数据面

  数据面控制服务全部进出流量,并植入服务治理逻辑。数据面同时负责控制面制定的策略的执行，并上报遥感数据至控制面。

  istio数据面默认的sidecar为envoy，envoy是L4/L7的高性能网络代理组件。

• 控制面

  控制面由Pilot、Mixer、Citadel、Galley四部分组成。

  • Pilot

    提供服务发现、流量动态路由和服务间的弹性能力(超时、重试、速率限制、熔断等)。

  • Mixer

    承担ACL、策略执行、黑白名单等职责，并收集服务遥感数据。

  • Citadel

    提供安全证书下发和管理的能力。

  • Galley

    Galley提供抽象的、统一的配置校验能力。

一些重要决策

1.Client Sidecar模式

istio自己提供了3种sidecar的模式:Client Sidecar、Server Sidecar、Both Sidecar，通过权衡，咱们最终决定暂时使用Client Sidecar的模式，只在服务调用方启用sidecar，缘由以下所述。

• 模式上的继承性

  严选第一代Service Mesh的实现cNginx也是 Client Sidecar的模式，而第二代istio原本就是一个很新很前沿的的东西，为了下降你们理解上和使用上的复杂性，同时让业务进行无缝对接，咱们对第二代Sidecar模式的变动暂时采起了保守的态度。

• 性能考虑

  从咱们的压测结果来看，istio client sidecar 模式与cnginx相比略微差一点，而both sidecar的模式因为网络上多了一跳性能也有更多的折损，为了避免让业务方在响应性、吞吐量等感知上出现过多的变化，咱们暂时选择了client sidecar模式。

• 治理能力的差异

  Client模式与Both模式在治理能力上的差别部分，咱们现有的基础设施都可以补足。好比服务可观察性，咱们有完善的APM平台和日志平台。因此在治理能力上咱们并不Care Server端是否启用了sidecar。

​

2.按需使用

istio就像一把瑞士军刀，它提供的功能很是很是多，初次使用它你可能会陷入迷茫。

严选对istio的使用一直秉承按需的原则，咱们初期只要求使用和cnginx对等功能，后面再逐步覆盖其它功能。

对于一些目前版本istio的实现上有性能问题的功能，咱们是坚定弃用的。好比Mixer的策略执行功能，由于每一次调用envoy都会同步调用Mixer进行一次策略检查，致使性能降低的很是迅速。关于这一点，社区也已经意识到并着手进行优化了,优化完成后咱们会考虑使用。

做为Mixer的策略执行的替代品，istio的rbac也是能够知足一部分功能的，好比服务白名单咱们就是经过rbac来实现的，这样就避免了Mixer的性能陷阱。

3.与k8s融合

​

Service Mesh自己是平台独立的，但与k8s融合有很是多的优势，已经逐步成为了业界主流的标准(也即云原生架构)，严选也采用了这种方式。

• sidecar自动注入，自动接管流量
• 一致的服务发现，统一基于K8S数据作服务发现
• 治理规则基于K8S CRD，无需专门管理服务
• 服务发现无需主动注册，声明为k8s service便可自动注入

过渡期架构方案

过渡期会存在cNginx(云外)与istio(云内)两种类型的Service Mesh共存的状况，为了让业务无感知，咱们设计了过渡期的架构方案。

​

• 对于云内服务来讲，若是服务提供方没有在云内部署，则自动兜底路由到云外服务。
• 对于云外服务来讲，云内服务提供者统一抽象成云外服务的一个逻辑服务实例，往云内的导流经过cNginx控制这个逻辑服务实例流量权重便可。

性能陷阱

Service Mesh最受人误解而诟病的是它的性能问题，不少人认为调用路径上网络多了一跳/两跳就以为Mesh性能会不好。从咱们的实践和压测来看，只要咱们作好抉择和裁剪，Mesh的性能问题并无那么恐怖。

• 1600rps+40个并发(主机配置均为8C16G)

​

从压测数据来看，在40个并发基础上，rps在1600（注:单机1600rps对于严选的业务来讲，容量的冗余已经很是充分了）时，istio(client模式)的RT overhead是0.6ms左右，cnginx的RT overhead在0.4ms左右。istio和cnginx的性能差异很是小，基本上能够等价。

并且Spring Cloud/dubbo这种框架自己也会引入资源开销、性能开销,因此替换成Service Mesh只是对性能开销进行了转移支付,性能影响相较而言就更小了。

严选使用的istio是杭研版的istio,当前杭研同窗正在对istio的性能作更深一步的优化。目前性能优化后初步测试结论以下。

• 方案1：采用eBPF/xDP(sockops)，优化路径为SVC <-> Envoy，延迟性能提高10-20%。Envoy部署方式per-pod，跟社区方向一致，也是目前严选采用的部署方案。
• 方案2：采用DPDK+Fstack用户态协议栈，优化路径为Envoy <-> Envoy，延迟性能提高0.8-1倍。Envoy部署方式为per-node，功能和运维层面的限制还在评估当中。

固然性能问题依然是个很核心的问题，因此咱们会建设咱们的常态化压测机制，对任何变动都进行压测回归。

总结

从cnginx到istio，咱们的服务治理能力和治理体系化实现了与时俱进和现代化。

架构落地的收益最终都是经过研发效能来体现，经过Service Mesh架构持续实践和落地，咱们解耦了业务逻辑和基础设施逻辑，进一步解放和发展了生产力，驱动了业务更好更快的发展。

网易技术热爱者队伍持续招募队友中！网易严选，由于热爱因此选择， 期待志同道合的你加入咱们， Java开发简历可发送至邮箱：lizhuo01@corp.netease.com