架构师训练营第 1 期 - 第 10 周 - 学习总结

微服务：服务本身的设计、维护以及治理

巨无霸应用系统带来的问题：

1. 编译、部署困难

2. 代码分支管理困难

3. 数据库连接耗尽

4. 新增业务困难

解决方案：拆分，将模块独立部署，降低系统耦合性

1. 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。

2. 横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。

微服务：落地实践的策略与思路

微服务框架 --- Web Service与企业级分布式服务

WSDL（Web服务描述语言，Web Services Description Language）

UDDI（Universal Description, Discovery, and Integration，统一描述、发现和集成）

SOAP（Simple Object Access Protocol，简单对象访问协议）

缺点：

Ø  臃肿的注册与发现机制

Ø  低效的XML序列化手段

Ø  开销相对较高的HTTP远程通信

Ø  复杂的部署与维护手段

这些问题导致Web Service难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。

微服务框架需求

• 负载均衡

• 失效转移（Fail Over）

• 高效的远程通信

• 对应用最少侵入

• 版本管理

微服务框架（Dubbo）架构

Service Mesh服务网络 是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级的网络代理，他们与应用程序部署在一起，而对应用程序透明。

微服务架构实践  ---- 微服务架构落地

确定业务边界与依赖->分出独立的模块->做成分布式的服务

微服务的目的是：1. 业务复用 2. 开发边界清晰 3.分布式集群->提升性能。

做法：

1. 实现服务层读写分离。

2.事件溯源--将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。

a. 精确复现任何用户状态，进行复核审计。

b. 有效监控用户状态变化，并在此基础上实现分布式事务。

3.断路器 --- 当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。

4.服务重试及调用超时 --- 上游调用者超时时间要大于下游调用者超时时间之和。

5.最重要的是需求。-- 1.需求 2.价值 3.原则 4.最佳实践 5.工具

微服务网关的技术架构

基于网关的微服务架构

网关的作用：

1.统一接入 （高性能、高并发、高可用、负载均衡……）

2.安全防护（防刷控件、黑白名单……）

3.协议适配 （http\dubbo\jsf……）

4.流量管控和容错（限流，降级，熔断……）

微服务网关：

1. 服务注册中心 2.网关（服务消费者）3. 服务提供者

网关管道技术（职责链模式 Chain of Responsibility）： 做各种校验和拦截。 （如 Filter）

Flower异步网关与异步微服务框架 https:/github.com/zhihuili/flower

利用Servlet3实现异步网关

开放平台网关：

Open API

协议转换

安全： 身份识别，权限控制，分级的带宽访问限制

审计： 记录第三方应用的访问情况，并进行监控、计费等。

路由：将开放平台的各种访问路由映射到时具体的内部服务。

流程： 将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者 调用。

开放授权协议 OAuth2.0

1.第三方应用 => 资源所有者（用户） 请求授权

2.资源所有者（用户）=> 第三方应用 同意给予授权

3.第三方应用 => 授权服务器 申请令牌

4.授权服务器 => 第三方应用 同意发放令牌

5.第三方应用 => 资源服务器 使用令牌访问资源

6.资源服务器 => 第三方应用 确认令牌无误，同意开放资源

授权码授权：

OAuth 2.0 一共有4种授权方式：授权码，隐式授权，资源所有者密码凭据，客户端凭据。

领域驱动设计DDD

贫血模型（事务脚本） vs 充血模型（领域模型）

由于事务脚本模式中，Service、Dao 这些对象只有方法，没有数值成员变量，而方法调用时传递的数值对象，比如Contract，没有方法（或者只有一些getter、setter方法），因此事务脚本又被称作贫血模型。

领域模型的对象则包含了对象的数据和计算逻辑，比如合同对象，既包含合同数据，也包含合同相关的计算。因此从面向对象的角度看，领域模型才是真正的面向对象。收入确认是和合同强相关的，是合同对象的一个职责，那么合同对象就应该提供一个calculateRecognition方法计算收入。

领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。和事务脚本被称作贫血模型相对应的，领域模型也被称为充血模型。



领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。

领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。



领域驱动设计 DDD的10个核心知识体系： 领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对象、聚合、聚合根

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。

• 公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。

• 很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。

• 在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到核心域了，且重点关注核心域。

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。

核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。



在 DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。

这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界



限界上下文拆解为两个词：限界和上下文。

限界就是领域的边界，

上下文则是语义环境。

通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。

用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

软件组件设计原则

一、 组件内聚原则： 1.复用发布等同原则 2. 共同封闭原则 3. 共同复用原则

二、 组件耦合原则：1. 无循环依赖原则 2. 稳定依赖原则 3.稳定抽象原则

三、人的因素（参考：康威定律）

在一个复杂的组织中，组件的依赖与设计需要考虑人的因素，如果组件的功能划分涉及到部问的职责边界，甚至会和公司内的政治关联起来。

案例：用领域驱动设计驱动系统重构