Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à 信息系统架构设计
Similaire à 信息系统架构设计 (20)
信息系统架构设计
- 1. 信 息 系 统 架 构 设 计 钟玮军 2016-10
- 2. • 现任： – 北京车网互联科技有限公司 总体架构师兼研发中心副总经理 • 过往经历： – 卓望信息技术移动飞信业务部 资深系统架构师 – 诺基亚西门子通信技术有限公司 开发工程师/团队负责人 – 中国电信 网络运行维护工程师 • 致力于： – 信息系统架构设计方法的学习、研究和应用 – 敏捷开发管理理念、技术方法在企业的传播和推广 • 倡导： – 互信、善从、爱学、乐助 • 联系方式： – 微信公众号：钟大军 关于讲师
- 4. 架构的职责要求
- 5. 本节目标 • 了解架构的职责和意义 • 了解架构的角色分类、工作内容和能力要求 • 了解架构的职业成长路径
- 6. “架构”名词的来源 最初起源于建筑领域： Architecture is both the process and product of planning, designing, and construction, usually of buildings and other physical structures. Architectural works, in the material form of buildings, are often perceived as cultural symbols and as works of art. 后被引用到IT领域
- 10. 架构师的角色分类 Enterprise Architect (Macro) Solution Architect (Point) Technical Architect (Detailed) •Business •Application •Data & Information •Technology •Security •Innovation •Product / Domain •Subject Matter Expert •Cradle to Grave •Project •Technical Services •Enabling Technology •Technology Product / Domain
- 12. 架构师的能力要求 • 架构设计方法 • 业务领域知识 • 概念化思维能力 • 技术领域知识 • 模式化抽象能力 问 题 定 义 解 决 方 案
- 13. 敏捷开发与架构设计
- 14. 架构师职业成长路径（一） Developer Solution Architect UI Architect Business Analyst Almost Anyone Business Analyst IT Support Snr Data Architect SOA Architect Snr Project Manager Infrastructu re Manager Integratio n Architect Data Architect Project Manager Infrastructu re Architect Application Architect 自哪儿来？ 参考《Career Development for Architects》，Kevin Francis
- 15. 架构师职业成长路径（二） 往哪儿去？ 参考《Career Development for Architects》，Kevin Francis Delivery Manager, etc Infrastructure Manager, etc CTOCIO Other Executive Infrastructu re Manager SOA Architect Snr Data Architect Snr Project Manager Solution Architect Enterprise Architect or Consultant
- 16. 架构师的四类不成 • 不能坚持学习的人不会成为好的架构师 • 不善沟通交流的人不会成为好的架构师 • 不会归纳总结的人不会成为好的架构师 • 不舍与人分享的人不会成为好的架构师
- 17. 知识测验 • 你听说过以下术语吗？ Zachman TOGAF TMForum Frameworks Cloud IOT BigDATA DevOps National Retail Federation ITIL SOA EDA TDD UML BPMN Design Patterns Architectur e Styles CEP … … OOAD MDD Agile Scrum KANBAN DDD CBD … … Design Principles Anything Else?
- 18. 本节回顾 • 架构的职责和意义 • 架构的角色分类、工作内容和能力要求 • 架构师的职业成长路径
- 19. 企业架构框架
- 20. 本节目标 • 了解企业架构的概念 • 了解Zachman、TOGAF等流行企业架构框架 • 通过应用案例掌握企业架构的过程和方法
- 21. 企业架构（Enterprise Architect） • 目的是将跨企业的、常为零散的那些遗留流程（人工 /自动）优化进一个集成的环境，它可以及时响应变 更并有效的支持业务战略的交付 • 有效的企业架构对企业的生存和成功具有决定性的作 用，是企业通过IT获得竞争优势的不可缺少的手段 – 业务和IT对齐的战略执行工具 – 设计、管理、沟通的工具 – 涉众对企业的as-is（现状）和to-be（优化）有一个整体、 一致的理解
- 22. 企业架构的组成 • 可以分为两大部分：业务 架构和IT架构 – 业务架构：把企业的业务 战略转化为日常运作的渠 道，业务战略决定业务架 构，它包括业务的运营模 式、流程体系、组织结构、 地域分布等内容 – IT架构：指导IT投资和设 计决策的IT框架，是建立 企业信息系统的综合蓝图， 包括数据架构、应用架构 和技术架构三部分
- 23. 企业架构框架
- 24. Zachman框架（一）
- 25. Zachman框架（二）
- 26. TOGAF框架（一） • TOGAF框架构件 – 架构开发方法 – 架构内容框架 – 企业连续系列 – 架构能力框架
- 27. TOGAF框架（二） • 架构开发方法 – 预备阶段 – 架构愿景阶段 – 业务架构阶段 – 信息系统架构阶段 – 技术架构阶段 – 机会与解决方案阶段 – 迁移规划阶段 – 实施管理阶段 – 架构变更管理过程 – 需求管理过程
- 28. TOGAF框架（三） 架构内容框架： 提供了一套架构工作产品的 详细模型，包括交付物，交 付物内的制品，以及交付物 代表的架构构建块 （ ABBs ）。 Slid 架构实现 机会及解决方案、迁移规划 工作包 架构合同 实施治理 标准 指引 规格 业务架构 动机 驱动力 目标 目的 测度 组织 组织 位置 施动者 角色 功能 业务服务 、合同、 服务质量 流程、 事件 控制、 产品 功能 信息系统架构 数据 数据实体 逻辑数据 构件 物理数据 构件 应用 信息系统 服务 逻辑应用 构件 物理应用 构件 技术架构 平台 服务 逻辑技术 构件 物理技术 构件 架构原则、愿景、和需求 预备阶段 架构原则 架构愿景 业务原则、目的 、和驱动力 架构愿景业务战略 技术战略 利益相关者 架构需求 需求 约束 假设 差距
- 32. 企业架构参考案例（二） Level 2 Processes …… 以解耦/分 解的核心 方法对业 务流程进 行逐层建 模，获得 eTOM业务 过程框架。 Level 0 Process Grouping
- 35. 企业架构参考案例（五） eTOM 0级视图 SID 1级视图 ABE：Aggregate Business Entity，ABE是SID中一组定义良 好的实体，具有高内聚、低耦合的特征。 共享信息数据模型（SID） 遵从高内聚低耦合原则， 按业务领域逐级划分和定 义业务实体对象，为企业 范围信息（数据）模型提 供了参考模型。
- 52. 本节回顾 • 企业架构的概念 • 流行企业架构框架 • 企业架构实施的过程和方法
- 53. 系统分析与设计方法
- 54. 本节目标 • 理解系统架构的本质方法 • 掌握模型驱动的系统需求分析方法 • 掌握面向服务/组件的系统架构设计方法 • 了解非功能性需求对系统架构设计的影响
- 56. 开篇 • 为什么要系统设计？
- 57. 系统设计的价值
- 58. 系统设计4+1视图
- 59. （一）系统架构的本质方法
- 60. 价 值 实 现 一个典型的“系统”架构案例 客户服 务部 销售部 华南销 售中心 华北销 售中心 资料/档 案室 项目管 理部 财务部 人力资 源部 经营管 理层协作流程 客户 客户 客户 XX公司 客户 A产品事业部 B产品事业部 C产品事业部 内部协作流程 研发中心 技术支持中心 产品中心 运营中心 XX产品 手册 XX产品 手册 XX产品 手册
- 61. 系统架构的本质方法 系统交互流程 客户 客户 客户 XX公司 客户 人力系统 业务协作流程 一级部门C 一级部门D 一级部门A 一级部门B 信息系统 系统接口协议 应用子系统C 应用子系统D 应用子系统A 应用子系统B 客户 接触 部门 /人 客户 门户 应用子系统E 二级部门E 业务协 作流程 二级部门a 二级部门b 二级部门c 三级部门d 组件接 口协议 组件 a 组件 b 组件 c 组件 d 部 门 接 口 人 系 统 接 口 服 务 价 值 实 现 • “分而治之”！ – 通过组织内部的 分工协作，提供 客户价值 • 业务角色 • 信息系统 – 通过系统内部的 分工协作，提供 用户价值 • 子系统 • 模块/组件 • 包 • 类 • …
- 63. 系统分析与设计过程 明确系统 思考边界 分析系统 对外价值 设计系统 内部实现 - 系统范围 - 思考粒度 - 外部环境 - 业务价值 - 用户价值 - 功能价值 - 静态结构 - 协作流程 - 满足非功能性需求
- 64. （二）系统需求分析与建模 • 系统需求是指： – 用户解决问题或达到目标所需的条件或能力； • 需求问题的症状： – 软件需求变更频繁，而且集中出现在项目的中后阶段
- 65. 需求变更的成因 • 分析要点： – 变更是对原需求的背离，还是补遗？ – 为什么会导致需求背离？ 没有变更是不可 能的，但是你首 先要确保真的了 解客户的“业务 动机”。
- 66. 需求的层次 业务分析 业务需求 (Epics) 用户需求 (Stories) 功能需求 (Functional) 设计 构建 软件需求的层次 需求类型 描述 业务需求 (Epics) 描述发起项目的原因、需达到的业务目标、以及衡量该项目是否成功的业务指标。 用户需求 (Stories) 描述所涉不同用户与系统接触的方式、以及他们期望协助系统所能完成的任务和目标。 功能需求 (Conversations) 是系统对于用户需求的具体实现，它定义了系统计算、数据的操作处理、用户与应用 的接口和交互，以及其它能体现用户需求如何被满足的特殊功能。 非功能需求 指的是信息系统中保证性能、可靠性、易用性、维护性、扩展性、移植性和安全性等 各类与系统运行状态有关，但与功能需求无关的需求。
- 67. 需求捕获方法 • 访谈 • 小组会议 • 问卷调查 • 其它 – 现场观摩 – 文档考古（分析用户已有的业务、信息建设的文档） – 原系统研究（现在的系统问题，改进要求） – 分析同类软件产品特性（文档或试用软件分析）
- 68. 需求分析方法 基于目标发掘与场景设置过程的需求分析方法 需求捕获渠道 • 访谈 • 小组会议 • 问卷调查 • 其它 – 现场观摩 – 文档考古（分析用户已有的业务、信息建设的文档） – 原系统研究（现在的系统问题，改进要求） – 分析同类软件产品特性（文档或试用软件分析）
- 69. 明确项目愿景
- 71. 模型驱动的系统需求分析全景视图 组织的 客户价值 业务用例视图 可视化 组织 提供 客户 消费 组织的 内部组成 组织的 内部协作 包括 包括 业务角色视图 可视化 业务过程视图 组织角色 功能职责 推导 履行 信息系统 功能职责 信息 系统 包括 系统用例视图 履行 包括 可视化 UML业务时序图 UML业务活动图UML业务用例图 包括 包括 包括 UML系统用例图 UML系统鲁棒图 辅助分析 可视化 包括 UML业务角色图 包括 补充 业务实体 对象 操作 业务实体 概念视图 UML类结构图 可视化 补充 包括 UML实体状态图 补充描述
- 72. （1）业务用例视图 注： - 考察对象是组织而不是系统 - 关注业务需求和价值而非实现 - 业务用例指组织外部可见的一个业 务功能单元，一般用动词短语简述 组织的功能 - 业务用例主执行者 - 业务用例辅执行者 - 模型元素间的几类关系 - 关联关系表示参与者与用例之间的 交互，通信途径，任何一方都可发 送或接受消息，箭头指向消息接收 方，表示主动执行还是被动执行 - 包含关系用来把一个较复杂用例所 表示功能分解成较小的步骤 - 扩展关系是指用例功能的延伸，相 当于为基础用例提供一个附加功能。 - 泛化关系是一般和特殊的关系，就 是通常理解的继承关系 业务参与者 业务用例 组织名称 组织边界 扩展关系 包含关系 泛化关系 箭头方向表示 主动执行还是 被动执行
- 73. （2）业务角色视图 注： - 业务参与者 - 在组织之外和组织交互的人群 或组织 - 业务活动的服务对象 - 业务工人 - 在组织内部承担一系列职责， 为业务执行者实现业务服务的 人 - 也包括替代人工作的内部IT系 统，即Automated Business Worker 业务参与者 业务工人 组织名称 组织边界
- 75. 业务时序图-现状建模 注： - 交互消息命名应重点区分职责而非 信息流 - 目的在于通过对业务过程的分析和 设计，快速获取系统的功能性需求 - 控制分析粒度，粗粒度系统功 能需求和职责区分 - 两步分析法 - 对业务实现现状进行建模 - 分析业务现状的痛点与不足， 优化业务流程，提取支持目标 业务流程所需的系统功能 Fragment 生命线 交互消息
- 76. 业务时序图-过程改进 注： - 依据项目愿景目标决定要优化的业 务流程和系统功能 - 可参考优化方向 - 引入自动化业务工人 - 用信息流替代物流 - 信息流的改善 - 封装领域逻辑，提供智能化
- 77. 业务活动图-细化功能交互逻辑 注： - 活动的命名应重点区分职责而非消 息流 - 优势在于支持对业务逻辑进行详细 描述 - 也用于粗粒度功能需求建模， 此时与时序图作用差别不大 - 练习 - 将买单请求之后的业务活动图 补全 信号的发 送和接收 泳道 判断分支 执行分支 活动 起始状态 终止状态
- 79. 系统用例图 注： - 系统用例的粒度控制到用户与系统 的一次事务级交互，不深入到系统 内部的实现步骤 - 用例命名反映系统功能的用户价值， 既不夸大也不缩小，用例名称与展 示层操作名称与有时一致也有时并 不一致 - 一个系统可以包括多个系统用例图， 多个系统用例图之间应体现低耦合 的原则，一个系统用例图包含耦合 度较高的一组用例。 - 首先完成核心系统用例的建模，再 逐步补充和完善其它系统用例 - 讨论 - 代客点餐与点餐是否不同用例？ - “记录已上菜”还是“上菜”？ 参与者 系统边界系统名称 系统用例 用例关系
- 80. 系统用例表示方法正误辨析
- 81. 系统用例完整性检查—鲁棒图分析法 注： - 鲁棒图表示法，采用三层架构模型 - Boundary代表系统的交互界面 或对外接口，负责与外部对象 进行交互 - Controller代表应用逻辑，负责 系统的逻辑计算和处理 - Entity代表业务实体对象，与数 据存储有关 - 鲁棒图可以快速帮助查找系统用例 的完整 - “菜单”业务实体对象只有读 操作没有写入操作？ - 初步设计，识别系统逻辑功能 - 识别建立业务实体对象模型 - 辅助划分子系统或模块，识别模块 间协作关系 Boundary Controller Entity
- 82. 鲁棒图分析法补充知识 鲁棒图的作用： - 识别建立业务实体对象模型 - 检查系统用例完整性 - 初步设计，识别系统逻辑功能 - 辅助划分子系统或模块，识别模块间协作关系 鲁棒图的规则 鲁棒图的语法
- 83. 系统用例完整性检查 – 其他涉众需求 注： - 系统实现应考虑其他涉众的需求 - 参考成熟方案可以帮助启发和挖掘 涉众需求 - Service Quality Analysis - Resource Quality Analysis - … - 与统计分析相关的系统需求要求从 业务系统用例中采集相关原始数据， 从而会影响业务系统用例的实现。
- 84. 补全系统用例 注： - 补全系统用例 - 将系统用例进行分组管理，注 意系统用例分组的合理性 - 一个系统可以包括多个系统用 例图，多个系统用例图之间应 体现低耦合的原则，一个系统 用例图包含耦合度较高的一组 用例
- 85. （5）业务实体概念视图 注： - 业务实体概念视图突出核心业务实 体对象概念以及业务实体对象概念 之间关系 - 业务实体对象概念模型与最终物理 存储模型之间可以通过ORM框架进 行映射 - 业务实体概念可以分包进行组织
- 86. （三）面向服务/组件的系统架构设计方法 • 好的系统架构的特征 – 低耦合，高内聚 – 符合责权利一致原则 • 面向服务/组件的系统架构 满足上述特征 – 重用性 – 可读性 – 扩展性 – 可测性 – 可变性 – 并行开发
- 87. 网站应用架构的演进 • 单一应用架构 – 当网站流量很小 时，只需一个应 用，将所有功能 都部署在一起， 以减少部署节点 和成本。 – 此时，用于简化 增删改查工作量 的 数据访问框架 (ORM) 是关键。 • 垂直应用架构 – 当访问量逐渐增 大，单一应用增 加机器带来的加 速度越来越小， 将应用拆成互不 相干的几个应用， 以提升效率。 – 此时，用于加速 前端页面开发的 Web框架(MVC) 是 关键。 • 分布式服务架构 – 当垂直应用越来 越多，应用之间 交互不可避免， 将核心业务抽取 出来，作为独立 的服务，逐渐形 成稳定的服务中 心，使前端应用 能更快速的响应 多变的市场需求。 – 此时，用于提高 业务复用及整合 的 分布式服务框 架(RPC) 是关键。 • 流动计算架构 – 当服务越来越多， 容量的评估，小 服务资源的浪费 等问题逐渐显现， 此时需增加一个 调度中心基于访 问压力实时管理 集群容量，提高 集群利用率。 – 此时，用于提高 机器利用率的资 源调度和治理中 心(SOA) 是关键。
- 89. 服务/组件化系统设计与SOA演进 前端逻辑 后端逻辑 后端逻辑 后端逻辑 前端逻辑 后端逻辑 后端逻辑 后端逻辑 前端逻辑 前端逻辑 后端 逻辑 后端 逻辑 后端 逻辑 模块化系统 面向接口编程 分布式SOA架构 面向服务编程 烟囱式应用 面向过程编程 动态模块化系统，如OSGI 微服务架构，如Docker Service Integration Infrastructure
- 90. 服务/组件化系统设计的特点 • 服务/组件化系统设计的特点 – 面向接口编程 – 隐藏内部实现 – 关注点分离 • 符合低耦合高内聚原则 – 可跟踪 – 可测试 – 可扩展 – 可复用
- 91. 高可复用系统组件的设计方法 • 高可复用性系统组件的设计方法 – 确定组件的职责，越单一越好（极简） – 客户使用场景的验证越多越好（极丰富） – 客户端知道内部实现细节越少，越能被复用（接口抽象） – 采用设计模式满足客户在不同场景下的使用（设计模式） – 场景驱动，迭代优化
- 92. 高可复用系统组件的设计案例 • Apache Shiro – 面向接口编程 • Subject接口向客户端提供非常清晰的 登录认证、授权检查、管理会话等功 能 • 内部子模块的设计也遵从面向接口编 程方式，易于替换内部子模块从而实 现系统的可扩展性 – 隐藏内部实现 • 客户端不需要关注用户角色权限如何 存储、会话如何存储、是否加载 Cache等内部实现，内部实现的改变 不影响客户端调用 – 关注点分离 • 只提供认证授权相关功能，不提供用 户角色权限管理功能 – 高度可扩展 • 可以与不同的用户数据存储、会话存 储、Cache等进行集成 • Token的抽象可支持不同认证方式， 密码加密的拓展
- 93. 面向服务/组件系统架构的根本方法 • 面向服务/组件系统架构的根本方法 客户 客户 信息系统 系统接口协议 应用子系统C 应用子系统D 应用子系统A 应用子系统B 系统 门户 应用子系统E 组件接 口协议 组件 a 组件 b 组件 c 组件 d 系 统 接 口 服 务
- 94. 系统划分的原则、策略和方法
- 97. （2）系统划分 – 机制的提取 • 机制提取的典型例子 -- SOA中间件
- 98. 系统划分 – 机制的提取 • 机制提取的典型例子 -- Spring Framework
- 99. 系统划分 – 机制的提取 • 机制提取的典型例子 -- 云计算生态系统
- 100. （3）系统划分 – 分区的引入 领域分区引入的案例 领域划分：核心域、支撑域和通用域
- 104. The Release Reuse Equivalency Principle（REP） The granule of reuse is the granule of release（软件包的粒度与可重用的粒度保持一致） The Common Closure Principle（CCP） Classes that change together, belong together（一致变化的类，应该属于同一个包） The Common Reuse Principle（CRP） Classes that aren’t reused together should not be grouped together（不被一起重用的类， 不放到一个包里） 高内聚（Cohesion） 面向服务/组件的系统架构设计过程
- 105. The Acyclic Dependencies Principle（ADP） The dependencies between packages must not form cycles（软件包之间不能相互依赖，构 成依赖循环） The Stable Dependencies Principle（SDP） Depend in the direction of stability（包之间的依赖关系都应该是稳定方向依赖的，包要依赖的 包要比自己更具稳定性） The Stable Abstractions Principle（SAP） Stable packages should be abstract packages（稳定的包，应该是抽象的包，以此带来可变 性） 低耦合（Coupling） 面向服务/组件的系统架构设计过程
- 107. 面向服务/组件的系统架构设计过程 • 由功能目标和内容变化的一致性决定高内聚 客户 服务 销售 资料/档 案室 项目管 理部 财务部 人力资 源部 经营管 理层协作流程 客户 客户 客户 XX公司 客户 A产品事业部 B产品事业部 C产品事业部 内部协作流程 研发中心 技术支持中心 产品中心 运营中心 买 买 买 吐 槽 吐 槽
- 109. 面向服务/组件系统架构设计过程 • 设计案例 – 京东
- 110. 面向服务/组件系统架构设计过程 • 设计案例 – 京东
- 111. 面向服务/组件系统架构设计过程 • 设计案例 – 京东
- 112. （5）CQRS架构风格 Betrand Meyer(Eiffel语言之父，开-闭原则OCP提出者)在Object Oriented Software Construction一书中提到一种命令查询分离(Command Query Separation, CQS)的 概念。 Separation of functions that write & functions that read Functions that write are called Command methods and must not return a value Functions that read are called Query methods and must have no side effects
- 113. 传统的CRUD方法的问题： 使用同一个对象实体来进行数据库读写可能会太粗糙，大多数情况下，比如编辑的时候可能只需要更新个别字段，但是却需要将整 个对象都穿进去，有些字段其实是不需要更新的。在查询的时候在表现层可能只需要个别字段，但是需要查询和返回整个实体对象。 使用同一实体对象对同一数据进行读写操作的时候，可能会遇到资源竞争的情况，经常要处理的锁的问题，在写入数据的时候，需 要加锁。读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加，并且会对系统吞吐量的增长会产生影响。 同步的，直接与数据库进行交互在大数据量同时访问的情况下可能会影响性能和响应性，并且可能会产生性能瓶颈。 由于同一实体对象都会在读写操作中用到，所以对于安全和权限的管理会变得比较复杂。 这里面很重要的一个问题是，系统中的读写频率比，是偏向读，还是偏向写，就如同一般的数据结构在查找和修改上时间复杂度不 一样，在设计系统的结构时也需要考虑这样的问题。解决方法就是我们经常用到的对数据库进行读写分离。 传统的CRUD方法
- 114. CQRS由Creg Yound在CQRS, Task Based UIs, Event Sourcing agh! 这篇文章中提出。“CQRS只是 简单的将之前只需要创建一个对象拆分成了两个对象，这种分离是基于方法是执行命令还是执行查询 这一原则来定的”。 CQRS使用分离的接口将数据查询操作(Queries)和数据修改操作(Commands)分离开，这也意味着在查询和更新过 程中使用的数据模型也是不一样的。这样读和写逻辑就隔离开了。 主数据库处理CUD，从库处理R，从库的的结构可以和主库的结构完全一样，也可以不一样，从库主要用来进行 只读的查询操作。在数量上从库的个数也可以根据查询的规模进行扩展，在业务逻辑上，也可以根据专题从主 库中划分出不同的从库。 CQRS简介
- 115. 从库也可以实现成ReportingDatabase，根据查询的业务需求，从主库中抽取一些必要的 数据生成一系列查询报表来存储。使用ReportingDatabase的一些优点通常可以使得查询 变得更加简单高效： ReportingDatabase的结构和数据表会针对常用的查询请求进行设计。 ReportingDatabase数据库通常会去正规化，存储一些冗余而减少必要的Join等联合查询操作，使得 查询简化和高效，一些在主数据库中用不到的数据信息，在ReportingDatabase可以不用存储。 可以对ReportingDatabase重构优化，而不用去改变操作数据库。 对ReportingDatabase数据库的查询不会给操作数据库带来任何压力。 可以针对不同的查询请求建立不同的ReportingDatabase库。 CQRS简介（续）
- 116. Client Commands Command Bus Sends Command Handlers Modify Repositories Read Write Data store Event Bus Command Services Event Handlers Events Read store Query HandlersQuery Results Queries Query Services Events Domain CQRS架构示意图
- 117. 寻找事件源(Event Sourcing)：聚合根 Aggregates track their own Domain Events and derive state from them OrderCreated ProductAdded ProductAdded ProductRemoved ProductAdded OrderShipped October 5 October 6 October 6 October 7 October 7 October 9 CQRS事件源
- 118. FULL CQRS with Event Sourcing: UI Domain Event Store Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth CQRS事件源(续)
- 119. FULL CQRS with Event Sourcing代码实现案例: public class CustomerCommandHandler { private Repository<Customer> customerRepository; public CustomerCommandHandler(Repository<Customer> customerRepository) { this.customerRepository = customerRepository; } @CommandHandler public void handle(UnsignCustomer cmd) { Customer customer = repository.load(cmd.getCustomerId()); customer.unsign(); } } public class Customer { private boolean signedUp; public void unsign() { if (signedUp) { apply(new CustomerUnsignedEvent()); } } @EventHandler private void handle(CustomerUnsignedEvent event) { signedUp = false; } } CQRS代码实现案例
- 120. Sales Product SKU Name Price Quantity Ordered … Inventory Service (SAP) Product SKU QOH Location Code … Pricing Service Product SKU Unit Price Promotional Price … Inventory Pricing Sales Customers New SKU Event New SKU Event New SKU Event Order AcceptedE vent MessageBus Who coordinates the sales process? Online Ordering System Web Shop (Composite UI) CQRS应用示例
- 121. 扩展新的应用功能： Sales Service Order Accepted Billing Service Shipping Process Manager (Saga) Shipping Service Online Ordering System MessageBus Order Accepted Order Accepted Customer Billed Customer Billed Ship Order Ship Order CQRS应用示例（续）
- 122. CQRS与大数据技术
- 124. 项目研发的三角关系 注： - 一般对话场景下，项目质量要求等 同于系统非功能性需求 - 系统架构设计师应在项目的范围、 成本、进度要求和项目质量之间掌 握平衡 - 重用（不要重新发明轮子） - 重构（迭代优化） - 采用框架的切面来解决 - 绝大部分系统非功能性需求可以通 过切面方式解决，而不影响系统的 功能逻辑实现
- 126. 系统安全总体架构 技术安全 管理安全 安全信息系统（技术+管理） 物理安全 网络安全 主机安全 应用安全 数据安全 管理机构 管理制度 人员管理 系统建设 运维管理 电磁防护 防潮温湿度 防雷放火 访问控制 物理位置 入侵防范 网络设备 网络审计 访问控制 网络结构 资源控制 资源保护 安全审计 访问控制 身份鉴别 代码安全 抗抵赖 安全审计 访问控制 身份鉴别 …… 数据恢复 数据备份 数据保密性 数据完整性 审核与检查 沟通与合作 授权和审批 人员配置 岗位设置 审批和修订 制定和发布 管理制度 第三方人员 教育培训 人员考核 人员离岗 人员录用 工程实施 软件开发 产品采购 方案设计 系统定级 应急预案 设备管理 介质管理 资产管理 环境管理 • 安全是一个庞大 的“系统工程” – 技术安全 • 物理安全 • 网络安全 • 主机安全 • 应用安全 • 数据安全 – 管理安全 • 管理机构 • 管理制度 • 人员管理 • 系统建设 • 运维管理
- 127. WEB网站安全通用技术措施 Web Server Firewall Apps Host Firewall Application Server Apps Host Database Server Host Database Securing the Network Router/Firewall/Switch 网络分区、端口管理、流量监控 和带宽管理、防flood攻击、入侵 检测及入侵检测防御、安全审计 认证、防病毒、防垃圾和病毒邮 件、VPN安全连接、设备账号、 网络冗余、故障恢复等 Securing the Host 系统补丁和系统更新、系统账号权限、文件目录权限、系统服务、网络端口和协议、共享资源、审 计和日志等 Securing the Application 输入验证、用户认证授权、配置安全、敏感数据、会话管理、密 码安全、参数篡改、异常管理、集群部署与负载均衡、故障恢复、 审计和日志等 Securing the Database 用户访问授权、数据加密、、 数据完整性检查、SQL注入 检查、冗余备份方案、故障 恢复 Securing the Network 网络分区隔离
- 128. 用户角色权限设计 注： - RBAC(Role-Based Access Control)， 基于角色的访问控制 - 常见问题 - 哪些是系统初始化时配置的， 哪些是系统使用中用户设置的？ - 什么是操作权限，什么是数据 权限？如何解决数据的可见性？ 隐私数据怎么保护？ - 如何解决用户权限和前端页面 展示之间的关系？ - 如何解决业务模块或业务单元 的即插性（启用或不启用）？
- 129. 用户角色权限设计 Feature 前 端 模 块 权限 includes 用户 角色 has Is a depends Feature 启停 功能定制 后 端 模 块 has 菜单 页面 元素 Initialize 服务组件 功能组件 Displayable?Accessable? 注： - 用户角色权限与业务模块的即 插即用、前端页面展示、以及 后端安全检查之间的逻辑关系。 - 扩展问题 - 用户认证和用户授权信息 的统一存储，或分离存储？ 认证信息 子系统A 子系统B 权限PA 权限PB 角色RA 角色RB
- 130. 用户角色权限设计 Application Service Domain Component 注： - 在返回给用户界面之前，隐藏和处 理部分数据内容。 - 概念辨析 - Persistence Objects - Domain Objects - Data Transfer Objects - View Objects - 扩展问题 - Domain Components返回给外 部（如Application Service 或者 另一个Domain Service）的数 据对象，应该是Domain Object、 DTO、还是别的一个什么东西？ Domain Services Domain Components UI Domain Objects Domain Repositories Data Transfer Objects View Objects Persistence Objects Persistence Objects
- 131. 日志审计 • 日志的信息结构 – WHEN：什么时候 – WHO：谁 – WHAT：做了什么 – WHY：出于什么原因 – HOW：结果怎样 • 业务日志和系统日志 – 业务日志：业务人员可读 – 系统日志：系统维护人员可读
- 133. 系统可重用性的层次 • 业务领域的相似性（TOP-DOWN） – 整体业务的相似性（业务系统） – 局部业务的相似性（业务组件） • 技术领域的相似性（BOTTOM-UP） – 开发框架的相似性（开发框架） – 技术领域的相似性（技术组件） – 算法和数据结构的相似性（技术组件）
- 134. 系统可重用性的挑战与应对措施 • 业务领域可重用性挑战 – 业务流程不同：系统可配置的业务流程 • 业务流程引擎 • Webflow – 业务规则不同：系统可配置的业务规则 • 业务规则引擎 • 业务组件代码：应用策略模式 • 技术领域可重用性挑战 – 技术环境不同 • 系统集成工具：ESB • 技术组件代码：应用适配器模式
- 135. （3）系统的高性能和高可靠性 • 系统的高性能：在用户数量激增的情况下，如何保证 系统正常且快速地工作？ • 系统的高可靠：系统如何达到 “99.999%”可操作 而不失败？
- 136. WEB服务器集群 服务器服务器 高性能/高可靠性系统架构方案 WEB Client 智能DNSCDN加速 HTTP页面缓存 反向代理服务器集群 静态内容 服务器集群 WEB服务器集群 数据本 地Cache 缓存服务器集群 分布式 Cache 数据服务器集群 主 从 分布式 Cache 数据服务器集群 主 从 数据本 地Cache 服务器服务器 数据本 地Cache 数据本 地Cache服务器 静态 html、js、 css、图 片等 服务器 静态 html、js、 css、图 片等 服 务 器 HTTP 页面缓存 服 务 器 HTTP缓存 • 提高硬件性能 • 提高软件质量 – 算法和数据结构 – 多线程/锁，NIO，… – 内存泄漏 • 启用负载均衡 – DNS/ 反向代理/分布式WEB 服务 – 数据库主从、分布式数据库 – Keep Alived • 启用缓存机制 – CDN/HTTP页面缓存 – 动静分离 – 数据缓存 • 启用分区机制 – 水平分区 – 垂直分区 • 系统监控与告警 • 服务分级与服务降级 系统监控与告警
- 138. 数据库ACID特性 • 原子性（Atomic）： – 一个事务包含多个操作，这些操作要么全部执行，要么全都不执 行。实现事务的原子性，要支持回滚操作，在某个操作失败后， 回滚到事务执行之前的状态。 • 一致性（Consistency）： – 一致性是指事务使得系统从一个一致的状态转换到另一个一致状 态。事务的一致性决定了一个系统设计和实现的复杂度。 • 隔离性（Isolation）： – 并发事务之间互相影响的程度，比如一个事务会不会读取到另一 个未提交的事务修改的数据。 • 持久性（Durability）： – 事务提交后，对系统的影响是永久的。
- 139. 两个故事 • 拜占庭将军问题（对端的可靠性） – 拜占庭帝国想要进攻一个强大的敌人，为此派出了10支军队去包围这个敌人。 这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。 基于一些原因，这10支军队不能集合在一起单点突破，必须在分开的包围状 态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队 同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵相互通信来协 商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有 叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将 军们能否找到一种分布式的协议来让他们能够远程协商，从而赢取战斗？ • 三军问题（网络的可靠性） – 白军驻扎在沟渠里，蓝军则分散在沟渠两边。白军比任何一支蓝军都更为强 大，但是蓝军若能同时合力进攻则能够打败白军。他们不能够远程的沟通， 只能派遣通信兵穿过沟渠去通知对方蓝军协商进攻时间。是否存在一个能使 蓝军必胜的通信协议？
- 141. RDBMS数据库全局事务一致性 • 数据库全局事务一致性 如果Transaction Manager(coordinator)中途发生故障怎么办？ 如果TM和Resource Manager(participant)网络故障怎么办？
- 142. 全局业务事务的一致性 • 全局业务的一致性？ – 技术人员眼中的一致性：数据库事务 – 最终客户眼中的一致性：端到端的业务 数据库 故障 网络传输 故障 应用程序 故障 机械 故障 我该怎么办？
- 143. 事务一致性的通常模式 • 两阶段提交（补偿） – 对事务的统一标识，可跟踪、 可核查是关键 – 主服务的执行记录日志 （Commit/Rollback/Recove ry）是关键 – 从服务的TCC支持是关键 • Try: 尝试执行事务 • Confirm：确认执行事务（幂 等性） • Cancel：取消执行事务（幂 等性） – 故障识别是关键 – 必要时需考虑人工干预
- 144. 数据最终一致性的实现机制
- 145. 本节回顾 • 系统架构的本质方法 • 模型驱动的系统需求分析方法 • 面向服务/组件的系统架构设计方法 • 非功能性需求对系统架构设计的影响
- 146. 软件设计原则与设计模式
- 147. 本节目标 • 了解软件设计原则 • 了解模式的概念及分类 • 熟悉软件设计模式
- 148. （一）软件设计原则 *开放封闭原则（OCP, Open Closed Principle） 模块应该对扩展开放，对更改封闭 依赖倒置原则（DIP, Dependency Inversion Principle） 依赖抽象，不要依赖实现；高层模块（稳定）不应该依赖于底层模块（变化），二者都应该依赖于抽象；抽象（稳定）不应该 依赖于实现细节（变化），实现细节应该依赖于抽象 单一职责原则（SRP, Single Responsibility Principle） 一个类应该仅有一个引起它变化的原因，应该只有一个职责；每一个职责都是变化的一个轴线，如果一个类有多个职责，这些 职责就耦合在了一起 Liskov替换原则（LSP, Liskov Substitution Principle） 子类必须能够替换它们的基类（IS-A）；如果调用的是父类的话，那么换成子类也完全可以运行 接口隔离原则（ISP, Interface Segregation Principle） 每一个接口应该是一种角色；多个客户特定的接口强于一个通用目的的接口，不应该强迫客户程序依赖它们不用的方法 SOLID原则：
- 149. *最少知识原则（迪米特法则） 一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。一个软件实体应当尽可能少的与其他实体发生相互作用；每一 个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。 针对接口编程，而不是针对实现编程 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口 优先使用对象组合，而不是类继承 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组 合则只要求被组合的对象具有良好定义的接口，耦合度低。 封装变化点 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次 间的松耦合。 软件设计原则 其它原则：
- 151. Context（语境）：设计问题产生的上下文背景 Problem（问题）：给定语境中重复出现的问题 -- 解决方案必须满足的需求 -- 你必须考虑的约束 -- 解决方案必须具有期望的特性 Solution（解决方案）：针对该问题，证实有效的解决方案 -- 规定了一个特定的结构 -- 规定了运行期间的行为 模式的构成
- 152. 架构模式 (Architecture Styles) -- 是系统的高层次策略 ，涉及到大尺度的组件以及整体性质 -- 可作为具体软件体系结构的模板，是开发一个软件系统时的基本设计决策 --规定了系统范围结构特性，架构模式的好坏影响到总体布局和框架性结构 设计模式 (Design Patterns) --是中等尺度的结构策略。实现了一些大尺度组件的行为和它们之间的关系 --模式的好坏不会影响到系统的总体布局和总体框架 --设计模式定义出子系统或组件的微观结构 代码模式 (Idioms) --是特定的范例和与特定语言有关的编程技巧 --处理特定设计问题的实现，关注设计和实现方面 --模式的好坏会影响中等尺度组件的内部、外部的结构或行为的底层细节 模式的层次分类
- 153. （三）软件设计模式
- 154. 从封装变化角度对设计模式的分类 对象创建 Factory Method Abstract Factory Prototype Builder 组件协作 Template Method Observer / Event Strategy 单一职责 Decorator Bridge 对象性能 Singleton Flyweight 接口隔离 Facade Proxy Mediator Adaptor 状态变化 Memento State 数据结构 Composite Iterator Chain of Responsibility 行为变化 Command Visitor 领域问题 Interpreter
- 155. 通过“对象创建”模式对象绕开new，来避免对象创建（new）过程中所导致 的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第 一步工作。 典型模式 Factory Method Abstract Factory Prototype Builder （1）“对象创建”相关模式
- 156. 动机 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对 象的具体类型经常变化。 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机 制”来避免客户程序和这种“具体对象创建工作”的紧耦合？ 意图 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类 Factory Method模式
- 157. 结构 适用性 当一个类不知道它所必须创建的对象的类的时候 当一个类希望由它的子类来指定它所创建的对象的时候 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类 是代理者这一信息局部化的时候。 解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同 Template Method， 具有实际的 逻辑和意义 该类型对客户端 是否隐藏呢？ Factory Method模式
- 158. 举例 你是一个ATM机软件的开发工程师，需要测试ATM软件的存取款功能，但在测 试时不想产生实际的银行业务，该怎么办呢？ public class ATMGui{ …… private Status doWithdrawal(Account account, float amount) { Transaction transaction = new Transaction(); transaction.setSourceAccount(account); transaction.setDestAccount(myCashAccount()); transaction.setAmount(amount); transaction.process(); if (transaction.successful()) { dispense(amount); } return transaction.getStatus(); } } Public class ATMGuiTest{ … … public void testCheckingWithdrawal() { float startingBalance = balanceForTestCheckingAccount(); AtmGui atm = new AtmGui(); insertCardAndInputPin(atm); atm.pressButton("Withdraw"); atm.pressButton("Checking"); atm.pressButtons("1", "0", "0", "0", "0"); assertContains("$100.00", atm.getDisplayContents()); atm.pressButton("Continue"); assertEquals(startingBalance - 100, balanceForTestCheckingAccount()); } } Factory Method模式
- 159. class Class Model EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version ATMGui + doWithdrawal() :void + createTransaction() :void MockedATMGui + createTransaction() :void ConcreteATMGui + createTransaction() :void ATMGuiTest + testCheckingWithdrawal() :void Transaction transaction = createTransactioin(); ...... return new MockedTransaction(); return new RealTransactioin(); ATMGui gui = new MockedATMGui(); ...... Factory Method模式
- 160. 动机 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求 的变化，往往存在更多系列对象的创建工作。 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来 避免客户程序和这种“多系列具体对象创建工作”的紧耦合？ 意图 提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它 们具体的类。 Abstract Factory模式
- 161. 结构 适用性 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。 当你要强调一系列相关的产品对象的设计以便进行联合使用时。 当你提供一个产品类库，而只想显示它们的接口而不是实现时。 主要用于应对“新系列”的需求变动。缺点在于难以应对“新对象”的需求变动 Abstract Factory模式
- 163. Abstract Factory模式
- 164. 动机 在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化， 这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。 如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变 对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？ 意图 使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。 Prototype模式
- 165. 结构 适用性 当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者 为了避免创建一个与产品类层次平行的工厂类层次时；或者 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆 它们可能比每次用合适的状态手工实例化该类更方便一些。 Prototype模式
- 167. 动机 在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子 对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈 的变化，但是将它们组合在一起的算法却相对稳定。 如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的 变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？ 意图 将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 Builder模式
- 168. 结构 适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 当构造过程必须允许被构造的对象有不同的表示时。 （变化点在哪里，封装在哪里）主要在于 “分步骤构建一个复杂的对象” 。其中“分 步骤”是一个稳定的算法，复杂对象的各个部分则经常变化。缺点在于难以应对“分 步骤构建算法”的需求变动。 Builder模式
- 169. 举例 ProtocolBuffer中，要实现协议类的快速序列化与反序列化，在协议类的实现中封装 了非常复杂的数据结构，而ProtocolBuffer的使用者，不希望用很复杂的方法来创建该协 议类。 message Request { // RPC service full name required string service_name = 1; // RPC method name required string method_name = 2; // RPC request proto required bytes request_proto = 3; } Request.Builder builder = Request.newBuilder(); builder.setServiceName(…); builder.setMethodName(…); builder.setRequestProto(…); Request request = builder.build(); Builder模式
- 170. 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作” 模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用 的模式。 典型模式 Template Method Observer / Event Strategy （2） “组件协作” 相关模式
- 171. 动机 在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤 却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和 任务的整体结构同时实现。 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？ 意图 定义一个操作中的算法的骨架(稳定)，而将一些步骤(变化)延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义(override 重写)该算法的某 些特定步骤。 Template Method模式
- 172. 结构 适用性 一次性实现一个算法的不变的部分，将可变的行为留给子类来实现。 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。是“重 分解以一般化”的一个很好的例子。 控制子类扩展。模板方法只在特定点调用“hook”操作（参见效果一节），这样就只 允许在这些点进行扩展。 被Template Method调用的虚方法一般推荐设置为protected。 Template Method模式
- 173. 举例 对于写Servlet的开发人员，常常只需要指定如何处理Get、Post、Put等几个少数的方法就 可以了，而对于一些复杂的处理过程，如把字节流转换为ServletRequest对象，或从字节 流中识别不同请求类型并分发到合适的处理方法，可以一概都不需要知道。 public abstract class HttpServlet extends GenericServlet implements java.io.Serializable { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { //略 … } protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String method = req.getMethod(); // 取得請求的方法 if (method.equals(METHOD_GET)) { // HTTP GET // 略... doGet(req, resp); // 略 ... } else if … } Template Method模式
- 174. 动机 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”,即一个对象 （目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如 果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。 使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而 实现软件体系结构的松耦合。 意图 定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依 赖于它的对象都得到通知并自动更新 Observer / Event模式
- 175. 结构 适用性 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的 对象中以使它们可以各自独立地改变和复用。 当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这 些对象是紧密耦合的。 Observer / Event模式
- 176. 举例 以下是采用Netty创建服务端的代码片段，利用了Java NIO非阻塞技术。 public class HelloServer { public static void main(String args[]) { // Server服务启动器 ServerBootstrap bootstrap = new ServerBootstrap(…); // 设置一个处理客户端消息和各种消息事件的类(Handler) bootstrap .setPipelineFactory(new ChannelPipelineFactory() { @Override public ChannelPipeline getPipeline() throws Exception { return Channels .pipeline(new HelloServerHandler()); } }); // 开放8000端口供客户端访问。 bootstrap.bind(new InetSocketAddress(8000)); } Observer / Event模式 private static class HelloServerHandler extends SimpleChannelHandler { // 当有客户端绑定到服务端的时候触发 @Override public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) { System.out.println("Hello world, I'm server."); } } }
- 177. 动机 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法 都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个 性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上 述问题？ 意图 定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法 可独立于使用它的客户而变化。 Strategy模式
- 178. 结构 适用性 “策略”及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方 便地根据需要在各个算法间进行切换。 提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的 数据结构。 Strategy模式
- 179. 举例 负载均衡是分布式计算中常见的问题，实现负载均衡有很多不同算法，如随机算法、 RoundRobin算法、一致性Hash算法等。(1) 运维人员可能根据需要随时调整负载均衡策 略；(2) 将来可能有更新更好的负载均衡算法。我们应该如何设计我们的分布式框架？ Protected Node getNode(LoadBalanceType type) { if (RANDOM == type) { return getRandomNode(); } else if (ROUNDROBIN == type) { return getRoundRobinNode(); } else if … } Strategy模式
- 180. 在软件组件的设计中”，如果责任划分的不清晰，使用继承得到的结果往往是随着 需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。 典型模式 Decorator Bridge （3） “单一职责”相关模式
- 181. 动机 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型 引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能 的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增 多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？ 意图 动态地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子 类更为灵活。 Decorator模式
- 182. 结构 适用性 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 处理那些可以撤消的职责。 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组 合将产生大量的子类，子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义 不能用于生成子类。 并非解决“多子类衍生的多继承”问题，应用的要点在于解决“主体类在多个方向上的扩展能 力”——是为“装饰”的含义 Decorator模式
- 184. 动机 由于某些类型的固有逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。 如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着 两个乃至多个方向变化，而不引入额外的复杂度？ 意图 将抽象部分与实现部分分离，使它们都可以独立地变化。 Bridge模式
- 185. 结构 适用性 使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可 以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。 有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个 变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。 应用一般在“两个非常强的变化强度” Bridge模式
- 187. Bridge模式
- 188. 面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通 常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的 成本必须谨慎处理。 典型模式 Singleton Flyweight （4） “对象性能”相关模式
- 189. 动机 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例， 才能确保它们的逻辑正确性、以及良好的效率。 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？这应该是类设计 者的责任，而不是使用者的责任。 意图 保证一个类仅有一个实例，并提供一个该实例的全局访问点。 Singleton模式
- 190. 结构 适用性 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个 扩展的实例时。 实例构造器可以设置为protected以允许子类派生；一般不要支持序列化和 ICloneable接口，因为有可能导致多个对象实例。 不能应对多线程环境：在多线程环境下，仍然有可能得到多个实例对象（需要加信号量） Singleton模式
- 191. 举例 每一个Java程序实际上都是启动了一个JVM进程。我们如何在Java程序中获取当前JVM的状态呢？ Runtime类封装了运行时的环境。每个 Java 应用程序都有一个 Runtime 类实例，使应用程序 能够与其运行的环境相连接。 一般不能实例化一个Runtime对象，应用程序也不能创建自己的 Runtime 类实例，但可以通过 getRuntime 方法获取当前Runtime运行时对象的引用。 一旦得到了一个当前的Runtime对象的引用，就可以调用Runtime对象的方法去控制Java虚拟 机的状态和行为。 Runtime run = Runtime.getRuntime(); System.out.println(“JVM最大内存：” + run.maxMemory()); System.out.println(“JVM空闲内存：” + run.freeMemory()); Singleton模式
- 192. 动机 采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高 的运行时代价——主要指内存需求方面的代价。 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对 象的方式来进行操作？ 意图 运用共享技术有效地支持大量细粒度的对象。 Flyweight模式
- 193. 结构 适用性 主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。 采用对象共享的做法降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。具体 实现时，要注意对象状态的处理。对象的大多数状态都可变为外部状态，如果删除对象的外部状 态，那么可以用相对较少的共享对象取代很多组对象。 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？需要根据具体应用情况进 行评估，而不能凭空臆断。 Flyweight模式
- 194. 举例 字符串在大多数应用程序中的出现频率较高，Java必须对字符串的执行进行优化以保证效率。 执行左边的代码，看看结果和你预期的是否一致？ public class StringTest { public static void main(String[] args) { String fly = "fly", weight = "weight"; String fly2 = "fly", weight2 = "weight"; System.out.println(fly == fly2); // ? System.out.println(weight == weight2); // ? String distinctString = fly + weight; System.out.println(distinctString == "flyweight"); // ? String flyweight = (fly + weight).intern(); System.out.println(flyweight == "flyweight"); // ? } } Flyweight的另一个典型例子是Java Swing。请查阅相关资料，指出Swing树的速 度是如何做到这么快的。(秘密在 TreeCellRenderer.getTreeCellRendererCompon ent()里) Flyweight模式
- 195. 在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实 现。采用添加一层间接接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。 典型模式 Facade Proxy Mediator Adaptor （5）“接口隔离”相关模式
- 196. 动机 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着 外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系 统的变化之间的依赖相互解耦？ 意图 为子系统中的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这 个接口使得这一子系统更加容易使用。 A方案 B方案 Facade模式
- 197. 结构 适用性 简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上 也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Façade接口的 变化。 更注重从架构的层次去看整个系统，而不是单个类的层次 并非一个集装箱，可以任意地放进任何多个对象。Façade模式中组件的内部应该是 “相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。 Facade模式
- 199. 动机 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操 作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构 带来很多麻烦。 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接 层是软件开发中常见的解决方式。 意图 为其他对象提供一种代理以控制对这个对象的访问。 Proxy模式
- 200. 结构 适用性 在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用Proxy模式。 具体实现方法、实现粒度都相差很大。可能针对单个对象也可能针对组件模块做 proxy 并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损失一些透明性是 可以接受的 Proxy模式
- 201. 举例 (1)远程代理（Remote Proxy） (2)虚代理（Virtual Proxy） (3)保护代理（Protection Proxy） (4)智能指针（Smart Reference） Spring AOP利用了Java的动态代理技术 Proxy模式
- 202. 动机 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持 一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的 变化。 在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交 互的对象之间的紧耦合引用关系，从而更好地抵御变化。 意图 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用， 从而使其耦合松散，而且可以独立地改变它们之间的交互。 Mediator模式
- 203. 结构 适用性 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。 一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。 想定制一个分布在多个类中的行为，而又不想生成太多的子类。 将多个对象间复杂的关联关系解耦，将多个对象间的控制逻辑进行集中管理。Façade是 解耦系统外到系统内（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之 间（双向）的关联关系。 随着控制逻辑的复杂化，可能需要对Mediator具体对象进行分解处理。 Mediator模式
- 205. 动机 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境 中应用，但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新 的应用环境所要求的接口？ 意图 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼 容而不能一起工作的那些类可以一起工作。 Adapter模式
- 206. 结构 适用性 你想使用一个已经存在的类，而它的接口不符合你的需求。 你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可 能不一定兼容的类）协同工作。 （仅适用于对象Adaptor）你想使用一些已经存在的子类，但是不可能对每一个都进行 子类化以匹配它们的接口。对象适配器可以适配它的父类接口。 Adapter模式本身要求我们尽可能地使用“面向接口的编程风格”，这样才能在后期很 方便地适配。 “对象”适配器 推荐 Adapter模式
- 210. 动机 在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能 够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对 象的状态，便会暴露对象的细节实现。 如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。 意图 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 这样以后就可以将该对象恢复到原先保存的状态。 Memento模式
- 211. 结构 适用性 备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原 发器状态。适用于“由原发器管理，却又必须存储在原发器之外的信息” 要防止原发器以外的对象访问备忘录对象。 备忘录对象有两个接口，一个为原发器使 用的宽接口，一个为其他对象使用的窄接口 现代语言（如C#、Java等）往往采用效率较高，又较容易正确实现的序列化方案来 实现Memento模式。 Memento模式
- 212. 动机 在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文 档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。 如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转 化之间引入紧耦合？ 意图 允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行 为。 State模式
- 213. 结构 适用性 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状 态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况 将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。 为不同状态引入不同对象使得状态转换变得更加明确，保证转换原子性 State模式
- 215. 常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结 构，将极大地破坏组件的复用。这时候，将这些特定数据结构封装在内部，在外部提 供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。 典型模式 Composite Iterator Chain of Responsibility （7）“数据结构”相关模式
- 217. 动机 在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部 实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、 扩展性等弊端。 如何将“客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂 结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？ 意图 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单 个对象和组合对象的使用具有一致性。 Composite模式
- 218. 结构 适用性 采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系， 使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象 容器。 将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将 与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能“应对变化” 。 具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技 巧来改善效率。 Composite模式
- 219. 动机 在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希 望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同 时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。 使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象” 提供了一种优雅的方式。 意图 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 Iterator模式
- 220. 结构 适用性 迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。 迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同 的集合结构上进行操作。 迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。 支持对聚合对象的多种遍历。 Iterator模式
- 221. 举例 Java集合类有Collection, List, Set, Map等，虽然每种类的细节各有不同，但对于集合 元素的遍历需求是一致的。 public class SimpleCollection{ public static void main(String[] args){ Collection<Integer> c = new ArrayList<Integer>(); for(int i = 0;i < 10; i++) c.add(i); //Autoboxing for(Integer i: c) System.out.println(i +", "); } } Iterator模式
- 223. 动机 在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一 个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。 如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来 处理请求，从而使两者解耦。 意图 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将 这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。 Chain of Responsibility模式
- 224. 结构 适用性 应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请 求发送者与接受者的耦合才有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从 而更好地应对变化。 对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。 如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对 象的责任，而不是发出请求的对象的责任。 Chain of Responsibility模式
- 226. 动机 在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但 在某些场合——比如需要对行为进行“记录、撤销/重做(undo/redo)、事务”等处 理，这种无法抵御变化的紧耦合是不合适的。 在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对 象，可以实现二者之间的松耦合。 意图 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排 队或记录请求日志，以及支持可撤销的操作。 Command模式
- 227. 结构 适用性 根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是 “将行为抽象为对象”。 具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息；可以将多 个“命令”封装为一个“复合命令”MacroCommand。 与C++函数对象区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格， 更符合抽象原则；C++函数对象以函数签名来定义行为接口规范，更灵活，更高效，但抽象能力 比较弱。 Command模式
- 229. 动机 在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方 法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破 坏原有设计。 如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个 类动态添加新的操作，从而避免上述问题？ 意图 表示一个作用于某对象结构中的各元素的操作。使得可以在不改变各元素的类的前提 下定义作用于这些元素的新操作。 Visitor模式
- 230. 结构 适用性 通过所谓双重分发（double dispatch）来实现在不更改Element类层次结构的前提下，在运行 时透明地为类层次结构上的各个类动态添加新的操作。所谓双重分发即Visitor模式中间包括了两 个多态分发：第一个为accept方法的多态辨析；第二个为visit方法的多态辨析。 最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。适用于“类 层次结构稳定，而其中操作经常面临频繁改动”。 Visitor模式
- 231. 举例 一个集合（Collection）中，可以包含一个Car，也可以包含一个Cat，对于不同类型的元素，他们的 行为也不尽相同，比如，Car可能有start()行为，而Cat可能有eat()的行为。可是对于Collection来说， 不管你是Car，还是Cat，取出来的都是Object，那么我们如何知道取出来的是什么呢？ 我们可能会如下操作： Iterator itor = collection.iterator(); while(itor.hasNext()){ Object o = itor.next(); if(o instanceof Car){ ((Car)o).start(); }else if(o instanceof Cat){ ((Cat)o).eat(); } } 这时你应该可以看出这种方式可能会出现的问题，假如现在Collection中放入了成千上万个不同类型 的对象，也就意味着你需要成千上万个if else。这时，我们是否需要考量一下，我们的设计… Visitor模式
- 233. 动机 在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现， 如果使用普通的编程方式来实现将面临非常频繁的变化。 在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释 器来解释这样的句子，从而达到解决问题的目的。 意图 给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表 示来解释语言中的句子。 Interpreter模式
- 235. 举例 (1)正则表达式； (2)规则引擎； (3)自动化测试工具； (4)DOM (5)Scripting Language Support：Apache Bean Scripting Framework (6)… … Interpreter模式
- 236. 本节回顾 • 软件设计原则 • 模式的概念及分类 • 软件设计模式
- 237. 系统架构参考模式
- 239. （一）SOA架构相关 • SOA及分布式相关技术参考 – 企业服务总线ESB、API网关 – 业务流程引擎、业务规则引擎 – 分布式服务框架 – Restful软件架构风格 – 微服务架构
- 240. （1）ESB/API网关 • ESB/API网关： – 企业服务集成 – Mediator – Pipelines & Filters – EDA
- 241. （2）业务流程引擎/规则引擎 • 业务流程引擎/规则引擎 – 适应企业业务流程和业务规则变化 – 业务人员和开发人员关注度分离 – Coordinator/Interceptor
- 242. （3）分布式服务框架 • 分布式服务框架(SOA治理) – 负载均衡 – 服务注册与发现 – 服务容量评估 – 服务调用统计 – 服务降级 – …
- 243. （4）Restful软件架构风格 • Restful软件架构风格 – Representational State Transfer（资源的表现层状态转化） – 资源（Resources）： • 网络上的一个实体，或者说是网络上的一个具体信息。 • 你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。（例： Protocol://ServiceName/ResourceType/ResourceID，http://myservice/persons/1） – 消息（Messages）：URI，Http Method，Http params，headers，content，status code – 模型表示（Representations）：JSON / XML /… – 一致接口（Uniform interface）：GET/PUT/DELETE/POST把方法分类成安全和幂等 – 无状态（Stateless）：RESTful 服务是无状态的并且不会为任何客户端保持状态 – 资源之间的连接（Links between resources）：资源模型表示（representation ） 可以包含其他资源的链接就像 HTML 页面包含到其他页面的链接一样。 – 缓存（Caching）：Cache-Control – 文档化Restful服务：@OPTIONS
- 244. （5）微服务架构 • 单体应用 – 巨无霸 – 降低开发效率和速度 – 启动时间长 – 不利于持续开发和部署 – 扩展困难 – 降低可靠性 – 重构困难
- 245. 微服务架构 • 微服务架构 – 每一个应用功能区都使 用微服务完成 – 每一个后台服务开放一 个REST API – 服务间采用异步的、基 于消息的通讯 – REST API通过API Gateway对外开放
- 246. 微服务架构 • Docker – 一个开源的引擎，可以轻松 的为任何应用创建一个轻量 级的、可移植的、自给自足 的微服务容器。 – 包含持续交付工具 • web应用的自动化打包和发布； • 自动化测试和持续集成、发布； • 在服务型环境中部署和调整数 据库或其他的后台应用；
- 247. 微服务架构 • Docker核心概念 – Image – Register – Container Docker Container
- 248. 微服务架构 • Docker集群管理 Kubernetes – 资源调度 – 部署运行 – 服务发现 – 扩容缩容