架构师训练营第十周学习总结

关注
发布于: 2020 年 08 月 09 日
巨无霸应用系统带来的问题
1）编译、部署困难。
2）代码分支管理困难，merge冲突，发布的时候问题互相纠缠，顾此失彼，每次发布都要半夜三更。
3）数据库连接耗尽。
4）新增业务困难。都是雷区，老人忙得要死，新人一帮忙就容易添乱。
﻿
大系统拆分方式
纵向拆分：将一个大应用拆分成多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。
横向拆分：将复用的业务拆分出来，独立部署成微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。
﻿
Web Service分布式服务
缺点：
1）臃肿的注册与发现机制
2）低效的XML序列化
3）开销相对高的HTTP网络通信
4）复杂的部署和维护手段
﻿
Dubbo微服务框架架构
﻿
Service Mesh服务网格
Service Mesh是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。
﻿
Service Mesh的sidecar模式
﻿
﻿
微服务架构落地
业务先行，先理顺业务边界和依赖关系（最重要），技术是手段而不是目的。
先有独立模块，后又分布式服务。
业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。
要搞清楚实施微服务的目的是什么？业务复用？开发边界清晰？分布式集群提升性能？
﻿
微服务最佳实践
CQRS：读命令与写命令隔离。
事件溯源：将用户请求过程中每次状态变化都记录到事件日志中。
断路器：三种状态是关闭、打开、半开。
服务重试与调用超时：上游调用者超时时间要大于下游调用者超时时间之和。
最重要的是需求：
﻿
远程过程调用（RPC）
﻿
Dubbo通信协议
Dubbo利用requestId避免对头阻塞，实现全双工通信。
﻿
按作用划分架构师
设计型架构师：也就是一般意义上的架构师，负责系统架构设计，同时也要负责架构的实施落地。
救火型架构师：充当救火队员的角色。
布道型架构师：对某一领域有较为深刻的认识，乐于分享，希望能够推广自己的技术主张，会成为忽悠大师。
Geek型架构师：精益求精，追求完美，通常技能不够全面。此类架构师通常怀才不遇。
﻿
 网关作用
统一接入：高性能、高并发、高可用、负载均衡
安全防护：防刷控制、黑白名单、统一鉴权认证
流量管控和容错：限流、降级、熔断
协议适配：http、dubbo等
﻿
Flower异步网关与异步微服务框架
﻿
开放授权协议OAuth2.0
﻿
﻿
OAuth2.0授权码登录
﻿
为什么需要DDD？
很多项目的实际情况：
产品经理需求零零散散，不断变更。
工程师在各处代码中寻找可以支持需求变更的代码，反复修修补补，对每块代码的职责缺乏思考。
软件只有需求分析，缺乏真正的设计，系统没有一个统一的领域模型维持其内在逻辑一致性。（产品堆功能，但是对于这个功能是否真的是这个领域所必要的，缺乏思考）
功能特性并不是按照领域模型内在的逻辑设计，而是按照人自己的主观想象拍脑袋设计。
﻿
项目时间一长，各种困难重重，需求延期，线上bug不断，管理者考虑要不要推倒重来，程序员考虑要不要跑路。
﻿
贫血模型VS充血模型
贫血模型：类似Controller、Service、Dao这种这种只有方法，没有成员变量，而方法调用时传递的数值对象，比如Contract，没有方法（或者只有构造方法、getter、setter），典型的面向过程。
充血模型：合并了行为和数据的领域对象模型。通过领域模型对象的交互完成了业务逻辑。也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。
﻿
什么是领域？
领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。
﻿
什么是子域？
领域是一个组织所做的事情及其包含的一切。这个范围就太大了，不知道该如何下手。所以通常的做法是把一个领域拆分成多个子域。比如：用户、商品、订单、库存、物流、发票等。（一个微服务很可能就是一个子域）如何划分子域是一个关键。（卖家提现功能属于用户子域，还是财务子域？）
﻿
限界上下文
在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性。通常限界上下文对应一个组件或者一个模块，或者一个微服务，一个子系统。
﻿
上下文映射图
不同的限界上下文，也就是不同的子系统或者模块之间会有各种交互动作。DDD使用上下文映射图来设计这种关联和交互。
﻿
DDD分层架构
领域实体的组合调用和事务控制在应用层。
﻿
DDD的战略设计和战术设计
领域、子域、限界上下文、上下文映射图，这些是DDD的战略设计。
实体（领域模型对象，每个实体是唯一的，有唯一标识。比如一个订单对象是一个实体。实体会发生变化，但是实体的唯一标识不会变化）、值对象（并不是领域内的对象都应该被设计为实体，比如住址的对象就是值对象，值对象不会变化，也没有行为）、聚合（是一个关联对象的集合，我们将其作为一个单元来处理数据更改。聚合根：将多个实体和值对象聚合在一起的实体）、CQRS、事件溯源，这些是DDD战术设计。
通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。
﻿