彩虹马的博客

高可用三大核心原理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来避免城市级别的灾难，并提供就近访问。 常见存储系统剖析存储系统学习方法 理解技术本质 明确部署架构 研究数据模型 模拟业务场景

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

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

架构定义系统拆分 按逻辑拆分：模块 按物理拆分：组件 4R架构定义 Rank：顶层架构 Role：角色组成 Relation：角色关系 Rule：运作规则 架构分类按业务划分 业务架构图 按领域划分 客户端架构图 前端架构图 后端架构图 面向复杂度的架构分析本质架构设计是为了降低软件系统的复杂度。 架构设计三原则合适原则合适优于业界领先。 简单原则简单优于复杂。 演进原则演化优于一步到位。

目前开源的组件如Skywalking、Zipkin只能做到横向监控，没法针对某一时间段方法纵向监控和告警。基于这种痛点和对一些组件的了解，自己写了一套可满足自己业务需求的服务监控组件，结合了Grafana、Loki、Promtail、Elasticsearch、Kafka等，可实现服务接口级监控、监控告警、告警日志在线查看等特性。 基础组件 Grafana：Grafana 搭建 Loki：轻量级日志采集Loki搭建 Elasticsearch：介绍及使用文档 消息中间件：kafka 服务监控组件(未开源)：service-profiler 设计思想 Client收集服务调用信息后生成数据快照(Snapshot)，通过Kafka定时上报到Server端。Client通过Promtail采集错误日志上报到Loki服务器。 Server端统计聚合Client端上报的信息后落库ES。Loki服务端接收到Client端上报的日志后存储至磁盘并生成索引。 通过Grafana整合统计信息和错误日志，通过丰富的仪表盘实时展示相关指标与分析结果。 当相关指标超过自定义阈值时，通过通知平台告警到相关研发 ...