[笔记] 01 架构的概念和目的，以及架构设计复杂度的来源

目录

• 概念
• 架构设计的目的
• 复杂度来源：

概念

1. 系统
   指由一组有关联的个体组成，并遵循某种规则运作，可以完成单个个体不能独立完成的工作的群体。

2. 子系统
   和系统一样，只是观察视角差异，是另一个更大系统的组成部分。

3. 模块 和 1.4. 组件
   都是系统的组成部分，是从不同角度来拆分系统。
   从逻辑角度拆分后的个体，就是模块，其目的在于职责分离；
   从物理角度拆分后的个体，就是组件，其目的在于复用。

4. 框架
   指为了实现某个标准或完成特定任务，提供的基础功能的软件产品。

5. 架构
   定义1：指软件系统的基础结构，以及创造这些结构的准则和对这些结构的描述。
   定义2：指软件系统的顶层设计。
   所以，架构其实是非常宽泛的概念，因为无论是系统和框架、还是模块和组件，都可以对其设计基础架构，并描述和说明设计准则，那么它们都有不同层次的架构。

架构设计的目的

是为了解决复杂度带来的问题。

复杂度来源：

1. 高性能

   • 单机内部高性能
     手工 - 批处理 - 进程 - 线程 - 协程；要结合业务分析、判断、选择、组合，要进程间通信，要多线程并发……
   • 多机集群
     任务分配：从1对1 ---> 1对N ---> N对N
     任务分解：简单更容易高性能，单任务可针对性扩展。但大大增加系统间数据访问次数，所以拆分也是有极限的，一定程度后，性能就很难上升了。

2. 高可用
   指系统无中断地执行其功能的能力。难点在于硬件会老化、会出故障；软件逐渐庞大复杂、会有bug。
   其解决方案本质上，都是通过“冗余”。冗余增强可用性，也带来复杂度。

   • 计算高可用
     单机to多机，需要任务分配（分配算法，不同目的等），需要多机互联的管理（心跳、中断恢复等）
   • 存储高可用
     数据同步是需要时间的。所以本质上意味着在同一时间，系统的不同存储服务器的数据，肯定是不一致。数据不一致，即使逻辑一直，业务表现就不一样。
     难点：不在于如何备份或同步数据，而是如何减少或规避数据不一致，对业务的影响。CAP定理，需要实际设计时，进行权衡取舍。
   • 高可用状态决策
     计算和存储高可用的基础，都是状态决策，就是系统能够判定当前状态，是正常的，还是出了异常。有异常就要有方案来保证。如果状态决策有问题，那么后续方案就没有价值了。
     本质上，只要是通过冗余来实现高可用，状态决策就不可能完全正确。

1. 独裁式存在决策者单机不可靠问题；2) 协商式存在无法彻底解决连接中断后主机选择问题；3) 民主式存在脑裂问题。

3. 可扩展
   设计具有良好扩展性的系统，有2个基本条件：正确预测变化、完美封装变化。难点是：
   对于预测变化：1) 不可能每个设计点都考虑可扩展性；2) 不能完全不考虑可扩展性；3) 所有的预测，都存在出错的可能性。
   对于应对变化：

   1. 区分变化和稳定
      a) 需要拆分出变化层和稳定层；b) 需要设计两个层之间的接口。需要在有变化的差异实现中，找出共同点的同时，保证接口不需要修改，是非常复杂的事情。
   2. 提炼抽象层和实现层
      a) 设计模式；
      b) 规则引擎。

4. 低成本
   和高性能高可用的目标冲突，所以经常不是主要目标，而是附加约束。但服务器规模成千上万时，低成本设计是一件很值得的事情。
   低成本给架构设计带来的挑战是：往往只有创新或引入新技术，才能解决问题。

5. 安全

   • 功能安全
     和编码相关，如XSS攻击、CSRF攻击、SQL注入、OS漏洞、密码破解……长期斗争
   • 架构安全
     互联网时代，全球任何地方都可以发起攻击，传统架构安全主要依靠防火墙；但防火墙性能一般，所以多用于银行和企业，而互联网面对DDOS攻击，更多依靠云服务商的强大带宽和流量清洗能力，没有太好的设计手段。

6. 规模

   • 功能多，关联多，业务逻辑复杂
   • 数据多，关联多，需要拆分(单表to多表，集中to分布式)