从 0 到 1 设计一个 Palantir：分层架构全景

“

系列：S2 架构全景 · 第 1 篇 | 难度：中级 | 阅读时间：18 分钟

TL;DR

智策平台（coomia-dip）将 Palantir Foundry 的能力域分解为 8 个逻辑 Layer，涵盖从部署运维到 SDK 开发者体验的完整链路，每个 Layer 可由独立架构师全权负责。
8 个逻辑 Layer 在物理部署上合并为 3 个进程（onto-control.jar、onto-data.jar、onto-intelligence），通过 ARCH-001/002 架构决策实现"逻辑解耦、物理内聚"。
所有 Layer 间通信强制使用 gRPC + Protobuf（64 个 proto 文件），REST 仅用于外部 SDK 门面，严格禁止内部使用 REST/JSON。

#1. 引言：为什么要对标 Palantir Foundry？

Palantir Foundry 是当今企业级数据平台领域的标杆产品。它将数据集成、本体建模、数据治理、推理决策和应用构建统一在一个平台上。然而，Foundry 是闭源的、昂贵的，且在中国市场面临数据主权问题。

智策平台（coomia-dip）的目标很明确：构建一个开源的、可私有化部署的 Palantir 替代品。但这不是简单的"抄作业"——我们需要在架构上做出适合开源生态和中国企业需求的设计决策。

第一个也是最关键的架构问题是：如何分解这个庞大的问题域？

我们的答案是 分层架构。

#2. 问题域分解：为什么是 8 个 Layer？

#2.1 从 Palantir Foundry 的能力矩阵出发

Foundry 的核心能力可以归纳为以下几个域：

Code

+------------------------------------------------------------------+
|                    Palantir Foundry 能力矩阵                       |
+------------------------------------------------------------------+
| 1. 数据集成与管道    | Foundry Pipeline, Contour                  |
| 2. 本体建模         | Ontology Manager, Object Types              |
| 3. 数据治理         | Lineage, Audit, Classification              |
| 4. 推理与决策       | Workshop, Logic Rules, AIP                  |
| 5. 应用构建         | Slate, Carbon, Actions                      |
| 6. 用户管理与权限   | RBAC, ABAC, Multipass                       |
| 7. 部署与运维       | Apollo, Resource Management                 |
| 8. 开发者体验       | OSDK, API, Developer Console                |
+------------------------------------------------------------------+

#2.2 Layer 的定义

我们使用 Layer 而非 Service 或 Module 来命名，灵感来自网络架构中的 Control Layer / Data Layer 分离。每个 Layer 代表一个工程责任域（Engineering Responsibility Domain），具有以下特征：

独立的技术选型权：可以选择最适合的语言和框架
明确的职责边界：通过 gRPC 契约定义与其他 Layer 的交互
独立的部署单元（逻辑上）：可以独立开发、测试
单一架构师负责制：每个 Layer 由一名架构师全权负责

#2.3 8 Layer 全景

Code

+------------------------------------------------------------------------+
|                        应用层 (Business Apps)                            |
|            业务应用 / Agent / 仪表盘 / 运营工具                           |
+------------------------------------------------------------------------+
         ^                                    |
         | REST/gRPC-Web                      | REST/gRPC-Web
         v                                    v
+------------------------------------------------------------------------+
| H. SDK & Developer Experience Layer                                     |
|    Python SDK / TypeScript OSDK / REST Facade / Developer Portal        |
+------------------------------------------------------------------------+
         ^
         | gRPC
         v
+------------------------------------------------------------------------+
| B. Control Layer              | G. Metadata & Governance Layer         |
|  - API Gateway                |  - Lineage Service                     |
|  - Auth (OAuth2+Policy)       |  - Audit Service                       |
|  - Schema Registry            |  - Replay Service                      |
|  - World Manager              |  - Metadata Service                    |
|  - User & Org Management      |  - Workflow Lineage                    |
+------------------------------------------------------------------------+
         ^
         | gRPC Internal Bus
         v
