写点什么

week10 学习总结

用户头像
任小龙
关注
发布于: 2020 年 08 月 11 日

微服务



单体架构发展后期的问题:

  1. 编译,部署困难

  2. 代码分支管理困难

  3. 数据库连接耗尽

  4. 新增业务困难



解决方案:

拆分,将模块独立布署,降低系统耦合

纵向拆分: 大拆小

横向拆分: 复用抽象



web service

服务提供者

WSDL(Web服务描述语言)

注册中心

UDDI(统一描述,发现和集成)

服务请求者

SOAP(简单对象访问协议)



微服务框架需求:

服务注册

服务发现

服务调用

失效转移

负载均衡

高效远程通信

对应用最少侵入

版本管理



Dubbo



Service Mesh 服务网格

Service Mesh 的Sidercar模式



微服务架构落地:

  1. 业务先行

  2. 模块独立

  3. 谨慎重构

  4. 有的放矢,明确实施微服务的目的



命令与查询职责隔离(CQRS):

在服务接口层面将查询(读操作)与命令(写操作)隔离,实现服务层的读写分离.



事件溯源:

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



断路器:

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



微服务网关:

作用:

  1. 统一接入:高性能,高并发,高可靠,负载均衡

  2. 安全防护:防刷控制,黑白名单

  3. 流量管控与容错:限流,降级,熔断

  4. 协议适配:http,dubbo,jsf



网关管道技术:

网关本身没什么业务,主要职责是做各种校验和拦截,这些职责可以通过管道技术连接起来



开放授权协议 OAuth2.0



领域驱动设计 DDD



贫血模型: 事务脚本(只有方法,没有数值或成员变量)

充血模型: 领域模型(合并了行为和数据的领域对象模型)



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

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



子域:由领域拆分而成

如何拆分?

与微服务拆分一样



限界上下文:

子域中, 会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义.这样边界称为限界上下文.限界上下文和子域具有一对一的关系,用来控制子域的边界.

通常限界上下文对应一个组件或者一个模块,或者一个微服务,或者一个类



上下文映射图:



实体:

领域模型对象也被称为实体,每个实体都是唯一的.具有一个唯一标识,一个订单对象是一个实体,一个产品对象也是一个实体



实体设计是DDD的核心所在,

业务分析->识别实体对象

业务逻辑->实体属性和方法

把握实体特征,职责范围(在业务场景和限界上下文中分析)



值对象:

不变性



聚合:关联对象的集合,每个集合都有一个根和边界.



聚合根:将多个实体和值对象聚合在一起的实体.



DDD分层架构

用户接口层:

应用层:

领域层:

DDD六边形架构:实际上就是分层架构的延伸



DDD战略设计: 领域,子域,限界上下文,上下文映射图

DDD战术设计: 实体,值对象,聚合,CQRS,事件溯源



通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要



资深程序员真正有优势的是他在一个业务领域的多年积淀,对业务领域有更深刻的理解和认知.那么如何将这些业务沉淀和理解反映到工作中,体现在代码中呢?实践DDD是一个不错的方式.



如果一个人有多年的经验,那么必然对领域模型有更深刻的认识,把握好领域模型在不断需求变更中的演进,使系统维持更好的活力,并因此体现自己真正的价值.



用户头像

任小龙

关注

还未添加个人签名 2019.02.11 加入

还未添加个人简介

评论

发布
暂无评论
week10 学习总结