云原生PaaS服务平台对象模型思考

　　在前面谈云原生技术解决方案和PaaS平台的时候，更多都是从技术平台层面进行阐述，如果真在要转变为面向多租户的PaaS服务平台，那么就需要一个完整的底层对象模型支撑。因此今天简单谈下PaaS服务平台的对象模型和关键对象之间的关系。多租户和面向应用开发者
　　对于PaaS服务平台来说本身应该是多租户架构。
　　这里的租户实际是应用开发商，应用开发商可以是一个大的企业或组织，也可能是一个独立的开发者，每个开发商应该分配独立的租户ID。
　　各个租户之间应该做到完全的资源和数据的隔离。
　　当开发商申请了PaaS云服务后，成为一个独立的租户可以进行开发商内部的团队管理。在这里简化为开发商可以简单独立的开发团队，维护每个开发团队里面的成员。
　　一个租户可以建立多个开发团队。一个开发团队可以有多名成员，同一个成员可以同时属于多个开发团队。
　　一个开发团队可以开发多个应用，这里的应用类似传统的单体应用系统。
　　一个应用本身有可以分解为多个微服务模块，实际上在云原生PaaS平台下，最终进行持续集成，部署交付的都是微服务模块。每个微服务都独立进行构建和部署交付。多个微服务模块构成一个完整的大应用系统。地域-可用区
　　地域容易理解，本身数据中心资源就分布在不同地域。比如内蒙数据中心和贵州数据中心，那么就是独立的两个地域。
　　每个地域数据中心内部还可以进行分区，每个区可以有独立的电力和网络设备做到进一步的物理隔离，但是又确保可用区之间能够互联互通。当然也可以为大型集团企业提供独立的VPC专用网络。
　　在可用区划分后，还可以在单个可用区划分不同的工作空间，工作空间类似于环境的概念。比如一个软件应用的研发涉及到不同的阶段和环境，如开发环境，测试环境，正式的生产环境，那么可以为不同的环境设置不同的工作空间。
　　工作空间之间也做到相互独立。通过工作空间实现资源分组隔离。
　　但是工作空间本身可以跨越多个可用区。应用-工作空间-集群
　　一个微服务模块可以对应多个工作空间，比如开发环境工作空间，测试环境工作空间，生产环境工作空间。
　　一个微服务最终要通过k8s集群进行部署，因此工作空间和集群之间有对应关系，两者可以理解为多对多的对应关系。
　　一个工作空间本身可以对应多个集群，按照阿里云的解释是因为一个 Workspace 只能对应到一个 VPC， 所以多个 Cluster 必须属于相同的 VPC。其次一个Cluster集群本身也可以为多个工作空间服务，比如开发空间和测试空间同时使用一个集群进行部署。
　　在公有云下，一个租户可以申请多个集群，但是一个集群只能够属于一个租户，难以在租户层面做到完全隔离。但是在私有云架构里面，一个集群往往可以为多个租户服务。
　　根据阿里云的说法，在PaaS的核心领域模型中，不再尝试定义＂环境＂这个模型，因为环境的概念在不同组织的研发协同流程中定义是不一致的，所以环境可以根据当前的PaaS领域模型组合搭建。
　　也就是说通过工作空间来弱化了环境。
　　对于大部分情况来说，一个 Workspace工作空间就是一个环境。但是，实际上一个环境也可以由多个 Workspace 组成。典型的场景就是一个开发商开发的应用同时部署在内蒙和贵州两个数据中心的资源池，都是生产环境。这个时候实际对应了内蒙和贵州两个工作空间。因为工作空间的概念本身是不跨Region的。工作空间（Workspace）的核心是一组不受网络连通性束缚的资源边界。
　　一个应用本身是可以跨地域的，同时一个地域本身也可以部署多个应用，因此应用和地域之间本身是一种多对多的关系。但是应用和地域没有直接建立关系，而是通过工作空间，可用区间接建立勾稽关系。PaaS平台多租户模型
　　上图为Gartner的多租户参考架构
　　在私有云和公用云环境对多租户的理解上是有不同的概念的。在公用云环境往往我们谈的是saas的多租户，租户往往为使用业务系统的一个企业或组织，而在私有云环境，paas平台提供的应用往往为平台级应用，平台级应用面对的租户是业务系统本身。
　　在多租户和云结合的情况下，iaas基础资源层的共享已经会变化为最基本的要求。那么在iaas层之上来谈主要则包括两个方面的内容，即应用是一套还是多套？数据库是一套还是多套？最彻底的多租户即上图中的第6种share everything的模式，在这种模式下数据库和应用都为一套，但是在paas平台下满足水平弹性扩展的需要。
　　多租户我们首先考虑隔离，在多租户下的隔离包括了几个方面的内容：
　　一个是系统本身元数据和基础主数据的隔离（用户，角色，权限，数据字典，流程模板），系统运行过程中产生的动态数据的隔离，一个是业务系统底层所涉及到的计算资源和存储资源的隔离。
　　在应用一套，数据库多套或多schema分离情况，我们比较容易实现计算资源和存储资源的单独分配，但是在完全share everthing的情况下，对于计算和存储资源的隔离则需要我们的paas应用本身去考虑。比如我们会引入实际的中间件容器的概念，可以将计算资源或存储资源分配给中间件容器，各种资源的使用严格区分。
　　在私有云下的多租户，往往隔离又不是绝对的，在能够完全隔离的情况下又需要支撑跨租户或组织的数据共享，可以看到如果存在这种需求，在share everthing的情况下是比较容易满足的。
　　多租户除了隔离外，另外一个重点就是能够为各个租户按需要实时地提供各种计算资源和存储资源，而且有清楚定义的数据采集和计费模型。由于资源池是共享的，我们必须要能够准确地采集到各个租户对实际资源的使用情况，以方便进行多租户的计费。
　　在公用云下的多租户，如果采用完全共享的模式，还必须考虑数据库的可扩展性，多租户架构服务提供独立数据库、扩展表和大表（保留字段）三种多租户架构，开发者可以通过API创建和管理多租户架构。独立数据库模式为每个租户分配一个独立的数据库；扩展表模式将租户的数据保存在扩展表（竖表）中，通过表记录扩展租户的配置信息；大表模式采用大表（横表）保存租户信息，租户的个性化信息保存在大表的保留字段中。
　　对于共享数据库模式，其多租户架构实现的核心是所有数据库表都需要增加租户ID字段对数据进行多租户隔离，以保障某一个租户登录系统只能够看到自己租户下的相关信息。如果是一个完整的多租户应用，还需要考虑第二层按用户，组织，角色群组等进行第二级的数据隔离，以满足业务系统的使用需求。