+--------------------+--------------------+------------------------------+
| C. Data Layer      | D. Reasoning &     | F. Pipeline &                |
|                    |    Decision Layer   |    Orchestration Layer       |
| - Ontology Runtime | - Reasoning Engine  | - Pipeline Engine            |
| - Query Federation | - Decision Engine   | - World Transform            |
| - Data Ingestion   | - Rule Engine       | - Scheduler                  |
| - Object Set       | - Derived Property  | - Trigger Rules              |
| - Vector Service   | - Function Runtime  | - Connection Management      |
| - Materialized View|                     |                              |
+--------------------+--------------------+------------------------------+
         |           | E. Agent Runtime    |
         |           |    Layer            |
         |           | - Action Engine     |
         |           | - AIP Logic         |
         |           | - Approval Workflow |
         |           | - Notification      |
         |           +---------------------+
         v
+------------------------------------------------------------------------+
| A. Platform Deployment & Ops Layer                                      |
|    Docker Compose / K8s Operator / Observability / Backup & Recovery    |
+------------------------------------------------------------------------+
         ^
         |
         v
+------------------------------------------------------------------------+
|                        统一存储层 (Storage Layer)                        |
|  Apache Doris | Iceberg+Nessie | Kafka | Redis | PostgreSQL | MinIO    |
+------------------------------------------------------------------------+

#3. 每个 Layer 的职责边界

#3.1 Deployment & Operations Layer — Platform Deployment & Ops（平台部署与运维）

技术栈: Docker Compose / Python / YAML / Kubernetes Operator

核心职责:

平台组件的编排与部署（Docker Compose 本地 / K8s 生产）
可观测性集成（OpenTelemetry：Traces, Metrics, Logs）
备份与恢复（Doris 增量备份、Nessie 快照、MinIO 冷归档）
资源管理与弹性扩缩
多租户基础设施隔离

不负责: 业务逻辑、数据处理、认证授权

#3.2 Control Layer（控制层）

技术栈: Spring Boot 3.x / Java 21 / gRPC

核心职责:

API Gateway（路由、限流、熔断）
认证与授权（OAuth2 + mTLS + Policy Engine）
Schema Registry（本体类型定义的注册与版本管理）
World Manager（世界分支的创建、切换、合并，基于 Nessie）
用户与组织管理（Tenant → Org → Space → Project → World 层级）
配置管理
数据分类服务（7 级敏感度自动分类）

关键 Proto 文件: authentication_service.proto, schema_registry.proto, world_manager.proto, policy_engine.proto, user_management.proto, classification_service.proto 等 16 个。

#3.3 Data Layer（数据层）

技术栈: Quarkus 3.x / Java 21 / gRPC

核心职责:

OntologyRuntimeService: 本体实例的 CRUD、批量操作、关系管理——这是整个平台的数据内核
Query Federation（联邦查询，跨数据源聚合）
Data Ingestion（数据接入，Flink CDC → Kafka → Doris）
Object Set（对象集操作，筛选、聚合、分组）
Vector Service（向量存储与 HNSW 搜索）
Materialized View（物化视图管理）
Time Series Store（时序数据存储与查询）
Temporal Query（时间旅行查询，基于 Nessie Commit）

关键 Proto 文件: ontology_runtime.proto, query_federation.proto, object_set.proto, data_ingestion.proto, vector_service.proto 等 15 个。

#3.4 Reasoning & Decision Layer — Reasoning & Decision（推理与决策）

技术栈: Python 3.x / FastAPI / gRPC

核心职责:

Reasoning Engine（推理引擎，基于规则和 AI 的推理）
Decision Engine（决策引擎，多目标优化、约束求解）
Derived Property（派生属性计算，支持 7 种计算策略）
Function Runtime（用户自定义函数的沙箱执行）
Rule Engine（低代码规则引擎）
RAG Service（检索增强生成）
ML Model Service（机器学习模型管理与推理）
Approval Service（审批服务）

关键 Proto 文件: reasoning_engine.proto, decision_engine.proto, derived_property.proto, function_runtime.proto, rule_script.proto 等 14 个。

#3.5 Agent Runtime Layer — Agent Runtime（Agent 运行时）

技术栈: Python 3.x / FastAPI / Temporal

核心职责:

Action Engine（动作执行引擎，触发副作用操作）
AIP Logic Workflow（AI 增强的逻辑工作流）
Approval Workflow（审批流编排，基于 Temporal）
Mutation Rules（变更规则，数据写入前的校验与转换）
Notification（通知服务，多渠道消息推送）

关键 Proto 文件: action_engine.proto, aip_logic_workflow.proto, approval_workflow.proto, mutation_rules.proto, notification.proto

