架构演进过程
- 单体架构
- 垂直结构
- SOA架构
- 微服务架构
单体架构：
全部功能 都在一个项目中 （All in one）
优点：架构简单，前期开发成本低，开发周期短，适合小型架构
缺点：
- 大型项目不易开发、拓展、维护
- 技术栈受限制
- 系统性能拓展，只能通过拓展集群节点，成本高(如果 一个单体有用户、商品等架构，如果商品上架过多，增加节点，用户模块也跟着变多了，不需要过多的用户模块，造成不必要的浪费)
垂直架构
将大的业务，进行分割，形成单体项目
优点：技术栈可扩展
缺点：
- 功能集中，不利于开发，维护
- 项目之间出现功能、数据冗余、耦合性强
- 系统扩张，也只能通过集群的方式
SOA架构
面向服务的架构，
将重复功能、模块抽取出来，形成服务，谁需要，直接调用就行。
优点：
- 可重新用强
- 可维护性高
- 开发效率高
缺点：
- 各个系统之间，很难确定功能、模块是不是重复的
- 抽取服务粒度大（对比分布式微服务）
- 系统与服务之间耦合性高
微服务架构
将项目中的服务层，完全抽取出来，形成一个个微服务
抽取粒度更细，遵循单一原则
采用轻量级框架协议传输（HTTP）
优点：
- 服务粒度更细，有利于提高学习效率
- 适用于互联网时代，迭代更新块
缺点：
- 粒度分的更细，维护成本高
- 开发成本技术过高，团队挑战难度高
Apache Dubbo
简介：是一款Java RPC 框架，前身是阿里巴巴高性能、轻量级Java RPC框架，可以与Spring框架无缝衔接
场景：A服务与B服务不在一个服务器上，A想调用B 就需要PRC
PRC 就是远程调用的过程，不是具体的技术
Dubbo的优点
- 自动注册与发现
- 面向接口的RPC远程调用
- 智能容错、负载均衡
- 可视化的服务治理与运维
- 运行期流量调度
SOA架构、微服务架构都可以使用dubbo
重点是 ：服务提供者、服务消费者、注册中心，监控中心就无所谓了
虚线代表异步请求、蓝虚线代表启动时完成、实现是真实工作执行的功能
Dubbo有那些注册中心？
- zookeeper中心
- redis注册中心
- 基于key-Map形式存储
- key存储的是服务名和类型
- Map的key存的是URL，value存的是过期时间
Dubbo的负载均衡有那些策略？
- 随机算法：随机调用服务
- 轮询：一个接替一个服务
- 最低活跃调用：调用最少活跃的服务
- 一致Hash策略：
Dubbo的执行流程
- 启动注册服务地址
- 访问注册中心的订阅服务的地址。
- 变更时，重新向消费者推送心的生产者地址。
- 随机调用服务提供者，如果失败了，就重试新的地址。
- 后台服务监控中心定期去收集服务的调用次数、时间等信息。
Zookpeper
zookeper是dubbo官方建议使用的注册中心
Zookpeper是树状目录服务
首先 根节点存储的是Dubbo，然后下面存储服务，每个服务下面有它的类型，每个类型下面都记录这进程的地址。
Zookeper安装
https://blog.csdn.net/zlbdmm/article/details/109669049
可查看本站：https://www.zanglikun.com/430.html
Duboo admin
下载地址：https://github.com/apache/dubbo-admin
可查看：本站：https://www.zanglikun.com/313.html
特殊说明：
上述文章均是作者实际操作后产出。烦请各位，请勿直接盗用！转载记得标注原文链接：www.zanglikun.com
第三方平台不会及时更新本文最新内容。如果发现本文资料不全，可访问本人的Java博客搜索：标题关键字。以获取最新全部资料 ❤
第三方平台不会及时更新本文最新内容。如果发现本文资料不全，可访问本人的Java博客搜索：标题关键字。以获取最新全部资料 ❤
评论(0)