企业官网建设流程全解析

• 后端
• 数据库
• GraphQL

本指南基于 Prisma 1.x 开源仓库的官方 FAQ 文档（docs/1.13/05-FAQ/03-Prisma-Cloud.md），系统讲解 Prisma Cloud 中 Workspace、Prisma Server、Service 三者的组织关系，覆盖三种服务器类型（本地自托管 / Demo / 私有）、团队权限、多环境部署、免费额度、数据库连接与备份策略等核心问题。读完本文，你将理解prisma deploy背后"选服务器 → 选工作区 → 写 endpoint"的完整机制，并能依据仓库源码判断每个配置项的真实行为与适用前提。

Workspace 是什么：Prisma Cloud 的组织单元

原 FAQ 用一个很形象的类比解释了 Workspace 的概念：可以把 Workspace 粗略理解为类似 GitHub Organization 的组织容器，它是个人账号、Prisma Server 与服务（Service）的集合。官方文档给出的三条关联规则如下：

• 一个 Workspace 可以关联多个个人账号，一个个人账号也可以加入多个 Workspace（多对多关系）。
• 一个 Workspace 可以关联多个 Prisma Server，但一个 Prisma Server 永远只属于恰好一个 Workspace（一对多关系）。
• 由于一个 Prisma Server 可以承载多个 Service，因此一个 Workspace 可以间接关联多个 Service。

注意：FAQ 中提到的"Prisma Server"均特指在 Prisma Cloud 中创建的私有 Prisma Server，对于自托管（self-hosted）服务器和 Demo 服务器，上述部分规则并不成立——例如自托管服务器并不隶属于任何 Workspace。

Workspace 的存在直接体现在服务的 endpoint 结构中。从源码看，CLI 会在校验配置时强制要求共享集群（shared cluster）携带 workspace slug：在 cli/packages/prisma-yml/src/PrismaDefinition.ts 的validate()方法中，若cluster属性缺少 workspace slug 会直接报错，并提示合法的 Demo endpoint 格式为：

https://eu1.prisma.sh/myworkspace/service-name/stage-name

也就是说，endpoint 中的myworkspace段正是 workspace 的唯一标识。在 cli/packages/prisma-yml/src/Cluster.ts 的getApiEndpoint()中，可以看到 workspace slug 如何拼入最终 API 地址：

${baseUrl}/${workspaceSlug}/${service}/${stage}

从源码结构看，Workspace 是一个"逻辑命名空间"：它把用户、服务器和服务归并到同一隔离域下，从而保证不同 Workspace 之间的服务即使同名也不会冲突。

团队成员的权限管理现状

关于权限，FAQ 的回答非常直白：目前（该文档编写时）所有被邀请加入 Prisma Cloud 项目的团队成员都拥有完整访问权限，更细粒度的访问与权限管理功能当时仍在规划中（"coming soon"）。

这一点对团队协作的实操含义是：如果你邀请同事加入同一个 Workspace，他默认就能访问该 Workspace 下所有私有服务器上的全部服务，因此在生产环境共享 Workspace 时应当谨慎。细粒度的角色划分（只读 / 只写 / 按服务授权等）在当时的版本中并不存在，需要依赖其他手段（例如为服务配置secret来保护管理 API，或使用PRISMA_MANAGEMENT_API_SECRET环境变量做服务端鉴权）来补充安全边界。

Prisma Server 与 Prisma Service：运行时与部署单元

两者关系

Prisma Server 是零个或多个 Prisma Service 的运行时环境（runtime environment）。要部署一个 Prisma Service（执行prisma deploy命令），前提是有一个可用的 Prisma Server。这在部署命令源码中可以得到印证：cli/packages/prisma-cli-core/src/commands/deploy/deploy.ts 的run()流程为——读取prisma.yml→ 解析 service 与 stage → 通过EndpointDialog选择集群 →initClusterClient→ 检查项目是否已存在 →addProject→ 真正执行deploy迁移。

三种 Prisma Server 类型

FAQ 把 Prisma Server 分为三类，这是理解整个部署模型的关键：

Demo 服务器与私有服务器在仓库源码中被建模为 Cluster 对象的不同属性。在 cli/packages/prisma-yml/src/Cluster.ts 中，Cluster类拥有local、shared、isPrivate、workspaceSlug等布尔/字符串属性，分别标记"本地的 / 共享的（Demo）/ 私有的 / 所属工作区"。两个 Demo 集群（prisma-eu1、prisma-us1）的固定端点定义在 cli/packages/prisma-yml/src/constants.ts：

