架构演进过程

• 单体架构
• 垂直结构
• SOA架构
• 微服务架构

单体架构：

全部功能 都在一个项目中 （All in one）

优点：架构简单，前期开发成本低，开发周期短，适合小型架构

缺点：

• 大型项目不易开发、拓展、维护
• 技术栈受限制
• 系统性能拓展，只能通过拓展集群节点，成本高(如果 一个单体有用户、商品等架构，如果商品上架过多，增加节点，用户模块也跟着变多了，不需要过多的用户模块，造成不必要的浪费)

垂直架构

将大的业务，进行分割，形成单体项目

优点：技术栈可扩展

缺点：

• 功能集中，不利于开发，维护
• 项目之间出现功能、数据冗余、耦合性强
• 系统扩张，也只能通过集群的方式

SOA架构

面向服务的架构，

将重复功能、模块抽取出来，形成服务，谁需要，直接调用就行。

微服务架构

将项目中的服务层，完全抽取出来，形成一个个微服务

抽取粒度更细，遵循单一原则

采用轻量级框架协议传输（HTTP）

优点：

• 服务粒度更细，有利于提高学习效率
• 适用于互联网时代，迭代更新块

缺点：

• 粒度分的更细，维护成本高
• 开发成本技术过高，团队挑战难度高

Apache Dubbo

简介：是一款Java RPC 框架，前身是阿里巴巴高性能、轻量级Java RPC框架，可以与Spring框架无缝衔接

官方：http://dubbo.apache.org/

场景：A服务与B服务不在一个服务器上，A想调用B 就需要PRC

PRC 就是远程调用的过程，不是具体的技术

Dubbo的优点

• 自动注册与发现
• 面向接口的RPC远程调用
• 智能容错、负载均衡
• 可视化的服务治理与运维
• 运行期流量调度

SOA架构、微服务架构都可以使用dubbo

重点是 ：服务提供者、服务消费者、注册中心，监控中心就无所谓了

虚线代表异步请求、蓝虚线代表启动时完成、实现是真实工作执行的功能

Dubbo有那些注册中心？

• zookeeper中心
• redis注册中心
• 基于key-Map形式存储
• key存储的是服务名和类型
• Map的key存的是URL，value存的是过期时间

Dubbo的负载均衡有那些策略？

• 随机算法：随机调用服务
• 轮询：一个接替一个服务
• 最低活跃调用：调用最少活跃的服务
• 一致Hash策略：

Dubbo的执行流程

1. 启动注册服务地址
2. 访问注册中心的订阅服务的地址。
3. 变更时，重新向消费者推送心的生产者地址。
4. 随机调用服务提供者，如果失败了，就重试新的地址。
5. 后台服务监控中心定期去收集服务的调用次数、时间等信息。

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