dubbo官网上描述的架构的发展

dubbo官网上的图和介绍

背景

1.单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM,如Hibernate,mybatis)是关键。

ORM框架:

提供了数据库中的表与持久化类的映射关系,ORM框架就能参照mapper文件,将对象持久化到数据库中的对应表

• 表===>类

• 记录===>对象

• 字段===>对象的属性

2.垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC,Model View Controller)是关键。

MVC与三层架构的区别:

三层架构是一种架构模式,重视层次结构,每一个层完成同一类型的操作

mvc是一种设计模式,不存在明显的层次结构,controller建立model与view的联系

它们就不是同一种类型的东西.不过可以同时存在,bs处理业务时可以使用三层架构

架构:一个蓝图,一种设计方案,将不同需求抽象为组件,描述这些组件的之间的通信和调用

框架:它们互相协作提供了针对某个给定的问题领域中的应用程序所用到的一种可复用的体系结构。

设计模式:是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，它强调的是一个设计问题的解决方法。	

一个架构可能用到多个框架和设计模式;框架是针对共性抽象出来的半成品,可能包含多个设计模式;设计模式是为了解决单一问题经过总结给出的一套解决方案

三层架构基于业务逻辑来分

是一种系统架构,属于宏观的解决方案,可以应用在任何语言\任何技术的应用程序,解决在业务操作过程中不同阶段代码的封装问题,为了使程序员更关注某阶段的业务逻辑.职责分离

结构清晰,耦合度低,可维护性\扩展性高,哪个地方出了问题,就找哪层,不会影响整个系统

就是说要解耦合,不要都放在一起,又要考虑业务逻辑\又要关心数据的存储\打印日志\记录时间,而是分成多层,每层都只专注自己想要做的事,方便代码复用.

如果程序需要,可以分为多层.大多数分为3层

UI:界面层(表现层),与用户交互的界面,显示数据,接收用户输入的数据
BLL:业务逻辑层,接收界面层传递的数据,根据不同的需求处理数据
DAL:数据访问层(持久层),执行对数据的增删改查,操作数据库

MVC基于页面来分

cs架构需要更新客户端,很麻烦,但是体验好;bs只需要电脑上有个浏览器

是一种设计模式,只是解决BS应用程序视图层和各部分的耦合关系.如展示数据的html与业务代码分离,独立到View中;与用户交互的程序逻辑放在controller中;在view和controller传递数据使用专门封装数据的实体类对象,统称为Model

M:model模型层,负责业务逻辑和数据库交互
V:view视图层,展示数据和发起请求
C:controller控制层,接收请求,调用M处理拿到结果交给V

3.分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

分布式就是拆拆拆

由于一台服务器承受不住压力,把一个业务拆分多个子业务，部署在不同的服务器上，每个服务器都完成不同的业务。通过rpc或webservice进行通信，为了完成共同的任务而协调工作，利用更多的服务器，处理更多的数据。但用户访问时,感觉是一个整体
当其中一个子业务崩了，这个业务就垮了

注意只有当使用一台计算机无法处理日益增长的计算，存储任务时，且提升硬件性能的代价高昂到得不偿失、程序也不能进一步优化，才需要考虑分布式

拆分方式分为垂直拆分和水平(横向)拆分

水平拆分:把视图层+控制层部署在服务器A,service和dao层部署在服务器B,
A中只需要调用B中的service完成服务

垂直拆分:根据业务进行拆分,把一个项目拆分成多个项目,拆分后的项目仍然可以作为独立的项目使用

RPC:

远程过程调用,是一种进程间通信方式,允许程序调用另一个地址空间的函数(说人话就是老板隔空喊话,跨国指挥员工)

集群：

同一个业务，部署在多个服务器上
哪个服务器压力少，就交给谁处理

(分布式+集群)先将一个业务拆分多个子业务，再将每个子业务集群部署

4.流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

SOA:

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

5.微服务架构

诞生:

随着服务不断的被拆分和分解,变得非常的细粒度.直到微服务架构的诞生

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

微服务是将模块拆分成一个独立的服务单元通过接口来实现数据的交互

一个小服务只提供一个功能，做一件事,可以单独部署运行。

每个服务都运行在独立的进程中,服务与服务之间通过rpc完成沟通
每个服务可以围绕业务,选择适合的语言、工具进行构建

与SOA架构的区别:

微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。

微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。

与分布式的区别:

分布式架构和微服务都是将一个系统划分为多个模块。分布式架构的目标是一台机器承受不了访问，不得不使用多台机器完成部署。微服务的目标是让各个模块拆分，某模块的升级或出现问题不会影响其它模块，可以在一台机器上部署

带来的问题:

服务之间依赖关系错综复杂，当调用某个服务失败该找谁，多个消费者时如何确保服务质量，当服务升级后，如果出现意外，如果控制不影响其它服务

https://blog.csdn.net/weixin_53173799/article/details/113698377

客户端如何访问服务

服务之间如何通信

这么多服务,如何查找

服务挂了怎么办

SpringCloud解决以上微服务架构的问题

负载均衡，网关路由：高可用、集群部署，校验、请求转发、服务集成。
服务治理：服务注册、发现。
容错：避免雪崩。熔断机制,服务降级
监控跟踪：监控资源利用、服务响应、容器资源利用情况。
消息总线：消息队列、异步通信。
配置管理：统一配置管理。