#3.6 Pipeline & Orchestration Layer — Pipeline & Orchestration（数据管道与编排）

技术栈: Quarkus 3.x / DolphinScheduler / Java 21

核心职责:

Pipeline Engine（数据管道定义与执行）
Transform Executor（数据转换执行器）
Scheduler（调度管理，集成 DolphinScheduler）
Connection Management（外部数据源连接管理）
Trigger Rules（触发规则定义）
Lineage（数据血缘追踪）

关键 Proto 文件: pipeline_engine.proto, scheduler.proto, transform_executor.proto, connection_management.proto, trigger_rule.proto 等 8 个。

#3.7 Metadata & Governance Layer — Metadata & Governance（元数据与治理）

技术栈: Java / Spring Boot 3.x / gRPC

核心职责:

Lineage Service（端到端数据血缘）
Audit Service（审计日志，属性级别追踪）
Replay Service（操作回放，支持问题复现）
Metadata Service（元数据统一管理）
Workflow Lineage（工作流血缘追踪）

关键 Proto 文件: audit_service.proto, lineage_service.proto, metadata_service.proto, replay_service.proto, workflow_lineage.proto

#3.8 SDK & Developer Experience Layer — SDK & Developer Experience（SDK 与开发者体验）

技术栈: Python SDK / TypeScript OSDK / REST

核心职责:

Python SDK（ontology_sdk 包，封装所有 gRPC 调用为 Pythonic API）
TypeScript OSDK（类型安全的前端 SDK，对标 Palantir OSDK）
REST Facade（将 gRPC 服务暴露为 REST API，共 59 个端点）
Developer Portal（开发者文档与 API Explorer）

#4. 逻辑 vs 物理：8 → 3 的部署合并（ARCH-001/002）

#4.1 为什么要合并？

8 个 Layer 独立部署听起来很美好，但在实际运维中面临严重问题：

问题	影响
8 个独立进程 = 8 倍运维成本	小团队无法承受
跨进程 gRPC 调用延迟	高频调用路径性能下降
分布式事务复杂度	数据一致性难以保证
资源碎片化	每个进程有固定的内存/CPU 开销
部署编排复杂	启动顺序、健康检查、依赖管理

#4.2 ARCH-001：2-JAR 合并（Java 侧）

Code

合并前（4 个 Java 进程）:
  control-Layer.jar     (Spring Boot)
  data-Layer.jar        (Quarkus)
  pipeline-Layer.jar    (Quarkus)
  governance-Layer.jar  (Spring Boot)

合并后（2 个 Java 进程）:
  onto-control.jar      (Spring Boot) = Control Layer + Metadata & Governance Layer
     端口: 6666 (gRPC) / 6667 (REST)
  onto-data.jar         (Quarkus)     = Data Layer + Pipeline & Orchestration Layer
     端口: 6668 (gRPC) / 6669 (REST/Flight SQL)

合并策略：

亲和性合并：将调用频率最高的 Layer 合并到同一进程
技术栈一致性：Spring Boot 的合并在一起，Quarkus 的合并在一起
逻辑隔离保持：代码组织仍按 Layer 划分包路径

#4.3 ARCH-002：D+E 合并（Python 侧）

Code

合并前（2 个 Python 进程）:
  reasoning-Layer/      (FastAPI + gRPC)
  agent-runtime-Layer/  (FastAPI + Temporal)

合并后（1 个 Python 进程）:
  onto-intelligence     (FastAPI + gRPC + Temporal)
     端口: 6670 (gRPC) / 6671 (REST)

#4.4 最终物理拓扑

Code

