【微服务】初识(day1)

基础概念

集群

集群是将一个系统完整的部署到多个服务器,每个服务器提供系统的所有服务,多个服务器可以通过负载均衡完成任务,每个服务器都可以称为集群的节点。

分布式

分布式是将一个系统拆分为多个子系统,多个子系统部署在多个服务器上,多个服务器上的子系统协同完成一个特定任务。

其实,并不需要特别区分集群和分布式的细微概念。如果非要细究的话,分布式强调的是物理形态,即工作在不同服务器上并且通过网络通信配合完成任务;集群强调的是逻辑逻辑,即是否为了完成特定服务目标。

主从

集群中,通常有一个程序需要承担更多的责任,该程序称为主程序,其他承担附属职业被称为从。例如,在MySQL集群中,通常只有一台服务器承担写责任(增删改),而其他的服务器都承担读责任,因此承担写责任的服务器称为主,而其他负责读的服务器成为从。

微服务

简单来说,微服务就是很小的服务,小到一个服务器只对应一个单一的功能,只做一件事,并且这个服务可以单独部署运行。

本质上,微服务是分布式架构的一种扩展,只不过微服务的拆分粒度更小、服务器更独立。可以理解为:微服务是一种经过良好架构设计的分布式架构方案。

微服务之间的通信方式有REST和RPC两种。

中间件

中间件是一种用户不同应用程序之间相互通信的软件,即处于不同技术、工具和数据库之间的桥梁。例如RabbitMQ就是一个典型的中间件程序。

亿级高并发架构演进之路

单机架构

单机架构表示应用服务和数据库服务都在一台主机上。在互联网早期,访问量比较小的时候,单机架构足以满足要求。

如下图就是单机架构图,可以看到应用和数据库在单个机器上就可以协作完成业务运作。

优点:部署简单、成本低

缺点:存在严重的性能瓶颈,并且数据库服务和应用服务互相竞争资源 

应用数据分离架构

应用数据分离架构表示应用服务和数据库服务进行拆分,即两个服务使用不同的服务器进行工作。

出现原因是单机架构存在严重的资源竞争,导致请求响应过慢。

如下图就是应用数据分离架构图,可以看到,应用服务和数据库服务在各自的服务器上通过网络协作来完成工作。 

优点:

 成本相对可控

 性能相比单机有提升

 数据库单独隔离,不会因为应用出现问题把数据库搞坏,有一定的容灾能力

缺点:

 硬件成本变高

 性能有瓶颈,无法应对海量并发 

应用服务集群架构

当上述两种架构无法解决问题时,就出现了两种解决方案:横向扩展(水平扩展)和纵向扩展(垂直扩展)。垂直扩展表示购买性能更优、价格更高的应用服务器来应对更高的流量,这种方案并不需要对软件做任何的改变,但是硬件性能提升和价格并不是线性的,即两倍性能的机子价格并不是两倍,而可能是三倍、四倍、五倍、六倍等等。水平扩展指的是调整软件架构,将用户流量分担到不同的应用服务器上,来提升系统的承载能力,这种方案在价格上相对较低,并且提升空间也比较大,但是给系统带来了更多的复杂性,需要技术团队有更丰富的经验。

水平扩展需要将用户流量分担到不同的应用服务器上,这时就需要引入一个新的组件——负载均衡。常见的负载均衡算法有:

公平轮询算法Round-Robin:非常公平的将请求依次分发给不同的应用服务器。

非公平轮询算法Weight-Round-Robin:为不同的服务器赋予不同的权重,能者多劳。

一致性哈希散列算法:通过计算用户的特征值(例如IP地址)得到哈希值,根据哈希结果做分发,优点是确保来自相同用户的请求总是分发给指定的服务器。

应用服务集群架构表示将应用服务部署在多个机子上,以集群方式进行运行,并且引入负载均衡组件,保证每个机子都能收到请求。

出现原因是单个应用已经不足以支持海量的并发请求,高并发时请求响应变慢。

如下图就是应用服务集群架构图,从下图可以看出,应用不再是一个,而是变成多个,通过负载均衡来支持海量数据并发。

