micklongen的专栏

A. 系统架构概要 概述 历史 第一次软件危机(20世纪60年代~20世纪70年代) 解决方案：抛弃GOTO的结构化程序通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。 第二次软件危机与面向对象(20世纪80年代) 第一次软件危机的根源在于软件的“逻辑”变得非常复杂，而第二次软件危机主要体现...

C. 高可用架构 --- 数据完整性 概述 数据的问题 数据的可访问性（可用性） 数据的完整性 手段：主动探测和快速修复能力 衡量指标 在线时间 延迟 规模 创新速度 隐私 备份与存档 备份：能够快速恢复 存档：存储，以满足审核，取证和合规要求 难点 核心：复制机制和冗余并不意味着可恢复性 如果该环境使用...

C. 高可用架构 --- 数据完整性 ---Google SRE保障数据完整性的手段 概述 用户删除数据 用户可见的垃圾 措施 用户可以还原 好处 预防用户错误 应用程序删除数据 用户不可见，有应用程序或者存储服务软删除 措施 可以被用户支持团队或者应用程序管理员恢复 好处 防范应用程序Bug和服务管...

C. 高可用架构 --- 连锁故障处理 概述 由于整个系统的一小部分出现故障，进而导致系统其他部分也出现故障 原因 服务器过载：原本均衡的两个系统，由于其中一个服务出现问题，导致另外一个服务出现过载 资源耗尽 CPU，副作用： 正在处理的请求数量上升 队列过长 线程卡住 CPU死锁或者请求卡住 RPC超时 CPU缓存效率下...

C. 高可用架构 --- 限流降级 概述 核心思路：优先保证核心业务和优先保证绝大部分用户 原因 内部原因：程序 bug 导致死循环，某个接口导致数据库慢查询，程序逻辑不完善导致耗尽内存等。 外部原因：黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户，第三方系统大量请求，第三方系统响应缓慢等。 过载情况 数据中心大量后端任务都处于过载状态 数据中...

C. 高性能架构 基本思路 操作 并发读 并发写 技术 性能优化 限流、降级 单服务器高性能模式 关键技术 服务器采取的并发模型 问题 服务器如何管理连接。 服务器如何处理请求。 解决方案 I/O 模型：阻塞、非阻塞、同步、异步。 进程模型：单进程、多进程、多线程。 连接/请求数量 ...

C. 高性能架构 --- 高性能负载均衡 概述 不同类型的请求，对网络链路要求不一样，比如说 搜索请求的要求是：延迟 视频上传的要求是：吞吐量 单从硬件来看，关于优化资源的利用率，避免某个服务器负载过高 分类 DNS 负载均衡：DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。 优点 简单、成本低：负载均衡工作交给 DNS 服务器处理...

D. 互联网架构模板 架构如何演进 流派 潮流派 保守派 跟风派 架构演进的驱动力 产品类：技术创新推动业务发展 服务类：业务发展推动技术创新 答案就是基于业务发展阶段进行判断 互联网技术演进的模式 核心问题：业务复杂度和用户量 业务复杂度 初创期 发展期：当业务推出后经过市场验证如果是可行的，则吸引的用户就会越来越多，此时原来不...

E. 业务场景 --- 秒杀系统 概要 核心问题 并发读 并发写 秒杀的整体架构可以概括为“稳、准、快”几个关键字 所谓“稳”，就是整个系统架构要满足高可用 就是“准”，就是秒杀 10 台 iPhone，那就只能成交10 台，多一台少一台都不行。 最后再看“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？ 架构设计原则...

C. 高可用架构 FMEA 具体分析方法 给出初始的架构设计图。 假设架构中某个部件发生故障。 分析此故障对系统功能造成的影响。 根据分析结果，判断架构是否需要进行优化。 FMEA 分析表 功能点 故障模式 故障影响 严重程度 故障原因 故障概率 风险程度 已有措施 规避措施 解决措施 后续规划...

C. 高可扩展架构 --- 微服务架构 SOA的区别 服务粒度 SOA：粗 微服务：细 服务通信 SOA：重量级，ESB 微服务：轻量级，HTTP、RPC 服务交付 SOA：慢 微服务：快 应用场景 SOA：企业级 微服务：互联网 微服务的坑 服务划分过细，服务间关系复杂 服务数量太多，团队效率急剧下降 调用链太...

C. 高可扩展架构 概述 前提：都是由普通人组成的团队，而不是高手组成的团队 基本思想：基本思想都可以总结为一个字：拆 思路：不同的拆分方式，本质上决定了系统的扩展方式 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。 优缺点 扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。例如学生信息管理系统...

A. 系统架构概要 --- 分布式系统 概述 常见场景 脑裂问题 需要人工干预场景的灾备切换 有问题的小组成员算法 理论基础 基础算法 一致性哈希 布隆过滤器 SkipList LSM树 Merkle哈希树 Snappy与LZSS算法 Cuckoo哈希 Gossip协议 任务调度 分布式协调系统 Chubby Zooke...

A. 系统架构概要 --- 分布式系统 --- 任务调度 基本问题 资源异质性和工作负载异质性 数据局部性 节点局部性 机架局部性 全局局部性 抢占式调度和非抢占式调度 资源分配粒度：作业级和任务级 全分或者全不分 增量满足式分配 资源储备 策略 饿死和死锁问题 资源隔离方法 资源管理与调度系统范型 集中式调度器 两级调...

A. 系统架构概要 --- 分布式系统 ---数据处理 概述 问题 工作分发不均造成的问题 任务调度 核心：在资源成本和挤占风险之间取得平衡 低优先级运行，导致不能及时获取足够的资源 惊群效应 一个错误导致整个集群出问题 摩尔负载模式：不同任务之间或者同一个任务的不同阶段的资源共享问题 离线批处理 MapReduce 实时流式处...

A. 系统架构理论基础（分布式） CAP原则 适用的分布式系统（互联和共享数据）：1. CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。2.CAP 关注的粒度是数据，而不是整个系统。 概念描述 一致性：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。 可用性：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。 分区容忍性...

A. 系统架构理论基础（理论） --- 数据一致性 算法 事务算法 算法 Redo算法 Undo算法 Redo/Undo算法 一致性协议 两阶段提交协议 第一阶段请求 第二阶段提交 向量时钟 RWN协议 Paxos协议 Raft协议 一致性模型 强一致性 最终一致性：最终一致性不代表不能实时修改，...

B. 应用开源项目 选择 1. 聚焦是否满足业务 2. 聚焦是否成熟 判断标准 版本号：除非特殊情况，否则不要选 0.X 版本的，至少选 1.X 版本的，版本号越高越好。 使用的公司数量：一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好，数量越多越好。 社区活跃度：看看社区是否活跃，发帖数、回复数、问题处理速度等。 3. 聚焦运维能力...

B. 系统架构设计步骤 架构设计三原则 合适原则：合适原则宣言：“合适优于业界领先”再好的梦想，也需要脚踏实地实现！这里的“脚踏实地”主要体现在下面几个方面。 1. 将军难打无兵之仗 2. 罗马不是一天建成的 3. 冰山下面才是关键 简单原则：简单原则宣言：“简单优于复杂”。 软件领域的复杂性体现在两个方面： 1. 结构的复杂性结构复杂的系统几乎毫无...

B. 系统重构 概述 问题 业务已经上线，不能停下来 关联方众多，牵一发动全身 旧架构的约束 思路 1. 后台系统重构：解决不合理的耦合 2. 游戏接入系统重构：解决全局单点的可用性问题 3. 系统：解决大系统带来的开发效率问题 沟通 合纵：产品经理、项目经理沟通 核心：所以在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说...