+---------------------------------------------------------------+
|                    物理部署架构（3 进程）                        |
+---------------------------------------------------------------+
|                                                                 |
|  +---------------------------+  gRPC  +---------------------+  |
|  | onto-control.jar          |<------>| onto-data.jar       |  |
|  | (Spring Boot)             |        | (Quarkus)           |  |
|  |                           |        |                     |  |
|  | Control Layer: Control          |        | Data Layer: Data       |  |
|  |  - Schema Registry       |        |  - Ontology Runtime |  |
|  |  - World Manager         |        |  - Query Federation |  |
|  |  - Auth/Policy           |        |  - Data Ingestion   |  |
|  |  - User Management       |        |  - Object Set       |  |
|  |                           |        |                     |  |
|  | Metadata & Governance Layer: Governance       |        | Pipeline & Orchestration Layer: Pipeline   |  |
|  |  - Audit Service         |        |  - Pipeline Engine  |  |
|  |  - Lineage Service       |        |  - Scheduler        |  |
|  |  - Metadata Service      |        |  - Transform        |  |
|  |                           |        |                     |  |
|  | Ports: 6666/6667         |        | Ports: 6668/6669    |  |
|  +---------------------------+        +---------------------+  |
|              ^                                ^                 |
|              | gRPC                           | gRPC            |
|              v                                v                 |
|  +----------------------------------------------------------+  |
|  | onto-intelligence (FastAPI + gRPC)                        |  |
|  |                                                            |  |
|  | Reasoning & Decision Layer: Reasoning & Decision                              |  |
|  |  - Reasoning Engine, Decision Engine                       |  |
|  |  - Derived Property, Function Runtime                      |  |
|  |                                                            |  |
|  | Agent Runtime Layer: Agent Runtime                                     |  |
|  |  - Action Engine, AIP Logic, Approval Workflow             |  |
|  |                                                            |  |
|  | Ports: 6670/6671                                           |  |
|  +----------------------------------------------------------+  |
|                              |                                  |
|                              v                                  |
|  +----------------------------------------------------------+  |
|  |                   Storage Layer                            |  |
|  | Doris | Nessie+Iceberg | Kafka | Redis | PostgreSQL | MinIO|  |
|  +----------------------------------------------------------+  |
+---------------------------------------------------------------+

#4.5 合并的优势与代价

维度	合并前（8 进程）	合并后（3 进程）
JVM 实例	4 个 JVM	2 个 JVM
Python 进程	2 个	1 个
基础内存消耗	~4 GB	~1.5 GB
部署 YAML 复杂度	高	中
内部调用延迟	跨进程 gRPC (~1ms)	进程内方法调用 (~0.01ms)
代码隔离	物理隔离	逻辑隔离（包路径）
独立扩缩	完全独立	同进程 Layer 绑定扩缩

#5. Layer 间通信：gRPC 契约驱动

#5.1 通信矩阵

Code

              onto-control    onto-data    onto-intelligence
              (B+G)           (C+F)        (D+E)
            +---------------+------------+-----------------+
onto-control|  进程内调用    |   gRPC     |     gRPC        |
(B+G)       |               |            |                 |
            +---------------+------------+-----------------+
onto-data   |   gRPC        | 进程内调用  |     gRPC        |
(C+F)       |               |            |                 |
            +---------------+------------+-----------------+
onto-intel  |   gRPC        |   gRPC     |  进程内调用      |
(D+E)       |               |            |                 |
            +---------------+------------+-----------------+

#5.2 Proto 文件组织

Code

proto/
├── common/
│   ├── common.proto          # WorldContext, RequestContext
│   ├── common_b.proto        # Control Layer 共享类型
│   └── errors.proto          # 统一错误码
├── plane_b/                  # 16 个文件
│   ├── authentication_service.proto
│   ├── schema_registry.proto
│   ├── world_manager.proto
│   └── ...
├── plane_c/                  # 15 个文件
│   ├── ontology_runtime.proto
│   ├── query_federation.proto
│   └── ...
├── plane_d/                  # 14 个文件
│   ├── reasoning_engine.proto
│   ├── decision_engine.proto
│   ├── derived_property.proto
│   └── ...
├── plane_e/                  # 5 个文件
│   ├── action_engine.proto
│   └── ...
├── plane_f/                  # 8 个文件
│   ├── pipeline_engine.proto
│   └── ...
└── plane_g/                  # 5 个文件
    ├── audit_service.proto
    └── ...

#5.3 WorldContext 贯穿一切

每个 gRPC 请求都必须携带 WorldContext，这是平台的第一公民概念：

PROTOBUF

message WorldContext {
  string world_id = 1;
  string branch_name = 2;
  optional string commit_hash = 3;
  optional Timestamp as_of_timestamp = 4;
  WorldType type = 5;
  map<string, string> metadata = 6;
  string tenant_id = 7;
  string org_id = 8;
  string project_id = 9;
  WorldBranchType world_branch_type = 10;
  string manifest_id = 11;
  optional string compute_version = 12;
}

