以色列如何建国：从民族运动到托管终结
1948年5月14日下午，本古里安在特拉维夫宣布以色列建国，随后返回司令部讨论战争。他当天的日记记录了一个具体分歧：是否加强行动，夺取通向耶路撒冷的胡勒达—沙尔哈盖道路周围地区。参谋人员认为兵力不足、不清楚敌方计划，几乎一致反对。在宣布国家的那一天，政治领导人仍须解决补给线和指挥权限问题；他甚至写道，还没有习惯把原来的行政机构称作“政府”。国家名称在改变，支撑它的组织与已经展开的战争则有更长的历史。本古里安日记，1948年5月14日 以色列的建立，是民族运动、移民社会、帝国制度、国际决策与战争动员共同形成的结果。1947年末，巴勒斯坦已经陷入社区间战争；1948年5月英国托管结束、以色列宣布独立以及阿拉伯国家正规军介入，使战争进入新的阶段。本篇追溯这些条件怎样形成，止于这个转折。后篇将从1947年末重新展开战事，重建道路争夺、城市陷落、难民迁移与国家军队交战，延伸至1949年。联合国巴勒斯坦委员会，S/676 历史联系与现实居民 犹太人与这片土地的历史联系，有独立于现代民族叙事的材料。亚述王室铭文记录了公元前九至八世纪的以色列王国，并将它与南部犹大区别；前722年撒马利亚...
第一次中东战争：从道路袭击到多战线战争
1947年11月30日，两辆犹太客车先后遇袭。1948年5月，埃及、外约旦等国的正规军进入巴勒斯坦。两个日期相隔五个多月，其间的战争已改变当地社会：街区被隔开，班车变成武装护航车队，沿路村庄和高地成为攻击目标，地方武装的战斗被纳入更大的地域控制计划。以色列宣布建国时，海法、雅法、萨法德等城市的军事和人口格局已经发生重大改变。本篇是建国史系列的第二篇，从这些中间步骤写到1949年的停战；S01S08S19 下文的沿海、耶路撒冷走廊、中央地区、北部和南部，是便于读图的地域划分，并非一套自1947年底就固定存在的战区司令部。实际指挥单位包括地方守备机构、旅、临时行动指挥部，以及后来能够协调多个旅的战线指挥机构。例如纳赫雄是跨单位集中兵力的编组，哈梅茨联合数个地区旅，达尼、约阿夫又使用更大的兵力组合。地名第一次出现附常见异名；E编号可以在文末详细事件表中定位，S编号链接到来源。S14S55S30S35 两辆巴士，和一个不能承担全部解释的起点 常见的“一辆巴士遇袭”省略了第二次袭击。莫里斯《1948》第76页记载：11月30日约8时20分，第一辆车在法贾（Fajja）、卡法尔西尔金...
俄乌战争的根源：国家形成、领土争议与欧洲安全秩序
俄乌战争不是古代共同起源或一次苏联划界的自然结果。乌克兰国家形成与俄罗斯对周边秩序的要求，在地区利益、政权危机和北约关系中发生冲突；2014年中央权力断裂、俄罗斯军事介入和地方武装动员，使争议转成战争。明斯克试图把停火同乌克兰内部政治安排结合起来，却未解决武装控制与政治重整的冲突；2022年俄罗斯进一步选择全面战争。历史联系和安全忧虑能够解释部分动机，不能单独证明这些行动不可避免。本文资料截止于2026年10月21日，分别考察2014—2021年的冲突与2022年后的全面战争。 国家如何形成 科切加罗夫指出，古罗斯宗教文化传统跨越后来的政治边界延续，但波兰—立陶宛制度及地方自治又使乌克兰地区积累了不同经验。哥萨克精英可以接受共同宗教传统，同时维护地方权利。共同继承与后来民族分化并不矛盾，也不能据共同来源推出永久统一。科切加罗夫的解释 普京2021年的文章也承认乌克兰人是古罗斯继承者，承认乌克兰名称、乌语文学与哥萨克自治。他否定的是独立于俄罗斯人的乌克兰民族观念的历史基础，并把现代乌克兰及其疆域归于苏联安排。但他又承认一个民族的一部分可以形成独立民族，个人可以选择民族身份，亲...
新旧功能的柔性切换：灰度路由、影子比较与读写迁移
新实现已经上线，旧实现仍在服务。只改一个开关，就能让少量请求试用新实现；同一份输入还可以交给另一侧执行，比较结果，却不改变用户看到的响应。试用扩大后，主次可以反过来：新实现负责响应，旧实现继续提供比较样本，并在符合条件时兜底。 这类能力发生在应用内部。需要切换的可能是一套规则、一份配置的读取方式、一个查询接口、一段任务流程，或者整个数据模型。蓝绿、金丝雀和滚动发布可以帮助放量，但发布单元的流量比例没有回答：谁有权返回结果，谁可以写数据，哪种失败允许回退，以及回退的数据是否还可信。 以目录查询为例，旧存储 O 正在服务，新存储 N 逐步接入。迁移先让 N 观察真实查询，再让已完成数据准备的人群使用新读，之后才转移写入权威。停止回退和停止维护旧数据又是两次不同的决定。模板计算和任务处理也可以沿这条路径分析，只是比较合同和副作用边界各不相同。 从一次查询看清四种角色 设旧实现为 O，新实现为 N。请求被路由到 N，不代表最终一定由 N 返回：N 可能失败，系统按照策略使用 O 的结果。与此同时，O 也可能只是被调用来比较，完全没有接管响应的资格。 因此至少需要分别表达主执行、影子执行、...
业务扩展框架03：组合实验与远程绑定
运行一个最小业务组合实验 在博客源码仓库根目录运行： 1bash examples/business-extension/run.sh 示例仅依赖 JDK 8 或更新 JDK，不下载第三方依赖。脚本在临时目录编译，运行后清理编译产物。完整代码位于仓库的 examples/business-extension/ExtensionLab.java，实验说明位于同目录 README.md。 这是自建教学模型，不是 TMF、Lattice 或美团 BPF 的源码。它验证 SPI 发现、注解注册、业务配置激活和本地扩展调用。库存、资格与销售时间仅记录 mock 事件，没有连接真实系统。 在 Java 8 下执行，三个业务输出如下： 12345retail v1 payable=10000 [validate.input, price.list, inventory.audit, inventory.stock(mock)]presale v1 payable=9000 [validate.input, validate.presale-window(mock), price.presale...
业务扩展框架02：注解模型与表驱动
注解把组件看成什么 业务框架读取一个类上的注解时，通常是在构建组件描述信息：这个实现的稳定标识是什么、实现哪个扩展点、归属哪种业务或产品、遵守什么调用契约。Java 对象负责执行代码，描述信息负责让框架管理和选择这个对象。 “被注解的组件”可能对应不同对象： 注解所在位置 可能建模的对象 不能仅凭注解得出的结论 领域接口或抽象类 能力定义、服务契约、流程节点类型 已经存在可执行实例 扩展接口的方法 一个变化点及其输入输出、归约语义 有多少业务实现会被激活 具体实现类 某个能力实现及其归属 本次请求一定执行它 配置加载器、代理工厂 框架本身的可替换基础设施 它属于某个商业产品 服务引用字段 远程服务引用的声明 远端实例已经发现且可用 因此同样叫 @Extension，在不同框架里可能标记扩展点定义，也可能标记扩展实现。理解注解必须同时看 @Target、处理器和注册过程；仅凭名字无法确定语义。 图 1：教学对照：注解所在位置与处理器共同决定被登记的对象；这些分支不代表同一个框架的统一 API。 flowchart TB accTitle: 注...
业务扩展框架01：TMF与美团平台化实践解决什么问题
多业务共用平台以后，复用为什么会变难 一个订单平台同时支持普通零售、预售和团购。三者都有商品、价格、订单与库存，但预售需要校验销售时间和预售额度，团购需要校验成团条件，普通零售通常直接处理现货。把共同步骤提取出来并不难，难的是下一次改预售规则时，怎样确定团购完全不受影响。 最直接的写法是在每个步骤判断业务类型。业务增多后，条件会散落到价格、库存、退款、消息消费等位置。新增业务的代价不只是多写几个分支，还包括找到所有分支、理解组合顺序、协调多个团队发布，以及证明旧业务没有改变。 将分支改成若干 Strategy 类，只解决了代码摆放。若每个策略自行判断是否适用、彼此没有清晰归属，两个策略可能同时生效，运行时仍然需要回答：这次请求应执行谁，为什么，冲突时怎么办。 TMF 一类业务扩展框架要把这些关系显式化：平台定义稳定的业务契约和变化点，业务提供定制实现，配置表达安装关系与冲突决策，运行时按明确的业务上下文执行。它需要的前提是已经存在值得复用的业务模型；框架不会从一堆任意 Java 方法中自动发现一个交易平台。 本系列分为三篇： 本篇：TMF 与美团公开实践的目标、领域模型和架构边...
Codex 架构全景：本地运行、云端长任务与多层 Loop
Codex 的架构需要同时回答两个问题：一次编码请求怎样完成，以及请求结束以后，什么状态还能保留、谁会再次启动工作。前一个问题涉及模型、工具和 Harness；后一个问题涉及会话、目标、执行环境、调度和身份。 “Codex 在本地运行”通常表示工作区和工具在本机，模型推理仍可以发生在 OpenAI 的服务器。“Desktop 连 Remote”通常表示客户端通过 SSH 控制远端 App Server；“Cloud 长期运行”则包含托管执行环境及其生命周期。这些模式可以共享执行框架，却承担着不同的运行责任。 本文以 2026 年 10 月 15 日读取的官方产品文档和 Codex rust-v0.162.1 源码为基线。源码固定在 092d3acd6bec3e3a14bdc7e7a2810ab628ab759d，提交日期为 2026 年 10 月 9 日；本地 codex --version 为 codex-cli 0.162.1。文中的拓扑是根据公开接口整理的解释模型，涉及托管 Cloud 的部分只描述公开契约。云端内部队列、数据库拓扑、VM checkpoint 算法和模型权...
Flink 生产部署拓扑与组件职责
Flink 作业能从 Kafka 读到数据，并不意味着它已经具备生产恢复能力。任务运行在什么进程、状态存在哪里、谁负责申请资源，以及故障后从哪个位置继续处理，需要在部署时分别确定。 本文以 Apache Flink 2.3 文档为基线，讨论有状态流作业的生产拓扑。图中的连接区分任务调度、记录传输与状态持久化；对象存储、Kafka 和 Kubernetes 都是外部系统，不属于 TaskManager 内部组件。批处理的调度与 shuffle 策略另有配置，不能把下面的持续流水线直接套用到所有有界作业。 集群内外的职责 JobManager 负责协调执行，TaskManager 执行 source、转换和 sink。业务记录通常在 TaskManager 及外部系统之间流动，不需要经过 JobManager 转发。客户端负责提交；作业以 detached 方式启动后，客户端退出并不等于作业结束。 图 1：Flink 控制连接、业务数据与快照存储的边界 flowchart TB C["客户端"] -.->|"提交"| JM["...
Kafka 生产部署拓扑与组件职责
Kafka 的部署单元包括控制器、保存分区副本的 Broker，以及运行生产者、消费者和数据管道的应用进程。三类进程承担不同负载，扩容和故障恢复也有不同边界。只画几个 Broker，容易漏掉元数据多数派、客户端网络地址和内部主题这些影响可用性的条件。 本文以 Apache Kafka 4.3 文档中的 KRaft 部署为参照。Kafka 4.0 起不再支持 ZooKeeper 模式；旧集群迁移需要经过兼容的 3.x 版本。图中的三控制器、三 Broker 是解释故障域的示例，不是所有业务的容量配置。 控制面与数据面 控制器维护 Broker 注册、主题和分区元数据，决定分区领导者等集群状态。Broker 保存业务日志副本并响应生产和消费请求。业务消息无需经过控制器转发，控制器的副本数也不决定业务主题的副本数。 图 1：KRaft 控制面与业务数据面的部署边界 flowchart TB subgraph CP[控制面：独立控制器进程] C1[Controller 1] --- C2[Controller 2] C2 --- C3[Controller 3] ...