详解微服务架构及其演进史

目录
  • 1 传统单体系统介绍
    • 1.1 单体系统的问题
    • 1.2 单体系统的优点
    • 1.3 单体服务到微服务的发展过程
  • 2 关于微服务
    • 2.1 单一职责
    • 2.2 轻量级通信
    • 2.3 独立性
    • 2.4 进程隔离
    • 2.5 混合技术栈和混合部署方式
    • 2.6 简化治理
    • 2.7 安全可靠,可维护。
  • 3 微服务演进史
    • 3.1 第一阶:简单服务通信模块
    • 3.2 第二阶:原始通信时代
    • 3.3 第三阶:TCP时代
    • 3.4 第四阶:第一代微服务(Spring Cloud/RPC)
    • 3.5 第五阶:第二代微服务
    • 3.6 第六阶:第一代Service Mesh
    • 3.7 第七阶:第二代Service Mesh

1 传统单体系统介绍

物理服务器的CPU、内存、存储器、连接数等资源有限,单体系统能够承受的的QPS也是有限的,某个时段大量连接同时执行操作,会导致web服务和数据库服务在处理上遇到性能瓶颈。

为了解决这个问题,伟大的前辈们发扬了分而治之的思想,对大数据库、大表进行分割,可以参考我的《Mysql数据库分库分表全面瓦解》,以便实施更好的控制和管理。

同时创建多个服务实例,使用多台服务机进行CPU、内存、存储的分摊,提供更好的性能。

1.1 单体系统的问题

1、复杂性高:由于是一个单体的系统,所以整个系统的模块是耦合在一起的,模块的边界比较模糊、依赖关系错综复杂。功能的调整,容易带来不可知的影响和潜在的bug风险。

2、服务性能问题:单体系统遇到性能瓶颈问题,只能横向扩展,增加服务实例,进行负载均衡分担压力。无法纵向扩展,做模块拆分。

3、扩缩容能力受限:单体应用只能作为一个整体进行扩展,影响范围大,无法根据业务模块的需要进行单个模块的伸缩。

4、无法做故障隔离:当所有的业务功能模块都聚集在一个程序集当中,如果其中的某一个小的功能模块出现问题(如某个请求堵塞),那么都有可能会造成整个系统的崩溃。

5、发布的影响范围较大:每次发布都是整个系统进行发布,发布会导致整个系统的重启,对于大型的综合系统挑战比较大,如果将各个模块拆分,哪个部分做了修改,只发布哪个部分所在的模块即可。

1.2 单体系统的优点

1、系统的简易性:系统语言风格、业务结构,接口格式均具有一致性,服务都是耦合在一起的,不存在各个业务通信问题。

2、易于测试:单体应用一旦部署,所有的服务或特性就都可以使用了,简化了测试过程,无需额外测试服务间的依赖,测试均可在部署完成后开始。

3、易于部署与升级:相对于微服务架构中的每个服务独立部署,单体系统只需将单个目录下的服务程序统一部署和升级。

4、较低的维护成本:只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统,微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集,成本呈指数级增长。

1.3 单体服务到微服务的发展过程

EUREKA的注册中心逐渐被ZooKeeper和Nacos等替代了。

2 关于微服务

微服务是 一种架构模式,是面向服务的体系结构(SOA)软件架构模式的一种演变,

它提倡将单一应用程序 划分成一组松散耦合的细粒度小型服务,辅助轻量级的协议,互相协调、互相配合,为用户提供最终价值。

所以,微服务(或微服务架构)是一种云原生架构方法,其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常包含如下特点:

2.1 单一职责

微服务架构中的每个节点高度服务化,都是 具有业务逻辑的,符合高内聚、低耦合原则以及单一职责原则的单元,包括数据库和数据模型;

不同的服务通过“管道”的方式灵活组合,从而构建出庞大的系统。

2.2 轻量级通信

通过REST API模式或者RPC框架,实现服务间互相协作的轻量级通信机制。

2.3 独立性

在微服务架构中,每个服务都是独立的业务单元,与其他服务高度解耦,只需要改变当前服务本身,就可以完成独立的开发、测试、部署、运维。

2.4 进程隔离

在微服务架构中,应用程序由多个服务组成,每个服务都是高度自治的独立业务实体,可以运行在独立的进程中, 不同的服务能非常容易地部署到不同的主机上,实现高度自治和高度隔离。

进程的隔离,还能保证服务达到动态扩缩容的能力,业务高峰期自动增加服务资源以提升并发能力,业务低谷期则可自动释放服务资源以节省开销。

2.5 混合技术栈和混合部署方式

团队可以为不同的服务组件使用不同的技术栈和不同的部署方式(公有云、私有云、混合云)。

2.6 简化治理

