NatusAI
单体与微服务之争往往从部署架构图开始：一个框，还是很多个？但更有价值的问题出现得更早：哪些复杂性应由您的团队承担，哪些应由平台来管理？
小团队需要清晰的模型，以及从想法到可用应用的捷径。成长中的组织还需要容量、韧性，以及让各团队独立工作的空间。这些需求彼此相关，但并不相同。
Cygnus探索的是另一种平衡：把应用逻辑和数据保持在同一个逻辑模型中，再逐步演进该模型的部署位置和执行方式。目标是减少开发者围绕彼此独立的数据库、服务和AI工具反复构建的集成工作。
01 / 架构选择
单体与微服务解决的是不同的问题
单体将应用打包为一个可部署单元。它可以是模块化的、经过严格测试的，也可以部署在负载均衡器之后进行复制。它的吸引力很务实：本地调用、调试直接、组件更少。其局限往往出现在共享发布、归属边界或资源需求不均衡等方面。
微服务将应用拆分为可独立部署的服务。当不同领域和团队需要各自的发布周期、扩缩容策略或运维边界时，微服务很有用。但这种独立性也带来工作量：网络调用、带版本的契约、可观测性、故障处理，以及往往还需要在彼此独立的数据存储之间保持一致性。
两者都不会自动更快或更具可扩展性。设计良好的单体可以承载大规模工作负载；拆分不当的微服务系统则可能把瓶颈分散开来，反而更难发现。
单体
单一部署。内部边界取决于代码设计。
微服务
服务与归属相互独立，由网络契约连接各个部分。
Cygnus设计
统一的开发模型。分布式部署是V1之后的方向。
这一区别很重要，因为部署的分布方式与业务的模块化是两个独立的决策。没有独立服务也可以有模块；使用多台服务器也不必拆散应用的逻辑模型。
02 / 一个逻辑模型
让数据库与后端更紧密地结合
Cygnus是NatusAI规划中的语言、数据库与后端基础。其设计将类型化应用逻辑、持久化数据和对外暴露的函数整合到一个统一连贯的环境中。开发者不必在每个边界维护单独的映射，而是直接操作互联的对象以及作用于这些对象的函数。
这对数字孪生或运营类应用尤为重要。一艘船、一栋建筑或一项工业资产都有身份、关系、位置、测量数据、文档和历史。把每个视角拆分到互不相关的系统中，就意味着要重建业务中本已存在的关联。
统一模型旨在保留这些关联。它还让运行时掌握更多关于数据、查询和执行的信息，这些信息可以为未来的部署和协调决策提供支持。
应用只用一个模型，
运行位置却有更多选择
这是一项设计原则，并不承诺每种工作负载都能透明地扩展。分区键、查询模式、事务边界和延迟，仍然会影响应用应当如何构建。
03 / 四种扩展方式
把请求扩展与数据扩展视为不同的需求
“我们需要扩展”可能意味着更多并发请求、更大的数据集、更高的可用性，或三者兼而有之。复制和分片解决的是这个问题的不同方面。下面的示意展示了Cygnus的分布式设计方向；它并非正在运行的集群，也不是已发布的部署功能。
01 · 单节点
从一个统一连贯的应用起步
应用逻辑和完整数据集共同运行在一台服务器上。这正是规划中的Cygnus V1部署形态的范围。
运维模式简单直接。容量和可用性取决于一台服务器及其恢复流程。
02 · 副本
在多个节点间复制模型
在分布式设计方向中，各节点承载相同的应用代码和一份完整的数据副本。复制可以提供冗余和额外的请求处理能力，但取决于一致性和写入路由模型。
各副本必须协调更新。副本增多并不会自动成倍提升写入吞吐量。
03 · 分片
拆分数据，保留模型
应用代码保持共享，而每个节点各自负责一部分数据分区。可根据工作负载，按地理区域、时间范围或键范围进行分布。
路由和跨分区查询需要明确的规则。数据或访问模式不均衡可能产生热点。
04 · 两者结合
为每个分区建立副本
将跨分片的容量与每个分片内的冗余结合起来。预期的开发体验仍是一个逻辑数据库与后端，而由运行时处理更复杂的物理拓扑。
副本放置、故障切换、再平衡和分布式事务都需要经过认定。这是V1之后的设计方向。
完整的数据副本 一个数据分区 · 仅为示意：并非正在运行的集群或已发布的部署功能。
从单节点起步
规划中的V1部署形态从一台服务器起步。应用代码和数据共同运行，让首次部署易于上手。备份、恢复、权限和资源限制仍是负责任运维的组成部分。
通过复制实现冗余并提升请求处理能力
在未来的分布式模型中，多个节点可以承载相同的代码和一份完整的数据集副本。这样可以有更多位置处理合适的请求，并让系统能够容忍部分节点故障。效果取决于路由、复制延迟、一致性保证，以及哪些操作可以在哪些副本上执行。
通过分片扩展数据容量
当数据集超出一台服务器的容量时，增加完整副本并不能解决存储限制。分片将数据分布到多个节点上。工作负载可以按地理区域、时间范围或键范围分区。跨越这些分区的查询需要路由，有时还需要分布式执行。
一个简单的容量示例：30 TB的逻辑数据至少需要八台各有4 TB容量的服务器，这还未计入副本、索引、运维余量或其他开销。这只是算术，并非Cygnus的容量实测结果。
两者结合
每个分片都可以拥有自己的副本。分片提供总体数据容量；副本增加冗余和处理请求的机会。人们设想数据库分布在一组服务器上时，通常指的就是这种组合拓扑。
随需求弹性伸缩
更长远的方向是围绕工作负载策略将这些选择自动化：需求增长时增加容量，让执行随所需数据迁移，需求下降时释放容量。目标是在部署位置变化时保持应用的逻辑模型不变。
缩容之前必须先排空工作，并安全地迁移或保留所需的数据副本。调度、再平衡、一致性和恢复都需要明确的规则并经过认定。自动扩容和缩容是未来集群的设计目标，不在规划中的单服务器V1范围内。
04 / 运行时的职责
把协调工作交给平台
按照预期的Cygnus体验，部署不断演进时，仍然只有一套应用代码库和一个逻辑数据库。由运行时管理的分布式机制将承担部署位置、路由、复制以及协调各参与节点的具体工作。
这些机制并不会消失。网络会带来延迟和分区。更新需要一致性规则。跨分片的事务需要明确定义的协议。恢复时必须知道哪些已经提交，再平衡时必须避免数据在迁移过程中失去归属。
机会在于把这些职责在平台中一次性实现，并配备明确的契约和运维工具，而不是让每个应用各自拼装一套。应用仍然需要与其工作负载相匹配的边界。
05 / 跨越时间的数据
互联模型需要记忆
许多业务问题都包含时间维度，即便没有人明确说出来。事故发生前这项资产在哪里？当时由哪家机构管理？系统在给出那条建议时掌握了哪些信息？
Cygnus的设计将图关系、地理空间数据、向量、三元组、时间序列和全文检索连接在同一个逻辑基础之中。它们是探索同一对象的不同方式，而不是对该对象的不同定义。
- 图与三元组
与什么相连，又是如何相连？
- 地理空间
它在某一时刻位于何处？
- 时间序列
它的读数如何演变？
- 全文与向量
哪些记录相匹配或含义相近？
概念模型。历史回答还需要保留来源版本，以及检索、模型和提示词的来源记录。
数据要有历史，AI要有来源
时态数据可以描述一项资产、其读数或其关系如何变化。而一个关于历史的AI回答需要更多：它还取决于生成该回答时所用的源文档、向量嵌入、检索配置、模型版本和提示词。
保留数据历史并不会自动保留每一个向量索引，也无法复现过去的模型响应。有用的设计会有意识地把这些版本关联起来并记录其来源，让回答能够追溯到支撑它的证据和上下文。
为应用和工具提供同一个基础
规划中的原生MCP和对话能力，提供了对外暴露获准函数和查询互联知识的方式。工具或对话界面应当与应用使用同一个模型和同一套访问策略。这样，历史查询就可以针对选定的时间提问，同时说明该回答有哪些证据和AI配置可用。
正是在这里，统一后端不再只是“部署更简单”：它可以为运营数据、业务历史和AI辅助工作提供共享的基础。
06 / 划定边界
让架构与工作保持一致
当独立团队、不同的安全边界或不同的运维要求确有需要时，微服务依然有用。当共享部署能让团队保持高效时，模块化单体依然有用。Cygnus的方向则提供了另一种选择：统一的应用与数据模型，由运行时在更深层管理分布式机制。
正确的选择始于工作负载。哪些请求占主导？更新需要多快可见？哪些数据应当放在一起？网络故障时会发生什么？哪些职责需要独立归属？
我们的目标是让开发者把更多时间花在这些有意义的决策上，减少重建工具之间连接的时间。从一个统一连贯的模型起步，保持业务关系完整；当工作负载和平台都准备就绪时，再扩展物理部署。
延伸阅读
- Martin Fowler: Monolith First（外部网站） ——随着对领域边界理解的加深，架构如何演进。
- PostgreSQL: Warm Standby（外部网站） ——复制、备库运行以及同步与异步更新之间权衡取舍的一个示例。
- Microsoft Azure Architecture Center: 分片模式（外部网站） ——分区键、路由以及数据分布的注意事项。
- Cygnus V1范围与后续部署形态——这一设计观点背后的公开范围与状态。