后续会慢慢更新0.0
单体架构?
- 将所有的功能,模块都耦合集中在一个应用服务器中 单体架构也叫单体系统
优点
-
部署简单
-
项目易于管理
缺点
-
可伸缩性差
-
可靠性差
-
跨语言程度差
-
测试成本高
-
迭代困难
-
团队协作困难
特点
-
会以一个进程的方式去运行
-
打成一个唯一的jar包或者是war包
微服务架构?
解释
微服务是一种架构风格。提倡将单一应用拆分为多个小模块 进行完全的解耦和 每一个服务运行在自己独立的进程中 服务之间项目配合 相互协调来完成一个完整的系统 一个大型的复杂软件应用,由一个或多个微服务组成。系统中 的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任 务并很好的完成该任务
优点
-
可伸缩性强
-
可靠性强
-
跨语言程度强
-
测试容易
-
迭代容易
-
团队协作方便
缺点
-
运维成本高 部署数量较多
-
接口兼容多版本
-
分布式系统的复杂性
-
分布式事务问题
常见的架构风格?
-
面向服务的架构风格(SOA)
-
基于组件的架构风格(EJB)
-
分层的架构风格(MVC)
-
客户端与服务端的架构风格
-
微服务架构风格
微服务的设计原则?
-
AKF设计原则 重点
-
前后端分离原则
-
无状态服务
-
RestFul 风格API
为什么要使用MQ消息队列?
- 同步变异步
- 假设一个订单系统 订单成功之后需要发短信 发邮件 等操作 是同步的话就需要等待操作 全部结束之后才返回给用户 就增长的用户的等待时间 如果使用MQ系统的话 我们可以直接将发送短信邮件的业务交给MQ系统去处理 我们接受到订单系统处理之后就直接返回给用户订单成功了
- 解耦
- 原本我们的每个模块都是直接耦合的 使用MQ之后 我们的订单服务就只需要请求MQ即可 具体的操作由MQ系统完成 接触我们的订单系统和其他模块的耦合度
- 流量削峰
- 在秒杀服务中 我们通过MQ的消息队列 可以对大并发流量进行控制 从而抑制大量的请求涌向服务器 造成服务器宕机
BASE理论?
- 基本可用
- 就是当系统发生错误时 需要保证核心服务可用
- 软状态[柔性事务]
- 允许系统中存在中间状态 这个状态不影响系统可用性 这里指的是CAP中的不一致
- 最终一致性
- 可能两台服务主机数据库不能够马上进行数据同步 但是在过一段时间他们的数据还是会一致性的进行同步 所以称为最终一致性
什么是服务注册中心?
-
服务注册中心是实现服务化管理的核心组件 主要用来存储服务信息 服务注册中心是SOA架构中基础的设施之一
-
作用?
- 服务的注册
- 服务的发现
-
解决了什么问题?
- 服务管理
- 当服务群体庞大的时候 每一个服务的IP和端口号是记不住的 所以需要服务注册中心来帮助我们解决这个问题
- 服务与服务之间的依赖关系
- 一个微服务项目中 每一个服务肯定是有相互依赖的 很少有没有依赖单独完成一个功能的 这些依赖关系可能会非常复杂 那么通过注册中心 我们可以全部注册到注册中心中 然后通过在注册中心中调用具体的服务即可
- 服务管理
什么是Eureka注册中心?
- 是NetFix开发的服务发现组件 本身就是一个服务 不过后来SpringCloud将他集成到了子项目spring-cloud-netfix中 以实现Spring Cloud 的服务注册与发现 同时还提供了 负载均衡 故障转移等能力
CAP 定理?
C 一致性
A 高可用性
P 分区容错性
是指在一个分布式系统中一致性 高可用性 分区容错性不可兼得
Zookeeper 和 Eureka 区别 ?
-
从CAP定理的角度来对比的话 Zookeeper保留了 CP Eureka保留了 AP 两者都是保留了分区容错特性
-
Zookeeper中的C呢时数据一致性的保障 这也是它先天的一个优势 P 呢是通过主从复制的形式来保证的中的数据不会丢失 但是如果数据量过大在进行复制的时候可能就会造成等待时间过长从而放弃了A特性
-
Eureka呢没有保留数据的一致性而是保留了高可用性和分区容错性 之所以说Eureka具有高可用性是因为Eureka具有自我保护的功能 当一个服务没有在规定时间内发送心跳 那么Eureka就会进入保护状态 不会直接将其删除 那么在一定时间内 该服务又恢复了运作 即还可以正常工作 分区容错性是节点和节点之间传递数据的
-
Dubbo集成 Zookeeper 支持Dubbo Eureka 不支持Dubbo
-
Spring Cloud 集成 Zookeeper 已支持 Eureka已支持
-
watch支持 zookeeper是使用监听的方式来监视数据变化的 Eureka是使用轮询的方式来监视数据的变化的
-
KV服务 zookeeper 支持数据存储 Eureka不支持数据存储
-
使用接口 多语言能力 zookeeper提供客户端 Eureka是使用Http多语言的
-
集群监控 zookeeper不支持 Eureka可以使用Metries来监视集群状态
Eureka 比 zookeeper 好在哪里?
- 综上所述 Eureka可以很好的应对网络故障失去部分节点 而zookeeper可能会使整个注册服务瘫痪
Eureka 自我保护条件?
- 一般情况下,微服务在 Eureka 上注册后,会每 30 秒发送心跳包,Eureka 通过心跳来 判断服务时候健康,同时会定期删除超过 90 秒没有发送心跳服务
- 有两种情况会导致 Eureka Server 收不到微服务的心跳
-
是微服务自身的原因 也就是说的是单点故障
-
是微服务与 Eureka 之间的网络故障
- 考虑到这个区别,Eureka 设置了一个阀值,当判断挂掉的服务的数量超过阀值时, Eureka Server 认为很大程度上出现了网络故障,将不再删除心跳过期的服务
-
Eureka自我保护阀值是多少呢?
- 15 分钟之内是否低于 85%; Eureka Server 在运行期间,会统计心跳失败的比例在 15 分钟内是否低于 85% 这种算法叫做 Eureka Server 的自我保护模式。