export const clusterEndpointMap: { [key: string]: string } = { 'prisma-eu1': 'https://eu1.prisma.sh', 'prisma-us1': 'https://us1.prisma.sh', }

而 cli/packages/prisma-yml/src/Environment.ts 则用sharedClusters: string[] = ['prisma-eu1', 'prisma-us1']将其标记为共享集群，并在登录后通过 Cloud API 的prismaCliGetClusters查询（见 Environment.ts）拉取当前 Workspace 下的全部集群列表（含私有集群及其 endpoint）。

从命令行视角理解三种服务器

在交互式部署时，CLI 会引导用户做出选择。相关逻辑集中在 cli/packages/prisma-cli-core/src/utils/EndpointDialog.ts 的getClusterQuestion()：它会提供

• Use existing database / Create new database：走本地 Docker 路线（对应自托管）；
• Demo server + MySQL database：免费 Demo 环境（未登录时会先要求登录，见getDemoCluster()，对应源码 EndpointDialog.ts）；
• Use other server：手动输入任意运行中 Prisma Server 的 endpoint（对应自托管/自定义服务器）。

选择 Demo 服务器后，CLI 会先 ping 两个区域并展示实测延迟（EU_WEST_1对应demo-eu1，US_WEST_2对应demo-us1，见 EndpointDialog.ts），方便你按地理位置选择延迟更低的区域。这与教程 docs/1.13/03-Tutorials2/01-Setup-Prisma/01-Demo-Server.md 中"选择demo-eu1或demo-us1"的指引一致。

多阶段（Multi-staging）开发工作流

多环境（dev/staging/prod）是团队开发的标准诉求。FAQ 给出的核心结论是：

1. 多个阶段可以共用同一个 Prisma Server：因为一个 Server 能承载多个 Service，你可以把代表不同阶段/环境的 Service（如dev、staging、prod）部署到同一台服务器上，并非必须为每个阶段单独开一台服务器。
2. 生产环境强烈建议独占服务器：为了确保dev或staging上的任何操作都不会对prod产生负面影响，推荐把生产环境部署到独立的 Prisma Server上。理想情况下，其他阶段/环境也各自独占一台，以最小化相互影响的风险。
3. 开发环境可灵活选择：本地 Prisma Server 或 Prisma Cloud 的 Demo 服务器都可以按需充当开发环境。

从源码看，一个 Server 承载多阶段服务是天然支持的：服务名（service）+ 阶段名（stage）共同决定唯一 endpoint（getApiEndpoint()中${baseUrl}/${workspace}/${service}/${stage}的拼接逻辑，见 Cluster.ts 对应的 Cluster.ts），因此在同一服务器上部署myservice/dev、myservice/staging、myservice/prod互不干扰。

部署时的具体行为还受 deploy 命令参数影响。在 cli/packages/prisma-cli-core/src/commands/deploy/deploy.ts 中可以看到常用的阶段运维参数：

免费版本：Demo 服务器的限制与适用边界

FAQ 明确回答了"Prisma Cloud 是否有免费版本"：部署到 Demo 服务器是免费的，但必须清楚它的两个硬性限制：

• 速率限制（rate limit）：约 10 次请求 / 10 秒；
• 存储上限（storage bound）：约 100 MB。

因此 Demo 服务器只适合学习、原型验证与开发用途。任何生产使用场景都应该使用自托管服务器或私有 Prisma Server。注意要使用 Demo 服务器，前提是拥有 Prisma Cloud 账号（FAQ 原话：you need a Prisma Cloud account to deploy to a Demo server）。

这一点在源码中有直接呼应：未登录时getDemoCluster()会先调用this.client.login()完成登录再继续（EndpointDialog.ts）；而在部署到非公开集群（即私有集群）时，deploy 命令会校验登录态或PRISMA_MANAGEMENT_API_SECRET，否则触发登录流程（deploy.ts）。会话凭据（cloudSessionKey）会持久化到用户主目录的~/.prisma/config.yml，见 Environment.ts 的saveGlobalRC()。

如何连接数据库

FAQ 的关键结论是：每个 Prisma Server 只被一个数据库支撑（未来才支持同一 Server 连接多个数据库），且数据库是在 Server 初次创建时绑定的，之后不能随意更换。