优点:

 应用满足高可用,不会因为一个服务出现问题而导致整个站点挂掉的情况出现

 应用服务具备一定的高性能,如果不访问数据库,应用相关处理通过扩展可以支持海量请求快速响应

 应用服务有一定扩展能力,支持横向扩展

缺点:

 数据库成为性能瓶颈,无法应对海量数据的查询

 数据库是单点,没有高可用

 运维工作增多,部署时需要同时部署多个应用,需要开发对应的工具应对快速部署

 硬件成本变高 

读写分离/主从分离架构

读写分离/主从分离架构表示将数据库应用进行集群化部署,将读写操作分散到不同的节点上,即给数据库服务搭建主从集群,一主一从/一主多从都可以,主机负责写操作、从机负责读操作。

出现原因是应用可以高并发工作,但是数据库成为了性能瓶颈,而互联网应用一般读多写少,因此数据库压力主要来源于读操作的,那么我们就可以把读操作和写操作分开。

如下图为主从分离/读写分离架构图,从下图可以看出,数据库服务不再是一个,而是变成了多个。数据库主机负责写操作,从机负责读操作,数据库主机通过复制将数据同步到从机。

优点:

 数据库的性能提升

 读取被其他服务器承担,写的性能简介提升

 数据库有从库,数据库的可用性提高了

缺点:

 热点数据的频繁读取导致数据库负载很高

 当同步挂掉,或者同步延迟比较大时,写库和读库的数据不一致

 服务器成本需要进一步提高 

冷热分离架构

冷热分离架构表示引入缓存,实行冷热分离,将热点数据放到缓存中快速响应。

出现原因:海量的请求导致数据库负载过高,响应再度变慢。

如下图是冷热分离架构图,可以看出增加了缓存服务器,对于热点数据全部放到缓存中,不常用的数据再去查询数据库。

优点:

 大幅度降低对数据库的访问请求,性能提升非常明显

缺点:

 带来了缓存一致性、缓存失效、缓存击穿等多种问题

服务器成本进一步提升

业务体量变大后,数据不断增加,数据库单库单表体量太大,数据查询变慢,导致数据库再度成为性能瓶颈。

垂直分库架构

垂直分库表示将库中的表按照业务的耦合程度进行拆分,分成不同的库进行处理。

垂直分表表示将标准的字段按照冷热程度进行拆分,常用的字段分到一个表中,不常用的字段分到另一个表中。

水平分库表示库里面的表都相同,但是存储不同的数据,即假设有两亿条数据,并且数据的格式相同,一个库中存储一亿条数据。

水平分表表示表的字段相同,但是存储的数据不同,即原本一个表中的数据分开存储。

简单来说,无论是库还是表的拆分。水平拆分指的是将数据进行分开存储,不做其他处理。垂直拆分指的是将原有的结构进行改变。

垂直分库架构表示将数据库、数据表进行拆分,数据库服务分布式存储、分布式处理、分布式查询,也可以理解为分布式数据库架构。

出现原因:单机的写库逐渐到达性能瓶颈,需要拆分数据库。数据表的数据量太大,处理压力太大,需要进行分表。为了解决运维难度,业界逐渐研发了分布式数据库、分布式数据表,例如MyCat技术栈。

如下图为垂直分库架构图,可以看出,数据库由多个主从库或存储集群构成,支持分布式大规模处理。

 优点:

 数据库吞吐量大幅度提升,不再是性能瓶颈

缺点:

 跨库join、分布式事务等问题,这些都需要去解决,不过目前的mpp(大规模并行处理)都有对应解决方案

 数据库和缓存结合目前能够扛住海量的请求,但是应用的代码整体耦合在一起,修改一行代码就会需要整体服务重新发布

微服务架构

微服务架构表示将服务按照业务板块进行拆分,使单个应用的职责更加请求,相互之间可以做到独立升级迭代。

