Service Mesh——微服务中的流量管理中间件

Service Mesh——微服务中的流量管理中间件

摘自-https://zhuanlan.zhihu.com/p/28794062

Service mesh 与 Cloud Native

Kubernetes 设计之初就是按照 Cloud Native 的理念设计的,Cloud Native 中有个重要概念就是微服务的架构设计,当将单体应用拆分微服务后, 随着服务数量的增多,如何微服务进行管理以保证服务的 SLA 呢?为了从架构层面上解决这个问题,解放程序员的创造性,避免繁琐的服务发现、监控、分布式追踪等事务,Service mesh 应运而生。

什么是 service mesh?

Service mesh 有如下几个特点:

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

目前两款流行的 service mesh 开源软件 Istio 和 Linkerd 都可以直接在 kubernetes 中集成,其中 Linkerd 已经成为 CNCF 成员。

理解 Service Mesh

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

Phil Calçado 在他的这篇博客 Pattern: Service Mesh 中详细解释了 Service Mesh 的来龙去脉:

  1. 从最原始的主机之间直接使用网线相连
  2. 网络层的出现
  3. 集成到应用程序内部的控制流
  4. 分解到应用程序外部的控制流
  5. 应用程序的中集成服务发现和断路器
  6. 出现了专门用于服务发现和断路器的软件包/库,如 Twitter 的 Finagle 和 Facebook 的 Proxygen,这时候还是集成在应用程序内部
  7. 出现了专门用于服务发现和断路器的开源软件,如 Netflix OSS、Airbnb 的 synapse 和 nerve
  8. 最后作为微服务的中间层 service mesh 出现

Service mesh 的架构如下图所示:

图片来自:Pattern: Service Mesh

Service mesh 作为 sidecar 运行,对应用程序来说是透明,所有应用程序间的流量都会通过它,所以对应用程序流量的控制都可以在 serivce mesh 中实现。

Service mesh如何工作?

下面以 Linkerd 为例讲解 service mesh 如何工作,Istio 作为 service mesh 的另一种实现原理与 linkerd 基本类似,后续文章将会详解 Istio 和 Linkerd 如何在 kubernetes 中工作。

  1. Linkerd 将服务请求路由到目的地址,根据中的参数判断是到生产环境、测试环境还是 staging 环境中的服务(服务可能同时部署在这三个环境中),是路由到本地环境还是公有云环境?所有的这些路由信息可以动态配置,可以是全局配置也可以为某些服务单独配置。
  2. 当 Linkerd 确认了目的地址后,将流量发送到相应服务发现端点,在 kubernetes 中是 service,然后 service 会将服务转发给后端的实例。
  3. Linkerd 根据它观测到最近请求的延迟时间,选择出所有应用程序的实例中响应最快的实例。
  4. Linkerd 将请求发送给该实例,同时记录响应类型和延迟数据。
  5. 如果该实例挂了、不响应了或者进程不工作了,Linkerd 将把请求发送到其他实例上重试。
  6. 如果该实例持续返回 error,Linkerd 会将该实例从负载均衡池中移除,稍后再周期性得重试。
  7. 如果请求的截止时间已过,Linkerd 主动失败该请求,而不是再次尝试添加负载。
  8. Linkerd 以 metric 和分布式追踪的形式捕获上述行为的各个方面,这些追踪信息将发送到集中 metric 系统。

为何使用 service mesh?

Service mesh 并没有给我们带来新功能,它是用于解决其他工具已经解决过的问题,只不过这次是在 Cloud Native 的 kubernetes 环境下的实现。

在传统的 MVC 三层 Web 应用程序架构下,服务之间的通讯并不复杂,在应用程序内部自己管理即可,但是在现今的复杂的大型网站情况下,单体应用被分解为众多的微服务,服务之间的依赖和通讯十分复杂,出现了 twitter 开发的 Finagle、Netflix 开发的 Hystrix 和 Google 的 Stubby 这样的 ”胖客户端“ 库,这些就是早期的 service mesh,但是它们都近适用于特定的环境和特定的开发语言,并不能作为平台级的 service mesh 支持。

在 Cloud Native 架构下,容器的使用给予了异构应用程序的更多可行性,kubernetes 增强的应用的横向扩容能力,用户可以快速的编排出复杂环境、复杂依赖关系的应用程序,同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发,赋予开发者更多的创造性。

原文地址:https://www.cnblogs.com/zhangfengshi/p/12530018.html

时间: 2024-11-08 15:49:49

Service Mesh——微服务中的流量管理中间件的相关文章

谈谈微服务中的 API 网关(API Gateway)

转载至:http://www.cnblogs.com/savorboard/p/api-gateway.html 背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用. 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举

微服务中的设计模式

