本篇介绍了蚂蚁 PaaS 平台的基本概念与核心领域模型，同时也对阿里云的 IaaS 核心模型进行了阐述，希望对想要初步了解蚂蚁 PaaS 平台技术架构的用户提供入门指引。
蚂蚁 PaaS 平台介绍
蚂蚁 PaaS 平台是蚂蚁业务全球化输出的技术支撑平台，PaaS 平台的领域模型定义，是 PaaS 层产品技术最核心的架构规范。蚂蚁 PaaS 平台作为金融科技商业化输出的底盘（商业化品牌名为 SOFAStack CAFE）提供了以应用为核心的研发、运行、运维全生命周期能力支撑。
IaaS 层核心领域模型与概念
地域（Region）与可用区（Availability Zone，AZ）
阿里云上的基础物理拓扑包括地域（Region）和可用区（Availability Zone），它们是阿里云的两个核心领域模型。
地域 Region：物理的数据中心。地域通常以城市为单位，如杭州、上海、青岛、北京等，每个地域之间是互相物理独立和隔离的，如要互通则需要通过物理专线的方式打通。不同的 Region 提供的产品能力、安全与稳定性水位、资源价格有所不同。
可用区 Availability Zone/AZ：在同一地域内，电力和网络互相独立的物理区域。可用区之间网络互通，故障隔离。是否将实例放在同一可用区内，主要取决于对容灾能力和网络延时的要求。可用区通常也代指机房，即 IDC，两者概念相同。
说明阿里云划分地域和可用区的原因是考虑网络延时。相同地域的不同可用区之间的网络延时不超过 2ms。
金融地域（金区）：针对金融行业客户对安全水位有更高要求的场景，会提供完全隔离，并专门部署更高安全水位的云产品组合的地域，称之为金融地域（或金融区）。例如公有云有三个金融 Region 分别是：杭州金区（cn-hangzhou-finance）、上海金区（cn-shanghai-finance-1）和深圳金区（cn-shenzhen-finance-1）。
专用网络（VPC）
专有网络 VPC（Virtual Private Cloud）是您自己独有的云上私有网络。您可以完全掌控自己的专有网络，例如选择IP地址范围、配置路由表和网关等，您可以在自己定义的专有网络中使用阿里云资源如云服务器 ECS、云数据库 Redis 版和负载均衡 SLB 等。
VPC 定义了网络边界， 您可以更加方便地在云上自定义网络的规划和管理：您可以自定义虚拟路由器（vRouter）网段，配置路由表规则，也可以自定义虚拟交换机（vSwitcher），配置子网。
阿里云对 VPC 模型的限制如下：
一个 VPC 不可以跨 Region。
一个 VPC 只有一个 vRouter。
一个 vSwitcher 只能属于一个 AZ。
一个安全组可以包括不同 vSwitcher 下的 ECS。
PaaS 层核心领域模型
应用（Application）与应用服务（AppService）
为了方便金融级大规模分布式系统的研发运维，蚂蚁 PaaS 平台在阿里云基础资源之上抽象了“应用（Application）”和 “应用服务（AppService）” 的概念。
一个租户内的一套代码对应一个应用，应用有对应的技术栈、分组、分级等基础元信息。应用是 PaaS 平台的核心概念，蚂蚁研发运维体系都围绕着应用来展开，研发应用、发布应用、运维应用、监控应用等。
应用服务（AppService）是 CAFE 发布运维体系的核心模型，一个业务应用常常由多个应用服务组成。应用服务代表一个应用在一个工作空间的一次部署，部署时需要有应用镜像/发布包、应用配置、以及部署的资源。
例如针对多人开发同一个应用的场景，每个开发同学会拉出自己的代码分支部署在开发环境去部署，即在开发工作空间（Workspace：Dev）中，有三个同学开发测试部署同一个应用的不同分支（App：paycore），会产生三个不同的应用服务（AppService：paycore_dev1、paycore_dev2、paycore_prod）。每个应用服务可以部署在不同的服务器上，关联不同的基线配置。但对于生产环境，不允许一个应用在生产环境有多个不同的代码版本，安全隐患极大。
工作空间（Workspace）、地域（Region）与可用区（Availability Zone）
工作空间（Workspace）是 SOFAStack 提供的一种组织机制，用于将服务于不同目标、阶段的资源分组隔离管理。典型的使用场景是根据研发运维流程，为每一个阶段分配工作空间，例如单机房（即单可用区）的开发工作空间、双机房（即包括两个可用区）的生产工作空间。
Workspace 可以跨可用区，实现容灾能力，但必须在同一个地域内，跨地域的多个工作空间可以组成工作空间组（通过单元化架构支持）。
工作空间（Workspace）的核心是一组不受网络连通性束缚的资源边界。在阿里云，地域之间的网络默认不通，同时云产品也基本上是以地域为边界设置产品实例。例如：SLB 不可能跨地域挂载 ECS、VPC 不可以跨地域等。因此，我们设立工作空间模型的原因是希望在这个范围内的资源之间的关系不用考虑网络连通性所带来的复杂性问题。
在实现过程中，工作空间通过 RAM 实现访问控制的隔离，通过 VPC 和安全组实现网络隔离，或者通过分属不同的 Kubernetes 集群实现物理隔离，亦或是通过在同一个 Kubernetes 集群内的不同资源标签实现筛选管理。
相关操作请参见：管理工作空间。
应用（Application）与工作空间（Workspace）
应用是租户级别的概念，一个租户内的一套代码对应一个应用。应用不仅跨 Workspace 存在，也会跨 Region 存在。
应用服务（AppService）与工作空间（Workspace）
应用研发的生命周期中，研发人员经常会接触多个环境。我们一般可以认为，一个 Workspace 就是一个环境。但是，实际上一个环境，也可以由多个 Workspace 组成。
在 PaaS 的核心领域模型中，不再尝试定义“环境”这个模型，因为环境的概念在不同组织的研发协同流程中定义是不一致的，所以环境可以根据当前的 PaaS 领域模型组合搭建。
一个应用服务，并不受工作空间范围的约束，因为一个应用服务往往可能同时部署在多个工作空间，比如一个“生产环境”可能由多个工作空间组成。
但是，应用服务下的资源一定是属于某一个工作空间的，同一资源不能同时属于两个工作空间。
相关操作请参见：创建应用服务。
工作空间（Workspace）与专用网络（VPC）
每个工作空间只会对应到唯一一个 VPC，这是因为工作空间的核心表达是一组不受网络连通性束缚的资源边界的定义。
同一个 VPC 可以绑定到不同的工作空间中，这时 VPC 中的资源需要手动导入到工作空间中。
可以通过高速通道进行不同工作空间的 VPC 之间的打通。
多租户（Multi-tenant）
公有云 SOFAStack 是多租户（Multi-tenant）架构，各租户可以按照需要创建自己的工作空间，并且定义人员可以进行的操作权限。
SOFAStack 与阿里云的账号体系进行了深层次的融合：一个租户映射到一个阿里云的云账号（即主账户）上。每个用户，都是属于这个云账号下的子账号。
主账号：即阿里云云账号，可用于登录阿里云平台，具有 Root 权限，是阿里云独立的结算个体，通常由企业持有，独立负责阿里云侧的结算。
子账号：主账号下虚拟的子账号，可以创建任意多个，通常对应企业内的人或者系统。
相关操作请参见：RAM 主子账号授权、跨云账号授权。
PaaS 层扩展领域模型
为了支撑更加复杂的应用场景，金融云 PaaS 还定义了以下更高级的模型。
工作空间组（WorkspaceGroup ）
应用服务实例组（AppService Instance Group，AIG）
部署单元（Cell）
工作空间组（WorkspaceGroup ）
工作空间组（WorkspaceGroup）是工作空间（Workspace）在多地域的扩展，在多地域内对资源进行分组隔离管理。多个地域的网络可以通过专线高速通道实现互通。如生产工作空间组（WorkspaceGroup：prod），包含两个工作空间：上海生产工作空间（Workspace：prod_shanghai）、杭州生产工作空间（Workspace：prod_hangzhou）。
在 SOFAStack 控制台上，有些产品会支持以 WorkspaceGroup 视角进行操作：比如单元化应用服务 LHC、异地容灾产品、监控产品等。
相关操作请参见：创建工作空间组。
应用服务组（AppServiceInstance Group，AIG）
应用服务组（AIG） 用于圈定一组应用服务下的资源，是 Application 的一个更加细粒度的部署分片。
一个应用服务（AppService）不一定必须属于一个 AIG，但一定属于一个 Application。
有些业务场景下，我们需要对同一个应用（Application）从业务层面进行更细粒度的划分。例如，不同的业务都依赖同一个 Application，如何从一个业务的视角，对这个应用下的部署实例进行更细粒度的控制，比如部署隔离、流量分配等。因此在 Application 模型下，增加了 AIG 这个模型。
应用服务组（AIG) 与工作空间组（WSG）
AIG 可以跨 WSG。按照蚂蚁集团的经验，可以将一个 WSG 定义为一个环境。
AppService 可以跨 WS，但不可以跨 WSG。因为通常来说，一个 AppService 不可能包括两个“环境”下的资源，两个“环境”下的 AppService 往往意味着两种不同的基线配置。
部署单元（Cell ）
Cell 是发布部署要感知的最小部署单元。一个 Cell 一般会对应一个中间件配置中心。
Cell 不可以跨 AZ。
Cell 是实现同城双活、蓝绿发布、单元化架构的基础。每个 Cell 内可以理解为有一个逻辑独立的配置中心。
Unit 是 LHC 产品封装的模型，不是 PaaS 层核心领域模型。LHC 产品利用 PaaS 层的 Cell 模型对单元化架构中的逻辑 Zone 进行划分。
相关操作请参见：管理部署单元。
应用服务（AppService）与部署单元（Cell ）
一个 App 的 AppService 可以跨 Cell。适用于双机房双活及蓝绿发布场景。
一个 App 的 AppService 可以跨 Cell，也可以跨 Workspace，适用于异地多活单元化场景。
一个 App 可以创建多个 AppService 放到多个 Cell 内。适用于多分支独立研发场景及单元化场景（假设一个unit 内只有一个 cell）。
同一 App 创建多个 AppService 部署在同一个 Cell。适用于使用 sofaRouter 的联调场景，或者不依赖配置中心的普通 App 场景。
PaaS 层领域模型与 Kubernetes 领域模型映射
PaaS 发展到现阶段，与 Kubernetes 的关系越来越紧密，Kubernetes 是一个很好的技术平台，但是 Kubernetes 不等于 PaaS，PaaS 层的领域模型本质是为了 PaaS 产品提供的业务语义服务。
为了让基于 Kubernetes 实现的 SOFAStack 平台能够继承前面所述 PaaS 层领域模型支撑的复杂场景和架构。我们有必要对 Kubernetes 与 PaaS 层领域模型进行一定的规约和映射。
集群（Cluster）与租户（Tenant）
公有云与专有云上，Tenant 对一个 Kubernetes Cluster 有不同的约束：
公有云上的一个 Cluster 只能属于唯一一个租户，而一个租户可以有多个 Cluster。
专有云的一个 Cluster 往往是多租户共享的。
相关操作请参见：创建集群。
集群（Cluster），命名空间（Namespace）与工作空间（Workspace）
Cluster 与 Workspace 为多对多关系：一个 Cluster 可以被多个 Workspace 共享，一个 Workspace 也可以拥有多个 Cluster。
公有云：一个 Workspace 可以包含多个 Cluster。且因为一个 Workspace 只能对应到一个 VPC， 所以多个 Cluster 必须属于相同的 VPC。一个 Cluster 的集群管理，比如创建和初始化，都在 Workspace 内完成。
专有云：一个 Cluster 的集群管理，并不在 Workspace 内部完成，会由全局统一管理，将一个 Cluster 分配给一个 Workspace。
命名空间（Namespace）是对一组资源和对象的抽象整合。在同一个集群内可创建不同的命名空间，不同命名空间中的数据彼此隔离，使得它们既可以共享同一个集群的服务，也能够互不干扰。一个 Namespace 只能关联到一个 Workspace 中。
相关操作请参见：创建集群。