开发者必须要了解的架构技术趋势:Service Mesh

内容概要

  • Service Mesh 是干啥的?解决了什么问题?
  • Service Mesh 的特性
  • Service Mesh 的主流实现有哪些?

1. Service Mesh 是什么?

简单来讲,Service Mesh 简化了微服务架构中服务间调用复杂度

这就涉及到了2个问题:

  • 服务调用怎么复杂了?
  • Service Mesh 怎么解决的?

(1)服务调用复杂度问题

对于每个微服务,我们可以简单的视为包含2个部分:

  • 业务逻辑
  • 网络功能

其中网络部分是非常复杂的,需要解决很多问题,例如:

  • 使用什么网络传输协议(HTTP1.x/2.x, gRPC ……)
  • 服务发现
  • 熔断机制
  • 处理超时
  • 重试
  • 服务调用时的负载均衡
  • ……

每个微服务都需要处理这些网络问题,如果所有微服务都使用同一套语言还好,可以使用一个框架统一解决,但如果使用了多种语言,那么每种语言又需要统一处理一遍。

所以,可以说:

微服务架构中,最复杂的不是构建服务本身,而是处理服务间调用问题

(2)Service Mesh 怎么解决的?

核心部分说明:

  • 业务逻辑

微服务实现自己的业务功能。

  • 内部网络功能

虽然很多网络功能都可以统一由 Service Mesh 解决,但有些基础的功能还需要微服务自己来解决。

例如,和 Service Mesh 如何沟通呢?使用 HTTP1.x, gRPC, TCP?

这部分功能通常由开发框架中的网络库来解决。

  • Service Mesh Sidecar(边车)

这部分就是用来解决应用级别通用的网络问题,例如熔断、超时、服务发现 ……。

把这些问题与微服务中的业务代码完全隔离开,开箱即用。

  • Service Mesh Control Plane

负责管理所有 service mesh 的代理。

例如:

1)访问控制

2)监控

3)服务发现

……

2. Service Mesh 功能特性

梳理一下 Service Mesh 的核心功能:

  • 服务间调用的弹性处理:熔断、超时、重试、错误处理、负载均衡、故障转移。
  • 服务发现:通过专用服务注册表发现服务终结点。
  • 路由:提供原始的路由功能,不涉及服务中业务相关的路由功能。
  • 监控:度量、监控器、分布式日志、分布式跟踪。
  • 安全:传输层安全,key 管理。
  • 访问控制:基于黑名单、白名单的访问控制。
  • 部署:原生支持容器,Docker 和 Kubernetes。
  • 通信协议:HTTP1.x, HTTP2, gRPC, TCP。

3. Service Mesh 实现

非常流行的2个开源实现:

  • Linkerd
  • Istio

他们的架构都比较简单,实现机制不同。

4. 小结

Service Mesh 把通用的服务调用需要处理的问题都统一处理了,你可以更加专注于服务自身的业务了,也可以放心的使用不同开发语言。

但 Service Mesh 也有不足,首先就是增加了系统整体的复杂度,例如增加了 Sidecar、Control Plane,而且服务间的通信不像以前那么直接了,需要经过代理。还有就是成熟度还不是很高,需要大规模线上应用的磨合完善。

推荐阅读:

原文地址:https://www.cnblogs.com/yogoup/p/12204118.html

时间: 2024-11-08 22:23:32

开发者必须要了解的架构技术趋势:Service Mesh的相关文章

微服务架构之「 下一代微服务 Service Mesh 」

Service Mesh 被大家称为下一代的微服务,是微服务领域的一颗新星,被大家讨论的非常多. 我在大家的讨论中,还看到有人说 “目前的微服务架构我都没学会呢,现在又来一个下一代微服务,真学不动了”. 哈哈,没办法,互联网技术就是发展得这么快,这些技术其实也都是由于大家所在的公司业务规模和复杂度变大以后所推动出来的. 最开始 Service Mesh 的概念是由Buoyant公司在2016年提出.然后在随后几年,业内就围绕着 Service Mesh 思想探索出了各种实现,其中包括以 Link

跨越数据库发展鸿沟,谈分布式数据库技术趋势