这意味着平台中不存在"全局操作"——一切操作都发生在特定的世界分支上下文中。

#6. 端到端数据流：从接入到决策

让我们跟踪一条完整的数据流，看 Layer 如何协作：

Code

[外部数据源]
     |
     | (1) Flink CDC 捕获变更
     v
+----------+     (2) 消息投递      +----------+
|  Kafka   | ------------------->  |  Data Layer |
|          |                       |  Data    |
+----------+                       |  Ingestion|
                                    +----------+
                                         |
                    (3) Schema 校验       | (4) 写入 Doris
                    +----------+          |     entity_common
                    |  Control Layer |<---------+     entity_edge
                    |  Schema  |          |     entity_event
                    |  Registry|          |
                    +----------+          v
                                    +----------+
                                    |  Doris   |
                                    | (统一存储)|
                                    +----------+
                                         |
                    (5) 变更事件          |
                    +----------+    Kafka CDC
                    |  Metadata & Governance Layer |<---------+
                    |  Audit   |
                    +----------+
                                         |
                    (6) 触发派生属性      |
                    +----------+    计算请求
                    |  Reasoning & Decision Layer |<---------+
                    |  Derived |
                    |  Property|
                    +----------+
                         |
                    (7) 回写结果
                         |
                         v
                    +----------+
                    |  Data Layer |
                    |  Ontology|
                    |  Runtime |
                    +----------+
                         |
                    (8) 通知订阅者
                         v
                    +----------+
                    |  Agent Runtime Layer |
                    |  Action  |
                    |  Engine  |
                    +----------+

步骤解析：

外部数据源通过 Flink CDC 捕获变更
变更以 Protobuf 消息投递到 Kafka
Data Ingestion 调用 Schema Registry 校验数据格式
校验通过后写入 Doris 的三张基础表
变更事件通过 Kafka 推送给 Audit Service 记录审计日志
变更事件触发 Derived Property 的级联重计算
计算结果通过 Ontology Runtime 回写
最终变更触发 Action Engine 执行业务副作用（通知、审批等）

#7. 与主流架构模式的比较

#7.1 对比表

维度	微服务	单体	模块化单体	8 Layer
部署单元	每服务独立	单进程	单进程	3 进程
代码隔离	仓库级	包级	模块级	Layer 级
通信	HTTP/gRPC	方法调用	方法调用	gRPC + 进程内
技术异构	完全自由	单栈	单栈	按 Layer 选型
团队自治	高	低	中	高
运维复杂度	高	低	低	中
数据一致性	最终一致	强一致	强一致	混合
独立扩缩	完全	不可能	不可能	Layer 组级

#7.2 我们的定位

分层架构本质上是一种 "带技术异构的模块化多体" 模式：

它有微服务的技术异构优势（Java / Python / TypeScript）
它有模块化单体的部署简洁性（3 个进程而非 20+ 个）
它有独特的 gRPC 契约边界（64 个 proto 文件定义所有交互）
它支持按需拆分（如果 Reasoning & Decision Layer 成为瓶颈，可以独立部署）

#7.3 为什么不是纯微服务？

Code

纯微服务架构（假设场景）:

  schema-registry-service     (独立进程)
  auth-service                (独立进程)
  world-manager-service       (独立进程)
  ontology-runtime-service    (独立进程)
  query-federation-service    (独立进程)
  data-ingestion-service      (独立进程)
  reasoning-engine-service    (独立进程)
  decision-engine-service     (独立进程)
  action-engine-service       (独立进程)
  pipeline-engine-service     (独立进程)
  audit-service               (独立进程)
  lineage-service             (独立进程)
  ... (20+ 个)

问题：
  - 每个请求平均跨越 4-5 个服务 = 4-5 次网络往返
  - 分布式事务无处不在
  - 小团队（< 10 人）无法承受运维成本
  - 本地开发需要启动 20+ 个容器

#7.4 为什么不是单体？

单体架构的致命问题在于 技术栈锁定：

Reasoning & Decision Layer + Agent Runtime Layer 的推理和 AI 能力需要 Python 生态（PyTorch、LangChain、scikit-learn）
Control Layer + Data Layer 的企业级服务需要 Java 生态（Spring Security、Quarkus）
SDK & Developer Experience Layer 的 OSDK 需要 TypeScript

你不可能用一种语言覆盖所有场景。