也就是说，"连接数据库"这个动作发生在创建私有 Prisma Server 的那一步，而不是部署服务时。创建时你需要提供数据库连接信息。在 CLI 的交互流程中，DatabaseCredentials接口（见 EndpointDialog.ts）定义了收集的凭据字段：

export interface DatabaseCredentials { type: DatabaseType // mysql | postgres | mongo | sqlite host?: string port?: number user?: string password?: string database?: string schema?: string ssl?: boolean uri?: string // Mongo 使用连接串 }

各数据库类型的默认端口在 EndpointDialog.ts 中有定义：PostgreSQL 5432、MySQL 3306、MongoDB 27017。选择"Create new database"时，CLI 还会自动生成对应的docker-compose.yml数据库服务定义（Postgres / MySQL 5.7 / MongoDB 3.6 的镜像与prisma/prisma默认凭据，见 EndpointDialog.ts）；选择"Use existing database"时，则会先通过connector.listSchemas()验证连接、再决定走 introspection（已有数据）还是使用默认 datamodel（空库），相关流程见 EndpointDialog.ts。

自动备份：Prisma 只做"数据库之上的那一层"

FAQ 对备份问题的回答体现了 Prisma 的架构定位：Prisma 只是运行在你数据库之上的一个层（a layer on top of your database），数据库本身始终由你完全掌控。因此：

• 你拥有备份策略的全部主动权与灵活性——备份/恢复仍然走你熟悉的数据库原生能力（如 MySQL 的 mysqldump、PostgreSQL 的 pg_dump、云厂商快照等）；
• 无论使用自托管、Demo 还是私有服务器，Prisma 本身并不替你管理数据库快照；
• FAQ 提到，未来 Prisma Cloud 计划简化备份工作流，例如支持自动的时间点恢复（point-in-time restores），但这在当时属于规划中的能力，不能视为现有功能。

这一"薄层"定位同样体现在架构上：服务端各数据库连接器独立实现（仓库中server/connectors目录下分别有 api-connector-jdbc、api-connector-mongo、api-connector-mysql、api-connector-postgres、api-connector-sqlite 等连接器模块），Prisma 负责把 GraphQL API、数据模型与具体数据库对接，而底层数据的持久化、备份与恢复仍属于数据库本身的管理职责。

快速实操：从零把服务部署到 Prisma Cloud

结合上面的概念，这里给出一个端到端的最小实操路径（依据教程 docs/1.13/03-Tutorials2/01-Setup-Prisma/01-Demo-Server.md 与 CLI 源码整理）：

第 1 步：安装 CLI

npm install -g prisma # 或 # yarn global add prisma

第 2 步：初始化服务

prisma init hello-world

CLI 会询问使用现有 Prisma Server 还是新建一个。选择Demo server后，若未注册 Prisma Cloud，浏览器会打开注册页；登录后选择区域（demo-eu1或demo-us1，CLI 会显示实测延迟），再连续按两次 Enter 确认服务名与 stage 的默认值。

第 3 步：查看生成的配置

目录下会生成prisma.yml与datamodel.graphql，典型的prisma.yml内容为：

endpoint: https://eu1.prisma.sh/alice-doe-fd2dcf/hello-world/dev datamodel: datamodel.graphql

其中alice-doe-fd2dcf是你 Prisma Cloud Workspace 的 ID（每人不同），hello-world是服务名，dev是 stage——三者共同构成最终 API endpoint。

第 4 步：部署与更新

prisma deploy # 部署（首次部署会自动建库建表） prisma deploy --force # 接受 schema 变更可能造成的数据丢失 prisma deploy --dry-run # 预演，不真正应用

部署成功后，服务即运行在所选 Server 上：Demo 服务器免费但有速率与存储上限，私有服务器则连接你自己提供的数据库。

小结

Prisma Cloud 的体系可以一句话概括：Workspace 是组织边界，Prisma Server 是运行单元，Service 是部署单元，数据库在创建 Server 时绑定。FAQ 文档明确了多阶段部署"可共享服务器、生产建议独占"、Demo 免费但有 10 次/10 秒与 100 MB 限制、备份完全交由数据库原生策略等关键结论。在仓库源码层面，这些规则分别落实在 Cluster.ts、Environment.ts、constants.ts、PrismaDefinition.ts 以及 EndpointDialog.ts 与 deploy.ts 中，理解这些实现细节有助于你在真实项目中准确判断部署行为与配置边界。

• 后端
• 数据库
• GraphQL