第 10 周模块分解

关注
发布于: 2020 年 11 月 29 日
巨无霸应用系统带来的问题编译、部署困难对于网站开发工程师而言，打包构建一个巨型应用是一件痛苦的事情。 也许只是修改了一行代码，输入 build 命令后，抽完一支烟，回来一看，还在 building； 又去喝了一杯水，回来一看，还在 building；又去了一次厕所，回来一看，还在 building； 好不容易 build 结束，一看编译失败，还得重来…
代码分支管理困难复用的代码模块由多个团队共同维护修改，代码 merge 的时候总会发生冲突。代码 merge 一 般在网站发布的时候，和发布等问题互相纠结在一起，顾此失彼，每次发布都要半夜三更。
数据库连接耗尽巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数 据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百台服务器集群的应用将 需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源， 以至于数据库缺乏足够的系统资源进行一般的数据操作。
新增业务困难想要在一个已经如乱麻般系统中增加新业务，维护旧功能，难度可想而知. 一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了，还是不能接手业务， 因为不知道水有多深。 于是就出现这种怪现象：熟悉网站产品的“老人”忙得要死，加班加点干活；不熟悉网站产品 的新人一帮忙就出乱，跟着加班加点； 整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。
解决方案拆分，将模块独立部署，降低系统耦合性
纵向拆分将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部 署为一个独立的Web应用系统。
横向拆分将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可 快速搭建一个应用系统。
微服务框架Web Service 与企业级分布式服务
服务提供者通过 WSDL（Web服务描述语言，Web Services Description Language） 向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用 UDDI （Universal Description, Discovery, and Integration，统一描述、发现和集成）发布 服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过 SOAP （Simple Object Access Protocol，简单对象访问协议 ）和服务提供者通信，使用相 关服务。
Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的 案例，但是也具有一些固有的缺点：
臃肿的注册与发现机制
低效的 XML 序列化手段
开销相对较高的 HTTP 远程通信
复杂的部署与维护手段
这些问题导致 Web Service 难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。
微服务框架需求对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功 能，还需要微服务框架能够支持以下需求
失效转移（Fail Over）对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框 架还需要支持服务提供者的失效转移机制，以实现服务高可用。
负载均衡（Load Balance）对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群 实现负载均衡。
高效的远程通信对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段， 服务调用可能会成为整个系统性能的瓶颈。
对应用最少侵入网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的 演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种 渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。
版本管理为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升 级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务 请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护， 同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本 的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。
微服务架构实践断路器当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求 阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务 的调用。
断路器三种状态：关闭，打开，半开
﻿
服务重试及调用超时上游调用者超时时间要大于下游调用者超时时间之和。
﻿
微服务网关基于网关的微服务架构
网关作用
微服务网关
网关管道技术网关本身没有什么业务，主要职责是做各种校验与拦截，这些职责可以通过管道技术连 接起来。
实现管道技术的责任链设计模式
﻿
开放平台网关API 接口:是开放平台暴露给合作者使用的一组 API，其形 式可以是 RESTful、 WebService、RPC 等各种形式
协议转换:将各种 API 输入转换成内部服务可以识别的形式， 并将内部服务的返回 封装成 API 的格式
安全:除了一般应用需要的身份识别、权限控制等安全手段， 开放平台还需要分级 的访问带宽限制，保证平台资源被第 三方应用公平合理使用，也保护网站内部服务不会 被外部 应用拖垮
审计:记录第三方应用的访问情况，并进行监控、计费等
路由:将开放平台的各种访问路由映射到具体的内部服务
流程:将一组离散的服务组织成一个上下文相关的新服务， 隐藏服务细节，提供统 一接口供开发者调用
开放授权协议 OAuth2.0
﻿
授权码授权OAuth2.0 一共有四种授权方式， 分别是授权码、隐式授权、资源 所有者密码 凭据和客户端凭据。 目前互联网上使用最多也是最安 全的的一种方式是授权码方式。
﻿
领域驱动设计 DDD事务脚本
领域模型
贫血模型 VS 充血模型由于事务脚本模式中，Service、Dao 这些对象只有方法，没有数值成员变量，而方法调 用时传递的数值对象，比如Contract，没有方法（或者只有一些 getter、setter 方法）， 因此事务脚本又被称作贫血模型。
﻿
领域模型的对象则包含了对象的数据和计算逻辑，比如合同对象，既包含合同数据，也 包含合同相关的计算。因此从面向对象的角度看，领域模型才是真正的面向对象。 收入 确认是和合同强相关的，是合同对象的一个职责，那么合同对象就应该提供一个 calculateRecognition 方法计算收入。
﻿
领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻 辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。和事务脚 本被称作贫血模型相对应的，领域模型也被称为充血模型。
DDD 战略设计领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。
﻿
领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。
子域领域是一个组织所做的事情以及其包含的一切。 这个范围就太大了，不知道该如何下手。 所以通常的做法是把整个领域拆分成多个子域，比如用户、商品、订单、库存、物流、 发票等。
限界上下文在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示 特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一 对一的关系，用来控制子域的边界，保证子域内的概念统一性。
通常限界上下文对应一个组件或者一个模块，或者一个微服务，一个子系统
上下文映射图不同的限界上下文，也就是不同的子系统或者模块之间会有各种的交互合作。DDD 使用 上下文映射图来设计这种关联和交互。
﻿
DDD 战术设计实体领域模型对象也被称为实体，每个实体都是唯一的，具有一个唯一标识，一个订单对象 是一个实体，一个产品对象也是一个实体，订单 ID 或者产品 ID 是它们的唯一标识。实 体可能会发生变化，比如订单的状态会变化，但是它们的唯一标识不会变化。
﻿
实体设计是 DDD 的核心所在，首先通过业务分析，识别出实体对象，然后通过相关的 业务逻辑设计实体的属性和方法。这里最重要的，是要把握住实体的特征是什么，实体 应该承担什么职责，不应该承担什么职责，分析的时候要放在业务场景和界限上下文中， 而不是想当然地认为这样的实体就应该承担这样的角色。
值对象并不是领域内的对象都应该被设计为实体，DDD 推荐尽可能将对象设计为值对象。比如 像住址这样的对象就是典型的值对象，也许建在住址上的房子可以被当做一个实体，但 是住址仅仅是对房子的一个描述，像这样仅仅用来做度量或描述的对象应该被设计为值 对象。
﻿
值对象的一个特点是不变性，一个值对象创建以后就不能再改变了。如果地址改变了， 那就是一个新地址，而一个订单实体则可能会经历创建、待支付、已支付、代发货、已 发货、待签收、待评价等各种变化。
聚合聚合是一个关联对象的集合，我们将其作为一个单元来处理数据更改。每个集合都有一 个根和一个边界。边界定义了聚合内部的内容。根是聚合中包含的单个特定实体。
﻿
聚合根：将多个实体和值对象聚合在一起的实体。
DDD 分层架构领域实体的组合调用和事务控制在应用层
DDD 六边形架构领域模型通过应用程序封装成一个相 对比较独立的模块，而不同的外部系 统则通过不同的适配器和领域模型交 互，比如可以通过 HTTP 接口访问领 域模型，也可以通过 Web Service 或 者消息队列访问领域模型，只需要为 这些不同的访问接口提供不同的适配 器就可以了。
DDD 战略设计与战术设计领域、子域、界限上下文、上下文映射图，这些是 DDD 战略设计
实体、值对象、聚合、CQRS、事件溯源，这些是 DDD 战术设计
通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要
组件设计原则在没有编程语言的时候就已经有了软件组件软件的复杂度和它的规模成指数关系一个复杂度为 100 的软件系统，如果能拆分成两个互不相关、同等规模的子系统，那么 每个子系统的复杂度应该是 25，而不是 50。软件开发这个行业很久之前就形成了一个 共识，应该将复杂的软件系统进行拆分，拆成多个更低复杂度的子系统，子系统还可以 继续拆分成更小粒度的组件。也就是说，软件需要进行模块化、组件化设计。
组件内聚原则组件内聚原则主要讨论哪些类应该聚合在同一个组件中，以便组件既能提供相对完整的功能，又不至于太过庞大
复用发布等同原则
共同封闭原则
共同复用原则
复用发布等同原则复用发布等同原则是说，软件复用的最小粒度应该等同于其发布的最小粒度。也就是说， 如果你希望别人以怎样的粒度复用你的软件，你就应该以怎样的粒度发布你的软件。这 其实就是组件的定义了，组件是软件复用和发布的最小粒度软件单元。这个粒度既是复 用的粒度，也是发布的粒度。
共同封闭原则共同封闭原则是说，我们应该将那些会同时修改，并且为了相同目的而修改的类放到同 一个组件中。而将不会同时修改，并且不会为了相同目的而修改的类放到不同的组件中。
﻿
组件的目的虽然是为了复用，然而开发中常常引发问题的，恰恰在于组件本身的可维护 性。如果组件在自己的生命周期中必须经历各种变更，那么最好不要涉及其他组件，相 关的变更都在同一个组件中。这样，当变更发生的时候，只需要重新发布这个组件就可 以了，而不是一大堆组件都受到牵连。
共同复用原则共同复用原则是说，不要强迫一个组件的用户依赖他们不需要的东西
﻿
这个原则一方面是说，我们应该将互相依赖，共同复用的类放在一个组件中。比如说， 一个数据结构容器组件，提供数组、Hash 表等各种数据结构容器，那么对数据结构遍历 的类、排序的类也应该放在这个组件中，以使这个组件中的类共同对外提供服务。
﻿
另一方面，这个原则也说明，如果不是被共同依赖的类，就不应该放在同一个组件中。 如果不被依赖的类发生变更，就会引起组件变更，进而引起使用组件的程序发生变更。 这样就会导致组件的使用者产生不必要的困扰，甚至讨厌使用这样的组件，也造成了组 件复用的困难。
组件耦合原则组件内聚原则讨论的是组件应该包含哪些功能和类，而组件耦合原则讨论组件之间的耦 合关系应该如何设计
无循环依赖原则
稳定依赖原则
稳定抽象原则
无循环依赖原则无循环依赖原则说，组件依赖关系中不应该出现环。如果组件 A 依赖组件 B，组件 B 依 赖组件 C，组件 C 又依赖组件 A，就形成了循环依赖。
﻿
很多时候，循环依赖是在组件的变更过程中逐渐形成的，组件 A 版本 1.0 依赖组件 B 版 本 1.0，后来组件 B 升级到 1.1，升级的某个功能依赖组件 A 的 1.0 版本，于是形成了 循环依赖。如果组件设计的边界不清晰，组件开发设计缺乏评审，开发者只关注自己开 发的组件，整个项目对组件依赖管理没有统一的规则，很有可能出现循环依赖
稳定依赖原则稳定依赖原则说，组件依赖关系必须指向更稳定的方向。较少变更的组件是稳定的，也 就是说，经常变更的组件是不稳定的。根据稳定依赖原则，不稳定的组件应该依赖稳定 的组件，而不是反过来。
﻿
反过来说，如果一个组件被更多组件依赖，那么它需要相对是稳定的，因为想要变更一 个被很多组件依赖的组件，本身就是一件困难的事。相对应的，如果一个组件依赖了很 多的组件，那么它相对也是不稳定的，因为它依赖的任何组件变更，都可能导致自己的 变更。
﻿
稳定依赖原则通俗地说就是，组件不应该依赖一个比自己还不稳定的组件。
稳定抽象原则稳定抽象原则说，一个组件的抽象化程度应该与其稳定性程度一致。也就是说，一个稳 定的组件应该是抽象的，而不稳定的组件应该是具体的。
﻿
这个原则对具体开发的指导意义就是：如果你设计的组件是具体的、不稳定的，那么可 以为这个组件对外提供服务的类设计一组接口，并把这组接口封装在一个专门的组件中， 那么这个组件相对就比较抽象、稳定。
﻿
Java 中的 JDBC 就是这样一个例子，我们开发应用程序的时候只需要使用 JDBC 的接 口编程就可以了。而发布应用的时候，我们指定具体的实现组件，可以是 MySQL 实现 的 JDBC 组件，也可以是 Oracle 实现的 JDBC 组件。
组件的边界与依赖关系，不仅仅是技术问题组件的边界与依赖关系划分，不仅需要考虑技术问题，也要考虑业务场景问题。易变与稳定，依赖与被依赖，都需要放在业务场景中去考察。有的时候，甚至不只是技术和业 务的问题，还需要考虑人的问题，在一个复杂的组织中，组件的依赖与设计需要考虑人 的因素，如果组件的功能划分涉及到部门的职责边界，甚至会和公司内的政治关联起来。
﻿