分布式微服务架构设计原理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
架构特点
SOA在这一时代的数据通信格式通 常为XML,因为XML标记定义在大 规模、高并发通信过程中,冗余的 标记会给性能带来极大的影响,所 以后来被JSON所取代
架构特点
SOA通过定义标准的对外接口,可以让底层通用服务进 行下沉,供多个上层的使用方同时使用,增加了服务的 可重用性
架构特点
SOA可以让企业最大化地使用内部 和外部的公共服务,避免重复造轮 子,例如:通过SOA从外部获取时 间服务。
1.1 从传统 单体架构到 服务化架构
01
1.1.1 JEE架构
02
1.1.2 SSH架构
ห้องสมุดไป่ตู้
03
1.1.3 服务化架构(SOA,代表面向服 务的架构)
1.1 从传统单体架构到服务化架构
1.1.1 JEE架构
以Java标准版为基
础进行扩展,将企业
1
软件架构分为三层
该架构缺点
5
该架构下典型的职能 团队划分如图
与SOA服务化的对
比
02
1.2.2 微服务架构 与传统单体架构的
对比
01
1.2.1 微服务架构
的产生
1.2 从服 务化到微 服务
1.2.1 微服务架构的产 生
Web Service 的 问题
01
02
ESB 的问题
问题是驱动人类进 步原动力,所以促 使了微服务的产生
03
1.2.1 微服 务架构的产 生
2020
1.分布式微服务架构设计原理
演讲人
2 0 2 5 - 11 - 11
目录
1.1 从传统单体架构到服务 化架构
1.2 从服务化到微服务
1.3 微服务架构的核心要点 和实现原理
1.5 服务化管理和治理框架 的技术选型
1.4 Java平台微服务架构的 项目组织形式
01
1.1 从传统单体架构到服务化架构
1.1 从传统单体架构到服务化架构
1.1.2 SSH架构
在JEE开始流程但 没有完全奠定其地
位时,开源软件 status、Spring 和Hibernate开
始展露头角
SSH时代的架构 如图
SSH缺点
在JEE开始流程但没有完全奠定其地位时,开源软件status、Spring和Hibernate开始展露 头角
实现SOA的 两个主流实
现方式
Web Service 分支主题
ESB 分支主题
根据以上分析,我们看到企业服务总线是ESB的核心要素, 所有服务都可以在总线上插拔,并通过总线的流程编排和协 议转接能力来组合实现业务处理能力。
02
1.2 从服务化到微服务
1.2 从服务化到微服务
03
1.2.3 微服务架构
1.2 从服务化 到微服务
1.2.2 微服务架构与传统单体架构 的对比
微服务架构图
通过对比来看,微服 务架构更灵活并且可 水平伸缩,可以让专 业的人来做专业的事
1.1.3 服务化架构(SOA,代表面向服务的架构)
架构特点
架构特点
SOA定义了良好的对外接口,通 过网络协议对外提供服务,服务 之间表现为松耦合性,松耦合性 具有灵活的特点,可以对服务流 程进行灵活组装和编排,而不需 要对服务本身做改变
架构特点
组成整个业务流程的每个服务的 内部结构和实现在发生改变时, 不影响整个流程对外提供服务, 只要对外的接口保持不变,则改 变服务内部的实现机制对外部来 说可以是透明的
4
将不同的模块化组件
2
聚合后运行在通用的
应用服务器上
3
该时代的典型架构如 图
以Java标准版为基础进行扩展,将企业软件架构分为三层
Web层
负责与用户交互或者 对外提供接口
1
数据存取层
将业务逻辑层处理的
结果持久化以待后续
3
查询,并维护领域模 型中对象的生命周期
2
业务逻辑层
为了实现业务逻辑而 设计的流程处理和计 算处理模块
将不同的模块化组件聚合后运行在通用的应用服务器上
WebLogic
01
02
WebSphere
To mca t
仅实现了JEE Web规范的Web 容器
04
03
JBoss
该时代的典型架构 如图
分支主题
该架构下典型的职能团队划 分如图
分支主题
该架构缺点
01
每层的多个业务逻辑实现会被 放在同一应用项目中
分支主题
SSH缺点
1
单体化
2
服务的粒度抽象为模块 化组件
3
所有组件耦合在一个开 发项目中,并且配置和 运行在一个JVM进程中
4
某个模块化组件需要升级 上线,则会导致其他没有 变更的模块化组件同样上
线
5
严重情况下,对某个模块 化组件的变更,由于种种 原因,会导致其他模块化
组件出现问题
1.1 从传统单体架构到服务化架构
Hibernate 作为对象模型和关系模型之间的纽带(对象关系映射层)
在JEE开始流程但没有完全奠定其地位时,开源软件status、Spring和Hibernate开始展露 头角
随着时间的发展,高度抽象的ORM框架被证明性能有瓶颈,因此,后来大家更倾向于使 用更加灵活的MyBatis来实现ORM
SSH时代的架构 如图
Web Service 的问题 依赖中心化的服务发现机制
使用SOAP通信协议,通常使用XML格式来序列化通信数据,XML格式的数 据冗余太大。协议太重 服务化管理和治理设施并不完善 ESB 的问题
ESB虽然是SOA实现的一种方式,却更多地提现了系统集成的便利性,通过 统一的服务总线将服务组合在一起,并提供组合的业务流程服务 组合在ESB上的服务本身可能是一个过重的整体服务,或者是传统的JEE服务 等 ESB视图通过总线来隐藏系统内部的复杂性,但是系统内部的复杂性任然存在 对于总线本身的中心化管理模型,系统变更影响的范围经常会随之扩大 问题是驱动人类进步原动力,所以促使了微服务的产生
02
运行在同一个JVM中
03
尽管公司会使用规范来约束, 但是随着复杂业务逻辑的迭代 增加及开发人员的不断流动, 新手工程师为了节省时间和赶 进度,非法使用了其它组件服 务,业务组件之间、UI组件之 间、数据存取之间的耦合性必 然增加,最后导致组件与组件 之间难以划清界限,完全耦合 在一起,将来的新功能迭代、 增加和维护将难上加难。
Web MVC 框架 Struts在交互的UI层进一步划分了前端的职责(Web层)
开源框架Spring发布,更加改变了JEE一开始指定的战略目标(业务逻辑层) 两个核心思想
IOC 控制翻转 AOP 面向切面编程
在JEE开始流程但没有完全奠定其地位时,开源软件status、Spring和Hibernate开始展露 头角