出现原因:

 扩展性差,应用程序无法轻松扩展,因为每次需要更新应用时,都需要重新构建整个系统

 持续开发困难,一个很小的代码改动,也需要重新部署整个应用,无法频繁并轻松的发布版本

 不可靠,即系统的一个功能不起作用,可能导致整个系统无法工作

 不灵活,无法使用不同的技术构建单体应用程序

 代码维护难,所有的功能耦合在一起,新人不知道从何下手

下图是微服务架构图,可以看出,一个应用拆分成了多个微服务,多个服务相互之间协作支持整个应用。

 优点:

 灵活度高,服务可以独立测试、部署、升级、发布

 独立扩展,每个服务都可以各自进行扩展

 提高容错性,一个服务出现问题并不会让整个系统瘫痪

 新技术的应用容易,支持多种编程语言,

缺点:

 运维复杂度高,业务不断扩展,应用和服务都会不断增多,导致部署变得复杂,并且同一台服务器上部署多个服务还要解决运行环境冲突的问题。此外,对于如大促这种需要动态扩缩容的场景,需要水平扩展服务的性能,就需要在新增的服务上准备运行环境,部署服务等,运维将十分困难。

 资源使用变多,所有这些独立运行的微服务都需要占用内存和CPU

 处理故障困难,一个请求跨多个服务调用,需要查看不同服务的日志完成问题定位

容器编排架构

容器编排架构就是借助容器化技术(Docker)将应用/服务打包为镜像,通过容器编排工具(K8s)来动态分发和部署镜像,服务以容器化方式运行。

出现原因:

 微服务拆分细,服务多部署工作量大,而且配置复杂,容易出错

 微服务数量多扩容麻烦,而且容易出错,每次缩容后又扩容需要重新配置服务对应的环境参数信息

 微服务之间运行环境可能冲突,需要更多的资源来进行部署或者通过修改配置来解决冲突。

如下图是容器编排架构图,可以看出,将每个服务打包到容器中,相互协作来完成系统功能,通过容器编排工具完成部署运维。

 优点:

 部署运维快速简单,一条命令就可以完成几百个服务的部署或者扩缩容

 隔离性好,容器与容器之间文件系统,网络等互相隔离,不会产生环境冲突

 支持滚动更新,版本间切换都可以通过一个命令完成升级或者回滚

缺点:

 技术栈变多,对研发团队要求高

 机器还是需要公司自身来管理,在非大促的时候,还是需要闲置大量机器资源来应对大促,机器自身成本和运维成本都极高,资源利用率低,可以通过购买云厂商服务器来解决。

总结

  1. 单体架构:应用互联网发展初期,将应用服务和数据库服务都集成在一个主机上提供服务。
  2. 应用数据分离架构:用户量增多,导致应用服务和数据库服务互相竞争资源,因此将应用服务和数据服务放到不同的主机上给用户提供服务。
  3. 应用集群架构:用户量再次增多,一个应用服务无法处理所有请求,因此将应用服务以集群的方式进行部署,通过负载均衡,把请求分发给集群中的服务。
  4. 读写分离/主从分离架构:应用服务可以相对支持高可用、高并发、高性能的场景,但是数据库还是那么一个,因此采用主从分离架构。即将数据库服务分成多个,一个主机负责写数据(增删改),其余从机负责读取数据。
  5. 冷热分离架构:不仅生活中存在二八原则,在数据库服务中也同样存在二八原则,即百分之二十的热点数据就可以支持百分之八十的应用。所以,引入缓存服务,将常用的热点数据放入缓存中,不常用的数据再到数据库中查询,减少数据库的请求。
  6. 垂直分库架构:数据库 + 缓存可以支持极高的请求了,但是数据量过多,导致查询速度变慢,因此出现分库分表架构,将库拆分,将表拆分。
  7. 微服务架构:集群化应用可以解决高可用、高并发,但是太过耦合,所以采用微服务架构,将服务进行拆分。
  8. 容器编排架构:微服务拆分之后,虽然容错性高、灵活度高,但是给运维人员带来了繁重的工作。试想一个应用就有上百个服务需要部署,这是非常头大的。此时引入了容器化技术和容器编排技术,可以通过简单的命令将上百个服务轻松部署。

