架构思维学习总结（二）

2022-05-31 本文已影响0人奋斗的韭菜汪

2-2 架构设计过程

一、架构风格与架构模式

架构风格（Architectural styles）有哪些
根据不同纬度有不同的分类方式，分类比较多。

component-based 基于组件（可复用）
Monolithic application整体应用
Layered 分层架构
Pipes and filters 管道与过滤器（部分分布式锁或者分布式事务的实现）
Event-drivens 时间驱动（消息队列的实现）
Plug-ins 插件化（做插件的，外部业务经常变化，做好底层保持不变，表示层应对不同变化使用插件化的方式去做）
Client-Service 客户服务端（安卓、iOS）
service-oriente 面向服务

架构模式（Architectural Pattern）

多层架构
MVC
DDD
...
$架构风格是概念，架构模式是实现$

二、六大主流架构风格介绍

$Layer Architectural 分层架构$
$\color{red}{本质是：降低复杂度}$ ，水平切分服务
业务（产品）- 前段 - 后端 - DB -测试 -运维
gateway -> controller -> service -> dao
...

$\color{red}{启示}$ ：

软件架构影响企业组织架构，如果不能改变企业组织架构就要考虑迎合企业组织架构进行软件架构设计。

DDD的战略设计中Bounded context 按部门拆分。

$实战应用：在微服务中如何应用分层架构？$
DDD、core/composite/api
详见：A2-05.02.六大架构风格介绍11:55

$Event-Driven Architectural 事件驱动架构$
$\color{red}{本质是：解耦}$
事件驱动的三个关键组件：生产者、路由器、消费者
时间驱动的方式可以实现绝对的解耦
事件是状态的更改和更新，例如：
a. 将商品放入购物车。
b. 购买商品。
c. 修改价格或者收货地址。
d. 状态更新：订单发货的通知。
基于事件驱动架构的实现：
Kafka\RocketMQ\RabbitMQ\ActiveMQ\Spring AMQP\分布式事务saga
$Microkernel Architectural 微内核架构$
$\color{red}{本质是：保证开放性。}$
例如：core system 结合plug-ins的实现
基于微内核架构的实现：操作系统
$Sevice Orient Architectural 基于服务的架构$
$\color{red}{SOA本质是：模块化，提升内聚}$ ，垂直切分服务
微服务本身就是基于服务的架构
延伸：查一查微服务面试题
$Space-base Architectural 基于空间的架构$
$\color{red}{本质是：动态的可扩展应对}$ ，解决可伸缩性和并发性问题
基于空间的架构的实现：K8s
$Big Ball Mud Architectural 大泥球$

三、软件非功能性需求

架构的非功能性参数
1、性能/Preformance：包括压力测试、峰值分析、使用功能频率、所需容量和响应时间的分析
衡量指标：时间（QPS、响应时间、延迟）
2、可扩展性/Scalability：随着用户和请求数量的增加，系统执行和操作的能力
衡量指标：空间（加机器加内存cpu、水平扩展、垂直扩展）
注：一般微服务都是水平扩展，加机器重新部署服务，而不是将服务的cpu内存调大
3、可用性/Availability：对于不停机系统，可用性指标指故障率（比如99.99%）
衡量指标：时间导数/可用率（正常时间/总时间）
如何提高可用性：分布式、异地灾备...
4、安全性/Security：评估系统是否需要故障安全，或者安全性对系统的影响
衡量指标：钱/ROI（成本收益）投入产出比
安全最应该防备公司内部，内部能很快提升ROI（比如定期备份，内部权限控制...）
5、可部署性/Deployability：系统的部署难易程度
难于衡量，那决策时用前置变量
什么因素影响可部署性最大？
架构的选择：默认选择微服务架构
提升服务的可部署性：devops，注：devops要结合自动化测试autotest
6、可测试性/Testability：指软件发现故障并隔离定位其故障的能力特性，以及在一定时间或成本前提下进行测试设计、测试执行的能力
7、灵活性/Modifiability：系统发生功能或者其他变更的适应能力
8、开发性/Developability ：开发的难易程度

四、单体架构的微服务改造过程

1、微服务时如何成为主流的
继承了单体架构的优势，从能使用个人开发到大规模团队开发，然后逐步具备主流优势，最终形成规模效益
2、改造过程
参考《Microservices Patterns》 FTGO点餐项目
问：单体模式最大问题是什么？
答：开发效率低（并非并发达不到），（可开发性，可部署性，可测试性）
源码管理，代码冲突，测试效率低，部署效率低

目标：能将大团队拆分成小团队

微服务改造第一步
1). 消息队列、注册中心、缓存等引入，通讯协议确定。
2). 同一数据库下模块拆分
3). 代码库的拆分（拆分代码放在不同的git库中，保证彼此不影响）
4). 数据库拆分
5). 提升其他非功能性需求（可测试性，可部署性，安全性等）

微服务拆分第二步
1). 使用DDD对服务模块进行拆分（目的：对服务进行拆分，但使用同一个repository）
2). 使用CQRS进行读写分离

微服务拆分第三步
按业务线拆分代码库

使用saga拆分数据库（前置条件：服务和代码库拆分完成）
1).先在一个库中对表进行虚拟划区，各自区的服务独立通过rpc调用
此步关键

业务逻辑建模，使用新数据库重构业务逻辑代码

提升其他非功能性需求（可测试性，可部署性，安全性等）
1).自动化测试引入
2). 使用DDD可替换orderRepository
3).可配置性：配置中心
4).可监控性：健康检查与监控告警
5).容器化与容器编排