#8. 架构决策记录（ADR）概要

以下是与分层架构相关的关键架构决策：

ADR	决策	状态
ADR-001	采用 Apache Doris 作为统一存储引擎	已采纳
ADR-002	Project-World 层级管理	已采纳
ADR-009	Python Layer 合并（D+E → onto-intelligence）	已采纳
ARCH-001	Java 服务整合（B+G → onto-control, C+F → onto-data）	已采纳
ARCH-002	物理部署从 8 进程简化为 3 进程	已采纳

#9. Layer 交互频率分析

通过分析 64 个 proto 文件的依赖关系，我们可以得到 Layer 间的调用热度图：

Code

调用频率矩阵（每秒请求数估算）:

            B       C       D       E       F       G
      +-------+-------+-------+-------+-------+-------+
  B   |   -   |  500  |   50  |   30  |   20  |  100  |
      +-------+-------+-------+-------+-------+-------+
  C   |  200  |   -   |  300  |  100  |  150  |   50  |
      +-------+-------+-------+-------+-------+-------+
  D   |   30  |  400  |   -   |  200  |   10  |   20  |
      +-------+-------+-------+-------+-------+-------+
  E   |   50  |  200  |  150  |   -   |   30  |   40  |
      +-------+-------+-------+-------+-------+-------+
  F   |   20  |  300  |   10  |    5  |   -   |   80  |
      +-------+-------+-------+-------+-------+-------+
  G   |   30  |   50  |   10  |   10  |   30  |   -   |
      +-------+-------+-------+-------+-------+-------+

最热路径:
  B <-> C : 700 req/s  (Schema 校验 + Ontology 查询)
  C <-> D : 700 req/s  (派生属性计算 + 数据读取)
  D <-> E : 350 req/s  (推理触发 Action)

这个调用频率分析正是 ARCH-001 合并决策的数据依据——将调用最频繁的 Layer 合并到同一进程，将跨进程 gRPC 调用转化为进程内方法调用。

#10. 未来演进路径

#10.1 弹性拆分

当平台规模增长到一定程度，可以选择性地将某些 Layer 独立部署：

Code

Phase 1 (当前): 3 进程
  onto-control.jar (B+G)
  onto-data.jar    (C+F)
  onto-intelligence (D+E)

Phase 2 (中期): 4 进程
  onto-control.jar (B+G)
  onto-data.jar    (C)
  onto-pipeline.jar (F)        <-- 拆分 Pipeline 独立
  onto-intelligence (D+E)

Phase 3 (远期): 5 进程
  onto-control.jar (B+G)
  onto-data.jar    (C)
  onto-pipeline.jar (F)
  onto-reasoning   (D)         <-- 拆分 Reasoning 独立
  onto-agent       (E)         <-- 拆分 Agent 独立

因为 Layer 间的通信始终通过 gRPC 契约，所以拆分是零代码改动的——只需要修改部署配置和服务发现地址。

#10.2 云原生演进

Code

Docker Compose (Dev)
     |
     v
Kubernetes (Staging/Prod)
     |
     v
Kubernetes + Karpenter (Auto-scaling)
     |
     v
Serverless Reasoning & Decision Layer + Agent Runtime Layer (Function-as-a-Service)

#Key Takeaways

Layer 是工程责任域，不是微服务。8 Layer 的划分基于问题域分解，而非技术分解。每个 Layer 拥有独立的技术选型权和架构师负责制，但在物理部署上合并为 3 个进程以降低运维成本。
"逻辑解耦、物理内聚"是核心策略。通过 gRPC 契约保持 Layer 间的逻辑独立性，同时通过进程合并获得性能和运维优势。64 个 proto 文件是架构的"宪法"——它们定义了一切交互边界。
WorldContext 贯穿一切操作。这不是一个可选参数，而是平台的基本假设：不存在脱离世界分支上下文的操作。这个设计决策使得分支隔离、时间旅行、场景推演成为平台的一等公民能力。

“

下一篇预告: [S2-02] 为什么我们选 gRPC 而不是 REST？内部通信设计决策——深入 64 个 proto 文件的组织方式、Protobuf 契约驱动开发工作流、跨语言代码生成管线，以及 REST Gateway 如何作为外部门面。

Tags: #ontology #architecture #palantir #Layer #grpc #modular-monolith #coomia-dip #智策平台