说到设计模式,大家一般会想到,工厂.单例等24种基本设计模式,当然也会想到并发型模式,生产-消费者模式,线程池模式等,但是微服务中用到什么设计模式了?前两篇介绍了,挎斗模式和代表模式,当然这一类设计模式属于云设计模式.AzureCAT模式和实践团队在Azure架构中心发布了九种新的设计模式.在设计和实现微服务时,这九种模式特别有用.微服务越来越变的流行是记录这些模式的动机. 下图说明了如何在微服务架构中使用这些模式: 对于每种模式,我们都会描述问题,解决方案,何时使用模式以及实现注意事项. Am

Spring Cloud微服务中网关服务是如何实现的?(Zuul篇)

导读 我们知道在基于Spring Cloud的微服务体系中,各个微服务除了在内部提供服务外,有些服务接口还需要直接提供给客户端,如Andirod.IOS.H5等等. 而一个很尴尬的境地是,如果直接将提供外部接口的微服务暴露给公网,那么意味着为了增强这个微服务的安全性,需要做很多额外的安全性措施,如报文数字签名.加密等:而大部分场景下,微服务本身又是提供给内部其他微服务调用的,即便所有的微服务都会不同程度地直接面向App客户端提供公网服务,那么为了这确保这些微服务的安全性,涉及的微服务也都需要实现

微服务中定位线上问题

微服务架构下的程序一般有多个节点提供服务,用户请求不一定落在哪一个节点,如果节点 存在问题,一般利用日志监控系统来确认问题. 日志监控系统提供实时日志,以及全文检索日志,并且日志实时查询以及全文检索查询都要 以倒叙查询. 中间件系统或业务系统对于日志生成的级别,debug.info.error等级别,以及error日志 要打印详细日志栈信息. 通过合理详细的使用日志以及配合日志监控系统的实时日志以及日志检索功能一般能够很快地 定位问题,定位到问题一般就能很快地解决. 错误日志尽量打印栈信息,in

Spring Cloud 微服务中搭建 OAuth2.0 认证授权服务

在使用 Spring Cloud 体系来构建微服务的过程中,用户请求是通过网关(ZUUL 或 Spring APIGateway)以 HTTP 协议来传输信息,API 网关将自己注册为 Eureka 服务治理下的应用,同时也从 Eureka 服务中获取所有其他微服务的实例信息.搭建 OAuth2 认证授权服务,并不是给每个微服务调用,而是通过 API 网关进行统一调用来对网关后的微服务做前置过滤,所有的请求都必须先通过 API 网关,API 网关在进行路由转发之前对该请求进行前置校验,实现对微服

微服务中基于Spring Boot的maven分布式项目框架的搭建

项目介绍 这里搭建的是基于 maven 的分布式工程,因为在一个项目中,多个微服务是属于同一个工程,只不过是提供不同的服务而已,再加上 IDEA 是默认一个窗口打开一个项目工程(这点和 eclipse 不同),如果项目大,不用 maven 聚合工程的话,那估计会打开十几个窗口--会崩溃--而且在架构上,也应该使用 maven 分布式工程来搭建微服务架构.这里手把手教大家在 IDEA 中搭建基于 maven 分布式的 Spring Cloud 微服务工程架构. maven分布式工程架构首先来看一下

微服务中使用 OpenJ9 JVM内存占用降低60%!

随着微服务的普及,许多企业踏上微服务之旅. 微服务化后,应用数量可能高一个数量级.一般企业,以前三五个应用能支撑业务,微服务化之后应用数量可能多达几十个.每个微服务往往独立部署,内存的消耗自然也高居不下,以前两台8核16G机器指不定就能跑起来,现两台16核64G还不一定够用,同时由于多套环境的存在加上容器编排工具(如K8s)所需的资源,硬件资源的投入自然是成倍增加. 在 Web 应用开发中,为了降低内存消耗,你是否尝试过: 去除不必要的组件,减少代码体积 更换 Web 容器,如将 Tomcat

我爱java系列---【微服务中feign拦截器的使用】

1.为什么要用feign拦截器? 作用:由于服务整合了oauth2,在被调用时需要传递令牌才能正常调用,feign拦截器的作用就是为了在服务之间传递令牌. 2.feign拦截器怎么用? (1)创建拦截器(一般定义在全局中) 在changgou_common服务中创建一个com.changgou.interceptor.FeignInterceptor拦截器,并将所有头文件数据再次加入到Feign请求的微服务头文件中,代码如下: @Component public class FeignInter

微服务中的测试

每个人的开发能力不同,要保证线上应用没问题,接口可用率达到100%,无天窗.无bug 难度还是比较大的,特别是业务开发很多要跟版发,时间紧.任务重问题更加严峻. 加强需求合理性评审,设计合理性评审,代码review. 单元测试: (junit)尽量将路径都覆盖到.(缺点代码实现不合理,代码结构修改,整个 程序结构变化会导致测试用例修改工作量大). 集成测试: (自己研发) 自动化读取配置的多个类型的pin,通用调用接口,匹配结果返回 个数,返回类型,部分pin匹配到返回值.自己开发的集成测试工具