路由器|无需修改代码,用 fcapp.run 运行你的 REST 应用

路由器|无需修改代码,用 fcapp.run 运行你的 REST 应用

文章图片

路由器|无需修改代码,用 fcapp.run 运行你的 REST 应用

文章图片

路由器|无需修改代码,用 fcapp.run 运行你的 REST 应用

文章图片

路由器|无需修改代码,用 fcapp.run 运行你的 REST 应用

文章图片


背景 阿里云函数计算产品[1
在较早的时候支持了 HTTP 触发器[2
能力 , 支持用户使用 HTTP 协议进行函数调用 。 函数计算后端通过一个共享的 APIServer 组件对所有客户提供响应 HTTP 触发器调用的服务 , 需要依赖 URL 中的 Path 将客户流量路由到客户的函数容器内部 。 容器内收到的 HTTP 请求 Path 会带有函数计算的路由标识 , 如果客户在函数计算部署 REST 风格的应用 , 那么就会遇见 404 问题 。

在一开始 , 函数计算并不是为客户运行中小型规模应用而设计的 。 函数计算提供了原生的 REST 架构 , 将每个函数视为一个独立的资源 , 通常一个函数只负责一小块功能 , 也就是一个 API 。 如果一个函数只对应一个 API , 那么在函数代码中也不必去实现一套路由逻辑去响应不同 URL Path 路径的请求了 。

函数计算在近两年引入了 Custom Runtime/Custom Container Runtime[3
类型的函数 , 客户可以直接在函数计算上运行自己存量的应用 , 而不必按照函数计算推荐的架构去拆分自己的应用 。 客户以及社区内比较成熟的项目的开发习惯是采用 MVC 等架构 , 在一个程序中开发大量的 REST API , 在进程内按照报文中的 HTTP Path 进行路由 , 将不同路径的请求“转发”至不同的方法或函数进行处理 。

在这样的背景下 , 客户可以在函数计算运行存量的 REST 应用 , 但应用无法正常对外提供服务 。 客户花费大量的精力对存量的应用进行改造 , 而且这个改造仅仅在函数计算是必须的 , 是一种典型的平台携裹用户的产品设计 。
使用 fcapp.run 调用函数 为了解决上述的问题 , 并兼容存量的函数以及客户习惯 , 函数计算为每个新创建的 HTTP 触发器分配了一个独立的域名 , 例如`{random-string.cn-shanghai.fcapp.run` 。 使用该域名访问函数计算 , 函数计算会按照域名进行路由 , 将流量转发至函数容器内 , 避免对客户代码造成侵入性 。

使用 fcapp-test.run 进行本地网页测试 由于中国大陆政策的影响 , 函数计算主域名无法在互联网为客户提供网站类型的业务 , 所有的函数请求结果将被转为下载行为[4
。 对于纯 API 类型的函数 , 我们认为将请求结果转为下载是没有影响的 。 但对于网站属性的函数 , 返回的 HTML 文本以及 JavaScript 代码强依赖浏览器的解释器才能正常展示 。 我们判断让开发者能够实时看到函数返回的页面是一个强诉求 。 在生产场景 , 我们推荐客户为函数绑定已备案的域名来解决这个问题 , 而在测试环境有更加简洁的方案 。 在测试阶段可以临时通过测试域名 fcapp-test.run 以及添加本地的 host 解析绕过这个问题 , 请求结果将不会被转为下载行为 , 可以正常进行网页调试 。
# 1. 从页面获取fcapp.run的域名FC_DOMAIN='wordpress-xxxxx-serverlordpress-ydziwvakfn.cn-shenzhen.fcapp.run'FC_TEST_DOMAIN=`echo ${FC_DOMAIN | sed 's/fcapp.run/fcapp-test.run/g'`echo \"FC域名: ${FC_DOMAIN\"echo \"FC测试域名: ${FC_TEST_DOMAIN\"# 2. 查询域名解析的IPFC_IP=`ping ${FC_DOMAIN -c 1 | HEAD -1 | awk '{print $3' | sed 's/[():