service mesh到底解决什么问题

Posted on Edited on

要完全的理解Service Mesh到底是什么样的一个东西，它为什么一经推出为什么会广受关注，并且现在不断有公司引入并落地，那么我们就去带着这些问题去探究一番。

先从分布式架构的不断演进历史来说吧

01分布式架构演进

1.1小型机时代

  • 2000年左右，互联网在我国开始盛行起来，但是那时候网民较少，上网时奢侈的事情，所以多数企业服务单一，采用集中式部署的方式就能满足需求，也就是所谓的all-in-one。
  • 坏处就不言而喻了，一旦小型机或者数据库出现问题，会导致整个系统的故障，而且功能的修改发布也不方便。

1.2 集群化时代

  • 用户量越来越大，就意味着需要更多的小型机，价格昂贵，操作维护成本高，不妨把小型机换成普通的PC机， 采用多台PC机部署同一个应用的方案，但是此时就需要对这些应用做负载均衡，因为客户端不知道请求哪一 个。

2013年5月17日，阿里集团最后一台IBM小型机在支付宝下线。

这是自2009年“去IOE”战略透露以来，“去IOE”非常重要的一个节点。“去IOE”指的是摆脱掉IT部署中原有的 IBM小型机、Oracle数据库以及EMC存储的过度依赖。告别最后一台小机，意味着整个阿里集团尽管还有 一些Oracle数据库和EMC存储，但是IBM小型机已全部消失。

  • 负载均衡可以分为硬件和软件，硬件比如F5，软件比如LVS(Linux Virtual Server)。负载均衡的思路是对外暴露 一个统一的接口，然后根据用户的请求进行对应规则的转发。同时负载均衡还可以做健康检查、限流等

  • 有了负载均衡，后端的应用就可以根据流量的大小进行动态的扩缩容了，也就是“水平扩展”.

1.3 服务化时代

  • 此时发现在用户，商品和订单等中有重复的功能，比如登录、注册、邮件等。一旦项目大了，集群部署多了， 这些重复的功能无疑是浪费资源，不妨把重复的功能抽取出来，起个名字叫“服务Service” 其实对于“服务”现在已经比较广泛了，比如“基础设施即服务IaaS”、“平台即服务PaaS”、“软件即服务SaaS“等

  • 这时候急需解决的就是服务之间的调用问题，RPC(Remote Procedure Call)，同时这种调用关系得维护起来， 比如某个服务在哪里，是不是得知道?所以不仅仅要解决服务调用的问题，还要解决服务治理的问题，比如像 Dubbo，默认采用Zookeeper作为注册中心，Spring Cloud使用Eureka作为注册中心 当然，要关注的还有很多，比如限流、降级、负载均衡、容错等

1.4 分布式微服务时代

在分布式架构基于SOA服务话时代可能服务拆分没有那么细，可能需要进一步的拆分–Microservices

下面是马丁大叔对于微服务的定义

https://martinfowler.com/articles/microservices.html

  • 所以接下来就涌现出了微服务的主流的解决方案

    Spring Cloud,Spring Cloud可以通过引入几个注解，写少量的代码完成微服务架构中的开发，相比Dubbo而言方便很多，并且使用时HTTP协议，所以对多语言也可以很好的支持

https://spring.io/projects/spring-cloud

spring-cloud-bus
spring-cloud-consul
spring-cloud-config spring-cloud-netflix:eureka、hystrix、feign、zuul、ribbon等

1.5 服务网格时代

微服务时代有了Soring Cloud就完美了吗？不妨想一想会有哪些问题

(1)最初是为了业务而写代码，比如登录功能、支付功能等，到后面会发现要解决网络通信的问题，虽然有 Spring Cloud里面的组件帮我们解决了，但是细想一下它是怎么解决的?引入以来dependency，加注解，写 配置，最后将这些非业务功能的代码打包一起部署，和业务代码在一起，称为“侵入式框架”;

(2)微服务中的服务支持不同语言开发，维护不同语言和非业务代码的成本;

(3)业务代码开发者应该把更多的精力投入到业务熟悉度上，而不应该是非业务上，Spring Cloud虽然能解决微服务领域的很多问题，但是学习成本还是较大的;