架构的发展并不是大佬每天闲着没事研究出来的,而是由于现有的架构无法支撑用户的要求,因此逐渐发展出来。因此,架构的出现也是随着业务的发展而出现,因此我们在实际工作中,不仅要了解新技术,更要关注一些复杂业务的实现。

SpringCloud

在Java后端技术栈中,一般是离不开Spring家族的,同样,微服务架构也是和Spring家族息息相关。值得提及的是,SpringCloud并不是实现了所有的微服务架构,他只是把一些比较优秀的微服务架构进行了整合。它基于自己的风格,对这些组件进行封装,屏蔽掉了原来复杂的配置和实现原理,为开发者提供了开箱即用的微服务开发体验。在SpringCLoud中,比较优秀的微服务框架有SpringCloudNetflix和SpringCloudAlibaba两家。

SpringCloud声称要做分布式微服务架构的一站式解决方案,其中的组件有:

  • 分布式版本配置
  • 服务注册和发现
  • 路由
  • 服务调用
  • 负载均衡
  • 断路器
  • 分布式消息

SpringCloudNetflix

SpringCloudNetflix是NetFlix OSS在SpringCloud规范下的实现,包含的组件及其主要功能大致如下:

  • Eureka:服务注册和发现
  • Zuul:服务网关
  • Ribbon:负载均衡
  • Feign:服务调用
  • Hystrix:断路器,例如熔断、限流等
  • Hystrix Dashboard:监控面板

在很长一段时间内,SpringCloud一度被泛指为SpringCloudNetflix。SpringCloud一直以来把Netflix套件作为官方默认的一站式解决方案。然而,2018时其公司宣布其核心组件进入维护状态,不再进行更新,SpringCloud也被迫宣布删除这些维护模块。

不过,Eureka仍在活跃范围中,利用是Netflix公司将其开源处理。

SpringCloudAlibaba

SpringCloudAlibaba是阿里巴巴集团下的开源组件在SpringCloud规范下的实现。

如果说Netflix的产品是SpringCloud的第一代实现,那么可以说阿里巴巴的产品就是SpringCloud的第一代实现,主要是由Nacos、Sentinel、Seata等组件组成。

微服务的优点

  1. 易开发和维护,每个微服务负责的业务比较清晰,体量小,开发和维护成本低。
  2. 容错性高,一个服务发生故障,可以使故障隔离在单个服务中,不影响整体服务架构。
  3. 扩展性好,每个服务都是独立运行的,我们可以结合项目实际情况进行扩展,按需伸缩。
  4. 技术选型灵活,每个微服务都是单独的团队来运维,可以根据业务特点和团队特点,选择合适的技术栈。

微服务的挑战

  1. 服务依赖,随着服务数量的增多,服务之间的关系也会变得复杂。一个服务的更改,需要考虑对其他服务的影响。
  2. 运维成本,一个业务流程可能设计多个微服务共同完成,有更多的服务需要编译、部署、运行,甚至可能是不同的编程语言,不同的运行环境,当然也需要集群来处理故障转移等。这对于运维人员来说,挑战无疑是巨大的。
  3. 开发和测试,一个业务流程可能涉及到多个微服务共同完成,服务调用会引入网络延迟,不可靠的网络,如何进行容错处理等问题。这对于开发和测试而言,难度也会提升。
  4. 服务监控,在一个单体结构中,很容易实现服务的监控,因为所有的功能都在一个服务器中。微服务架构下,不仅需要对整个链路进行监控,还需要对每一个服务实现监控。
  5. 负载均衡,微服务架构中的服务实例数量可能非常巨大,因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性。

服务拆分原则

单一职责原则

单一职责原则原本是面向对象设计中的一个基本原则,它指的是一个类应该专注于单一功能。不要存在多余一个导致类变更的原因。

在微服务架构中,一个微服务也应该只负责一个功能或者业务领域,每个服务应该有清晰的定义和边界,只关注自己的特定业务领域。

服务自治

服务自治是指每个微服务都应该具备高度自治的能力,即每个服务都要做到能独立开发、独立测试、独立构建、独立部署、独立运行。

