第十周学习总结

一、微服务

1、单体应用的问题：

👉编译、部署困难。系统庞大之后，也许只修改了一行代码，就可能会需要编译相当长的时间。

👉代码分支管理困难。多个团队维护公共代码，冲突多。

👉数据库连接耗尽。

👉新增业务困难。新人不敢做事，老人加班加不完。

2、解决上述问题的方法：

👉拆分，独立部署，降低耦合性；纵向拆分（独立业务）；横向拆分（复用业务）。

3、Web Service 的思想

👉服务请求者、服务提供者、注册中心（90 年代就出现的面向服务的体系架构）

👉Web Service 的缺点：臃肿的注册与发现机制；低效的 xml 序列化手段；开销相对较高的 http 远程通信、复杂的部署与维护手段

4、微服务框架要求

失效转移、负载均衡、高效的远程通信、对应用最少侵入、版本管理

5、Service Mesh 服务网格

👉Service Mesh 基础设施层

👉1、用简单的方式将请求发送给本地的 service mesh 实例 2、Service mesh 进行服务发现 3、Service mesh 将请求转发给目标服务

6、微服务架构落地

👉业务先行，技术是手段而不是目的

👉先有独立的模块，后有分布式的服务

👉逻辑复杂多变的系统进行微服务重构要谨慎

👉实施微服务的目的是什么

👉命令与查询职责隔离

👉事件溯源

👉断路器

👉服务重试及调用超时：上游调用者超时时间要大于下游调用者超时时间之和

7、RPC 协议实现原理

👉通讯协议：网络通信协议（TCP、UDP）、编码传输协议（二进制、文本）

👉常见协议：定长协议、特殊结束符协议、变长协议（协议头+协议体）

8、基于网关的微服务架构

👉网关的作用：统一接入、安全防护、协议适配、流量管控与容错

👉网关管道技术

👉异步网关、异步微服务

👉开放平台网关

👉开放授权协议 OAuth2.0

授权码模式（使用最多、最安全）

隐式授权

资源所有者密码凭据

客户端凭据

二、领域驱动设计 DDD

1、为什么需要 DDD

👉需求零散、不断变更

👉工程师各处寻找、修修补补

👉只有需求分析，没有设计

👉功能特性按照主观想象设计

2、贫血模型 VS 充血模型

设计好了领域模型对象，也就设计好了业务逻辑实现

3、领域

👉领域：软件开发的目标范围

👉领域驱动设计：从领域出发，分析领域内模型及其关系

👉子域

👉限界上下文：通常对应一个组件、一个模块、一个微服务或者一个子系统

👉实体：领域模型对象。实体设计是 DDD 的核心。

👉DDD 分层架构、DDD 六边形架构

👉战略设计（领域、子域、限界上下文、上下文映射图）、战术设计（实体、值对象、聚合、CQRS、事件溯源）

三、架构师

👉设计型架构师（一般意义）、救火型架构师、布道型架构师、Geek 型架构师

👉夏尔巴人架构师（解决最具技术难度和挑战性的部分）、斯巴达人架构师（必胜的信念）

👉产品架构师、基础服务架构师、基础设施架构师