(4)对于Spring Cloud而言，并不是微服务领域的所有问题都有对应的解决方案，也就是功能有限，比如 Content Based Routing和Version Based Routing。当然可以将Spring Cloud和Service Mesh结合起来使用， 也就是对SC的补充、扩展和加强等;

(5)互联网公司产品的版本升级是非常频繁的，为了维护各个版本的兼容性、权限、流量等，因为Spring Cloud是“代码侵入式的框架”，这时候版本的升级就注定要让非业务代码一起，一旦出现问题，再加上多语言之 间的调用，工程师会非常痛苦;

(6)其实大家有没有发现，服务拆分的越细，只是感觉上轻量级解耦了，但是维护成本却越高了，那么怎么 办呢?网络的问题当然还是要交给网络本身来解决

1.5.1 问题如何解决呢？

  • 本质上要解决服务之间通信的问题，不应该将非业务的代码融合到业务代码中

  • 也就是从客户端发出的请求，要能够顺利到达对应的服务，这中间的网络通信的过程要和业务代码尽量的无关

    通信的问题–>服务发现、负载均衡、版本控制、蓝绿部署等

  • 在之前的单体架构中，其实通信问题也是需要写在业务代码中，那个时候怎么解决呢？

    网络通信，流量转发等问题放到了计算机网络模型中的TCP/UDP层，也就是非业务功能代码下沉到底层封装

  • 沿着这样的思路，其实大家应该首先想到的就是引入一个代理去做不就可以了吗？比如最初的Nginx，HaProxy等其实他们做反向代理吧请求转发给其他服务器，其实这些思路就是Service Mesh诞生和完成提供参考。

1.5.2 代理的探索SideCar

很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像14年Netflix的Prana、15年唯品会的local proxy，其实Sidecar模式和Proxy很类似，但是Sidecar功能更全面，也就是Sidecar功能和侵入式框架的功能对应

问题 :这种Sidecar是为特定的基础设施而设计的，也就是跟公司原有的框架技术绑定在一起，不能成为通用性的产 品，所以还需要继续探索。

1.5.3 Service Mesh的实现之Linkerd

2016年1月，离开Twitter的基础设施工程师William Morgan和Oliver Gould，在github上发布了Linkerd 0.0.7 版本，从而第一个Service Mesh项目由此诞生。并且Linkerd是基于Twitter的Finagle开源项目，实现了通用性。

后面又出现了Service Mesh的第二个项目Envoy，并且在17年都加入了CNCF项目。

小结 :Linkerd解决了通用性问题，在Linkerd思想要求所有的流量都走Sidecar，而原来的Sidecar方式可以走可以直 连，这样一来Linkerd就帮业务人员屏蔽了通信细节，也不需要侵入到业务代码中，让业务开发者更加专注于业务本 身。

问题 :但是Linkerd的设计思想在传统运维方式中太难部署和维护了，所以就后来没有得到广泛的关注，其实主要的 问题是Linkerd只是实现了数据层面的问题，但没有对其进行很好的管理。

1.5.4 Service Mesh实现之istio

由Google、IBM和Lyft共同发起的开源项目，17年5月发布0.1 release版本，17年10月发布0.2 release版本，

18年7月发布1.0 release版本。
很明显Istio不仅拥有“数据平面(Data Plane)”，而且还拥有“控制平面(Control Plane)，也就是拥有了数据

接管与集中控制能力。
官网Why use Istio?:https://istio.io/docs/concepts/what-is-istio/#why-use-istio

02 Service Mesh

What ‘s a service mesh?

William Morgan:https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one

1
2
3
A service mesh is a dedicated infrastructure layer for making service-to-service
communication safe, fast, and reliable. If you’re building a cloud native application, you
need a service mesh.

istio官网：https://istio.io/docs/concepts/what-is-istio/#what-is-a-service-mesh

1
2
3
4
5
6
>The term service mesh is used to describe the network of microservices that make up such
>applications and the interactions between them. As a service mesh grows in size and
>complexity, it can become harder to understand and manage. Its requirements can include
>discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also
>often has more complex operational requirements, like A/B testing, canary rollouts, rate
>limiting, access control, and end-to-end authentication.

