Week 10 学习总结
一、微服务
1、为什么使用微服务?
1)单体巨无霸系统带来的问题
a. 编译、部署困难
b. 代码分支管理困难
c. 数据库连接耗尽
d. 新增业务困难
2)拆分,将大应用拆分为多个小应用
a. 横向拆分:将公共的业务拆分出来,复用于其他业务
b. 纵向拆分:将大应用拆分多个小应用
二、微服务架构落地的支撑--微服务框架
1、微服务框架的起源--Web Service
1)三个角色:
a. Service Provider:服务提供者
b. Service Requester:服务消费者
c. Service Broker:服务注册中心
2)不足之处:
a. 臃肿的注册于发现机制
b. 低效的XML序列化手段
c. 开销相对较高的HTTP远程通信
d. 复杂的部署与维护手段
-->难以满足大型网站对系统“高性能、高可用、易部署、易维护”的要求
2、微服务框架中的关键点
1)服务的注册与发现:
2)服务间的远程调用:
3)失效转移--高可用:
a. 服务集群化部署,实现服务的高可用
b. 调用某个服务实例失败时,调用者需要尝试换一个服务实例
4)负载均衡:
a. 服务集群化部署后,需要使用负载均衡的访问方式
b. 调用者按照负载均衡策略访问服务实例
5)高效远程通信--通信协议:
a. HTTP协议相对低效,需要自己实现一套高效的通信协议
6)对应用最少侵入
a. 业务开展服务化的过程是渐进的,所以微服务框架要减少对业务的影响,方便业务的演进
7) 服务的版本管理
3、微服务框架案例分析--Dubbo
4、Service Mersh
1)微服务框架存在的问题
a. 服务的调用者需要自己负责服务的发现和调用(通过代理对象)
b. 服务的调用者需要自己实现失效转移处理(通过代理对象)
c. 服务的调用者需要自己实现负载均衡的调用处理(通过代理对象)
d. 服务的调用者需要自己决定远程调用服务的方式和使用协议(通过代理对象)
-->服务调用方为了调用服务,需要做很多的事情,而且这些事情对不同的调用方而言,是相似的、重复的!
2)Service Mersh做的事情
a. Service Mersh构建了一个用于服务间通信的基础设施层,用于处理服务间的通信
b. 相当于把代理对象抽离出来,构成了一个中间层,原来代理对象做的事情,都交给了Service Mersh
c. Service Mersh的Sidecar模式
三、如何落地微服务架构
1、微服务落地的关键点,不是技术,而是要理顺业务,梳理业务的边界
1)业务先行,先理顺业务边界和依赖,技术是手段而不是目的
2)先有独立的模块,后有分布式的服务
3)业务耦合严重,逻辑复杂多变的系统进行微服务重构要谨慎
4)搞清楚实施微服务的目的是什么,业务复用?开发边界清晰?分布式集群提升性能?
-->倒三角模型:
2、微服务落地时的一些关注点
1)事件溯源
a. 将用户的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储
b. 可复现用户的状态变化,进行复核审计
c. 可在此基础上实现分布式事务
2)断路器
a. 阻断对故障服务的调用,避免响应延迟或失败率增加,导致请求的阻塞和资源消耗
3)服务重试&调用超时
4)分布式链路追踪
3、微服务落地时的一些实践
1)CQRS
四、微服务网关
1、基于网关的微服务架构
2、网关的作用
1)统一接入
2)流量管控与容错
3)协议适配
4)安全防护
3、网关中的技术
1)网关管道技术:责任链模式
2)异步网关:Servelrt3
4、网关分类
1)开放平台网关
2)安全网关
五、微服务发展小结
1、单体应用->微服务:解决发布、部署困难的问题
2、微服务->平台化:构建通用服务、服务复用
3、平台化->中台化:微服务定义了业务规范。业务系统依赖微服务,实现具体的业务
六、领域驱动设计--DDD
1、为什么需要DDD
1)软件只有需求分析,没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一致性
2)功能特性并不是按照领域模型内在的逻辑设计,而是按照个色人等自己的主观想象设计
3)以上两点导致随着需求的零散开发和变更,项目变的越来越复杂和难以维护
2、DDD是什么
1)传统开发模式:事务脚本型、面向过程的编程;DDD:领域模型、面向对象的编程
2)贫血模型 VS 充血模型
3、怎么做DDD
1)领域:明确产品要做的事情、范围、边界
2)子域:整个领域要做的事情太多、太大,需要拆分,拆分成多个子域
a. 如何划分子域?划分的规则?
3)界限上下文
a. 和子域具有一对一的关系,用来控制子域的边界 b. 在界限上下文划定的边界中,任何领域对象都具有唯一的特定含义,不存在二义性
4)上下文映射图:描述子系统或模块之间的交互合作
5)实体
6)值对象
a. 实体 VS 值对象:对实体而言,属性值相同并不表示是同一个对象,一定需要通过ID值进行区分;对值对象而言,属性值相同一定表示同一个对象
7)聚合
4、DDD相关架构
1)分层架构
2)六边形架构
5、DDD战略设计与战术设计
1)战略 VS 战术
a. 领域、子域、界限上下文、上下文映射图,这些是战略设计 b. 实体、值对象、聚合、CQRS、事件溯源,这些是战术设计
2)战略的作用
a. 通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要
评论