一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。
这大部分场景下还要考虑幂等的问题。
这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2025-09-13
分布式事务
问题定义 对经典的电商场景而言：下单是个插入操作，扣减金额和库存是个更新操作，操作的模型不同，如果进行分布式的服务拆分，则可能无法在一个本地事务里操作几个模型，涉及跨库事务。 CAP 定义 根据 Eric Brewer 提出的 CAP 理论： Consistency：All Nodes see the same data at the same time。所有节点看到同一份最新数据。Brewer 论文里的 C 严格定义是 linearizability，工程语境下常被泛化为 strong consistency。 Availability：Reads and writes always succeed。非故障节点必须在合理时间内响应。 Partition tolerance：System continues to operate despite arbitrary message loss or failure of part of the system。网络分区时系统继续运行。在云原生环境（K8s 跨可用区、跨 region）这是默认前提，不是可选项。 由此诞生三种设计约束...
2021-03-01
HTAP 问题
问题定义 AP 的出现 在互联网浪潮出现之前，企业的数据量普遍不大，单机数据库就足以保存核心业务数据。那时候的存储不需要复杂架构，所有线上请求（OLTP，Online Transaction Processing）和后台分析（OLAP，Online Analytical Processing）都跑在同一个数据库实例上。后来业务越来越复杂，数据量越来越大，问题随之而来：单机数据库支持线上 TP 请求已经非常吃力，再跑较重的 AP 分析任务无以为继。AP 由此从 TP 系统分离，某种程度上 AP 是 TP 的一个分支。 这等于在存储层做读写分离的架构设计；另一种思路是在应用层做读写分离。 AP 的玩法 在这种背景下，以 Hadoop 为代表的大数据技术开始蓬勃发展，它用大量相对廉价的 x86 机器构建了一个数据分析平台，用并行能力破解大数据集的计算问题。 AP 系统的典型技术栈演进： 阶段 代表技术 特点 第一代 Hadoop MapReduce + Hive 批处理，延迟高（分钟到小时级） 第二代 Spark + Spark SQL 内存计算，延迟降到秒级 第...
2022-01-12
《架构师修炼之道》
刻戒于碑，铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起，就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者，也就是 stakeholder。 主动撰写设计决策，承担设计职责。 软件之所以叫软件，是因为它灵活而易于变动。架构是软件里硬的部分，为变动提供了章法，也制造了约束-否则我们不用经常“对架构产生冲击”，而需要打破架构。 设计原则： 以人为本（能落地能产生价值的架构才是真的好架构） 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策，要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中，导致项目无法受控。 忽视前人的设计，是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式： 理解：换位思考 探索：尝试各种结构组合，找到最能提升目标质量属性的那种组合。-大多数情况下，是我们手头最简单最现成的解决方案。 展示：用图、表、模型、原型来展示，探讨。原型应该尽量具有交互性，可以直接和客户评审。 评估：评估到底我们要做什么东西...
2021-02-10
《恰如其分的软件架构》
前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法，架构方法是一种思维模型（mind set），这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐，列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因，还是这本书的内容以谈概念为主，虽然书中举的例子非常生动，仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件（比如很多书籍都会反复出现在“xxx 播放器”）的例子。这些软件架构非常经典，可以只用一些小的组件、场景，就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候，仿佛重新回到了抄书和念书的大学课堂，对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新，是一本书经典化的特征。而能够阅读非入门级的纯理论书籍，则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦，证明我还是对于形式化的符号（symbol）、记法（notion）还不是很熟悉，而且对于书中运用的问题解...
2020-09-02
异地多活与单元化
核心结论 单元化不是“多建几套机房”，也不是把应用复制到多个城市就结束。它解决的是一个更具体的问题：当业务规模大到单机房、单库、单服务集群都无法继续水平扩展时，如何让一部分用户或一部分业务身份的请求，从接入层、服务层、中间件到数据层，都尽量闭环在同一个逻辑单元里。 一个成熟的单元化系统，至少要把四个域对齐： 域 需要对齐的内容 失配后的结果 流量域 请求能按用户、商家、地域、订单等分片标识进入指定单元 入口正确，内部调用仍然乱跳 数据域 核心数据按同一分片规则落到对应单元 服务闭环，数据库跨城访问 故障域 单元故障只影响该单元承载的流量和数据 一个局部故障拖垮全站 治理域 路由规则、注册中心、发布、监控、演练都理解单元 规则靠人工同步，切换时失控 这个定义能把几个常被混用的词分开： 概念 隔离对象 是否要求存储隔离 常见用途 AZ（Availability Zone） 基础设施故障域 不要求 机房级容灾、容量冗余 Set / Cell 业务流量和业务数据 通常要求 容量扩展、故障隔离、异地多活 RZone / GZone / ...
2021-08-18
如何写系统规划
列出背景 列出现状。 列出当前组织的 okr，分析机会和挑战。 将当前系统的视图勾勒出来，要能理解信息流和资金流。 列出痛点，分析需要实现的技术能力。 对标 对标其他团队的成功经验。 分析背景和成功原理。 要有架构图。 解决方案 要有目标架构图 有问题拆解：什么服务，是什么问题域的解空间，拥有什么能力，建设路径分几期，需要多少人力成本。 全团队分工： 本团队产品怎么分工 本团队后端怎么分工 本团队前端怎么分工 本团队数据怎么分工 本团队算法怎么分工 其他团队怎么分工 里程碑 按照绝对时间拆解 按照任务事件拆解 如何画简单的架构图 水平分层极其重要，每一层左边在层次里会有层次说明。 要用圆角都用圆角，要用直角都用直角。 重点：要填满整个空间： 深底色配白字。 模块之间的应该要直，不然应该优美、松弛。 图像应该紧凑，不留缝隙。 越处于背景之中，颜色越浅。 有时候，利用立体图形是好的。 要有阴影。 要玻璃化。
