01.微服务问题

• https://segmentfault.com/a/1190000039672263

1.1 微服务实现流程

1、服务都注册到服务注册中心

• 要构建微服务体系，首先我们需要独立部署一款实现服务注册/发现功能的组件服务，目前可供选择的主流方案一般有Eureka、Consul、Nacos等
• 搞定服务注册/发现后，我们编写一个Java微服务，此时为了将该服务注册到服务注册中心
• 一般会引入Spring Cloud提供的支持对应注册中心接入的SDK，并在应用入口类中通过@EnableDiscoveryClient注解的方式标注
• 之后SDK中的逻辑就会在应用启动时执行服务注册动作，并提供给注册中心相应地探测接口，以此实现微服务与服务注册中心之间的连接。
• 以此类推，我们可以通过这种方式将一组微服务都注册到服务注册中心！

2、服务之间要互相调用

• 一般我们会通过编写FeignClient接口来实现微服务之间的调用
• 而其底层的逻辑则是通过Feign所集成的Ribbon组件去注册中心中获取目标服务的服务地址列表
• 之后Ribbon根据服务地址列表进行负载均衡调用。
• 至于服务与注册中心之间如何保证连接有效性，则依赖于服务注册中心与其SDK之间的协作机制。

3、负载均衡、熔断、限流、网关

• 而高级一点，服务之间的调用除了实现负载均衡，还要实现熔断限流
• 那么此时可以通过部署服务网关组件（例如Zuul/Spring Cloud GateWay）来实现微服务入口的熔断限流
• 内部服务之间的限流熔断则通过集成Hystrix或Sentinel组件，以客户端本地配置或远程配置中心的方式来实现。

1.2 微服务遇到的问题

1、框架/SDK太多，后续升级维护困难

• 在这套体系中，与服务治理相关的逻辑都是以SDK代码依赖的方式嵌入在微服务之中
• 如果某天我们想升级下服务注册中心的SDK版本，或者熔断限流组件Hystrix或Sentinel的版本，那么需要升级改造的微服务可能会是成百上千
• 且由于这些组件都与业务应用绑定在一起，在升级的过程中会不会影响业务稳定，这都是需要谨慎对待的事情，所以对SDK的升级难度可想而知的！

2、多语言微服务SDK维护成本高

• 试想下如果构建的微服务体系，也要支持像Go、Python或者其他语言编写的微服务的话
• 那么上述这些微服务治理相关的SDK是不是得单独再维护几套呢？
• 所以在这种体系结构中，对多语言微服务的支持就成了一个问题！

3、服务治理策略难以统一控制

• 基于该套体系构建的微服务体系，在对像熔断、限流、负载均衡等服务治理相关的策略管理上，都是比较分散的
• 可能有人会写到自己的本地配置文件，有人会硬编码到代码逻辑中，也可能有人会将其配置到远程配置中心
• 总之对于服务治理策略逻辑都是由对应的开发人员自己控制，这样就很难形成统一的控制体系！

4、服务治理逻辑嵌入业务应用，占有业务服务资源

• 在这套微服务体系中，服务治理相关的逻辑都是在微服务应用进程中寄生运行的
• 这多少会占有宝贵的业务服务器资源，影响应用性能的发挥！

5、额外的服务治理组件的维护成本

• 无论是服务注册中心、还是服务网关，这些除了微服务应用本身之外服务治理组件，都需要我们以中间件基础服务的方式进行维护
• 需要额外的人力、额外的服务器成本

02.Service Mesh实现

2.1 Service Mesh是什么

• 如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。
• 对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用）
• 同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情
• 比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 有如下几个特点

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

2.2 Service Mesh网格

• 其中绿色的正方形表示正常部署的微服务，而蓝色的正方形表示一个网络代理，也就是大家通常所说的SideCar。
• 在Service Mesh架构下，每部署一个微服务，都需要部署一个与之相对应的代理服务，所有与微服务本身的交互都通过SideCar代理
• 而SideCar之间会形成一张形似网格的交互链路，这就是服务网格名称的来由
• 在Service Mesh中，当我们将一个服务部署在Kubernetes之后
• 安装在Kubernetes中的Service Mesh组件（例如Istio）就会自动在该微服务的同一个Pod之中启动一个与之对应的代理进程（例如istio-proxy)
• 这个保姆式的代理进程会代替微服务本身去实现原先在Spring Cloud体系中需要微服务自身完成的服务注册、负载均衡、熔断限流等微服务治理功能。
• 并且，这些代理进程并不是孤军奋战，而是会通过像xDS协议（Service Mesh中数据面与控制面通信的通用协议）与Service Mesh控制组件保持连接。

2.3 ServiceMesh开源项目

• Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。
• Envoy（https://github.com/envoyproxy/envoy）：第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 个人开发（Lyft 工程师），之后默默发展，版本较稳定。
• Istio（https://github.com/istio/istio）：第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，之后稳定的开发和发布。
• Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 整体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。
• nginMesh（https://github.com/nginmesh/nginmesh）：2017 年 9 月首发布，由 Nginx 开发，定位是作为 Istio 的服务代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，极度低调，GitHub 上的 star 也只有不到 100。
• Kong（https://github.com/Kong/kong）：比 nginMesh 更加低调，默默发展中。