Service Mesh是什么?怎么来的?怎么实现?

本文探讨了微服务架构的演进,从微服务的起源到微服务2.0,即ServiceMesh的兴起。ServiceMesh作为独立的基础架构层,解决了微服务间的通信、监控、治理等问题,无需修改服务代码。文章还介绍了实现ServiceMesh的关键技术,包括Docker、Kubernetes、Istio等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

都在说的service mesh 是什么东西?

​ 2019年,一个群魔乱舞的年头,新兴了很多新的技术与概念,今天我们就来讲讲这个很高大上的service mesh到底是什么,因何兴起,怎么实现的。

我们的应用与产品想要抗住大并发,这些应用就要基于微服务架构来开发。而微服务架构只是一种架构的思想,微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始,2014年,Martin FowlerJames Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的行程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP/RPC API 通信。同时服务会使用最小的规模的集中管理 能力,服务可以用不同的编程语言与数据库等组件实现。

而想要实现微服务则是以分布式系统的开发实现。

分布式系统有基本的三高指标:

高性能,高并发,高可用。

也有其四大痛点:
  • 服务与服务之间的通信如何解决?
  • 这么多服务,客户端如何访问?
  • 服务如何治理?
  • 服务挂了怎么办?(负载均衡、服务降级、服务限流、服务熔断)

这么多服务对外接口怎么统一标准?

服务如何治理?

服务挂了怎么办?

​ 实现三大指标就需要基础设施来实现,也就是常见的DevOps(云计算,服务器运维)。而如今流行的这种基础设施就是 Docker,关于Docker的功能及其基础我们会另起篇章详细讲解,可以先理解为它就是一个可以运行多台虚拟机且将内存最大化利用的软件。我们用Docker能启动多个划分成型且可运行的微服务,但是,想一些大的项目类似淘宝、抖音这种极大并发量的应用,它可能需要几万个微服务,也即是启动docker里的几万个容器来承载这些服务的运行,几万个容器想要在一台服务器上运行就是天方夜谭,我们也不可能光靠shell脚本去管理这些启动的服务,况且,服务的治理怎么办?于是谷歌对于这个技术上的难题,就推出了Kubernetes(K8s)功能强大的容器编排系统,简单理解就是可以控制哪个容器启动。常见的服务编排系统还有ESC、Nomad和Mescos。所以在基础设施云计算这一部分,添加了Kubernetes这部分。也就是其一整套的云计算的基础设施流程就是:Linux→Docker→Docker-Compose→Kubernetes。

而有了容器编排系统,也还要解决服务通信分布式日志管理容器服务性能监控****及分布式持久化,以上实现分别由:

Istio,是由谷歌、IBM及莱夫三家公司联合打造的提供一种简单的方式来为已部署的服务建立网络,且该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。且在2019年称为微服务下一代的一种标准,也称为微服务架构2.0。

分布式日志管理ELK, 是elastic公司提供的一套完整的日志收集、问题排查、全文搜索以及展示的解决方案,是三个产品的首字母缩写,分别是ElasticSearch、Logstash 和 Kibana。

Zabbix是Zabbix公司专门为监控服务器打造的一个企业级解决方案,支持实时监控数千台服务器,虚拟机和网络设备,采集百万级监控指标。它可根据采集到的度量值自动检测问题的状态,而无需连续观察采集到的度量值。

Fescar是阿里分布式事务解决方案GTS(Global Transaction Service)推出的开源版本,对业务无侵入且高性能,因为分布式事务这个技术问题的制约,要求应用在业务层面进行设计和改造。

TiDB 是一款定位于在线事务处理/在线分析处理( HTAP: Hybrid Transactional/Analytical Processing)的融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时 OLAP 等重要特性。同时兼容 MySQL 协议和生态,迁移便捷,运维成本极低。

以上都是个人理解下对于微服务2.0标准化实现三高标准且能解决微服务四大问题的一整套解决方案,也就是服务网格化(Service Mesh)的一套实现方案。以上实现基础下,总结来说:它是一种控制应用程序不同部分彼此共享数据的方式。它能够适应分布式微服务环境的独特性质。在搭建在微服务中的大规模应用程序中,有许多既定的服务实例,它们跨本地和云服务器运行。所有这些移动部件显然使得各个微服务难以找到他们需要与之通信的其他服务。Service mesh可以在短时间内自动处理发现和连接服务,而无需开发人员以及各个微服务自行匹配。

当然,并不是说只要学会了以上各种高逼格的框架就是学会了Service Mesh,就能实现百万级并发架构或亿级并发架构,没有实战都是纸上谈兵。

本篇只是作为一个开发者对service mesh的方向及落地的粗浅理解,真正理解Service Mesh还需不断的理论结合实战,总结。

之后可能会从云计算开始做一系列实战的教程,为了提高语言组织能力、写作能力及系统化总结这段时间学习的东西。

最后:

有术无道,止于术;有道无术,术尚可求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值