架构演进过程

  • 单体架构
  • 垂直结构
  • 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有那些注册中心?
zoonekeeper中心
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

初步部署Dubbo

Duboo admin

下载地址:https://github.com/apache/dubbo-admin