组件可以彼此独立地进行扩缩容和治理,从而减少了因必须缩放整个应用程序而产生的浪费和成本,因为单个功能可能面临过多的负载。

2.7 安全可靠,可维护。

从架构上对运维提供友好的支撑,在安全、可维护的基础上规范化发布流程,支持数据存储容灾、业务模块隔离、访问权限控制、编码安全检测等。

3 微服务演进史

我们前面已经了解了微服务的概念,通过百度指数可以看出,从2012年之后,微服务的发展有显著的发展趋势。

目前业内的微服务相关开发平台和框架还是比较多的,比如较早的Spring Cloud(使用Eureke做服务注册与发现,Ribbon做服务间负载均衡,Hystrix做服务容错保护),

阿里的Dubbo,微软的.Net体系微服务框架 Service Fabric,再到后来进阶的服务网格(Service Mesh,如 Istio、Linkerd)。

那从12年开始到现在,微服务到底发展到哪个阶段了,在各个阶段的进阶过程中,又有哪些的变化。所以我们需要了解微服务技术的历史发展脉络。

下面的内容参考了 Phil Calçado的文章《Pattern: Service Mesh》,从开发者的视角,详细分析了从微服务到Service Mesh技术的演进过程,这边做了进一步的整理和总结。

3.1 第一阶:简单服务通信模块

这是最初的模样,开发人员最开始的时候想象的两个服务间简单的通信模式,抽象表示如下,两个服务之间直接进行通信:

3.2 第二阶:原始通信时代

上面的方式非常简单,但实际情况远比想象的复杂很多,通信需要底层字节码传输和电子信号的物理层来完成,在TCP协议出现之前,

服务需要自己处理网络通信所面临的丢包、错误、乱序、重试等一系列流控问题,因此服务实现中,除了业务逻辑外,还包含对网络传输问题的处理逻辑。

3.3 第三阶:TCP时代

TCP协议的出现,避免了每个服务自己实现一套相似的网络传输处理逻辑,解决网络传输中通用的流量控制问题。

这时候我们把处理网络传输的能力下沉,从服务的实现中抽离出来,成为操作系统网络层的一部分。

3.4 第四阶:第一代微服务(Spring Cloud/RPC)

TCP出现之后,服务间的网络通信已经不是一个难题了,所以 GFS/BigTable/MapReduce 为代表的分布式系统得到了蓬勃的发展。

这时,分布式系统特有的通信语义又出现了,如服务注册与发现、负载均衡、熔断降级策略、认证和授权、端到端trace、日志与监控等,因此根据业务需求,完成一些通信语义的实现。

3.5 第五阶:第二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能,随着技术的发展,一些面向微服务架构的通用开发框架出现了,如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等,

这些框架实现了分布式系统通信需要的各种通用语义功能:如负载均衡和服务发现等,因此一定程度上屏蔽了这些通信细节,使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

3.6 第六阶:第一代Service Mesh

上面的第二代微服务框架目前看着挺完美了,但整套微服务框架其实是很复杂的,比如Spring Cloud,聚合了很多组件。所以在实践过程中,会发现有如下诸多问题:

  • 侵入性强。想要集成SDK的能力,除了需要添加相关依赖,业务层中 入侵的代码、注解、配置,与治理层界限不清晰。
  • 升级成本高。每次升级都需要业务应用修改SDK版本,重新进行功能回归测试,并对每一台服务进行部署上线, 与快速迭代开发相悖。
  • 版本碎片化严重。由于升级成本高,而中间件版本更新快,导致 线上不同服务引用的SDK版本不统一、能力参差不齐,造成很难统一治理。
  • 中间件演变困难。由于版本碎片化严重,导致中间件向前演进的过程中就需要在代码中 兼容各种各样的老版本逻辑,带着"枷锁”前行,无法实现快速迭代。
  • 内容多、门槛高。依赖组件多,学习成本高,即使通用分布式系统屏蔽了很多的实现细节,我们引入微服务框架并熟练使用也是要花费巨大的精力的。
  • 治理功能不全。不同于RPC框架,SpringCloud作为治理全家桶的典型,也不是万能的,诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。
  • 无法实现真正意义上的语言无关性。提供的框架一般只支持一种或几种语言,要将框架不支持的语言研发的服务也纳入微服务架构中,是比较有难度的。

所以,第一代微服务架构 Service Mesh就产生了,它作为一个基础设施层,能够与业务解耦,主要解决复杂网络拓扑下微服务与微服务之间的通信,其实现形态一般为轻量级网络代理,并与应用以边车代理(SideCar)模式部署,同时对业务应用透明。

SideCar将分布式服务的通信抽象为单独一层,需要和服务部署在一起,接管服务的流量,通过代理之间的通信间接完成服务之间的通信请求。

所以在这一层中它能够实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。

