week10 模块分解 作业和学习总结
作业一:
(至少完成一个)
根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图。
关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?
作业二:
根据当周学习情况,完成一篇学习总结
作业提交链接
微服务架构是目前主流的互联网开发和部署架构。从个人的观察来看,微服务的兴起和互联网浪潮的兴起密不可分。互联网企业强调的快速迭代,海量用户,作为微服务架构来说还是非常切合的。DDD 设计模式则是在业务和代码已经复杂到一定程度以后,所采取的应对手段,强调业务的重用和边界,以节省开发成本,提升研发效率,缩短产品的迭代周期。
微服务
单体应用的问题
开发运维:编译部署困难
研发管理:代码分支管理困难
基础架构:数据库链接耗尽
产品层面:新增业务困难
单体应用拆封策略
纵向拆分:大应用拆分多个小应用
横向拆分:业务复用独立为微服务
基本原则:
单向依赖,上层依赖下层,不能反向依赖
同层依赖,尽量少的同层依赖
微服务发展历程
SOA 架构
服务发现:注册中心
服务调用:SOAP
微服务
失败转移
负载均衡
高效 RPC 通道
对应用低侵入
服务版本管理
服务网格
基于 SideCar 模式,零侵入
路由透明代理
确定:配置复杂,调用维护关系困难
微服务架构实践
基本原则
业务先行,理顺业务边界和依赖,计算是手段不是目的
先独立模块,后有分布式事物
谨慎处理复杂逻辑,高耦合的系统
明确实施微服务的目标
基本模式
CQRS:命令与查询分离
EventSourcing:实践溯源
断路器
服务调用超时
架构倒三角
Needs:需求
Values:价值
Principles:原则
Practices:实践
Tools:工具
微服务网关
网管是前段和后段的边界控制
基本功能
统一接入
安全防护
协议适配
流量管控与容错
基本模式:管道技术的责任链设计模式
网管类型
异步网管
开放平台
对外开放能力
OAuth2.0 认证
领域驱动 DDD
DDD 诞生的背景
需求零零散散,不断变更
基于零散需求不断修修补补
只有需求分析,没有软件设计
面向需求而不是真实业务
代码结构区别
事务脚本:MVC+DAO
领域模型
贫血模型:Servers 管逻辑,POJO 只管属性
充血模型:对象既有逻辑,又有属性
DDD 战略设计
领域定义
子域
限界上下文
上下文映射图
实体
值对象
聚合
DDD 分层架构
用户接口层
应用层
领域层
DDD 重构基本套路
组件设计原则
原理
内聚原则
耦合原则
评论