爱站网官网,网站内容建设的建议,怎么在阿里巴巴做网站,软件工程技术学什么基础概念
集群
集群是将一个系统完整的部署到多个服务器#xff0c;每个服务器提供系统的所有服务#xff0c;多个服务器可以通过负载均衡完成任务#xff0c;每个服务器都可以称为集群的节点。
分布式
分布式是将一个系统拆分为多个子系统#xff0c;多个子系统部署在…基础概念
集群
集群是将一个系统完整的部署到多个服务器每个服务器提供系统的所有服务多个服务器可以通过负载均衡完成任务每个服务器都可以称为集群的节点。
分布式
分布式是将一个系统拆分为多个子系统多个子系统部署在多个服务器上多个服务器上的子系统协同完成一个特定任务。 其实并不需要特别区分集群和分布式的细微概念。如果非要细究的话分布式强调的是物理形态即工作在不同服务器上并且通过网络通信配合完成任务集群强调的是逻辑逻辑即是否为了完成特定服务目标。 主从
集群中通常有一个程序需要承担更多的责任该程序称为主程序其他承担附属职业被称为从。例如在MySQL集群中通常只有一台服务器承担写责任增删改而其他的服务器都承担读责任因此承担写责任的服务器称为主而其他负责读的服务器成为从。
微服务
简单来说微服务就是很小的服务小到一个服务器只对应一个单一的功能只做一件事并且这个服务可以单独部署运行。
本质上微服务是分布式架构的一种扩展只不过微服务的拆分粒度更小、服务器更独立。可以理解为微服务是一种经过良好架构设计的分布式架构方案。
微服务之间的通信方式有REST和RPC两种。
中间件
中间件是一种用户不同应用程序之间相互通信的软件即处于不同技术、工具和数据库之间的桥梁。例如RabbitMQ就是一个典型的中间件程序。
亿级高并发架构演进之路
单机架构
单机架构表示应用服务和数据库服务都在一台主机上。在互联网早期访问量比较小的时候单机架构足以满足要求。
如下图就是单机架构图可以看到应用和数据库在单个机器上就可以协作完成业务运作。 优点部署简单、成本低
缺点存在严重的性能瓶颈并且数据库服务和应用服务互相竞争资源
应用数据分离架构
应用数据分离架构表示应用服务和数据库服务进行拆分即两个服务使用不同的服务器进行工作。
出现原因是单机架构存在严重的资源竞争导致请求响应过慢。
如下图就是应用数据分离架构图可以看到应用服务和数据库服务在各自的服务器上通过网络协作来完成工作。 优点 成本相对可控 性能相比单机有提升 数据库单独隔离不会因为应用出现问题把数据库搞坏有一定的容灾能力
缺点 硬件成本变高 性能有瓶颈无法应对海量并发
应用服务集群架构 当上述两种架构无法解决问题时就出现了两种解决方案横向扩展水平扩展和纵向扩展垂直扩展。垂直扩展表示购买性能更优、价格更高的应用服务器来应对更高的流量这种方案并不需要对软件做任何的改变但是硬件性能提升和价格并不是线性的即两倍性能的机子价格并不是两倍而可能是三倍、四倍、五倍、六倍等等。水平扩展指的是调整软件架构将用户流量分担到不同的应用服务器上来提升系统的承载能力这种方案在价格上相对较低并且提升空间也比较大但是给系统带来了更多的复杂性需要技术团队有更丰富的经验。 水平扩展需要将用户流量分担到不同的应用服务器上这时就需要引入一个新的组件——负载均衡。常见的负载均衡算法有 公平轮询算法Round-Robin非常公平的将请求依次分发给不同的应用服务器。 非公平轮询算法Weight-Round-Robin为不同的服务器赋予不同的权重能者多劳。 一致性哈希散列算法通过计算用户的特征值例如IP地址得到哈希值根据哈希结果做分发优点是确保来自相同用户的请求总是分发给指定的服务器。 应用服务集群架构表示将应用服务部署在多个机子上以集群方式进行运行并且引入负载均衡组件保证每个机子都能收到请求。
出现原因是单个应用已经不足以支持海量的并发请求高并发时请求响应变慢。
如下图就是应用服务集群架构图从下图可以看出应用不再是一个而是变成多个通过负载均衡来支持海量数据并发。 优点 应用满足高可用不会因为一个服务出现问题而导致整个站点挂掉的情况出现 应用服务具备一定的高性能如果不访问数据库应用相关处理通过扩展可以支持海量请求快速响应 应用服务有一定扩展能力支持横向扩展
缺点 数据库成为性能瓶颈无法应对海量数据的查询 数据库是单点没有高可用 运维工作增多部署时需要同时部署多个应用需要开发对应的工具应对快速部署 硬件成本变高
读写分离/主从分离架构
读写分离/主从分离架构表示将数据库应用进行集群化部署将读写操作分散到不同的节点上即给数据库服务搭建主从集群一主一从/一主多从都可以主机负责写操作、从机负责读操作。
出现原因是应用可以高并发工作但是数据库成为了性能瓶颈而互联网应用一般读多写少因此数据库压力主要来源于读操作的那么我们就可以把读操作和写操作分开。
如下图为主从分离/读写分离架构图从下图可以看出数据库服务不再是一个而是变成了多个。数据库主机负责写操作从机负责读操作数据库主机通过复制将数据同步到从机。 优点 数据库的性能提升 读取被其他服务器承担写的性能简介提升 数据库有从库数据库的可用性提高了
缺点 热点数据的频繁读取导致数据库负载很高 当同步挂掉或者同步延迟比较大时写库和读库的数据不一致 服务器成本需要进一步提高
冷热分离架构
冷热分离架构表示引入缓存实行冷热分离将热点数据放到缓存中快速响应。
出现原因海量的请求导致数据库负载过高响应再度变慢。
如下图是冷热分离架构图可以看出增加了缓存服务器对于热点数据全部放到缓存中不常用的数据再去查询数据库。 优点 大幅度降低对数据库的访问请求性能提升非常明显
缺点 带来了缓存一致性、缓存失效、缓存击穿等多种问题
服务器成本进一步提升
业务体量变大后数据不断增加数据库单库单表体量太大数据查询变慢导致数据库再度成为性能瓶颈。
垂直分库架构 垂直分库表示将库中的表按照业务的耦合程度进行拆分分成不同的库进行处理。 垂直分表表示将标准的字段按照冷热程度进行拆分常用的字段分到一个表中不常用的字段分到另一个表中。 水平分库表示库里面的表都相同但是存储不同的数据即假设有两亿条数据并且数据的格式相同一个库中存储一亿条数据。 水平分表表示表的字段相同但是存储的数据不同即原本一个表中的数据分开存储。 简单来说无论是库还是表的拆分。水平拆分指的是将数据进行分开存储不做其他处理。垂直拆分指的是将原有的结构进行改变。 垂直分库架构表示将数据库、数据表进行拆分数据库服务分布式存储、分布式处理、分布式查询也可以理解为分布式数据库架构。
出现原因单机的写库逐渐到达性能瓶颈需要拆分数据库。数据表的数据量太大处理压力太大需要进行分表。为了解决运维难度业界逐渐研发了分布式数据库、分布式数据表例如MyCat技术栈。
如下图为垂直分库架构图可以看出数据库由多个主从库或存储集群构成支持分布式大规模处理。 优点 数据库吞吐量大幅度提升不再是性能瓶颈
缺点 跨库join、分布式事务等问题这些都需要去解决不过目前的mpp大规模并行处理都有对应解决方案 数据库和缓存结合目前能够扛住海量的请求但是应用的代码整体耦合在一起修改一行代码就会需要整体服务重新发布
微服务架构
微服务架构表示将服务按照业务板块进行拆分使单个应用的职责更加请求相互之间可以做到独立升级迭代。
出现原因 扩展性差应用程序无法轻松扩展因为每次需要更新应用时都需要重新构建整个系统 持续开发困难一个很小的代码改动也需要重新部署整个应用无法频繁并轻松的发布版本 不可靠即系统的一个功能不起作用可能导致整个系统无法工作 不灵活无法使用不同的技术构建单体应用程序 代码维护难所有的功能耦合在一起新人不知道从何下手
下图是微服务架构图可以看出一个应用拆分成了多个微服务多个服务相互之间协作支持整个应用。 优点 灵活度高服务可以独立测试、部署、升级、发布 独立扩展每个服务都可以各自进行扩展 提高容错性一个服务出现问题并不会让整个系统瘫痪 新技术的应用容易支持多种编程语言
缺点 运维复杂度高业务不断扩展应用和服务都会不断增多导致部署变得复杂并且同一台服务器上部署多个服务还要解决运行环境冲突的问题。此外对于如大促这种需要动态扩缩容的场景需要水平扩展服务的性能就需要在新增的服务上准备运行环境部署服务等运维将十分困难。 资源使用变多所有这些独立运行的微服务都需要占用内存和CPU 处理故障困难一个请求跨多个服务调用需要查看不同服务的日志完成问题定位
容器编排架构
容器编排架构就是借助容器化技术Docker将应用/服务打包为镜像通过容器编排工具K8s来动态分发和部署镜像服务以容器化方式运行。
出现原因 微服务拆分细服务多部署工作量大而且配置复杂容易出错 微服务数量多扩容麻烦而且容易出错每次缩容后又扩容需要重新配置服务对应的环境参数信息 微服务之间运行环境可能冲突需要更多的资源来进行部署或者通过修改配置来解决冲突。
如下图是容器编排架构图可以看出将每个服务打包到容器中相互协作来完成系统功能通过容器编排工具完成部署运维。 优点 部署运维快速简单一条命令就可以完成几百个服务的部署或者扩缩容 隔离性好容器与容器之间文件系统网络等互相隔离不会产生环境冲突 支持滚动更新版本间切换都可以通过一个命令完成升级或者回滚
缺点 技术栈变多对研发团队要求高 机器还是需要公司自身来管理在非大促的时候还是需要闲置大量机器资源来应对大促机器自身成本和运维成本都极高资源利用率低可以通过购买云厂商服务器来解决。
总结
单体架构应用互联网发展初期将应用服务和数据库服务都集成在一个主机上提供服务。应用数据分离架构用户量增多导致应用服务和数据库服务互相竞争资源因此将应用服务和数据服务放到不同的主机上给用户提供服务。应用集群架构用户量再次增多一个应用服务无法处理所有请求因此将应用服务以集群的方式进行部署通过负载均衡把请求分发给集群中的服务。读写分离/主从分离架构应用服务可以相对支持高可用、高并发、高性能的场景但是数据库还是那么一个因此采用主从分离架构。即将数据库服务分成多个一个主机负责写数据增删改其余从机负责读取数据。冷热分离架构不仅生活中存在二八原则在数据库服务中也同样存在二八原则即百分之二十的热点数据就可以支持百分之八十的应用。所以引入缓存服务将常用的热点数据放入缓存中不常用的数据再到数据库中查询减少数据库的请求。垂直分库架构数据库 缓存可以支持极高的请求了但是数据量过多导致查询速度变慢因此出现分库分表架构将库拆分将表拆分。微服务架构集群化应用可以解决高可用、高并发但是太过耦合所以采用微服务架构将服务进行拆分。容器编排架构微服务拆分之后虽然容错性高、灵活度高但是给运维人员带来了繁重的工作。试想一个应用就有上百个服务需要部署这是非常头大的。此时引入了容器化技术和容器编排技术可以通过简单的命令将上百个服务轻松部署。 架构的发展并不是大佬每天闲着没事研究出来的而是由于现有的架构无法支撑用户的要求因此逐渐发展出来。因此架构的出现也是随着业务的发展而出现因此我们在实际工作中不仅要了解新技术更要关注一些复杂业务的实现。 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等组件组成。
微服务的优点
易开发和维护每个微服务负责的业务比较清晰体量小开发和维护成本低。容错性高一个服务发生故障可以使故障隔离在单个服务中不影响整体服务架构。扩展性好每个服务都是独立运行的我们可以结合项目实际情况进行扩展按需伸缩。技术选型灵活每个微服务都是单独的团队来运维可以根据业务特点和团队特点选择合适的技术栈。
微服务的挑战
服务依赖随着服务数量的增多服务之间的关系也会变得复杂。一个服务的更改需要考虑对其他服务的影响。运维成本一个业务流程可能设计多个微服务共同完成有更多的服务需要编译、部署、运行甚至可能是不同的编程语言不同的运行环境当然也需要集群来处理故障转移等。这对于运维人员来说挑战无疑是巨大的。开发和测试一个业务流程可能涉及到多个微服务共同完成服务调用会引入网络延迟不可靠的网络如何进行容错处理等问题。这对于开发和测试而言难度也会提升。服务监控在一个单体结构中很容易实现服务的监控因为所有的功能都在一个服务器中。微服务架构下不仅需要对整个链路进行监控还需要对每一个服务实现监控。负载均衡微服务架构中的服务实例数量可能非常巨大因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性。
服务拆分原则
单一职责原则
单一职责原则原本是面向对象设计中的一个基本原则它指的是一个类应该专注于单一功能。不要存在多余一个导致类变更的原因。
在微服务架构中一个微服务也应该只负责一个功能或者业务领域每个服务应该有清晰的定义和边界只关注自己的特定业务领域。
服务自治
服务自治是指每个微服务都应该具备高度自治的能力即每个服务都要做到能独立开发、独立测试、独立构建、独立部署、独立运行。
单向依赖
微服务之间要做到单向依赖严禁循环依赖、双向依赖。 如果一些业务场景中存在循环依赖或者双向依赖采用其他方式解决比如分布式消息等。
