演进式架构思维导图模板_ProcessOn思维导图、流程图

1 软件架构

演进式架构

一切都在变化，如何长期规划

风险（eg.甘蔗蟾蜍）

向高度动态的系统引入变化，可能会产生无法预料的结果

观念PK

软件架构 = 将来难以变更的部分

易于改变时架构的基本原则

构建完架构后，如何防止退化

持续演进的能力

增量变化、适应度函数、适当的耦合

增量变更

增量地构建

增量地部署

引导性变更

保护重要的架构特征

“适应度函数”

计算潜在的解决方案与既定目标的差距

多个架构维度

技术

架构中的实现部分：框架、依赖的库和实现语言

数据

数据库模式、表设计、优化设计

安全

定义安全策略、指导方针和指定工具来帮助发现缺陷

运维与系统

关注架构如何映射到物理的技术设施中

康威定律

设计系统的架构 = 组织的架构

为何演进

一个适用的并能在其所处的不断变化的环境中持续运行的系统

2 适应度函数

总概

定义

为某些架构特征提供了客观的完整评估

安全、性能、故障恢复力...

维度

单一适应度函数

业务场景不同，关注特征不同

全系统适应度函数

权衡

什么是适应度函数

为某些架构特征提供了客观的完整评估

适应度函数分类

原子 VS 整体

触发式 VS 持续式

静态 VS 动态

结果固定 VS 基于上下文变化的因素（高并发低响应）

自动 VS 手动

临时 VS 预设

升级前破坏测试

特定领域

尽早确定

风险

错误的设计选型，导致失败

过度设计，资源浪费

系统无法适应后续变化

3 类

关键维度

对技术、设计决策至关重要

相关维度

在特性级别考虑，不太会指导架构决策

不相关维度

不影响设计和决策

审查

外部环境变化后，是否还满足设计目标

清单

审查已有的适应度函数

审查当前适应度函数的相关性

确定每个适应度函数的规模的变化

确定是否有更好的办法测量

发现新的适应度函数

3 实施增量变更

包含

开发

如何增量构建

运维

如何增量部署

构件

可测试性

部署流水线

组合适应度函数

eg.每天部署60次

目标冲突

假设驱动 VS 数据驱动

eg.移植什么

4 架构耦合

模块化

架构的量子和粒度

不同架构的演进能力

大泥团

单体架构

事件驱动架构

服务导向架构

“无服务”架构

控制架构量子大小

eg.防止组件循环依赖

5 演进式数据

演进式数据库设计

数据库模式演进

共享数据库集成

不当的数据耦合

二阶段提交事务

数据的年龄和质量

eg.PW 的路由演进

6 构建可演进的架构

演进机制

识别受演进影响的架构维度

为每个维度定义适应度函数

使用部署流水线自动化适应函数

全新的项目

改良现有项目

适当的耦合和内聚

工程实践

适应度函数

商业成品软件

架构迁移

迁移步骤

演进模块间的交互

构建指南

去除不必要的可变性

让决策可逆

演进优于预测

构建防腐层

eg.服务模板

构建可牺牲架构

应对外部变化

更新库与更新框架

持续交付优于快照

服务内部版本化

eg.PW 的评分服务演进

7 演进式架构的陷阱和反模式

技术架构

反模式：供应商为王

完全围绕供应商产品构建的架构，将组织和工具病态地耦合

建议：所有软件都视为集成点，构建防腐层

陷阱：抽象泄露

底层抽象破坏会导致意外的灾难

随着时间的推移，技术的变更，起初的抽象都会出现意外偏差

建议：找到关键集成点，通过适应度函数自动保护它们

反模式：最后10%的陷阱

套装软件、平台和框架的陷阱

解决80%问题，猴子补丁搞定10%问题，剩下10%无能为力

反模式：代码复用和滥用

复用软件更像是器官移植而不是拼装乐高积木——John D. Cook

代码复用性越高，其可用性越低

微服务：重复优于耦合

使用服务模板将服务的各个部分耦合一起

建议：复用前评估它们仍能提供价值

允许团队分叉（fork）组件代码并添加自己的新功能

陷阱：简历驱动开发

不要为了架构而构建架构，构建架构是为了解决问题

增量变更

反模式：管理不当

将不同技术栈统一成单一技术栈

统一技术栈

员工可替代，意外的耦合

不同技术栈

员工不可替代，耦合度低

“金发姑娘”管理

小型项目

Ruby on Rails 和 MySQL

中型项目

Go 和 MongoD/MySQL

大型项目

Java 和 Oracle

陷阱：发布过慢

生成周期：开发人员开始某个新功能开发，到这个功能在生产环境中运行

演进速度和生产周期成正比，生成周期越短，演进越快

业务问题

陷阱：产品定制

为每个客户定制

永久的功能开关

产品驱动定制化

反模式：报表

正例：架构师构建分层来减少意外耦合，创建隔离层来分离关注点

反例：报表设计员将报表和数据库模式直接耦合起来

协调也是耦合

使用事件流 or 消息队列

eg.分离领域服务和报表服务，通过消息队列协调

陷阱：规划视野

早期的假设可能错误

沉默成本影响决策

投入越多，越难放弃

建议：警方长期规划，将大型项目分解成更小的早期可交付物

8 实践演进式架构

组织因素

全功能团队

目标之一：消除协调摩擦

业务分析师、架构师、开发人员、测试人员、运维人员、DBA...

围绕领域组织团队

产品高于项目

围绕项目组织

开发团队->运维团队

开发人员无需修复bug和维护工作，对质量不再关心

围绕产品组织

全体成员对产品都有责任感

应对外部变化

如何构建可以自由演进的组件，同时还维持集成点的完整性呢？

消费者驱动的契约

团队成员间的连接数

连接数：

尽量减少团队之间的连接数

团队的耦合特征

文化

试验文化

鼓励试验

从外部吸收想法：参加展会，技术沙龙...

鼓励明确的改进：丰田的持续改善

进行探针试验并稳定下来：临时方案->正式方案

创造创新时间：Google的20% 业余项目时间

基于多方案的开发方式

连接工程师和最终用户

首席财务官和预算

架构量子和成本之间的关系

构建企业适应度函数

企业架构师职责

指导架构和定义企业级适应度函数

eg.开源库的合法性

从何开始

容易实现的目标

最高价值优先

测试

基础设施

全功能团队

常见问题

开发/运维的隔离

研发公司/运行主体的隔离

Why not?

为何选择构建演进式架构

1、可预测与可演进性

未来不可预测，增强软件适应变化

2、规模

架构中任何耦合点最终将阻碍架构延伸

解耦强化可演进性

3、高级业务能力

一旦组件高度耦合，将难以执行A/B 测试

4、以生产周期为业务指标

5、在量子级别隔离架构特征

为何不选择构建演进式架构

1、大泥团无法演进

2、其他架构特征占主导地位

3、可抛弃的架构

先临时验证可行性，再构建真正的架构

4、计划即将停止业务