FaaS函数平台建设之路和在通天塔落地实践

通天塔是一个面向京东运营和商家的活动搭建平台，提供了丰富和强大的模板，平台用户可基于模板自由搭建活动页面。其中的活动页面数据查询业务覆盖了京东主站、极速版、微信、QQ等不同渠道下的活动内容查询，底层服务端采用传统的Java应用开发模式，一般性的需求都需要经历产品评审、接口设计、前后端联调、测试验证、前后端发版等过程。然而随着渠道的增加、各渠道间个性化需求的增多，产品需求迭代的加速，传统的服务端架构开发模式已显得力不从心，我们虽然沉淀出一套通用框架，但受限于开发模式的本质并没有变化，业务开发的灵活性和开发成本依然很高。总结起来，面临的挑战主要是：依赖三方数据源多、业务需求变化快、渠道个性化需求多、前后端联调成本大等。

最近两年，Serverless这个概念非常火热，其能带来的弹性伸缩、快速开发、无运维等特性也深深吸引了众多优秀的实践者。结合我们自身的业务特点和对FaaS的研究，我们希望通过FaaS技术的引入把一系列基础能力沉淀下来，在此之上，通过FaaS来承接上层业务逻辑，通天塔FaaS平台应运而生。

随着云计算服务体系的发展，慢慢演进出IaaS（Infrastructure as Service)、CaaS（Container as a Service）、PaaS(Platform as Service) 和FaaS(Function as Service) 等服务模型。

为了方便理解以下列出以上各模型的特点和代表性产品：

• IaaS: 提供存储、服务器、网络等底层资源，比如阿里云服务器ECS
• CaaS: 提供容器及容器编排能力，比如阿里云的ACK
• PaaS: 提供平台,比如CRM解决方案提供商-Salesforce
• FaaS：AWS的Lambada

无论是哪种服务模型，其目的都是通过封装行业现有认可的基本解决方案和架构，提供给用户业务快速启动的能力。FaaS 平台（Function as a Service）是为用户提供开发、运行和管理的函数服务平台。用户只需要专注于编码和业务逻辑，无需关注硬件、操作系统等资源，应用的管理和部署也交给平台。

通过分析梳理通天塔内部各应用实际可落地的FaaS场景以及考虑到各应用对时效性的高要求，通天塔FaaS平台一期主要实现应用方以集成SDK的方式本地加载运行FaaS平台编写的函数，所以FaaS平台整体的核心架构主要是由集成SDK、一站式运维发布平台、DUCC(京东分布式配置管理平台)、JFS（京东文件存储系统）组成。诚然当前FaaS平台并非真正意义上的FaaS产品，并没有中心化运行和弹性伸缩的能力，可以理解为当前版本是我们对FaaS的初步探索和落地，后续我们会逐步演进升级架构，迈向真正的FaaS。

如上图1-4过程为函数的一次发布更新流程。

• Function Consumer 是我们为开发者封装的一套SDK。开发者在具体的业务逻辑代码中通过调用SDK提供的API即可的执行函数内容逻辑。
• Function Center 一站式运维发布平台是面向开发者的主要操作平台，开发者在平台上进行函数编写、版本提交发布、回滚、监控运维等一系列工作。
• Function Repository 函数仓库负责存储函数内容的服务，对外提供统一的API包括函数内容新建、更新、拉取等功能，其底层存储介质可在Redis、JFS（京东文件存储系统）自由切换。
• Ducc 是京东的分布式配置管理平台，函数的内容更新监听主要依赖于Ducc。

开发接入成本低

FaaS平台通过一站式的云端开发平台，使用户可以直接面向业务逻辑的开发，无需关注基础服务和中间件同时业务逻辑开发模式轻量化、无应用化，发布回滚秒级生效，极大的减轻了传统服务端开发过程的繁琐流程，将开发的精力集中于核心业务逻辑开发。FaaS平台上函数除了开发成本低，调用者接入方式也比较简单，通过引入我们提供的SDK调用函数，此时函数的执行完全在调用者应用本地进程里，对性能几乎没有附加的影响。

函数执行本地化

函数加载运行在调用者本地应用进程里，开发者对函数的运行拥有完全的自主控制权同时运行的状态也是完全对开发者透明的。本地函数运行没有网络耗时，跟调用本地方法一样。

支持JSF泛化调用

通过对JSF（京东RPC通信组件）泛化调用的API封装同时提供参数解析工具，用户可以通过一个简单的注解引入三方JSF接口，而不需要用传统的方式 引入三方JAR-配置XML-加入配置，极大的降低了开发者使用公共组件的门槛。

监控运维透明化

FaaS平台上创建的函数从发布到线上监控对开发者都是透明的，开发者发布时可实时观察当前发布状态以及宿主应用环境中函数加载的状态同时可以查看当前函数执行流量和可用率等指标。开发者也可基于此自定义配置告警策略。

Function Consumer的设计思想来源于Mybaits 的mapper设计思想，了解mybatis的都知道mybatis是通过代理将xml编写的sql语句映射到mapper接口方法上。

所以Function Consumer的设计是将FaaS平台编写的函数映射到Function Mapper上，在使用上只需要定义一个函数接口，调用时直接自动注入接口并在调用上下文中传入业务code和场景code，此时函数平台上对应配置的函数实现将会被执行。如下所示函数接口与函数平台编写的函数关系：

结合目前通天塔业务特点，即大多以活动内容数据查询为主，以历年618、双11搭建的大促活动页面来看，活动查询具有楼层多、数据拼配组装复杂、上游数据源多等特点，传统的Java服务端开发模式已经承载不了高频率的迭代需求了。因此我们通过引入FaaS，希望提高服务端开发的灵活性，让开发者更多的面向业务逻辑而不是花较大量的时间在服务的部署维护上面。

统一数据源接入

我们使用FaaS实现数据源接口的接入和字段匹配，当有新的数据源接口需要接入时，直接在FaaS平台上通过函数编写实现，可以做到在本地Java应用不发布的情况下，直接上线新数据源。对于新业务接口的快速接入具有重要意义。同时在数据源接口需要升级或者更新的情况下，同样我们只需要通过变更函数逻辑快速实现。

API协议字段扩展

上游API请求前后嵌入FaaS函数扩展点，当有个性化会场需求时，比如特定渠道会场要求切换推荐算法、商品支持展示到手价等，我们只需要在FaaS平台上创建该场景的函数并编写业务逻辑实现即可。无需开发人员熟悉整个业务应用、本地环境搭建等繁琐操作。

模板协议匹配

通天塔提供了丰富和强大的模板，用户基于模板搭建出各式各样的活动页面，而模板协议即后端和前端约定的模板数据格式，当有新的模板需要创建时，我们只需要基于模板协议转换的函数接口扩展点实现协议转换逻辑，对已编排后的数据进行转换。

平台整体上还处于刚刚起步阶段，也是我们Serverless实践的初步尝试。接下来如下几方面继续探索演进

1.开发一套idea FaaS函数编写插件，支持开发者本地函数开发、代码安全检测、一键同步平台端。

2.支持函数中心化方式运行，即运行在我们建立的宿主环境中，并在宿主环境中集成公司中间件及三方服务。

3.寻找更多的业务切入点，通过FaaS进一步提升现有技术架构的灵活性和迭代效率。

同时我们致力于推广和实践Serverless化的BFF（Backend For Frontend）架构，即SFF(Serverless For Frontend)，让更多的前端同学只需要关注于业务逻辑，就可以完成 API 的编写，发布和上线，实现数据层的自管理，减少前后端沟通成本，提高整体研发效率，赋能更多内部业务系统。