/tags/%E6%9E%B6%E6%9E%84.html Recent content in 架构 on IT 运维小秋 Hugo -- gohugo.io zh-cn chenwx716@139.com chenwx716@139.com Sun, 15 Mar 2026 12:53:32 +0800 /p/soft-base-standardization.html Sun, 15 Mar 2026 12:53:32 +0800 chenwx716@139.com /p/soft-base-standardization.html <h2 id="基本公式---三板斧">基本公式 - 三板斧</h2> <p>性能优化</p> <ol> <li>缓存</li> <li>异步</li> <li>并行</li> </ol> <p>一致性</p> <ol> <li>raft 多数节点投票</li> <li>双写: 附加一致性校验 or 版本控制</li> <li>分布式事务 / 最终一致性</li> </ol> <p>安全</p> <ol> <li>隔离</li> <li>升级</li> <li>权限</li> <li>审计</li> </ol> <p>高并发</p> <ol> <li>队列</li> <li>分流</li> <li>熔断 / 降级</li> </ol> <p>秒杀</p> <ol> <li>限流</li> <li>队列</li> <li>锁: 避免超售</li> </ol> <p>高可用</p> <ol> <li>多副本</li> <li>自动故障转移</li> <li>自愈</li> </ol> <h2 id="高可用架构设计---基础设施">高可用架构设计 - 基础设施</h2> <h3 id="cap-定理">CAP 定理</h3> <p>分布式环境中有一个不可能的三角 CAP 定理: 一致性, 可用性, 分区容错性;</p> <ul> <li>C(Consistency)一致性: 所有节点在同一时刻看到相同的数据;</li> <li>A(Availability)可用性: 每个请求都能收到(非错误)响应, 但不保证数据是最新的;</li> <li>P(Partition tolerance)分区容错性: 系统在网络分区(节点间消息丢失或延迟)时仍能继续运行;</li> </ul> <p>在分布式系统中, 当发生网络分区(P 必须满足)时, 无法同时保证 C 和 A, 只能在 C 和 A 之间做取舍;</p> <p>典型选择:</p> <ul> <li>CP 系统: 放弃 A, 保证强一致性(如 Zookeeper, Etcd, HBase); 分区时可能拒绝服务;</li> <li>AP 系统: 放弃 C, 保证最终一致性(如 Cassandra, CouchDB, Eureka); 分区时允许读到旧数据;</li> </ul> <p>大部分互联网业务(如商品库存, 用户信息)倾向于 AP + 最终一致性, 配合消息队列, 对账修复来弱化不一致窗口;<br /> 金融, 分布式锁等场景必须用 CP(如 Raft), 允许在分区时短暂不可用;</p> <h3 id="多副本">多副本</h3> <p>双中心</p> <ol> <li>同城主备</li> <li>同城双活</li> <li>异地备份</li> <li>异地双活</li> </ol> <p>两地三中心:</p> <ul> <li>同城双中心</li> <li>异地灾备中心</li> </ul> <p>云环境</p> <ul> <li>多 AZ</li> <li>混合云</li> <li>多 AZ + IDC 同城双活</li> </ul> <p>延迟同步:</p> <ul> <li>核心数据可以附加延迟备份, 避免类似 DDL 语句造成全量数据影响;</li> </ul> <p>相关有状态组件</p> <ul> <li>数据库</li> <li>缓存</li> <li>MQ</li> </ul> <p>多副本的核心问题</p> <ul> <li>一致性: 数据如何同步, 冲突如何解决</li> <li>流量如何选择入口</li> </ul> <h4 id="用户入口问题">用户入口问题</h4> <ol> <li>DNS/CDN <ul> <li>DNS 配置多个地址, 随机取一条访问</li> <li>智能 DNS, 就近路由, 故障转移</li> <li>CDN 回源时, 按策略进入指定区域</li> </ul> </li> <li>网关重定向: 智能 DNS 解析到 任意区域网关服务, 由网关服务根据条件将用户请求重定向到合适区域</li> <li>前置: 客户端内置多个路径, 根据算法选择路径</li> </ol> <h4 id="多中心数据一致性">多中心数据一致性</h4> <p>根据 CAP 和需求进行取舍;</p> <p>数据冲突</p> <ol> <li>同时只有 1 个数据中心可写, 将冲突问题改为同步问题</li> <li>细化的全局锁, 获得锁的中心才能写数据, 同步完成才解锁</li> <li>raft 协议, leader 节点可写;</li> <li>数据拆分, 设计成不同中心写的数据完全不会冲突; 例如 uid 单双数进入不同中心;</li> </ol> <p>数据同步</p> <ol> <li>异步复制; 网络分区时, 暂时使用旧数据, 后续进行数据补偿和修复;</li> <li>强同步, 只有对方机房同步成功, 本端才能成功;</li> </ol> <h3 id="灾备设计">灾备设计</h3> <p>传统的灾备只是单向同步数据, 日常没有流量; 导致在关键时刻没人有信心敢立即切流量过去;</p> <p>通常启用灾备中心并切换流量后, 都会伴随较多的人工操作和各种大小问题;</p> <p>所以正确的灾备中心设计, 不应该只做备, 而是日常就要有全业务的小比例流量, 才能保障在关键时刻能顶上;</p> <p>灾备设计重点</p> <ul> <li>入口流量怎么过来</li> <li>数据一致性; 包括数据库, 中间件, 缓存等所有有状态数据节点的数据;</li> </ul> <h3 id="自愈">自愈</h3> <p>发生故障时的自我恢复能力, 应用程序有内部自愈和外部自愈两类;</p> <p>内部自愈: 核心是防止自己死了;</p> <ol> <li>例如当调用数据库不通时, 不再接收新业务请求, 等通了再接收新连接, 避免自己死掉</li> <li>自我监控内存信息, 当无可用内存时, 主动释放资源</li> </ol> <p>外部自愈: 死了后能被拉起来</p> <ol> <li>脚本循环检测, 发现死了重新拉起来, 并且重写加入集群;</li> <li>更多逻辑判断, 处理故障后再拉起来</li> <li>在程序故障之前提前进行处理, 如通过监控发现程序可能出现内存泄漏, 主动重启或告警</li> <li>参考 k8s 的 operator 模式, 由一个管理控制器来运维;</li> <li>可回滚, 例如新版本刚发布的场景, 能自动回滚;</li> </ol> <h3 id="自动故障转移">自动故障转移</h3> <p>一般来说特指将发往故障节点的流量, 转发到正确节点上去;</p> <p>相关策略</p> <ul> <li>例如 keepalived 的故障检测和 VIP 漂移</li> <li>对于网关服务, 参考 nginx 应该对上游有故障检测和屏蔽机制;</li> <li>微服务体系种, 故障检测和屏蔽能力 转移到了注册中心上去;</li> </ul> <h2 id="高可用架构设计---应用服务">高可用架构设计 - 应用服务</h2> <p>核心是避免外部流量冲垮自己</p> <h3 id="服务降级">服务降级</h3> <p>在高压力或某一块业务故障后, 进行服务降级; 屏蔽非核心业务, 以保障核心基础服务的可用;</p> <p>相关策略</p> <ul> <li>降级开关集中化: 例如将开关放置在 nacos 配置内拉取, 或由运维平台内通过接口推送;</li> <li>开关前置化: 例如在网关层(nginx or gateway)配置降级策略, 直接响应某接口的请求, 或转移流量;</li> <li>次要功能可由同步改为延迟异步策略</li> <li>降低一致性需求, 比如点赞数, 可以降级为暂时只使用本地缓存, 不读数据库或 redis;</li> </ul> <h3 id="限流">限流</h3> <ol> <li>应对恶意流量</li> <li>应对突增的超出业务处理能力的流量</li> </ol> <p>相关策略</p> <ul> <li>网关层就进行限流拦截</li> <li>恶意请求: 使用 Nginx Deny 策略或者 iptables 或 waf 联动</li> <li>对于能穿透到数据库的核心请求做 limit 处理</li> </ul> /p/gateway.html Tue, 11 Jul 2023 12:53:32 +0800 chenwx716@139.com /p/gateway.html <h2 id="基础概念">基础概念</h2> <p>一个物理或逻辑区域的入口或出口</p> <h2 id="网关分类">网关分类</h2> <ol> <li>网络层网关: 重点是网络数据包转发和访问控制</li> <li>API 网关: 属于业务网关, 主要附带身份认证、流控、安全等业务功能</li> <li>数据网关; 缓存, 数据库, 存储, 数据仓库</li> <li>安全网关: 隔离，鉴权</li> <li>管理网关</li> <li>边界网关: 逻辑概念, 区分不同区域</li> </ol> <hr /> <h2 id="api-网关">API 网关</h2> <p>将统一业务入口, 流控, 负载均衡, 鉴权, 安全等功能进行前置<br /> 黑白名单, 协议适配(tcp/udp/http), 容错可用能力</p> <h3 id="主要用途">主要用途</h3> <ol> <li>隔离: 作为企业系统边界, 隔离外网系统与内网系统, 隐藏内部细节</li> <li>解耦: 使得各业务系统之间 或 微服务系统 之间能够独立, 自由, 高效, 灵活地调整;</li> </ol> <h3 id="常用方式">常用方式</h3> <ol> <li>nginx+lua</li> <li>traefix</li> <li>Spring Cloud Gateway</li> <li>业务自建</li> </ol> <h3 id="通用api网关设计要点">通用api网关设计要点</h3> <ol> <li>高性能</li> <li>安全性: 身份认证、权限认证</li> <li>高可用: 无状态设计原则</li> <li>可扩展: 支持插件, 脚本 等扩展功能</li> <li>运维友好</li> <li>隔离性：某个类型的后端服务异常时不影响其它类型服务</li> <li>动态变更: 负载规则变更时，不影响其它服务</li> </ol> <h2 id="api-网关设计要点">API 网关设计要点</h2> <ol> <li> <p>API标准化: 无标准不平台</p> </li> <li> <p>支持 API接口测试: 即可以方便地对接口进行测试, 或者方便区分或隔离测试流量和生产流量</p> </li> <li> <p>全生命周期管理<br /> 覆盖 API 的定义、测试、发布的整个生命周期管理，<br /> 便捷的日常管理、版本管理，支持热升级和快速回滚</p> </li> <li> <p>协议主流化<br /> http, https, xml, json, grpc<br /> 提供 java php python 等SDK</p> </li> </ol> <h1 id="业务-api-网关设计">业务 API 网关设计</h1> <h2 id="接口命名">接口命名</h2> <ol> <li>风格统一 (都为英文小写)</li> <li>模式固定 (xx.xx.xx.xx)</li> <li>简洁明了</li> <li>有扩展性</li> <li>分类与分层</li> </ol> <p>举例：suning.custom.order.get</p> <p>格式：suning. 业务分类. 模块简称. 操作符</p> <h2 id="文档规范化">文档规范化</h2> <p>API文档组成<br /> 简介、接口描述、公共参数、请求参数、响应参数、请求示例<br /> 业务异常码、公共异常码、响应示例、FAQ、异常示例、API工具</p> <h2 id="异常码标准化">异常码标准化</h2> <p>统一风格，分类，唯一性，有利于监控、告警、问题排查<br /> 有条件的情况，除返回异常码外，还要有中文描述</p> <h2 id="api管理">API管理</h2> <p>可以开关、流量控制和限流<br /> 安全管理、<br /> 接口分流: 不同的分类对应不同的后端服务<br /> 服务降级: 进行快速错误</p> <h2 id="api监控">API监控</h2> <p>日志<br /> 接口统计<br /> 告警<br /> 存储监控数据</p> <hr />