dubbo(1)-架构的演变

2024-05-02 09:08
文章标签 架构 dubbo 演变

本文主要是介绍dubbo(1)-架构的演变,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

架构演变:

1. 单体应用

All in one ,一个系统包含所有的功能。项目比较大。eg:一个商城系统,系统中包含了很多功能,订单功能,用户功能,物流功能,购物车功能。

  1. 刚开始,打成一个war包,部署服务。网站访问量小,流量少,完全可以支撑。

  2. 随着流量越来越多,已经不足以支撑流量,我们需要进行优化和扩展单体应用。怎么扩展呢。

    分为水平扩展和垂直扩展:

水平扩展:就是多搞几台机器,多部署几台机器,起到分流的作用。

垂直扩展:对于硬件来说就是换更厉害的机器。换牛逼的cup,硬盘等,但是这些终究是有限的。那们硬件不行,我们就来软件的。将应用拆分为互不相干的几个应用,每个应用都是一个小型的单体应用。前端 后端 数据库一应具全。也就是所谓的烟囱架构,各个应用想烟囱一样,彼此独立。这就是垂直应用架构。

2. 垂直应用架构

烟囱架构:

既然垂直应用架构是要进行系统拆分,那就是将一个大型的系统拆分成几个小的系统。其实说白了就是将大的单体应用拆分成 多个小的单体应用。这几个单体应用需要互不相干。既然互不相干就是说明每个系统能够独立的运行。所以在拆分系统的时候要注意。

信息孤岛:

eg:将商城系统拆分成订单系统,物流系统,但是订单系统和物流系统都会依赖于用户功能,所以需要在这两个子系统都实现用户模块的功能。所以用户功能相当于重复了。而且订单系统里的用户信息和物流系统里的用户信息还不能共享,这就是所谓的信息孤岛

但随着垂直应用的增多,重复功能的增多,难免需要系统之间的交互。所以也需要一种架构避免这种重复性的情况。而且前后端不分离,每次修改,都需要整个系统进行部署,所以提出分布式应用架构。

这里的框架是 mvc框架,ssh(struts+spring+heberneter),ssm(spring mvc+spring+mybaits) 等

3. 分布式架构

分布式架构包含范围很多,分布式应用、分布式网络、分布式数据库、分布式存储等。

而我们所说一般都指的是分布式应用。当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。也就是说我们将垂直架构中每个单独的系统再次拆分,前后端分离等,抽取出公共的服务等。

SOA架构是分布式架构的实现,面向服务编程架构(Service-Oriented Architecture),但是SOA提出后,真正落地实施是ESB的实现和RPC的实现。SOA将系统拆分成多个服务系统,或者服务平台,通过服务之间的相互依赖和组合共同实现系统功能。

eg:以上的商城系统,就可以拆分成订单系统,用户系统,物流系统,或者如果还需要一些文件的上传下载,可以开发一个文件服务平台,订单系统依赖用户系统,物流系统依赖用户系统,三个系统都依赖文件平台,然后前后端分离,依赖,组合各种服务实现整个商场功能功能。

3.1 SOA架构

SOA的两种实现方式:

webService+esb总线 和 微服务架构

  1. webService+esb总线就能实现整体功能。一般用于企业中一些大型项目系统的框架
  2. 微服务架构算是SOA的升级版,如果说SOA专注于将系统服务化和分散化,那么微服务更专注于将服务精细化和专业化,认为业务需要彻底的组件化和服务化。一般用于网络电商的框架。

3.2 微服务架构

微服务,微就是细小,就是在SOA的基础上将服务拆分的更细更小。

微服务架构目前主流的框架支持是dubbo 和 Spring cloud

dubbo使用RPC协议

spring cloud RustFul的http协议

而dubbo框架目前有两种看法:

  1. 认为dubbo算是SOA的一种实现,和webService+esb归为一种
  2. 任务dubbo属于微服务的一种

3.3 soa 和微服务的比较

soa的特点:

优点:
    抽取公共的功能为服务,提高开发效率,保证可重复性
    对不同的服务进行集群化部署解决系统压力,保证高效性
    基于ESB/DUBBO减少系统耦合,并且能够对所有服务系统进行整理和统一规划,ESB的使用,保证有序性
 缺点:
    抽取服务的粒度较大
    服务提供方与调用方接口耦合度较高

微服务的特点:

优点:

(1)解耦,根据功能将系统分为不同的独立运行的服务,拆分的更细更小,将原来的复杂的系统简单化,每个服务交付给不同的团队去负责,提高了开发效率。开发人员可以只关注自己的业务功能。
(2)容错性高,将错误隔离在单个服务内。
(3)技术选型灵活,不同的服务可以根据自己的需求选择不同的技术。
(4)易于扩展,可以按需扩展服务,避免资源的浪费
(5)独立部署,每个服务独立部署,当其中一个服务有需求变更时,可以只编译部署单个应用,减少了对用户的影响

缺点:(1)开发人员需要面对分布式系统的复杂性。测试更加困难,需要保证服务之间的通信;需要团队之间的协调;当用例涉及到多个服务的时候,需要实现分布式事务管理。
(2)部署比较复杂。不过现在已经提供了自动化部署的工具。
(3)增加内存开销,微服务系统用多个服务实例取代了传统垂直架构的单个服务实例。有多少服务实例,就会有多少在内存运行的开销。

区别:

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

这篇关于dubbo(1)-架构的演变的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/953902

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

【系统架构设计师】黑板架构详解

黑板架构(Blackboard Architecture)是一种软件架构模式,它模仿了多个专家系统协作解决问题的场景。在这种架构中,“黑板”作为一个中央知识库,存储了问题的当前状态以及所有的解决方案和部分解决方案。黑板架构特别适合于解决那些没有确定算法、需要多个知识源(或称为“专家”)共同作用才能解决的复杂问题。 一、黑板架构的组成 黑板架构主要由以下几个部分组成: 黑板(Blackboa

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

Arch - 演进中的架构

文章目录 Pre原始分布式时代1. 背景与起源2. 分布式系统的初步探索3. 分布式计算环境(DCE)4. 技术挑战与困境5. 原始分布式时代的失败与教训6. 未来展望 单体时代优势缺陷单体架构与微服务架构的关系总结 SOA时代1. SOA架构及其背景1. 烟囱式架构(Information Silo Architecture)2. [微内核架构](https://www.oreilly.c

新一代车载(E/E)架构下的中央计算载体---HPC软件架构简介

老规矩,分享一段喜欢的文字,避免自己成为高知识低文化的工程师: 屏蔽力是信息过载时代一个人的特殊竞争力,任何消耗你的人和事,多看一眼都是你的不对。非必要不费力证明自己,无利益不试图说服别人,是精神上的节能减排。 无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。 时间不知不觉中,快要来到夏末秋初。一年又过去了一大半,成

Linux 云计算底层技术之一文读懂 Qemu 架构

Qemu 架构概览 Qemu 是纯软件实现的虚拟化模拟器,几乎可以模拟任何硬件设备,我们最熟悉的就是能够模拟一台能够独立运行操作系统的虚拟机,虚拟机认为自己和硬件打交道,但其实是和 Qemu 模拟出来的硬件打交道,Qemu 将这些指令转译给真正的硬件。 正因为 Qemu 是纯软件实现的,所有的指令都要经 Qemu 过一手,性能非常低,所以,在生产环境中,大多数的做法都是配合 KVM 来完成