自动供给：定义即部署的 Ontology 基础设施
传统方式：定义一个新的业务对象需要多少人工操作？
Coomia发布于 2025年8月16日18 分钟阅读
分享本文Twitter / X
自动供给：定义即部署的 Ontology 基础设施
“系列：S4 本体建模 · 第 12 篇 | 难度：中级 | 阅读时间：18 分钟
#TL;DR
- 自动供给（Auto-Provisioning）让 ObjectType 的注册自动触发全栈基础设施创建——存储表、索引、API 端点、权限配置、SDK 类型、监控仪表板，全部自动完成，开发者只需定义 Schema。
- 供给管道（Provisioning Pipeline）分 6 层——存储层、索引层、API 层、权限层、SDK 层、监控层，每层独立供给且支持回滚，一个层失败不影响其他层。
- 变更感知供给——不只是首次创建，Schema 变更时也自动执行增量供给（新增列、更新索引、刷新 API），实现 Ontology 的全生命周期基础设施自动化。
#1. 为什么需要自动供给
#1.1 传统方式的人工流程
Code
传统方式：定义一个新的业务对象需要多少人工操作？
Step 1: 设计表结构（DBA）
→ 编写 DDL → 审批 → 执行 → 1~3 天
Step 2: 创建 ORM 模型（后端开发）
→ 编写 Entity 类 → 编写 Repository → 1 天
Step 3: 创建 API 端点（后端开发）
→ 编写 Controller → 编写 DTO → 编写文档 → 2 天
Step 4: 配置权限（安全团队）
→ 创建角色 → 分配权限 → 配置 RBAC → 1 天
Step 5: 更新 SDK（SDK 团队）
→ 生成类型定义 → 发布新版本 → 1 天
Step 6: 配置监控（运维团队）
→ 创建 Dashboard → 配置告警 → 1 天
总耗时：7~9 天，涉及 5 个团队
问题：
├── 每次新增 ObjectType 都要重复这个流程
├── 各团队之间的协调成本高
├── 人工操作容易出错
├── 不同 ObjectType 的基础设施不一致
└── Schema 变更时更新更复杂（改了 Schema 忘了改 API）
#1.2 coomia-dip 的自动供给
Code
coomia-dip 方式：定义 ObjectType → 全部自动完成
开发者操作：
POST /api/v1/ontology/object-types
{
"objectTypeId": "ShippingOrder",
"properties": [...],
"relations": [...]
}
系统自动执行（< 30 秒）：
✅ 创建存储表 + 分区策略
✅ 创建索引（主键、外键、常用查询）
✅ 注册 CRUD API 端点
✅ 生成 API 文档（OpenAPI）
✅ 配置默认权限
✅ 生成 Python SDK 类型
✅ 生成 TypeScript SDK 类型
✅ 创建 Grafana Dashboard
✅ 配置基础告警规则
✅ 注册到服务发现
从 7~9 天变成 30 秒
从 5 个团队变成 0 个团队（纯自动化）
#2. 供给管道架构
#2.1 六层供给管道
Code
供给管道（Provisioning Pipeline）：
┌─────────────────────────────────────────────────────┐
│ Layer 1: Storage Provisioning │
│ ├── 创建存储表 │
│ ├── 配置分区策略 │
│ └── 设置数据保留策略 │
├─────────────────────────────────────────────────────┤
│ Layer 2: Index Provisioning │
│ ├── 主键索引 │
│ ├── 外键索引（关系属性） │
│ ├── 搜索索引（全文检索属性） │
│ └── 自定义索引（标记为 indexed 的属性） │
├─────────────────────────────────────────────────────┤
│ Layer 3: API Provisioning │
│ ├── CRUD 端点注册 │
│ ├── 搜索/过滤端点 │
│ ├── 批量操作端点 │
│ ├── OpenAPI 文档生成 │
│ └── gRPC Service 注册 │
├─────────────────────────────────────────────────────┤
│ Layer 4: Permission Provisioning │
│ ├── 默认角色创建 │
│ ├── CRUD 权限配置 │
│ ├── 属性级权限 │
│ └── 审计日志配置 │
├─────────────────────────────────────────────────────┤
│ Layer 5: SDK Provisioning │
│ ├── Python SDK 类型生成 │
│ ├── TypeScript SDK 类型生成 │
│ ├── SDK 文档生成 │
│ └── 版本号递增 │
├─────────────────────────────────────────────────────┤
│ Layer 6: Monitoring Provisioning │
│ ├── Grafana Dashboard 创建 │
│ ├── 告警规则配置 │
│ ├── 日志收集配置 │
│ └── SLO 目标设置 │
└─────────────────────────────────────────────────────┘
每层独立供给，支持并行执行（无依赖的层）
Layer 1-2 顺序执行（索引依赖表）
Layer 3-6 并行执行（互不依赖）
#2.2 供给事件流
Code
供给过程的事件流：
ObjectType 注册事件
│
├──→ ProvisioningStarted
│ timestamp: 2025-01-15T10:00:00.000Z
│
├──→ StorageProvisioned
│ table: "shipping_order_objects"
│ partitionKey: "created_at"
│ duration: 2.3s
│
├──→ IndexProvisioned
│ indexes: ["pk_shipping_order", "idx_status", "idx_created_at"]
│ duration: 5.1s
│
├──→ ApiProvisioned (并行)
│ endpoints: ["/api/v1/objects/ShippingOrder/*"]
│ grpcService: "ShippingOrderService"
│ duration: 1.2s
│
├──→ PermissionProvisioned (并行)
│ roles: ["ShippingOrder.Reader", "ShippingOrder.Writer", "ShippingOrder.Admin"]
│ duration: 0.8s
│
├──→ SdkProvisioned (并行)
│ python: "ontology_sdk.types.ShippingOrder"
│ typescript: "@coomia-dip/sdk/ShippingOrder"
│ duration: 3.5s
│
├──→ MonitoringProvisioned (并行)
│ dashboard: "ShippingOrder Overview"
│ alerts: ["error_rate > 1%", "latency_p99 > 500ms"]
│ duration: 2.1s
│
└──→ ProvisioningCompleted
totalDuration: 12.5s
status: SUCCESS
#3. Layer 1: 存储供给
#3.1 表结构自动生成
Code
从 ObjectType 定义自动生成 DDL：
ObjectType 定义：
{
"objectTypeId": "ShippingOrder",
"properties": [
{"name": "orderId", "type": "STRING", "primaryKey": true},
{"name": "status", "type": "ENUM", "values": ["PENDING","SHIPPED","DELIVERED"]},
{"name": "totalWeight", "type": "DECIMAL", "precision": 10, "scale": 2},
{"name": "shippingAddress", "type": "STRUCT", "fields": [
{"name": "street", "type": "STRING"},
{"name": "city", "type": "STRING"},
{"name": "zipCode", "type": "STRING"}
]},
{"name": "items", "type": "ARRAY", "elementType": "STRING"},
{"name": "metadata", "type": "JSON"},
{"name": "createdAt", "type": "TIMESTAMP", "autoGenerate": true},
{"name": "updatedAt", "type": "TIMESTAMP", "autoUpdate": true}
]
}
自动生成的 DDL：
CREATE TABLE shipping_order_objects (
-- 系统字段
_onto_id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
_onto_version BIGINT DEFAULT 1,
_onto_created TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
_onto_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
_onto_deleted BOOLEAN DEFAULT FALSE,
-- 业务属性
order_id VARCHAR(255) NOT NULL UNIQUE,
status VARCHAR(50) NOT NULL DEFAULT 'PENDING'
CHECK(status IN ('PENDING','SHIPPED','DELIVERED')),
total_weight DECIMAL(10,2),
shipping_address JSONB, -- STRUCT 存储为 JSONB
items TEXT[], -- ARRAY 存储为数组
metadata JSONB,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) PARTITION BY RANGE (created_at);
-- 自动创建月度分区
CREATE TABLE shipping_order_objects_2025_01
PARTITION OF shipping_order_objects
FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');
-- 触发器：自动更新 updated_at
CREATE TRIGGER trg_shipping_order_updated
BEFORE UPDATE ON shipping_order_objects
FOR EACH ROW EXECUTE FUNCTION update_timestamp();
类型映射规则：
STRING → VARCHAR(255)
TEXT → TEXT
INT → INTEGER
LONG → BIGINT
DOUBLE → DOUBLE PRECISION
DECIMAL → DECIMAL(precision, scale)
BOOLEAN → BOOLEAN
TIMESTAMP → TIMESTAMP WITH TIME ZONE
DATE → DATE
ENUM → VARCHAR(50) + CHECK 约束
STRUCT → JSONB
ARRAY → 原生数组类型
JSON → JSONB
#3.2 分区策略
Code
自动分区策略选择：
规则引擎根据 ObjectType 特征选择分区策略：
IF 有 TIMESTAMP 类型的 createdAt 属性:
→ 按时间分区（RANGE，月度）
ELIF 有 ENUM 类型的 status/region 属性 AND 值域 < 10:
→ 按枚举值分区（LIST）
ELIF 预估数据量 > 1000 万:
→ 按主键 HASH 分区（HASH，4~16 个分区）
ELSE:
→ 不分区（小表）
分区策略示例：
时间分区（最常见）：
PARTITION BY RANGE (created_at)
每月自动创建新分区
超过保留期的分区自动归档
列表分区（按状态/区域）：
PARTITION BY LIST (region)
每个区域一个分区
查询时自动分区裁剪
哈希分区（大表均匀分布）：
PARTITION BY HASH (order_id)
16 个分区均匀分布
适合没有明显分区键的大表
#4. Layer 2: 索引供给
#4.1 智能索引策略
Code
自动创建的索引类型：
1. 主键索引（必选）：
CREATE UNIQUE INDEX idx_pk_shipping_order
ON shipping_order_objects(order_id);
2. 外键索引（关系属性自动创建）：
如果 ShippingOrder 有 customerId 关联 Customer：
CREATE INDEX idx_fk_customer
ON shipping_order_objects(customer_id);
3. 枚举索引（ENUM 类型自动创建）：
CREATE INDEX idx_status
ON shipping_order_objects(status);
4. 时间索引（TIMESTAMP 类型自动创建）：
CREATE INDEX idx_created_at
ON shipping_order_objects(created_at);
5. 全文搜索索引（标记为 searchable 的属性）：
CREATE INDEX idx_search_address
ON shipping_order_objects
USING GIN (to_tsvector('english', shipping_address->>'street'));
6. 复合索引（基于查询模式分析）：
如果检测到频繁的 status + created_at 组合查询：
CREATE INDEX idx_status_created
ON shipping_order_objects(status, created_at DESC);
索引创建策略：
├── 主键和外键索引：同步创建（阻塞）
├── 其他索引：异步创建（CONCURRENTLY，不阻塞读写）
├── 全文索引：延迟创建（数据量达到阈值后）
└── 复合索引：基于查询模式自动学习（上线后 7 天分析）
#5. Layer 3: API 供给
#5.1 自动 CRUD API
Code
注册 ObjectType 后自动生成的 API 端点：
REST API（自动注册到 API Gateway）：
GET /api/v1/objects/ShippingOrder # 列表查询
GET /api/v1/objects/ShippingOrder/{objectId} # 单个查询
POST /api/v1/objects/ShippingOrder # 创建
PUT /api/v1/objects/ShippingOrder/{objectId} # 全量更新
PATCH /api/v1/objects/ShippingOrder/{objectId} # 部分更新
DELETE /api/v1/objects/ShippingOrder/{objectId} # 删除（软删除）
POST /api/v1/objects/ShippingOrder/batch # 批量操作
POST /api/v1/objects/ShippingOrder/search # 高级搜索
gRPC Service（自动生成 .proto 并注册）：
service ShippingOrderService {
rpc Get(GetShippingOrderRequest) returns (ShippingOrder);
rpc List(ListShippingOrderRequest) returns (ListShippingOrderResponse);
rpc Create(CreateShippingOrderRequest) returns (ShippingOrder);
rpc Update(UpdateShippingOrderRequest) returns (ShippingOrder);
rpc Delete(DeleteShippingOrderRequest) returns (Empty);
rpc Search(SearchShippingOrderRequest) returns (SearchShippingOrderResponse);
rpc BatchCreate(BatchCreateRequest) returns (BatchCreateResponse);
}
列表查询自动支持：
├── 分页：?page=1&pageSize=20
├── 排序：?orderBy=createdAt&direction=DESC
├── 过滤：?filter=status:eq:SHIPPED
├── 字段选择：?fields=orderId,status,totalWeight
└── 关系展开：?expand=customer,lineItems
#5.2 OpenAPI 文档自动生成
Code
自动生成 OpenAPI 3.0 文档：
{
"openapi": "3.0.3",
"info": {
"title": "ShippingOrder API",
"description": "Auto-generated API for ObjectType: ShippingOrder",
"version": "v1"
},
"paths": {
"/api/v1/objects/ShippingOrder": {
"get": {
"summary": "List ShippingOrders",
"parameters": [
{"name": "page", "in": "query", "schema": {"type": "integer"}},
{"name": "pageSize", "in": "query", "schema": {"type": "integer"}},
{"name": "filter", "in": "query", "schema": {"type": "string"}}
],
"responses": {
"200": {
"description": "Successful response",
"content": {
"application/json": {
"schema": {"$ref": "#/components/schemas/ShippingOrderList"}
}
}
}
}
},
"post": {
"summary": "Create ShippingOrder",
"requestBody": {
"content": {
"application/json": {
"schema": {"$ref": "#/components/schemas/CreateShippingOrder"}
}
}
}
}
}
},
"components": {
"schemas": {
"ShippingOrder": {
"type": "object",
"properties": {
"orderId": {"type": "string"},
"status": {"type": "string", "enum": ["PENDING","SHIPPED","DELIVERED"]},
"totalWeight": {"type": "number", "format": "decimal"},
"shippingAddress": {"$ref": "#/components/schemas/Address"},
"createdAt": {"type": "string", "format": "date-time"}
}
}
}
}
}
文档自动发布到 Swagger UI：
https://platform.company.com/docs/api/ShippingOrder
#6. Layer 4: 权限供给
#6.1 默认权限模型
Code
自动创建的权限配置：
角色自动创建：
├── ShippingOrder.Reader — 只读权限
├── ShippingOrder.Writer — 读写权限
├── ShippingOrder.Admin — 管理权限（含删除和配置）
└── ShippingOrder.Owner — 所有权限 + 权限管理
权限矩阵：
┌────────────────────┬────────┬────────┬────────┬────────┐
│ 操作 │ Reader │ Writer │ Admin │ Owner │
├────────────────────┼────────┼────────┼────────┼────────┤
│ 读取 │ ✓ │ ✓ │ ✓ │ ✓ │
│ 创建 │ │ ✓ │ ✓ │ ✓ │
│ 更新 │ │ ✓ │ ✓ │ ✓ │
│ 删除 │ │ │ ✓ │ ✓ │
│ 批量操作 │ │ │ ✓ │ ✓ │
│ 修改 Schema │ │ │ │ ✓ │
│ 管理权限 │ │ │ │ ✓ │
│ 导出数据 │ │ ✓ │ ✓ │ ✓ │
│ 查看审计日志 │ │ │ ✓ │ ✓ │
└────────────────────┴────────┴────────┴────────┴────────┘
属性级权限（敏感属性自动识别）：
如果属性名包含 "password", "secret", "token", "ssn", "creditCard":
→ 自动标记为 SENSITIVE
→ Reader 角色不可见
→ Writer 角色只能写不能读
→ 只有 Admin/Owner 可读写
#6.2 审计日志自动配置
Code
自动为每个 ObjectType 配置审计日志：
记录的操作：
├── CREATE: 谁在什么时候创建了什么对象
├── UPDATE: 谁在什么时候修改了哪些字段（含旧值和新值）
├── DELETE: 谁在什么时候删除了什么对象
├── READ: 谁在什么时候读取了什么对象（可配置）
└── EXPORT: 谁在什么时候导出了什么数据
审计日志格式：
{
"auditId": "audit-20250115-001",
"objectType": "ShippingOrder",
"objectId": "SO-001",
"action": "UPDATE",
"actor": "alice@company.com",
"timestamp": "2025-01-15T10:30:00Z",
"changes": {
"status": {"from": "PENDING", "to": "SHIPPED"},
"updatedAt": {"from": "...", "to": "..."}
},
"metadata": {
"ip": "10.0.1.100",
"userAgent": "coomia-dip-sdk/1.0.0",
"requestId": "req-abc-123"
}
}
审计日志保留策略：
CREATE/UPDATE/DELETE: 永久保留
READ: 保留 90 天
EXPORT: 保留 365 天
#7. Layer 5: SDK 供给
#7.1 Python SDK 自动生成
Code
自动生成的 Python SDK 类型：
# Auto-generated: Do not edit manually
# ObjectType: ShippingOrder
# Generated at: 2025-01-15T10:00:00Z
from datetime import datetime
from decimal import Decimal
from typing import List, Optional
from pydantic import BaseModel, Field
from ontology_sdk.base import OntologyObject
class ShippingAddress(BaseModel):
street: str
city: str
zip_code: str = Field(alias="zipCode")
class ShippingOrder(OntologyObject):
"""物流订单对象类型"""
object_type_id: str = "ShippingOrder"
order_id: str = Field(..., description="订单ID", alias="orderId")
status: str = Field(default="PENDING", description="订单状态")
total_weight: Optional[Decimal] = Field(None, alias="totalWeight")
shipping_address: Optional[ShippingAddress] = Field(None, alias="shippingAddress")
items: List[str] = Field(default_factory=list)
metadata: Optional[dict] = None
created_at: Optional[datetime] = Field(None, alias="createdAt")
updated_at: Optional[datetime] = Field(None, alias="updatedAt")
class Config:
populate_by_name = True
# 自动生成的 CRUD 方法
class ShippingOrderClient:
def get(self, order_id: str) -> ShippingOrder: ...
def list(self, filter: Optional[str] = None, page: int = 1) -> List[ShippingOrder]: ...
def create(self, order: ShippingOrder) -> ShippingOrder: ...
def update(self, order_id: str, updates: dict) -> ShippingOrder: ...
def delete(self, order_id: str) -> None: ...
def search(self, query: str) -> List[ShippingOrder]: ...
#7.2 TypeScript SDK 自动生成
Code
自动生成的 TypeScript SDK 类型：
// Auto-generated: Do not edit manually
// ObjectType: ShippingOrder
// Generated at: 2025-01-15T10:00:00Z
export interface ShippingAddress {
street: string;
city: string;
zipCode: string;
}
export interface ShippingOrder {
orderId: string;
status: 'PENDING' | 'SHIPPED' | 'DELIVERED';
totalWeight?: number;
shippingAddress?: ShippingAddress;
items: string[];
metadata?: Record<string, unknown>;
createdAt?: string;
updatedAt?: string;
}
export interface ShippingOrderClient {
get(orderId: string): Promise<ShippingOrder>;
list(options?: ListOptions): Promise<PagedResult<ShippingOrder>>;
create(order: Omit<ShippingOrder, 'createdAt' | 'updatedAt'>): Promise<ShippingOrder>;
update(orderId: string, updates: Partial<ShippingOrder>): Promise<ShippingOrder>;
delete(orderId: string): Promise<void>;
search(query: SearchQuery): Promise<PagedResult<ShippingOrder>>;
}
#8. Layer 6: 监控供给
#8.1 自动 Dashboard 创建
Code
自动为每个 ObjectType 创建 Grafana Dashboard：
Dashboard 面板：
Row 1: 概览
├── 总对象数量（单值面板）
├── 最近 24h 新增数量（趋势图）
├── 最近 24h CRUD 操作分布（饼图）
└── 平均 API 响应时间（单值面板）
Row 2: 操作指标
├── API 请求量（按端点分组的时序图）
├── API 延迟 P50/P95/P99（时序图）
├── 错误率（时序图）
└── 活跃用户数（时序图）
Row 3: 数据指标
├── 存储空间使用量（趋势图）
├── 按状态分布（饼图）
├── 数据增长趋势（时序图）
└── 数据质量评分（仪表盘）
Row 4: 告警
├── 活跃告警列表
└── 最近告警历史
#8.2 自动告警规则
Code
自动配置的基础告警规则：
alerts:
- name: "{ObjectType} API Error Rate High"
condition: error_rate > 1%
duration: 5m
severity: WARNING
- name: "{ObjectType} API Latency High"
condition: latency_p99 > 500ms
duration: 5m
severity: WARNING
- name: "{ObjectType} Storage Growth Abnormal"
condition: growth_rate > 200% (vs last week)
duration: 1h
severity: INFO
- name: "{ObjectType} Data Quality Drop"
condition: quality_score < 95%
duration: 15m
severity: WARNING
#9. 变更感知供给
#9.1 Schema 变更触发增量供给
Code
Schema 变更时的增量供给：
变更类型 → 触发的供给操作：
ADD_PROPERTY:
Storage: ALTER TABLE ADD COLUMN
Index: 如果标记为 indexed → CREATE INDEX CONCURRENTLY
API: 更新 OpenAPI 文档
SDK: 重新生成类型定义
Monitoring: 无变更
MODIFY_PROPERTY (类型变更):
Storage: ALTER TABLE ALTER COLUMN TYPE
Index: 如果影响索引 → 重建索引
API: 更新 OpenAPI 文档
SDK: 重新生成类型定义
Monitoring: 无变更
DELETE_PROPERTY:
Storage: 标记列为 deprecated（不立即删除）
Index: 删除相关索引
API: 更新 OpenAPI 文档 + 添加 deprecated 标记
SDK: 标记为 @deprecated
Monitoring: 移除相关面板
ADD_RELATION:
Storage: 创建外键索引
API: 添加关系查询端点
SDK: 添加关系导航方法
Monitoring: 添加关系指标面板
#9.2 供给回滚
Code
供给失败时的回滚策略：
每层供给都记录回滚信息：
Layer 1 回滚（存储）：
DROP TABLE IF EXISTS shipping_order_objects;
Layer 2 回滚（索引）：
DROP INDEX IF EXISTS idx_pk_shipping_order;
DROP INDEX IF EXISTS idx_status;
Layer 3 回滚（API）：
从 API Gateway 注销端点
删除 gRPC Service 注册
Layer 4 回滚（权限）：
删除自动创建的角色和权限
撤销已分配的权限
Layer 5 回滚（SDK）：
从 SDK 包中移除类型定义
发布回退版本
Layer 6 回滚（监控）：
删除 Grafana Dashboard
移除告警规则
部分失败场景：
Layer 1-3 成功，Layer 4 失败
→ 只回滚 Layer 4-6
→ Layer 1-3 保留
→ 重试 Layer 4
→ Layer 4 成功后继续 Layer 5-6
#10. 供给模板与自定义
#10.1 供给模板
Code
不同类型的 ObjectType 使用不同的供给模板：
模板 1: 标准业务对象
存储：PostgreSQL + 时间分区
索引：标准索引集
API：完整 CRUD
权限：标准 4 角色
SDK：Python + TypeScript
监控：标准 Dashboard
模板 2: 高频事件对象
存储：TimescaleDB + 压缩
索引：时间索引 + 分区索引
API：只写 + 聚合查询（无单条查询）
权限：Writer + Analyst
SDK：Writer 接口 + 聚合接口
监控：吞吐量 + 延迟重点
模板 3: 配置对象
存储：PostgreSQL（不分区）
索引：最小索引集
API：完整 CRUD + 版本历史
权限：Admin 只读，Owner 读写
SDK：完整接口
监控：变更频率 + 审计重点
模板 4: 只读参考数据
存储：PostgreSQL + 重度缓存
索引：查询优化索引
API：只读 API
权限：Reader only
SDK：只读接口
监控：缓存命中率重点
#10.2 自定义供给钩子
Code
在供给过程中插入自定义逻辑：
hooks:
beforeStorageProvision:
type: WEBHOOK
url: "https://dba-approval.internal/api/review"
timeout: 24h # DBA 审批（大表才需要）
condition: "estimatedRowCount > 10000000"
afterApiProvision:
type: SCRIPT
script: |
# 自动注册到 API 网关
register_to_kong(objectType, endpoints)
# 自动配置限流
set_rate_limit(objectType, rps=1000)
afterSdkProvision:
type: WEBHOOK
url: "https://ci.internal/api/trigger"
payload:
pipeline: "sdk-publish"
version: "{{sdkVersion}}"
afterMonitoringProvision:
type: SCRIPT
script: |
# 自动添加到 On-Call 看板
add_to_oncall_dashboard(objectType)
# 自动创建 PagerDuty 服务
create_pagerduty_service(objectType)
#Key Takeaways
- 自动供给将"7~9 天、5 个团队"压缩为"30 秒、零人工"——ObjectType 注册后，存储、索引、API、权限、SDK、监控全部自动完成，开发者只需关注 Schema 定义，基础设施由平台承担。
- 六层供给管道确保了可靠性和可恢复性——每层独立供给、独立回滚，一个层的失败不影响其他层。Layer 1-2 顺序执行保证依赖关系，Layer 3-6 并行执行提升速度。
- 变更感知供给解决了"改了 Schema 忘了改 API"的问题——Schema 变更自动触发增量供给，新增属性自动加列、加索引、更新文档、重新生成 SDK，全生命周期自动化。
- 智能策略减少了不必要的供给——根据属性类型自动选择索引策略，根据数据量自动选择分区策略，根据使用模式自动优化查询计划。
- 供给模板和自定义钩子兼顾了标准化与灵活性——标准业务对象用默认模板，高频事件对象用事件模板，特殊需求通过钩子插入自定义逻辑。
#Next Article
下一篇 S4-13 连接注册表 将讨论如何统一管理 Ontology 的外部连接——数据库连接、API 凭证、消息队列配置，如何实现连接的复用、加密存储、健康检查和故障自动切换。
#ontology #auto-provisioning #infrastructure-as-code #crud-generation #sdk-generation #monitoring #zero-touch #schema-driven