如果我们从一个全局视角来看,绿色的为应用服务,蓝色的为SideCar,就会得到如下部署图:

如果我们省略去服务,只看Service Mesh的代理边车的网格应该是这样的:

流量经过的时候,会先被代理边车所劫持,然后再进入服务,所以它就是一个由若干服务代理所组成的错综复杂的网格。

3.7 第七阶:第二代Service Mesh

第一代Service Mesh由一系列独立运行的单机代理服务构成,为了提供统一的上层运维入口,演化出了集中式的控制面板,我们称之为控制面(control plane)。

控制面和所有的数据面(data plane,即代理边车)进行交互,比如策略下发、数据采集等。这就是以Istio为代表的第二代Service Mesh。

只包含控制面和数据面的 Service Mesh 服务网格全局结构图 如下:

从上面的结构图可以看出,Service Mesh 的基础设施层主要分为两部分:控制平面与数据平面。当前流行的开源服务网格 Istio 和 Linkerd 都是这种构造。

控制平面的特点:

  • 不直接解析数据包。
  • 与控制平面中的代理通信,下发策略和配置。
  • 负责网络行为的可视化。
  • 通常提供 API 或者命令行工具可用于配置版本化管理,便于持续集成和部署。

数据平面的特点:

  • 通常是按照无状态目标设计的,但实际上为了提高流量转发性能,需要缓存一些数据,因此无状态也是有争议的。
  • 直接处理入站和出站数据包,转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
  • 对应用来说透明,即可以做到无感知部署。

到这一步我们大概了解了微服务架构的演进过程,也初步了解Service Mesh技术比较于传统的微服务架构有哪些优势。

以上就是详解微服务架构及其演进史的详细内容,更多关于微服务演进史的资料请关注我们其它相关文章!

(0)