2.1 Linkerd和Istio发展历程

  • Microservces

Martin Fowler
14年提出 https://martinfowler.com/articles/microservices.html

  • Linkerd
    William Morgan[Buoyant] 
    Scala语言编写，运行在JVM中，Service Mesh名词的创造者 
    16年01月15号，0.0.7发布

17年01月23号，加入CNCF
17年04月25号，1.0版本发布
  • Envoy

C++语言编程[Lyft]

16年09月13号，1.0发布

17年09月14号，加入CNCF

  • istio

Google、IBM、Lyft发布0.1版本

2.2 国内发展情况

  • 蚂蚁金服的SOFA

全称Scalable Open Financial Architecture 前身是SOFA RPC
18年07月正式开源

  • 腾讯的Tencent Service Mesh
  • 华为的CSE Mesher

以上基本上都是借鉴了Sidecar、Envoy和istio等设计思想

最终目的:

TCP/IP协议解决了计算机之间连接的问题，其实我们很少感知到它的存在。

而目前的服务治理也面临相似的问题，也就是要让计算机中的服务更好的连接起来，而且要做到业务代码尽可能无感知。

2.3 我们再梳理一下Service Mesh的发展过程

  • 借鉴反向代理，对Proxy模式进行探索，让非业务的代码下沉
  • 使用Sidecar弥补Proxy模式功能的不足，解决“侵入式框架”中非业务代码的问题
  • Linkerd解决传统Sidecar模式中通用性的问题
  • Istio增加了控制平面，解决整个系统中的流量完全控制的问题

03 Istio

基于Sidercar模式，数据平面和控制平面，主流Service Mesh解决方案

官网 :https://istio.io/
github :https://github.com/istio

3.1 先进性

  • 引入了数据平面和控制平面
  • Sidercar的方式解决了数据通信的问题，而在sitio中还加入了控制平面，所有的流量都能够有效的被控制，也就时通过控制平面可以控制整个系统

3.2 Istio可以解决哪些问题

(1)针对HTTP、gRPC、WebSocket等协议的自动负载均衡

(2)故障的排查、应用的容错、众多路由

(3)流量控制、全链路安全访问控制与认证

(4)请求遥测、日志分析以及全链路跟踪

(5)应用的升级发布、频率限制和配合等

3.3 Istio的架构

1.0版本架构。https://istio.io/v1.0/docs/concepts/what-is-istio/

image-20201130102800424

image-20201130102944977

Istio的设计理念核心就是将所有链路管理都下沉至协议级别，有istio提供连接管理，安全控制，负载限流的统一微服务平台，istio不仅提供了服务之间的流量控制，访问控制策略，还集成了各种链路服务及相关扩展接口，而这一切都是无须上层业务感知的，和业务充分解耦。好处是开发只需要关注自己业务开发，通信，负载均衡、限流，降级、熔断，认证安全等都都下沉到底层处理，完全解耦。功能不需要侵入代码，应用服务不需要重启。

Istio之所以可以在不修改源代码的情况之下，很轻松的给微服务加上诸如负载均衡、身份验证、监控等等功能，主要是istio通过在你的微服务部署所在的pod中注入sidecar数据平面为服务天假istio的支持，作为流量代理可以拦截微服务之间的所有网络通信，然后通过控制平面的功能来配置和管理istio来实现服务治理。

名词解释

数据平面：组件为Envoy,代理控制服务间的通信且可以收集网络流量，拓扑信息等遥测功能

控制平面：组件为istiod,负责配置管理数据平面，提供控制平面及数据平面的编程抽象层。

Envoy在istio中是以sidecar模式部署在pod里边，istio通过公知Envoy来控制所有流量获取监控数据。

控制层的Pilot、Mixer和Citadel

Pilot为Envoy提供服务发现，智能路由（AB测试、金丝雀部署）和弹性流量管理功能（如超时、重试、熔断），它负责将高层的抽象陆游规则转化成低级的envoy的配置。

Mixer,是一个和平台无关的组件，用来控制访问策略和使用策略，同时会收集监控信息，将收集到的信息传给用户以自定义的后端进行处理。

Citadel提供了服务间和服务到终端用户的认证，同时可以直接将http流量升级成https流量。