彩虹马的博客

引言前面文章中介绍了很多架构相关理论，接下来说一说怎样才能画出一幅好看、好懂、好用的架构图。俗话说“一图胜千言”，一张好的结构图是不需要过多解释的，他应该是自描述的，并且要具备一致性、健壮性和足够的准确性，能够和代码相呼应。 架构图分类 产品/业务架构使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分，需要考虑各个模块的分层和边界。主要包括业务规划、业务模块和流程以及问题域的列表等。 模板可参考我的ProcessOn文件：产品蓝图、产品架构图 应用架构对整个系统实现的总体上的架构，需要指出系统的层次、系统各个层次的应用服务、组成关系、依赖关系。 体现了架构是分层的，不同层次有不同的规则与关联。 类似Java开发里面的三层架构，数据访问层、业务逻辑层、展现层。或者类似领域模型中的领域服务层、应用层、界面接口层分层方法。 模板可参考我的ProcessOn文件：应用架构图 存储/数据架构是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景 ，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。 技术架构离程序员最近的架构设计，突出技 ...

引言在众多分布式ID中，雪花算法是比较简单且常用的算法，分布式ID一般具有的特性有： 唯一性：生成的ID全局唯一，在特定范围内冲突极小。 有序性：生成的ID全局或按规则有序，便于数据库插入及排序。 可用性：可保证高并发下的可用性，确保任何时候都能正确的生成ID。 自主性：分布式情况下不依赖中心认证即可自行生成ID。 安全性：不暴露系统和业务的信息，如：订单数、用户数…. 常见的分布式ID生成方式比较 比较点 SnowFlake Leaf UidGenerator Redis 依赖数据库 否 是 可选 是 支持分布式 是 是 是 是 可预测 - - - - 依赖性 毫秒级时间戳 + 标识 位 + 序列号 时间戳 + node + pid + 序列号 秒级时间戳 + workId + 序列 Redis单线程自增 维护中 多个变种 是 否 - 雪花算法SnowFlake是Twitter开源的分布式ID生成算法，生成的一个64bit的long类型数值，组成部分使用了时间戳，保证了粗略自增。 优缺点优点 高性能高可用：完全在内存中生成，不依赖数据库。 高吞吐：每 ...

高可用三大核心原理CAP 分布式数据存储系统不可能同时满足一致性、可用性和分区容忍性。 一致性 Consistency 可用性 Availability 分区容忍性 Partion Tolerance BASE 核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用 Basically Available 软状态 Soft State 最终一致性 Eventually Consistency FLP 异步通信场景中，即使只允许一个节点失败，也没有任何确定性算法能够保证非失败进程达到一致性。 Safety Fault Tolerance Liveness FEMA具体含义 Failure：假设系统某些组件或者模块出现故障。 Mode： 故障发生的方式、可能性。 Effect ：故障的影响。 Analysis：分析系统的可能反应，以及如何改进。 评估维度 大纲 业务及灾备架构常用架构 同城双中心。 跨域紧邻双中心。 跨域远端双中心。 跨国数据中心。 异地多活架构模式业务定制型按照业务的优先级进 ...

微服务架构详解微服务VS SOA 微服务架构陷阱与挑战六大陷阱拆分颗粒度太细 服务关系复杂 团队效率下降 问题定位困难 系统性能下降 基础设施不完善 无法快速交付 服务管理混乱 四大挑战 分布式事务 全局幂等 接口兼容 接口循环调用 微服务基础设施选型 核心为服务运行层：服务注册、服务发现、服务路由 嵌入SDK式 反向代理式 网络代理式 微服务拆分技巧按业务拆分 业务边界划分 三个火枪手原则 【定义】 平均3个开发人员负责一个微服务。 【剖析】 为什么不是1个？ 因为没有备份，且一个人思维有局限。 为什么不是2个？ 因为异常情况下剩余1个，压力会很大； 2个人负责维护一个微服务，微服务复杂度偏低。 为什么不是4个或者5个？ 如果4个或4个以上，每个人不一定能掌握单个服务所有细节。 【技巧】 微服务数量 = 服务端开发人数 /3 ； 3 = 1 +2，1个有经验的(P7/P6+)，2个普通的(P5/P6)； 处于维护期的服务，维护人员为2人。 按质量拆分 按性能拆分 按业务重要程度拆分 按可用性拆分 按稳定性拆分 ...

多级缓存架构缓存设计 缓存内容 缓存时间 缓存系统 更新机制 多级缓存 客户端缓存 CDN缓存 WEB容器缓存 应用缓存 分布式缓存 分布式缓存架构设计分类 数据缓存：实时性要求高，读多写少 结果缓存：计算量大实时性要求不高 缓存问题 缓存穿透 缓存雪崩 缓存热点 负载均衡架构 DNS F5：100万~1000万 LVS：10万~100万 Nginx：5万~10万 服务路由(Gateway)：1000~5000 负载均衡技巧通用算法 轮训 随机 加权轮训 负载有限 性能优先 hash 服务器性能估算接口性能 线上业务服务器接口处理时间分布为 20~100ms； 平均大约为 50ms； 访问存储或者其它系统接口是主要的性能消耗点。 服务器性能线上单个服务器（32核）性能大约为 300~1000 TPS/QPS 服务器数量服务器数量 = (总 TPS+QPS) / 单个服务器性能 接口高可用 限流 排队 降级 熔断

数据库读写分离复杂度复制延迟 业务分级(常用) 读写绑定 二次读取 任务分解 代码封装 中间件封装 分库分表垂直拆分-提升单机处理性能按照业务将表进行分类，分布到不同的数据库上面。 水平拆分-提升集群处理性能按行切分。 复制架构 设计存储架构 分片架构与分区架构分片架构通过叠加服务器来提升写性能和存储性能。 分区架构通过冗余IDC来避免城市级别的灾难，并提供就近访问。 常见存储系统剖析存储系统学习方法 理解技术本质 明确部署架构 研究数据模型 模拟业务场景

架构师职责架构师是业务与技术之间的桥梁。 核心能力 判断-确定性思维 拆解-创造性思维 取舍-系统性思维 主要职责架构设计前期 澄清不确定性 识别复杂需求 与业务方交流 与利益干系人交流 业务架构图 核心场景流程 架构设计中期 选择、设计备选方案 架构小组讨论 方案评估 方案汇报 架构设计后期 细化架构 完善架构 写文档 架构宣讲 最终的架构文档 架构设计前期 架构设计中期 架构设计后期架构设计文档 业务背景 约束&限制 总体架构设计 详细架构设计 架构质量设计 架构演进规则 详细架构设计 架构规范 架构质量

可扩展架构设计鸡蛋篮子第一法则拆分法则 拆分颗粒度内部复杂度可以用参与的开发人数来衡量单个拆分对象的复杂度。三个火枪手原则。 外部复杂度可以用业务流程涉及对象数量来衡量外部复杂度。 高性能架构设计鸡蛋篮子第二法则叠加法则 高可用架构设计鸡蛋篮子第三法则冗余法则 分类 计算高可用 存储高可用 架构质量可测试性软件系统在测试环境下能否方便的支持测试各种场景的能力。 可维护性软件系统支持定位问题、修复问题的能力。 可观测性软件系统对外展现内部状态的能力 可观测性是可测试性、可维护性的基础。