架构解耦优化PPT课件_第1页
架构解耦优化PPT课件_第2页
架构解耦优化PPT课件_第3页
架构解耦优化PPT课件_第4页
架构解耦优化PPT课件_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

架构解耦优化 周万宝 产品生命周期 随着产品的不断发展 复杂度不断增加 生产率 Features数量 下降 质量 Bugs 不受控制 稳定性 Fluctuation 变差 架构变得腐化 目录 提供全局的原则 模式 最佳实践和工具集整理现有领域间 模块间的关系分析问题 制定优化方案架构优化实施与治理 架构优化原则 1 单一职责2 领域内聚3 抽象接口隔离4 重用5 管理架构资产 模块解耦模式 1 模块重新划分表现 一个模块在领域中内聚性不强 而和某个领域的耦合性很强解决方案 模块重新划分领域 保持领域及模块的内聚性 必要的情况下可以拆分该模块到不同领域 模块解耦模式 2 通用抽象模式表现 各领域实现了相同或相近的业务逻辑 导致维护工作量大 架构不一致解决方案 抽象出各领域的通用逻辑 并在应用框架 ApplicationFramework 上进行实现 各领域继承该通用逻辑 并且可以插入扩展点 各领域实现差异化实现插件 模块解耦模式 3 消除强耦合 循环依赖 解耦方式 根据耦合关系的处理方式 分为耦合上升耦合下沉回调依赖倒置消除耦合关系 数据解耦模式 1 数据共享模式表现 相同或相关数据在跨领域被创建 转换或传输 存在重复 冲突等问题根据策略提供多种解决方案 1 数据重新划分领域 如足够通用的数据划分到通用基础数据供各业务领域共享 而错误划入通用基础数据的业务数据被重新划入业务领域 2 跨领域的复杂数据 划分抽象通用数据及和业务领域相关数据 采用通用数据共享 而和业务相关的数据则分业务领域存储 3 通用数据分领域视图 对有领域通用并且有业务组织权限的数据 对各不同领域提供不同视图 数据解耦模式 2 数据拆分模式表现 集中数据方式下 当企业的业务量激增后 导致集中式数据库成为整个系统的性能瓶颈解决方案 分领域拆分各自的数据Schema 逻辑上进行拆分 可以根据业务量的需求 部署在一个数据库实例 或者分领域部署在不同的数据库实例中 架构最佳实践 1 API抽象 服务 层问题 各领域之间存在直接调用 互相循环调用 甚至不合理调用的情况 各领域之间蜘蛛网式的耦合关系 导致一个问题互相影响 问题跟踪起来困难 各领域之间很难独立发布版本 解决方案各领域之间的调用都采用标准的API方式服务接口 领域调用采用服务接口消费的调用方式统一管理 各领域之间存在了一个接口隔离层 不会导致互相影响或影响比较小 各领域在接口稳定的情况下可以独立发布版本 架构最佳实践 2 事件总线 EventBus 问题 原来的应用框架采用继承方式来提供扩展性 导致继承层次很多 逻辑复杂 框架的可维护性差 可演进性差 同时在分析问题时不知道问题出在框架还是业务 诊断成本高解决方案采用EDA架构 EventBus构成框架的核心交互组件 通过事件分类应用的不同扩展点 各层的业务根据事件定制自己的可插拔扩展插件 降低了各领域系统和框架的依赖关系 增加了框架的可扩展性和可演进性 提供框架的API及通用的服务实现 各业务领域可以跟进各自的需要进行重新实现和替换 工具集 1 模块代码依赖关系分析工具 分析各模块的依赖关系 可以生成依赖关系图2 模块代码耦合分析工具 分析各模块的实际代码依赖的调用3 依赖关系管理插件 开发工具 及持续构建依赖管理工具4 数据审计工具 可以分析模块依赖的数据是否是本领域还是跨领域 目录 提供全局的原则 模式 最佳实践和工具集整理现有领域间 模块间的关系分析问题 制定优化方案架构优化实施与治理 整理现有领域间 模块间的关系 1 通过工具 协以分析代码的方式 找出各领域 进一步是各模块 之间的依赖关系2 数据的依赖通过使用的ORM和SQL进行分析3 分类是数据依赖 还是代码层次的依赖 是领域间依赖还是模块间依赖4 依赖是否是必须的依赖 不必要的依赖后面都会消除依赖关系 整理现有领域间 模块间的关系 5 分领域分工梳理 每个领域需要提交梳理结果6 重现每个领域的模块关系 及梳理出各领域之间的关系 模块关系现状很复杂 就类似于下图的意大利面条似的关系网 模块之间的关系图 目录 提供全局的原则 模式 最佳实践和工具集整理现有领域间 模块间的关系分析问题 制定优化方案架构优化实施与治理 分析问题 制定优化方案 整体架构优化 分层 基础设施 服务管理 基础服务 应用框架 基础数据 SCM FI HR MM OA 服务注册和消费 Event 分析问题 制定优化方案 根据解耦模式 制定各个模块对应的解耦方案 以消除强耦合依赖关系对于不必要的依赖 必须给出消除的方案 如依赖关系下降到通用模块 完全消除依赖关系等等数据依赖比代码依赖更难处理 谨慎处理数据依赖 包括数据的转换 迁移的成本 影响到对客户迁移的成本需要权衡利弊 并不是完美的解耦就好 而是权衡的结果 目录 提供全局的原则 模式 最佳实践和工具集整理现有领域间 模块间的关系分析问题 制定优化方案架构优化实施与治理 设立专项分组实施 1 设立系统解耦专项小组 制定解耦项目开发计划 各领域分工2 架构部提供解耦方法和规范集供各领域参考 各领域分析依赖关系和制定优化方案3 架构部组织各领域评审解耦方案4 根据计划分工实施5 制定各模块的依赖关系 解耦后的Project要通过依赖管理的构建 制定治理策略并实施 1 服务的治理构建统一的服务管理平台 每个领域把自己的服务注册发布服务到服务中心 而消费方领域则注册消费服务到服务中心 跨领域必须提供服务平台进行服务调用 禁止直接调用 根据需要各领域可以集中部署 采用Local调用 或者分布式部署 采用Remote调用 服务的调用提供统一的平台进行监控和管理 制定治理策略并实施 2 依赖关系管理为防止系统的进一步腐化 模块之间的依赖必须管理起来 依赖不能随意添加 必须通过在设计层面统一考虑 持续集成代码构建时检查依赖关系 不符合依赖关系的会导

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论