week10 学习总结
微服务
单体架构发展后期的问题:
编译,部署困难
代码分支管理困难
数据库连接耗尽
新增业务困难
解决方案:
拆分,将模块独立布署,降低系统耦合
纵向拆分: 大拆小
横向拆分: 复用抽象
web service
服务提供者
WSDL(Web服务描述语言)
注册中心
UDDI(统一描述,发现和集成)
服务请求者
SOAP(简单对象访问协议)
微服务框架需求:
服务注册
服务发现
服务调用
失效转移
负载均衡
高效远程通信
对应用最少侵入
版本管理
Dubbo
Service Mesh 服务网格
Service Mesh 的Sidercar模式
微服务架构落地:
业务先行
模块独立
谨慎重构
有的放矢,明确实施微服务的目的
命令与查询职责隔离(CQRS):
在服务接口层面将查询(读操作)与命令(写操作)隔离,实现服务层的读写分离.
事件溯源:
将用户请求处理过程中的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储
断路器:
当某个服务出现故障,响应延迟或者失败率增加,继续调用这个服务会导致调用者请求阻塞,资源消耗增加,进而出现服务级联失效,这种情况下使用断路器阻断对故障服务的调用.
微服务网关:
作用:
统一接入:高性能,高并发,高可靠,负载均衡
安全防护:防刷控制,黑白名单
流量管控与容错:限流,降级,熔断
协议适配:http,dubbo,jsf
网关管道技术:
网关本身没什么业务,主要职责是做各种校验和拦截,这些职责可以通过管道技术连接起来
开放授权协议 OAuth2.0
领域驱动设计 DDD
贫血模型: 事务脚本(只有方法,没有数值或成员变量)
充血模型: 领域模型(合并了行为和数据的领域对象模型)
领域: 一个组织所做的事情以及其包含的一切,通俗地说,就是组织的业务范围和做事方式,也是软件开发的目标范围
领域驱动设计就是从领域出发,分析领域内模型及其关系,进而设计软件系统的方法.
子域:由领域拆分而成
如何拆分?
与微服务拆分一样
限界上下文:
子域中, 会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义.这样边界称为限界上下文.限界上下文和子域具有一对一的关系,用来控制子域的边界.
通常限界上下文对应一个组件或者一个模块,或者一个微服务,或者一个类
上下文映射图:
实体:
领域模型对象也被称为实体,每个实体都是唯一的.具有一个唯一标识,一个订单对象是一个实体,一个产品对象也是一个实体
实体设计是DDD的核心所在,
业务分析->识别实体对象
业务逻辑->实体属性和方法
把握实体特征,职责范围(在业务场景和限界上下文中分析)
值对象:
不变性
聚合:关联对象的集合,每个集合都有一个根和边界.
聚合根:将多个实体和值对象聚合在一起的实体.
DDD分层架构
用户接口层:
应用层:
领域层:
DDD六边形架构:实际上就是分层架构的延伸
DDD战略设计: 领域,子域,限界上下文,上下文映射图
DDD战术设计: 实体,值对象,聚合,CQRS,事件溯源
通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要
资深程序员真正有优势的是他在一个业务领域的多年积淀,对业务领域有更深刻的理解和认知.那么如何将这些业务沉淀和理解反映到工作中,体现在代码中呢?实践DDD是一个不错的方式.
如果一个人有多年的经验,那么必然对领域模型有更深刻的认识,把握好领域模型在不断需求变更中的演进,使系统维持更好的活力,并因此体现自己真正的价值.
还未添加个人签名 2019.02.11 加入
还未添加个人简介
评论