分布式系统架构笔记
概述
能够识别与分布式系统的非功能性需求相关的指标和机制
能够识别和解释在对分布式系统进行建模时使用的各种视点。
能够在设计分布式系统时对架构样式进行适当的选择。
能够实现一个简单的分布式系统，考虑函数外属性。
能够分析架构模型并评估从不同角度呈现的分布式系统模型，以评估它们对各种非功能性需求的满足程度。
包含两部分：架构和系统
分布式系统的三部分：processing elements、communication network和software。
在去中心化的系统里，仍然有一部分“中心节点”
而在分布式系统中，完全不存在任何中心节点。
只要在去中心化系统中加一两条边，就可能使得整个系统变成分布式系统。
逻辑上中心化和物理上集中化的系统：
全局上没有时间、状态的观念（每个计算机不会去记录其他计算机的情况）
异质结构——跨平台
分布式系统的设计目标：
1. 资源共享
2. 分布式的透明性（注意定义，这里是说的对用户而言，看不出来系统实际上是分布式的）
Relocation是系统发起让资源转移的
Migration是指在使用过程中，用户发起的转移，比如使用手机
3. 可规模性（Scalability）
3.1 规模可规模性：可以向系统添加更多用户和资源，但不会有明显的性能损失。
3.2 地理可规模性：用户和资源可能相距很远，但通信延迟可能很严重这一事实却很难被注意到。
3.3 管理可扩展性：即使跨越多个独立的管理机构，仍能轻松管理。
4. 公开性
网格计算（异质的计算机）、集群计算（同质的计算机）
开发时的一些错误假设：
架构
所谓的中间件层将应用程序与底层平台分离。
架构概念
概念、ISO/IEC/ICEE 42010/4+1模型
架构框架：用于描述在特定应用领域和/或利益相关者社区内建立的架构的约定、原则和实践
环境：决定系统所有影响的设置和环境的上下文
利益相关者：对系统持有关注的个人、团队、组织（或其类别）
对应关系：两个或多个架构描述元素之间已识别或命名的关系
关注点：对与其一个或多个利益相关者相关的系统的兴趣
方面：实体的特征或本质的一部分
规范：以完整、精确和可验证的方式识别实体的需求、设计、行为或其他预期特征的信息部分
利益相关者视角：思考利益实体的方式，尤其是与关注点相关的实体
架构视图：从特定系统关注点的角度表达系统架构的工作产品
acquirers：负责采购系统时的事务
assessors：负责考虑系统是否合规合法
communicators：通过文档解释系统
developers：构建开发系统
maintainers：维护系统（管理迭代）
suppliers：提供软硬件条件
support staff：协助用户在系统上运作
system administrators：部署后运行系统
testors：检查系统是否符合预期的成果
users：定义系统的功能、成果并使用
view：看到的东西
viewpoint：从哪看的
Kruchten view：
逻辑view、过程view、开发view、部署view
用户用、开发者开发、系统管理者管理、系统工程师部署
RW Viewpoint：
Context Viewpoint：
描述系统与其环境（人、系统、外部实体）之间的关系、依赖关系和交互。
解决问题：
1. 系统范围
2. 责任
3. 使用的数据
Functional Viewpoint：
描述系统的运行时功能元素及其职责、接口和主要交互。
解决问题：
1. 功能能力
2. 外部接口
3. 内部结构
4. 设计理念
Information Viewpoint：
描述架构存储、操作和分发信息的方式。
解决问题：
1. 信息结构
2. 内容和流程
3. 数据所有权、数量、有效性、生命周期和可访问性；交易管理（交易到底是啥？）
4. 恢复
5. 内部规范
Concurrency Viewpoint：
描述系统的并发单元（如进程和线程）、其功能以及所需的协调。
解决问题：
1. 任务结构
2. 进程间通信
3. 状态管理
4. 同步与重载入
5. 进程的创建和销毁
Development Viewpoint：
描述系统的开发和集成过程
解决问题：
1. 模块组织
2. 共同处理
3. 设计和测试标准化
4. 代码组织与检测
Deployment Viewpoint：
描述系统的部署环境，例如节点数、链路数、软件依赖关系等
解决问题：
1. 硬件
2. 第三方软件
3. 技术兼容性
Operational Viewpoint：
描述系统在生产环境中的操作方面，例如安装过程
解决问题：
1. 安装与升级
2. 监控运行情况
3. 配置管理
4. 资源管理
EFR：额外功能要求
非常希望可以使用该架构来查看这些问题是否得到满足
可访问性、可理解性、可用性、通用性、可操作性、简单性、移动性、游牧性、可移植性、准确性、效率、占用空间、响应性、可扩展性、可调度性、容错性、及时性、CPU利用率、延迟、吞吐量、并发性、灵活性、可变性、可进化性、可扩展性、可修改性、可定制性、可升级性、可扩展性、一致性、适应性、开放性、可组合性、互操作性、可集成性、责任性、完整性、简洁性、正确性、可测试性、可跟踪性、连贯性、可分析性、模块化、可重用性、可配置性、可分发性、可用性、机密性
架构风格
服务：
合同指定的实体的整体功能。
协议
一组正式的规则，规定实体之间的信息交换以及交互应如何进行。
规则规定
1. 消息格式
2. 有限状态机
3. 时间限制
4. 其他质量属性
四个特别的风格：
Layered
分层架构：只有上层的东西能够调用下层的东西
每层都应该有一定的功能，且有稳定的方式保证各相邻层之间能够稳定通信。
问题：过于依赖通信和下层
严格分层时只有n-1层
Client-server
客户端-服务器风格
动机：关注点分离、共享一些资源、保护和管理内容、延迟绑定、减少依赖
动态结构，服务器可以分布
服务器是被动的
客户端没有限制
缺点：
单个服务器可能成为性能瓶颈
服务器可能出现单点故障
Publish-subscribe
服务器主动，可能有中介，当数据可用且相关时发送数据
缺点：由于额外的间接性，延迟时间更大且波动更大。不适合硬实时约束。
Peer-to-peer
点对点
动机：共享资源和内容、社区合作、角色对称、并发性高
特征：加入社区，被动向其他host提供服务、积极使用其他host的服务。
有Super peer，为社区提供更多资源。
弱点：安全性、缺乏管理
时间耦合是指分布式系统的不同组件必须与特定时间或截止日期同步运行的情况
引用耦合是指分布式系统中组件或模块之间基于共享数据或引用的依赖关系
云计算：硬件+软件分层
服务Client-server
虽然后续有关于REST等架构的题，但考试不会考，这部分包括：
REST
Batch
Pipe & filters
Service-oriented
Model View Controller
Blackboard
Virtual machine
Interpreter
系统
交互风格
层叠式协议和中间件：
中间件权衡
交互模式：
1. 中间件仅提供通信服务
2. 中间件提供网络接口
Remote procedure call（远程过程调用）、消息导向的中间件
命名
服务发现
名称系统
分布式扁平化方案
分布式结构化方案
虚拟化
资源分配
资源整合（resource consolidation）
容器（container）
可扩展性
可扩展性的种类，以及如何评估他们
容错
系统错误容错及过程错误容错
复制及一致性
一致性
副本（replica）管理
分布式服务器（访问集群）
集群的目的：
1. 提高性能
2. 提高可靠性
3. 提高可用性
请求处理：
让第一层处理所有通信可能遇到瓶颈
增加一个服务器（交换机）来处理连接问题，不过响应可以直接返回给客户端
请求调度：
对于Finger table，如果我们不能直接跳到这个数本身上，我们就跳到其后边存储其的点上（甚至于说，我们就应该跳到后面存储其的点上）
注意finger table一般假设每个节点能够感知其存储了多少个节点（不然没法做了）
删除存储节点时，只需要将所有与存储节点有关的值替换成其下一个存储节点的位置。因此需要特别注意的是一些大跳的情况。
迭代的DNS解析：
递归的DNS解析：
可规模性（Scalibility）vs弹性（Elasticity）
前者是用来衡量规模的，系统应对成长的能力。
应对的是用户端那一侧的
后者是用来衡量系统系统适应成长的能力。
阿姆达尔定律：
问题不变时，评估程序在并行后的加速比
$s+p / (s+p/N)$
Gustafson定律
问题大小扩展时，程序的加速比
$s+(p*N)$
架构位于高层，本身无法保证质量
必须权衡各个部分的重要程度
CAP定理：一致性、可靠性和进程组的划分不能兼得
拜占庭将军问题的解
容错问题：
Failure：故障，外部可观察到的不同（崩溃的程序）
Error：错误，可能导致故障的状态（编程上的小失误）
Fault：错误的原因，比如程序不够全能
比如：
给数字输入了字符串
错误的原因是程序不能处理字符串
错误状态是读取后程序的状态
故障（如果存在）就是输出了乱码什么的
冗余保障不会那么错——多个位数
心跳检测
容错——防止错误变成故障的技术
分区vs复制
复制是完全一样，分区是分成若干块
分布式系统的读写顺序不一定，可能会导致故障
在本地多存一份数据
要求进程的读写操作和按照某种顺序执行的结果必须相同。