单向依赖

微服务之间要做到单向依赖,严禁循环依赖、双向依赖。

 如果一些业务场景中存在循环依赖或者双向依赖,采用其他方式解决,比如分布式消息等。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/55248.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

免费录屏软件工具:助力高效屏幕录制

录屏已经成为了一项非常实用且广泛应用的技术。无论是制作教学视频、记录游戏精彩瞬间,还是进行软件操作演示等,我们都常常需要一款可靠的录屏软件。今天,就让我们一起来探索那些功能强大录屏软件免费版,看看它们是如何满足我们多…

Leecode刷题之路第六天之Z字形变换

题目出处 06-Z字形变换 题目描述 个人解法 思路: todo 代码示例:(Java) todo复杂度分析 todo 官方解法 06-Z字形变换官方解法 方法1:利用二维矩阵模拟 思路: 代码示例:(Java&am…

蓝桥杯【物联网】零基础到国奖之路:十五. 扩展模块之双路ADC

蓝桥杯【物联网】零基础到国奖之路:十五. 扩展模块之双路ADC 第一节 硬件解读第二节 CubeMX配置第三节 代码编写 第一节 硬件解读 STM32的ADC是12位,通过硬件过采样扩展到16位,模数转换器嵌入到STM32L071xx器件中。有16个外部通道和2个内部通道&#xf…

MongoDB微服务部署

一、安装MongoDB 1.在linux中拉去MongoDB镜像文件 docker pull mongo:4.4.18 2. 2.创建数据挂载目录 linux命令创建 命令创建目录: mkdir -p /usr/local/docker/mongodb/data 可以在sshclient工具查看是否创建成功。 进入moogodb目录,给data赋予权限777 cd …

后台管理系统脚手架

后台管理系统脚手架 介绍 在快速迭代的软件开发世界里,时间就是生产力,效率决定成败。对于构建复杂而庞大的后台系统而言,一个高效、可定制的后台脚手架(Backend Scaffold)无疑是开发者的得力助手。 脚手架 后台脚…

自动驾驶系列—自动驾驶发展史介绍

🌟🌟 欢迎来到我的技术小筑,一个专为技术探索者打造的交流空间。在这里,我们不仅分享代码的智慧,还探讨技术的深度与广度。无论您是资深开发者还是技术新手,这里都有一片属于您的天空。让我们在知识的海洋中…

C语言、Eazy_x——井字棋

#include<graphics.h>char board_data[3][3] { { -,-,-},{ -,-,-},{ -,-,-}, };char current_piece o;//检测指定棋子玩家是否获胜 bool CheckWin(char c) {if (board_data[0][0] c && board_data[0][1] c && board_data[0][2] c)return true;if (…

WPS使用越来越卡顿

UOS统信wps频繁的使用后出现卡顿问题&#xff0c;通过删除或重命名kingsoft文件缓存目录。 文章目录 一、问题描述二、问题原因三、解决方案步骤一步骤二步骤三 一、问题描述 用户在频繁的使用wps处理工作&#xff0c;在使用一段时间后&#xff0c;用户反馈wps打开速度慢&…

c++primier第十二章类和动态内存

本章内容包括&#xff1a; 对类成员使用动态内存分配隐式和显式地复制构造函数隐式和显式地重载赋值操作符在构造函数中使用new所必须完成的工作使用静态类成员 将布局new操作符用于对象使用指向对象的指针实现队列抽象数据类型(ADT) 动态内存和类 复习范例和静态类成员 首…

《动手学深度学习》笔记2.2——神经网络从基础→进阶 (参数管理-每层的权重/偏置)

目录 0. 前言 正文&#xff1a;参数管理 1. 参数访问 1.1 [目标参数] 1.2 [一次性访问所有参数] 1.3 [从嵌套块收集参数] 2. 参数初始化 2.1 [内置初始化] 2.2 [自定义初始化] 2.3 [参数绑定-共享参数] 3. 小结&#xff08;第2节&#xff09; 4. 延后初始化 (原书第…

AR 眼镜之-蓝牙电话-来电铃声与系统音效

目录 &#x1f4c2; 前言 AR 眼镜系统版本 蓝牙电话 来电铃声 系统音效 1. &#x1f531; Android9 原生的来电铃声&#xff0c;走的哪个通道&#xff1f; 2. &#x1f4a0; Android9 原生的来电铃声&#xff0c;使用什么播放&#xff1f; 2.1 来电铃声创建准备 2.2 来…

国庆普及模拟2总结

目录 题目链接&#xff1a; 官方题解&#xff1a; 概述&#xff1a; 总结反思&#xff1a; 题目 T1: 题目分析&#xff1a; 错误代码&#xff1a; 错因&#xff1a; &#xff21;&#xff23;代码&#xff1a; T2&#xff1a; 题目分析&#xff1a; 赛时代码&#xf…

LeetCode[中等] 55.跳跃游戏

给你一个非负整数数组 nums &#xff0c;你最初位于数组的 第一个下标 。数组中的每个元素代表你在该位置可以跳跃的最大长度。 判断你是否能够到达最后一个下标&#xff0c;如果可以&#xff0c;返回 true &#xff1b;否则&#xff0c;返回 false 。 思路 贪心算法 可达位置…

CSS中字体图标的使用

引言&#xff1a; 在网页设计当中&#xff0c;会有很多很简洁的图标&#xff0c;比如箭头&#xff0c;照相机&#xff0c;放大镜等 这些大概率都是使用字体图标来完成的&#xff0c;因为字体图标比较简洁高效&#xff0c;不会像图片一样需要向浏览器请求数据。那么字体图标该…

记一次vue路由跳转登陆之前的页面,参数丢失问题

一、背景 vue3.0,项目登陆之前访问某个可访问的页面,当跳转到需要登陆才能访问的页面时,跳转到登陆页面,登陆后再跳转到登陆之前需要登陆才能访问的页面,跳转时发现参数丢失了。 A页面(无需登陆)===> B页面(需要登陆)====> 如果未登陆跳转到C登陆页面 ===>…

什么是文件完整性监控(FIM)

组织经常使用基于文件的系统来组织、存储和管理信息。文件完整性监控&#xff08;FIM&#xff09;是一种用于监控和验证文件和系统完整性的技术&#xff0c;识别用户并提醒用户对文件、文件夹和配置进行未经授权或意外的变更是 FIM 的主要目标&#xff0c;有助于保护关键数据和…

《NoSQL》非关系型数据库MongoDB 学习笔记!

Mongo基础&#xff1a; 使用数据库&#xff1a; 使用use 命令 后面跟着要使用的数据库名字即可&#xff0c; 例如&#xff1a;use cities, 值得注意的是&#xff0c; mongo中不像mysql&#xff0c; 还需要先创建数据库&#xff0c;后访问&#xff0c; mongo中&#xff0c;你无…

数据库管理-第246期 为啥有些老板瞧不上技术(20241002)

数据库管理246期 2024-10-02 数据库管理-第246期 为啥有些老板瞧不上技术&#xff08;202401002&#xff09;1 背景2 割裂3 感触总结 数据库管理-第246期 为啥有些老板瞧不上技术&#xff08;202401002&#xff09; 作者&#xff1a;胖头鱼的鱼缸&#xff08;尹海文&#xff09…

leetcode:380. O(1) 时间插入、删除和获取随机元素

实现RandomizedSet 类&#xff1a; RandomizedSet() 初始化 RandomizedSet 对象bool insert(int val) 当元素 val 不存在时&#xff0c;向集合中插入该项&#xff0c;并返回 true &#xff1b;否则&#xff0c;返回 false 。bool remove(int val) 当元素 val 存在时&#xff0…

数据仓库简介(一)

数据仓库概述 1. 什么是数据仓库&#xff1f; 数据仓库&#xff08;Data Warehouse&#xff0c;简称 DW&#xff09;是由 Bill Inmon 于 1990 年提出的一种用于数据分析和挖掘的系统。它的主要目标是通过分析和挖掘数据&#xff0c;为不同层级的决策提供支持&#xff0c;构成…