千博网站后台,wordpress是否免费,山西做杂粮的网站,外包公司网站开发戳蓝字“CSDN云计算”关注我们哦#xff01;作者 | 奎哥来源 | 不止思考Service Mesh 被大家称为下一代的微服务#xff0c;是微服务领域的一颗新星#xff0c;被大家讨论的非常多。我在大家的讨论中#xff0c;还看到有人说 “目前的微服务架构我都没学会呢#xff0c;现… 戳蓝字“CSDN云计算”关注我们哦作者 | 奎哥来源 | 不止思考Service Mesh 被大家称为下一代的微服务是微服务领域的一颗新星被大家讨论的非常多。我在大家的讨论中还看到有人说 “目前的微服务架构我都没学会呢现在又来一个下一代微服务真学不动了”。哈哈没办法互联网技术就是发展得这么快这些技术其实也都是由于大家所在的公司业务规模和复杂度变大以后所推动出来的。最开始 Service Mesh 的概念是由Buoyant公司在2016年提出。然后在随后几年业内就围绕着 Service Mesh 思想探索出了各种实现其中包括以 Linkerd 为代表的第一代 Service Mesh随后又有以 Istio 为代表的第二代 Service Mesh。在国内的一些大厂里例如 阿里、新浪 等也都有基于Service Mesh思想的自研实现。既然 Service Mesh 这么火那它到底是什么呢又该如何去应用呢一、什么是「 Service Mesh 」Service Mesh 中文称为 服务网格为啥因为它的部署图看起来就像一个网格如下图Service Mesh 就是一个基础设施层它是用于处理微服务中服务与服务之间通信的一种技术。在 Service Mesh 的实践方案中它是由一系列轻量级的网络代理组成的并且这些网络代理会与咱们的应用部署在一起特别适用于云原生应用因为 Service Mesh 可以做到应用是无感知的。上图的绿色小块可以理解成是咱们微服务的应用蓝色小块可以理解成 Service Mesh 的轻量级网络代理有了 Service Mesh 之后微服务中服务与服务之间的通信就是靠这些 网络代理模块 来保障。那我们为啥需要采用 Service Mesh 呢Service Mesh 帮我们解决了目前微服务之间调用的啥痛点了吗二、为什么需要「 Service Mesh 」在传统微服务架构中随着业务越来越大拆分的服务实例也越来越多那么各个服务之间的依赖就变成了非常复杂的网络拓扑结构可能就类似于这样了哈哈晕图了、晕图了在如此复杂的分布式部署结构下咱们微服务中服务依赖调用和数据传输所面临的问题也成倍增加极大的提高了服务治理的难度。同时由于 容器化技术 的成熟和规模化微服务都会采用容器化并朝着 云原生应用 的方向发展。而传统的微服务架构中虽然也有服务治理的组件但是这些组件大多需要在应用代码里进行集成这是不符合 云原生应用 的思想的。因此大家急需一个标准化能高效部署和运维的微服务体系方案。因此Service Mesh 就出现了Service Mesh 就是用来解决这些痛点的设计的目的就是用来解决微服务架构中 服务间可靠调用、服务治理 等问题。下面就拿第一代 Service Mesh 产品 Linkerd 举例说明图中可以看到每一个服务实例Service的部署都会同时部署一个 Linkerd 实例并且服务之间的调用并不是直接进行的而是先经过 Linkerd 模块去代理转发完成的。例如Service A 需要调用 Service B 的时候Service A 是把请求发给与它一起部署的 Linkerd-1 的然后这个 Linkerd-1 将请求发给 Service B 所部署模块的 Linkerd-2然后 Linkerd-2 再将请求内容转发给 Service B 处理。因此在整个流程中Service A 和 Service B 只需要关注自己的业务逻辑即可无需关注任何服务框架的功能这些服务框架的功能都是由Linkerd 去实现Linkerd 要做 负载均衡、熔断、限流、监控等等。下面我们具体来看看 Service Mesh 的原理。三、「 Service Mesh 」的原理与应用Service Mesh 的核心其实就2个模块SideCar 与 Control Plane如图搞懂了 SideCar 与 Control Plane 也就对 Service Mesh 的基础思想原理明白了。SideCar上面说到的与服务部署在一起的轻量级网络代理也就是指SideCar它的作用就是实现服务框架的各项功能这样就可以让服务Service A 或 Service B回归业务本质。传统的微服务架构中各种服务框架的功能例如服务发现、负载均衡、限流熔断等都代码逻辑或多或少的都需要耦合到服务实例的代码里给服务实例增加了很多无关业务的代码也带来了复杂度。有了SideCar之后服务节点只做业务逻辑自身的功能服务之间的调用交给了SideCar由SideCar去注册服务、去做服务发现、去做请求路由、去实现熔断限流、去做日志统计。那么在这种新的微服务架构中所有的 SideCar 组成在一起其实就是一个服务网格了。那么这个大型的服务网格并不是完全自治的它还需要一个统一的控制节点也就是 Control Plane。Control PlaneControl Plane 是用来从全局的角度上控制 SideCar 的。比如 它负责所有 SideCar 的注册它存储一个统一的路由表帮助各个 SideCar 进行负载均衡和请求调度。它收集所有 SideCar 的监控信息和日志数据。它就相当于 Service Mesh架构 的大脑。Control Plane 控制着 SideCar 来实现服务治理的各项功能。在文章的最开始提到过以 Linkerd 为代表的被称为第一代 Service Mesh而以 Istio 为代表的称为了第二代 Service Mesh。主要的不同就是 Istio 引入了 Control Plane 的概念可以通过 Control Plane 来对服务进行一些精细化控制所以 Istio 也被称为是实际上的 Service Mesh 标准产品。以上就是我对微服务架构中「 Service Mesh」的一些思考你是怎么看的呢福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读面试官问你MyBatis中有哪些设计模式把这篇文章发给他听说私有云也出新一代了搞不懂SDN那是因为你没看这个小故事…华为最强自研 NPU 问世麒麟 810 “抛弃”寒武纪北邮通信博士万字长文带你秒懂 4G/5G 区别LinkedIn最新报告: 区块链成职位需求增长最快领域, 这些地区对区块链人才渴求度最高……中文NLP的分词真有必要吗李纪为团队四项任务评测一探究竟 | ACL 2019真香朕在看了
