来源：今日头条/i6914469326074479108/之前讲API网关的时候讲到快速开发平台，就是把API快速开发的一些内容放到API网关里面。在实践中，它围绕API生命周期管理展开，它本身包括开发状态、运行状态和运维状态。对于API网关来说，更多的是解决运行状态的问题。API网关本身应该轻量级设计，不要做过多的协议转换、适配、数据映射等工作。这些任务应该在API开发平台上完成。API开发平台最终开发出来并暴露了一个标准的HttpAPI接口，并将该接口注册并连接到API网关。API全生命周期管理围绕API全生命周期管理，整个子系统划分如下：简单来说，这部分可以分解为四个子系统，分别是API开发平台、API网关引擎、API监控运维平台、API全生命周期管控平台。对于传统ESB总线中的适配器，协议转换等相关繁重的内容可以转移到API快速开发平台来完成，即API开发平台对外暴露标准的API服务接口，注册并连接到API网关引擎.对于API监控平台，从引擎采集日志信息，用于API性能监控和日志监控分析。API全生命周期管控平台实现了API接口从设计、开发、测试、部署到上线的全生命周期管理。也可以理解为底层三个子系统的统一管理入口，实现与以下三个子系统的集成。针对API开发平台开发配置的微服务API接口，可以支持自动部署到微服务运行平台。基于对象的建模驱动在整个API开发平台的实现中，核心思想应该还是基于对象的建模驱动。通过对象建模，很好的实现了接口、底层数据库、数据库表之间的解耦，也方便实现底层多数据库、多表的支持能力。目前很多API快速开发平台都是基于数据库对象或者表，直接发布类似CRUD的API接口服务。但是在直接发布数据库表的基础上，我们还是推荐反向对象层，方便后续在对象层进行相关组合。规则扩展等操作。对象建模和API接口契约可以直接在API开发平台上创建对象，定义数据项。该对象是一个多层树结构实体。一个对象可以生成多个表到数据库。对于已有的数据对象，也可以将它们组合起来形成复合对象结构。对象的好处是一个完整的对象属于同一个生命周期，可以一起用于事务控制。一个设计良好的对象可以默认生成标准的POST、GET、DELETE等接口操作方法。类似下图，整个对象接口契约的生成应该也是自动的。定义好的对象可以直接生成RAML、YAML、WADL等接口契约文件，与Swagger工具类似，完成的对象建模本身也可以直接导出不同语言不同开发框架下的客户端消费框架，服务端提供框架代码。将对象适配到数据库上面说了，可以直接由数据库逆向，也可以在对象建模完成后适配到数据库。完成对象与数据库表的映射。一个对象可以映射到多个数据库表，所以在映射过程中除了要完成数据库表和字段的映射外，还需要完成主外键关联的映射操作。完成对象模型与数据库表的映射适配后，基础版本的API接口已经可用。API接口发布对于完成的对象定义，您可以选择发布哪些API接口服务能力。比如只能选择发布查询接口，或者只能选择发布数据导入的POST接口等。注意API接口的发布，具体是基于全局对象建模，配置具体的需要发布到接口的数据项信息。很多时候，我们对数据对象的操作并不是对整个对象集合进行操作，而只是对某些数据项进行操作。API接口模拟测试验证可以对发布的API接口进行模拟测试验证，因此需要提供在线API测试工具，方便API接口的在线测试。同时，可以保存测试过的用例和测试数据。API接口文档生成支持自动生成API接口文档的功能。这个地方可以直接对接开源的Swagger等工具，实现API接口文档的自动生成功能。对象的常用接口操作对象定义完成后，可以根据对象自动生成相关的API接口。这里简单罗列一下常用的基于对象的接口方法，主要包括添加一条数据，根据主键更新、查询、删除数据。还有一些是基于条件查询对数据进行查询相关的操作。GtiHub中还有一个xmysql开源工具，可以直接将整个MySQL数据库中的数据库表发布为RestAPI接口，可以安装试用。npminstall-gxmysqlxmysql-hlocalhost-umysqlUsername-pmysqlPassword-ddatabaseNamehttp://localhost:3000注意需要提前安装Node.js，部分接口方法罗列如下：由于生成的API接口做没有相关权限控制，本开源工具仅用于自身测试验证。但是生成的方法和API可以作为API开发工具时的参考。实际上，对于API接口的生成，我们不建议所有复杂查询条件下的查询都通过GET方式实现。更好的想法是使用POST方法将查询条件作为POST输入进行处理。一次性生成复合对象，例如以订单为对象，实际包括订单表头和订单明细表，而基于订单对象的插入操作和查询操作可以通过API一次性生成生成。最终查询的是一个订单复合实体Json数据。对于订单插入，也是先准备好整个订单实体信息，调用一次API接口完成数据插入，也方便实现API接口时的交易控制。复合对象生成的API接口更类似于领域对象暴露的API接口服务能力。分页支持对于查询API接口服务的生成，需要支持分页能力，具体页面的大小，本次查询访问的具体页数等信息可以设置为API接口的查询输入参数.直接定义API接口并发布。上一节我们讲了基于对象发布API接口服务，但是还有一些业务规则逻辑接口，复杂的管理数据查询接口等，不能简单的通过对象自动生成。因此，也需要能够基于方法发布API接口服务。即API快速开发平台可以自定义API接口，详细定义API接口的输入参数和输出参数信息。同时，用于定义接口实现和后台方法的绑定。实现与JAR包中API接口的绑定您可以实现与JAR包中方法或函数的绑定，将方法或函数发布为HttpAPI接口方法。这种实现在目前很多公有云的云服务总线产品中都能看到。实现与动态SQL的绑定，可以将定义好的API接口方法与动态SQL进行绑定。其中，动态SQL本身有特定的动态输入参数，这些输入参数与API接口定义中的输入进行映射。同时将SQL语句查询的输出结果与API接口定义的输出字段进行映射。如果动态SQL是插入或更新类，也可以通过参数化变量来进行数据映射和绑定操作。与存储过程绑定数据库的存储过程实际上是一个方法函数，因此API接口定义的输入输出可以与数据库存储过程的输入输出进行映射绑定。需要注意的是，不同的数据库存储过程在schema信息的获取和适配上是有区别的，这也是为什么上图中要建立一个独立的统一数据库适配层的原因。规则处理在API接口开发过程中，可以进行一些简单的规则处理。具体如下：输入数据完整性检查，检查输入数据的完整性，包括场景的数据类型、长度、范围约束等，通过配置比较容易实现。数据项之间的规则处理可以对多个数据项进行简单的规则处理，包括场景数据映射、数据丰富、数据拦截等，这些也是主流的传统ESB总线产品所支持的。自定义脚本语言可以作为API快速开发平台本身的低代码开发平台的子类。因此，如果能够支持自定义脚本语言进行规则处理，那么整体的可扩展性和灵活性将得到极大的提升。消息头和输出预留，对于API开发平台发布的API接口，需要提前约定输入消息头、输出异常类型、异常代码、信息等字段。输入的消息头往往包含用户名、Token等访问安全验证的字段，以及路由、寻呼等相关的扩展字段信息。对于输出字段，需要约定返回的异常类型、编码、异常信息等，尤其是涉及到数据CUD操作时，需要按照约定的输出字段进行输出。服务组合与编排可以进一步为API开发平台提供服务组合与服务编排能力。该能力的实现不适用于API网关，需要在API开发平台上实现。服务组合编排就是服务组合、服务组装等，希望这些东西都可以通过服务编排来完成，而不是简单的完成单个服务的设计开发。它是将多个原子服务组合或组装在一起，形成一个新的服务并提供它的能力。让我们用一个例子来说明。比如有A、B、C三个原子服务，我们通过服务编排形成一个新的D服务。三个原子服务都是查询服务。我们希望组装一个新的服务，同时返回A、B、C三个服务的查询结果。这就是我们所说的服务组合能力。例如，我们可以查询合同的基本信息和合同条款信息。结合合约执行信息查询的三个基本原子服务，最终返回一个综合信息查询服务，一次返回三个查询结果。在这种场景下，我们需要考虑查询结果应该并行返回还是分层返回。两个查询类的原子服务最终需要返回两个数据集关联查询的结果集。微服务架构中底层数据库拆分后经常会遇到这种情况。例如，对于物料的基本信息查询，采购订单明细的查询，分别在两个独立的数据库中提供独立的服务。而我们要返回的查询结果集是物料代码、名称、型号、单位、价格、采购数量的复合结果集。在这种场景下，往往是在前端功能开发时组装的。其实可以考虑在服务编排层能不能解决这个问题。写代码很容易解决这个问题，但是需要是可视化的服务编排配置方式。做起来其实挺难的。对单个已有服务进行裁剪和丰富，形成新的服务输出，暂属于服务编排的范畴，即仍然是输入服务，但输出是提供新的服务。即对单个已有服务进行剪裁和丰富，比如过滤掉一些数据项作为输出结果，固定加入一些数据项作为输入等。这些简单的服务剪裁、丰富，或者简单的数据转换都可以在服务编排时完成并提供新的服务。是我们经常看到的一种服务编排场景，多个原子服务按顺序串联起来形成服务提供，即直接编排A、B、C三个服务，即服务A的输出直接成为B服务的输入，B服务的输出成为C服务的输出。如果这只是上面的假设，那么这种基于流程的服务编排还是非常简单易实现的。但实际的难点在于服务A的输出本身需要是服务C的输出，同时服务A和服务B的输出也可能是整体输出的一部分，这本身就增加了难度服务编排的可视化设计。单个业务服务是主要服务，但安排多个业务规则逻辑处理服务也是常见的场景。例如，当我们导入合同信息时，首先要调用合同有效性验证服务，同时调用预算信息查扣服务进行相关的完整性和业务规则检查。这些校验完成后，调用实际的合约信息导入服务。如果验证失败，则直接返回失败结果。这种服务编排往往是我们在实际开发前端功能时的服务组装逻辑。多个导入服务组合成一个导入服务。合并导入形成新服务的场景其实对应的是场景一，既然可以将多个服务组合起来形成一个组合结果返回，那么将多个导入的服务合并为一个是很自然的。导入服务，一次完成数据导入。比如有项目信息导入和项目WBS信息导入两个原子服务，那么我们可以提供一个新的项目信息导入服务，一次性完成项目基础信息和项目WBS信息的导入。在这些场景中我们可以看到，其实服务编排就是常见的服务串接、服务并联下的输入输出合并、服务内容的丰富和裁剪等场景。在理想的场景下，我们最希望达到的是，一个业务功能点的实现，可以完全通过服务编排的可视化设计来完成。源码导出对于API快速开发平台，实现复杂的业务规则编码难度较大。因此，当有复杂的业务规则实现时，还是建议开发者自己开发代码来完成。因此，整个平台应该提供源码导出功能，导出的源码应该可以直接编译，不需要API开发平台就可以部署运行。对于导出的源码，考虑到后续API接口变更的场景，建议约定扩展部分。比如一个标准的API接口服务实现方法，可以在前后添加扩展处理。//BeforeDo();//ProcessAPI();//AfterDo();这样可以在接口实现之前进行额外的业务规则处理和完整性验证，在接口返回数据和处理之前可以对输出数据做进一步的处理。微服务应用可以将多个对象或多个API接口服务打包成一个微服务应用进行部署和发布。所以这里引入微服务集的概念，对微服务API进行封装。打包后的微服务可以导出为独立的JAR包进行部署，也可以直接托管部署在API开发平台上。对于API开发平台本身，应该是对接微服务运行平台的。近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
