对架构和架构师的认知
最近读了两篇文章，一篇是《带你详细了解架构设计》，一篇是《如何成为架构师？》，写的很好，也很认同，推荐有时间的多读几篇原文，本文是对这两篇文章的理解和自己的经验总结。
文章有很多概念，读起来会让人回到中学读书时代，在中学阶段，学生会通过教科书、课堂讲解等方式了解基本概念和定义，比如数学中的几何形状、物理中的力学规律等。
知识学习的套路是建立在掌握基础概念的基础上，通过理论学习与实践相结合、持续练习和复习、拓展知识面和深入学习，以及持续学习和更新来不断提升自己的学习能力和技能水平。
在 IT 技术学习中对于打工人来说有点繁文缛节，太正版，不接地气，顾弄玄虚。我以前这么认为的，不过最近认知升级，有这么一些变化：《能文能武李延年》为什么拍的好，因为它讲明白一件事，我们为什么要打仗，我们要学习架构，是不是应该搞懂为什么需要架构，架构是什么，再扩延一下，5W2H，理论作为指导，和实践相结合，才能一直打胜仗。
说了一堆废话，想说明白自己的一个理解，概念和定义是理论，可以用来指导我们的实践。
架构
用5W2H维度来思考一下架构：
- 2w（分析维度）：why what。回答 为什么 和 是什么这个问题。
- 3w（属性维度）：when who where
- 1h ：how to do 核心本质怎么做
- 1h ：how much 核心成本，也是 ROI
What & Why
架构是什么？
架构是经过系统性的思考，权衡利弊之后在现有资源约束下的最合理的决策，最终明确的熊他那个骨架：包含子系统，模块，组件，以及他们之间的协作关系，约束规范，指导原则。并由他来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。
架构由以下几个方面组成：
- 系统性思考的合理决策
- 明确的系统骨架
- 系统协作关系
- 约束规范和指导原则
为什么要架构设计，架构设计的目的？
架构的本质是管理和解决系统的复杂性，提高效率。
管理复杂性：对系统进行有序化重构，不断减少系统的熵，使系统不断进化，改善软件质量为目的的内在结构性变化。
提高效率：对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
When & Who & Where
何时进行架构设计？谁来参与架构设计？
架构不是一成不变的，是演进的。在软件开发的各个阶段都有可能介入。
参与架构的人：架构师，开发，业务人员等
在哪些地方进行架构设计？
可以用 TOGAF9 架构分类来说明在哪些方面架构
- 业务架构：业务战略、治理、组织和关键业务流程
- 数据架构：组织的各类逻辑和物理数据资产以及数据管理资源的结构
- 应用架构：系统之间交互，以及他们与组织核心业务之间关系
- 技术架构：IT 基础设施、中间件、网络和通信、部署处理和标准
How to do
架构设计怎么做？
从架构分类角度分布考虑设计，从架构是否合理角度设计出发。
//TODO
How much
核心成本，架构设计是否合理？
- 业务需求角度
- 非业务需求角度
- 成本
业务需求：
- 能解决当前业务需求和问题
- 高效完成业务需求
- 前瞻性设计
非业务需求：
- 高可用
- 文档化
- 可扩展化
- 高复用
- 安全
架构师应该具备的能力
业务能力
这里的业务能力是指业务架构能力，//TODO
架构能力（设计）
这里的架构能力是指技术架构能力，//TODO
通用技术方案（包含设计）
常用技术手段：
- 布隆过滤器
- 一致性哈希
- 缓存
- WAL
- 分段日志，定时合并日志
- 常用负载均衡方法
- 惰性过期删除
- 读写分离
- Leader/Follower
- 事件驱动
- 异步设计
- 消息队列
- 幂等
典型技术拆分方案：
- 分库分表
- 高并发拆分
- 集群
- 多活&热备
分布式设计方案涉及问题和手段：
最终一致性
分布式事务：xa,tcc,saga
分布式锁
高水位线（High-Water mark）
领导者(Leader)和追随者(Follower)
分布式协议 raft
Gossip 协议
CAP 定理
校验和