aPaaS设计思考
一、概述
本文基于团队在开发aPaas过程中的讨论及实践经验以及对网上相关aPaaS资料的学习，总结整理而成，着重介绍有关aPaaS平台设计方面的一些思考。
根据Gartner的定义，aPaaS是基于PaaS的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。
简而言之，aPaaS是让用户能自己开发应用程序的一个服务平台，其目的是为了提高应用研发的交付效率。关于aPaaS是否真能提高交付效率网上其实是有争议的，但本文旗帜鲜明地持肯定意见，这源于我对软件工程及aPaaS的下述几个基本理念。
- 效率因素：软件工程领域的效率提升源于技术变革和分工细化两个方面。
- 本质变化：aPaaS本质上是一种新的开发方法，而不是一种新技术，带来的是分工的细化而不是技术的变革。
- 力量来源：aPaaS开发应用的方式极大利用了软件专业领域的技术积累和非专业人士关于软件的知识沉淀。
二、模型设计
模型是表达设计构思的好工具，在开始设计aPaaS平台前，我们首先对要建设一个什么样的aPaaS要有一个统一的认知，这个认知建立在一些基本的概念之上，可以称之为概念模型。概念模型可以看做是设计草图或设计大纲，是对我们脑海中想象的设计对象的最粗略描述，是设计者、实现者、使用者所达成的第一份共识。
（注意，本文中的“概念模型”一词有别于数据库设计领域中所说的概念模型。 ）
概念模型
aPaaS概念模型.png
清晰明确的概念模型及对概念的解释是后续设计的基础，也是在团队协作中保障概念完整性的必要手段。下面是我对模型中涉及的aPaaS相关概念的理解：
- aPaaS平台
平台是一个系统，由一系列工具和服务组成。aPaaS平台包含了创建应用的工具、支撑aPaaS应用运行的服务及底层数据存储、网络、硬件等基础设施。
- 应用（App）
应用的全称是应用程序，在aPaaS平台上创建出来的应用程序，其运行依赖于aPaaS平台提供的服务，应用可分为普通应用和SaaS应用。
- 租户
租户是指租赁使用一个系统或平台的用户，租户通常是一个机构。在aPaaS上，租户可自建应用，也可以选用服务供应商创建的应用，不同租户的应用和数据应彼此隔离。
- 服务供应商（Service Provider，SP）
服务供应商指专门开发应用给aPaaS租户使用的特殊机构，SP开发的应用一般为SaaS类应用，对应的租户自建的应用可称之为普通应用或私有应用。
- SaaS应用
SaaS应用指一个SaaS系统，一个SaaS应用可以给不同的租户使用。
- 应用池
应用池是指所有应用的集合，包含普通应用和SaaS应用，应用池由aPaaS平台统一管理。
三、架构设计
架构设计的目标是为系统提供一个蓝图，用于指导后续的详细设计和实现开发等各方面工作。一个完整详实的架构应该从多方面视角进行描述，常用的方法有4+1视图、五视图法等。然而实际工作中大家往往只用一张图来表达架构，其侧重点也因人而异，并没有事实上的统一标准。
本文我用逻辑架构和系统架构两张图来表达对aPaaS架构的设计构思。
（一）逻辑架构
逻辑架构更多面向用户和产品人员，主要从功能职责的角度对系统进行模块化设计，并阐述各模块之间的逻辑关系。
aPaaS逻辑架构.png
逻辑模块说明
- 平台门户
这是用户了解并接触aPaaS平台的入口，是平台对外的门户网站。用户在未登录状态下应该可以看到到平台的能力介绍、应用市场、帮助文档等内容。
- 应用搭建环境
这是用户基于aPaaS平台搭建应用的集成开发环境（IDE），通常实现为一个基于Web的拖拽式的设计器。用户在这里设计应用的页面、数据模型，预览设计结果，最终打包发布，便完成了应用的搭建。
- 租户/SP管理后台
这是租户或SP对其在平台上资源和信息进行管理的后台，例如查看、启用、禁用创建的应用，管理应用的用户、数据、权限，编辑查看租户的注册信息等。
- 运营管理后台
这是平台的运营或管理人员对平台本身进行管理的后台，例如管理租户、应用、IDE、服务器资源等。
- 身份服务
身份服务负责平台的注册登录、角色权限管理、租户的组织人员信息维护等。身份服务可以实现为IAM或IDaaS，它是构成aPaaS平台的基础部件。
- 应用运行环境
这是支撑aPaaS应用运行的一组服务，如负责绘制应用界面的渲染引擎、保障应用流程正确执行的流程引擎、以及对应用运行进行监控管理的监控和日志模块等。
- 应用服务
这是用于管理应用元数据的一组服务，如查看或修改应用的基本信息、配置信息，按条件获取应用或应用模板等。模块1~4中应该相关的功能将依赖此服务。
- 数据服务
这是一组负责平台所有数据的读写、搜索、或分析的服务。
- 权益服务
这是有关租户付费权益的服务，负责平台付费功能的开通、关闭、计费等。
（二）系统架构
系统架构面向开发和测试人员，主要从技术角度对系统水平和垂直拆分，描述组成系统的前端程序、后台服务、子系统、中间件等之间的关联依赖关系。
aPaaS系统架构.png
系统模块说明
- 应用层
应用层细分为前端、网关和API三层，前端通常是基于Web技术实现运行于浏览器中，因此本层也可以称之为Web层。但也可以基于小程序、移动端等技术实现前端层。前端的模块主要按产品功能划分，其中的组件、模块可能不止一个，X前端代表其他前端模块。
- 服务层
服务层是负责业务处理的一层，按业务功能进行模块划分，各模块不应定与API层一一对应，一个API模块按需可以依赖多个服务。
- 数据层
数据层是存储数据的一层，分为在线数据和离线数据。
- PaaS层
PaaS层通常是一个云计算平台，包含了数据库、操作系统、虚拟化、网络代理等一系列基础设施。
四、实现设计
实现设计是对架构的实现方案和实现过程的设计。实现方案要根据团队现状、企业基础设施、项目工期、未来规划等约束条件进行技术选型，确定技术实现方案、输出系统的技术架构。实现过程是要对架构中的模块进行优先级排序，制定架构实现的里程碑，有时甚至要对部分模块进行过渡方案的设计，因为任何系统的实现都不是一撮而就的，架构的落地应该是一个逐步满足产品需求的循序渐进的过程。
基于上述原因，本文暂不提供具体的实现设计，但分享几个在实现系统架构时的注意事项。
（一）概念完整性
概念完整性有时也称作概念一致性，指的是在概念的传递过程中确保概念不被曲解、所有人都对同一概念有相同的理解。可以类比数据安全三要素之一的数据完整性来理解。在系统设计的任一阶段，都会引入很多概念，概念完整性是确保设计被准确实现的重要基础。
（二）康威定律
康威定律是马尔文康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。” 简单来说就是，有什么样人员组织结构就会设计出什么样的系统架构。后来康威定律逐渐演变为四个定律：
- 第一定律 组织沟通方式会通过系统设计表达出来。
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。
- 第四定律 大的系统组织总是比小系统更倾向于分解。
（三）演化原则
有句话叫“好的架构是进化出来的，不是设计出来的”。虽然本文给出的设计更多是基于理性模型，但这不代表我认可设计中的理性主义。设计中的理性主义者认为良好的教育、成熟的经验和足够细致的思考能让设计者创造出完美的作品。与之相对的，设计的实证主义者则认为，人都优缺点、总是会犯错的，因此设计工作就应该是一个在实践中不断找寻缺陷并在下一次迭代中改进提升的过程。相信大部分人都会选择实证主义的吧。
参考资料
- 产品领域的元宇宙：aPaaS产品解构
http://www.woshipm.com/pd/5224337.html - 一文讲透APaaS平台是什么
https://blog.mingdao.com/11411.html - 腾讯ToB，“千帆计划”进化
https://www.leiphone.com/category/CorporateServices/iuLnjB7Qgnt4FcOu.html - 什么是IDaaS
https://help.aliyun.com/document_detail/408885.html - 阿里低代码引擎和生态建设实战及思考
https://mp.weixin.qq.com/s/MI6MrUKKydtnSdO4xq6jwA - 《设计原本》（图灵奖得主、《人月神话》作者经典著作）