相关推荐

  • 从0到1搭建后端架构的演进(MVC,服务拆分,微服务,领域驱动)

    目录 一.MVC 二.服务拆分 三.微服务架构 四.领域驱动设计 产品是一款服务于人力资源的SaaS在线服务,面向HR有Web Android/iOS 小程序多个客户端 后端采用RESTful风格API来提供服务.主要使用Python语言,方便快速迭代. 架构的演进经历了4个大的阶段: 一.MVC 项目刚开始的时候,后端同事不超过5个,这个阶段主要的工作是实现产品的原型,没有太多的考虑架构 使用Django来快速实现功能,DB的表结构设计好之后,抽象出功能View 由于产品设计也很不完善,后端需

  • 浅谈架构模式变迁之从分层架构到微服务架构

    前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern).它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,因此,作为一个软件工程师,我们不仅要熟悉设计模式,对常见的架构模式也要熟稔于心.正如看到一个设计模式的名字脑里就能浮现出大致的结构图,当我们看到一个架构模式的名字时,也要马上想到对应的架构图及其基本特点.比如,当谈到分层架构时,我们就应该想起它的架构图是怎样

  • 详解多云架构下的JAVA微服务技术解析

    微服务生态 微服务生态本质上是一种微服务架构模式的实现,包括微服务开发SDK,以及微服务基础设施. 目前比较成熟的 JAVA 微服务生态包括 servicecomb(华为), spring-cloud (Pivotal), dubbo(阿里), tsf(腾讯)等.gRPC.Thrift 等也用于内部服务之间的通信,但是微服务基础设施比较欠缺. 核心的微服务基础设施包括:注册中心.配置中心.应用网关.此外,分布式事物管理.计划任务.调用链跟踪系统等也是微服务基础设施的组成部分.完整的微服务基础实施

  • 详解Java 微服务架构

    一.传统的整体式架构 传统的整体式架构都是模块化的设计逻辑,如展示(Views).应用程序逻辑(Controller).业务逻辑(Service)和数据访问对象(Dao),程序在编写完成后被打包部署为一个具体的应用.如图所示: 系统的水平扩展 如果要对系统进行水平扩展,通常情况下,只需要增加服务器的数量,并将打包好的应用拷贝到不同的服务器,然后通过负载均衡器(Nginx)就可以轻松实现应用的水平扩展. 整体式架构的缺点 应用复杂度增加,更新.维护困难. 易造成系统资源浪费. 影响开发效率. 应用

  • 详解微服务架构及其演进史

    目录 1 传统单体系统介绍 1.1 单体系统的问题 1.2 单体系统的优点 1.3 单体服务到微服务的发展过程 2 关于微服务 2.1 单一职责 2.2 轻量级通信 2.3 独立性 2.4 进程隔离 2.5 混合技术栈和混合部署方式 2.6 简化治理 2.7 安全可靠,可维护. 3 微服务演进史 3.1 第一阶:简单服务通信模块 3.2 第二阶:原始通信时代 3.3 第三阶:TCP时代 3.4 第四阶:第一代微服务(Spring Cloud/RPC) 3.5 第五阶:第二代微服务 3.6 第六阶

  • 微服务架构之服务注册与发现功能详解

    目录 微服务的注册与发现 1.服务注册 2.服务发现 3.注册中心 4.现下的主流注册中心 4.1 Eureka 4.1.1 介绍 4.1.2 整体架构 4.1.3 接入Spring Cloud 4.2 ZooKeeper 4.2.1 介绍 4.2.2 整体架构 4.2.3 接入Dubbo生态 4.3 Consul 4.3.1 介绍 4.3.2 整体架构 4.3.3 生态对接 4.4 总结对比 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务的注册与发现 我们前面

  • 微服务架构之服务注册与发现实践示例详解

    目录 1 服务注册中心 4种注册中心技术对比 2 Spring Cloud 框架下实现 2.1 Spring Cloud Eureka 2.1.1 创建注册中心 2.1.2 创建客户端 2.2 Spring Cloud Consul 2.2.1 Consul 的优势 2.2.2 Consul的特性 2.2.3 安装Consul注册中心 2.2.4 创建服务提供者 3 总结 微服务系列前篇 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务架构之服务注册与发现功能详解

  • 微服务架构拆分策略详解

    目录 1 微服务迁移准备 2 微服务颗粒的拆分策略 2.1 基于业务逻辑拆分 2.1.1 领域模型拆分 2.1.2 用户群体拆分 2.2 基于可扩展拆分 2.3 基于可靠性拆分 2.3.1 核心模块拆分 2.3.2 主次链路拆分 2.4 基于性能需求拆分 3 总结拆分原则 微服务架构及其演进史 微服务全景架构全面瓦解 前面我们学习了微服务的全景架构,了解到相对于传统单体架构,微服务的优势,以及系统服务化的发展趋势. 对于新启动的项目,我们在权衡之后可以大方的使用微服务架构.但其实大部分情况下,我

  • 微服务架构设计RocketMQ进阶事务消息原理详解

    目录 前言 RocketMQ事务流程概要 RocketMQ事务流程关键 实现 基础配置 引入组件 添加配置 发送半消息 执行本地事务与回查 消费消息 测试 总结 前言 分布式消息选型的时候是否支持事务消息是一个很重要的考量点,而目前只有RocketMQ对事务消息支持的最好.今天我们来唠唠如何实现RocketMQ的事务消息! Apache RocketMQ在4.3.0版中已经支持分布式事务消息,这里RocketMQ采用了2PC的思想来实现了提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败

  • 详解Rainbond内置ServiceMesh微服务架构

    目录 ServiceMesh 微服务架构对比 为何使用ServiceMesh ServiceMesh相对其他微服务架构优势 最大层度透明 学习成本低 架构灵活 ServiceMesh架构性能 ServiceMesh只对网络进行治理么? Rainbond与ServiceMesh ServiceMesh 一般的字面解释是“服务网格”,作为时下最流行的分布式系统架构微服务的动态链接器,处于服务到服务的通信的专用基础设施层,该层独立于应用程序为服务之间的通信提供轻量级的可靠传递. 如果简单的描述的话,可

  • 详解Spring Cloud微服务架构下的WebSocket解决方案

    WebSocket在现代浏览器中的应用已经算是比较普遍了,在某些业务场景下,要求必须能够在服务器端推送消息至客户端.在没有WebSocket的年代,我们使用过dwr,在那个时候dwr真实一个非常棒的方案.但是在WebSocket兴起之后,我们更愿意使用标准实现来解决问题. 首先交代一下,本篇文章不讲解WebSocket的配置,主要讲的是针对在微服务架构集群模式下解决方案的选择. 微服务架构大家应该都不陌生了,在微服务架构下,服务是分布式的,而且为了保证业务的可用性,每个服务都是以集群的形式存在.

  • 详解SpringCloud服务认证(JWT)

     - JWT JWT(JSON Web Token), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景.JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密. - JWT与其它的区别 通常情况下,把API直接暴露出去是风险很大的,不说别的

  • 使用 Apache Dubbo 实现远程通信(微服务架构)

    目录 前言 1. Dubbo 基础知识 1.1 Dubbo 是什么 1.2 Dubbo 的架构图 1.3 Spring Cloud 与 Dubbo 的区别 1.4 Dubbo 的特点 1.5 Dubbo 的 6 种容错模式容错模式 1.7 主机绑定规则 2. 构建 Dubbo 服务提供方 2.1 构建服务接口模块 2.2 添加 pom.xml 依赖文件 2.3 修改 application.yml 配置文件 2.4 在主程序类上添加注解 2.5 实现 2.1 定义的接口 3. 构建 Dubbo

随机推荐