金融行业架构转型需求随着移动化与互联网化的不断发展,我国金融行业的商业模式与技术体系已经逐渐走上了与西方世界完全不同的道路.众所周知,欧美国家的移动化普及率远远不如我国,同时人口基数也有着数量级的不同,这就使得国内外金融行业所面临的业务类型.数据量.并发量都存在巨大的差异,导致对整个IT基础设施的需求截然不同. 在最近的一两年中,国内部分科技领先的银行已经率先对微服务与分布式技术进行了探索,一些新建的互联网金融类业务也已经开始尝试使用微服务架构.分布式技术.DevOps框架进行应用的开发与维护.

一个可供中小团队参考的微服务架构技术栈

一个可供中小团队参考的微服务架构技术栈 聊聊架构 2018-05-07 作者 杨波 作者 |  杨波编辑 |  张浩 近年,Spring Cloud 俨然已经成为微服务开发的主流技术栈,在国内开发者社区非常火爆.我近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据我个人的一线实践经验和我平时对 Spring Cloud 的调研,我认为 Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离.比方说 Spring Cloud Config 和 Spring Cloud

Dubbo和SpringCloud架构技术路线对比

微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路,例如Dubbo和Spring Cloud.各大互联网公司也有自研的微服务框架,但其模式都于这二者相差不大. 微服务主要的优势如下: 1.降低复杂度 将原来偶合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累.每一个微服务专

精选架构技术文章和总结来袭

大家都是我的老朋友了,所以今天就来点干货.当然,奉献给大家首先是技术总结(电子书),对着手机看文章,不急,看不完先收着,以后慢慢看. 笔者通过总结.归类和细化公众号历史原创文章,并梳理成电子书,电子书打包的目录如下: <RDMA原理分析.对比和技术实现解析><数据备份和副本管理技术全面解析><容器技术架构.网络和生态详解><闪存技术.产品和发展趋势全面解析><虚拟化技术最详细解析><传统企业存储知识完全解析><IO知识和系统性能

.Net 微服务架构技术栈的那些事

一.前言 大家一直都在谈论微服务架构,园子里面也有很多关于微服务的文章,前几天也有一些园子的朋友问我微服务架构的一些技术,我这里就整理了微服务架构的技术栈路线图,这里就分享出来和大家一起探讨学习,同时让新手对微服务相关技术有一个更深入的了解. 二.技术栈 2.1 工欲善其事,必先利其器 现在互联网盛行的年代,互联网产品也层出不穷,受欢迎的互联网产品都有一个比较牛的技术团队,我这里分享下.net 微服务架构技术栈图如下: 俗话说得好:工欲善其事,必先利其器.一个优秀的工程师应该善于使用框架和工具,

2017年八大顶尖的技术趋势

技术日新月异,我们都必须跟上步伐.新技术带来了新的商机.那些忽视技术趋势的人最终都被遗忘在竞争激烈的世界中.那些及时做出调整,并能适应开展业务的新方式的人,会马上取得领先优势,并获得财务回报. 所以,如果你在经营一个企业,不管是大是小,找出正在发生哪些技术变革.这些新的发展通常会被忽视,只有当新的小玩意出现在市场上时,人们才会知道他们.但是,这些第一批首先注意新技术趋势的人会在市场竞争中脱颖而出, 企业,特别是小企业,可以从现代技术中受益匪浅.新技术将大幅降低运营成本和其他成本,增加小企业家的利

整理收藏一些大型网站架构技术方面的文章

整理收藏一些大型网站架构技术方面的文章,这里就作为一个导航页面吧,也许文章来自博客园好友,或者其他网站,论坛,博客,我知道地址的都会注明,偶尔也会发表一些自己的看法,仅供收藏,以备自己不时查看,也欢迎博客园好友点评 1.收集的php编写大型网站问题集 http://www.cnblogs.com/ruthon/p/4477904.html

架构的力量!!2016解密互联网公司架构技术

大型互联网架构 解决问题的通用思路是将分而治之(divide-and-conquer),将大问题分为若干个小问题,各个击破.在大型互联网的架构实践中,无一不体现这种思想. 架构目标 低成本:任何公司存在的价值都是为了获取商业利益.在可能的情况下,希望一切都是低成本的. 高性能:网站性能是客观的指标,可以具体体现到响应时间.吞吐量等技术指标.系统的响应延迟,指系统完成某一功能需要使用的时间:系统的吞吐量,指系统在某一时间可以处理的数据总量,通常可以用系统每秒处理的总的数据量来衡量:系统的并发能力,