自主服务

了解lenso.service.v2边界、服务拥有的运行时、持久工作流、身份和无集群开发。

自治服务是业务边界拥有其运行时的点， 数据、发布和操作证据。这不是默认起点 对于每个模块。

Lenso 保持了三种不同的形态：

服务合约

lenso.service.v2 描述一项逻辑服务，与有多少个服务无关 处理它运行的进程。服务可以声明：

• API、Worker、迁移和扩展工作负载；
• 它拥有的模块；
• 一个或多个逻辑服务存储；
• 租赁方式及经营区域；
• 配置、可靠性、API、事件和依赖契约。

当其工作负载计数或部署拓扑时，服务身份保持稳定 变化。 Kubernetes 部署是适配器细节，而不是业务 身份。

服务拥有的运行时

lenso-autonomous-service 运行时验证之前的完整定义 启动，将服务和模块迁移应用到注入的存储，运行 服务拥有的队列，并中继其事务Outbox。它无法启动 通过主机或重新解释Provider v1 Manifest。

边界有意严格：

• 业务路由和迁移仍然来自自有模块；
• 工作流状态、计时器、尝试、Inbox和Outbox保留在服务存储中；
• 当系统平面或运行时运行状况和本地证据仍然可用 控制台不可用；
• 部署编排从不参与业务请求流量。

Durable Workflow

模块可以声明版本化的工作流定义。每个实例都固定准确的 定义工件和摘要，因此升级不能默默地重新解释工作 已经在运行了。

转换保留Story、因果关系、租户、参与者、截止日期和幂等性 语境。重试计时器很耐用。子工作流保留显式的父链接。 已完成的效果可以声明补偿请求和完成事件；这 工作流保持 compensating，直到远程反转得到确认。

这不是分布式事务。每个服务都有自己的业务 本地效果和持久消息状态。

身份和证据

生产调用者以稳定的 service:<service-id> 主体身份进行身份验证。 第一个受支持的生产配置文件使用 SPIFFE X.509-SVID mTLS 和 受众限制 JWT-SVID。本地系统沙箱使用确定性 仅用于开发的身份Provider。

每个服务都会公开一个经过身份验证的仅附加Story片段提要。饲料 使用精确的受众、租户授权、签名的不透明游标和稳定的 段修订。集合是只读的：它不能确认、推进或 解锁工作流执行。

Runtime Console在Story聚合器收集后显示联合Story 那些部分。延迟或不可用的控制台不会更改本地服务 执行。

无集群开发

使用系统沙箱进行最短的多服务证明：

lenso system dev \
  --system-file lenso.system.json \
  --sandbox-file lenso.sandbox.json

在不分配资源的情况下验证确切的启动计划：

lenso system dev \
  --system-file lenso.system.json \
  --sandbox-file lenso.sandbox.json \
  --dry-run --json

运行一个已声明的故障场景并让沙箱仅清理 其拥有的资源：

lenso system dev \
  --system-file lenso.system.json \
  --sandbox-file lenso.sandbox.json \
  --scenario api-crash --json

Kubernetes 是一个可选的交付适配器。本地不需要 服务开发或服务合约本身。

何时移动边界

在边界至少有一个具体理由存在后选择自治：

• 独立所有权或发布节奏；
• 隔离数据权威；
• 明确的信任边界；
• 独立运行的可靠性或扩展性；
• 无法合理地驻留在 Rust 主机中的运行时。

如果都不适用，请保持功能链接。显式接口采取后续行动 机械化，无需提前支付运营成本。

继续系统的服务系统平面] 组合或单区域 GA 为支持的 生产信封。