Bmob FaaS 或“函数即服务” 介绍（2）

上一篇讲过Bmob在国内最早做这个的企业之一，当时还完全未有借鉴，所以与目前腾讯与阿里云有所不同。

他们（腾讯与阿里云）2家的服务设置与使用都非常相似，从2017年同时推出公测起都是奔着亚马逊的Lambda 的功能来的，只是2家函数代码互不兼容，展现形式一致。

image.png

image.png

image.png

腾讯云.png

阿里云.png

可以看出这几点都是相同的,由此看出他们的技术架构都来自同一套类似的东西然后对其定制加入自家云内部接口函数

我们的云逻辑发展历程

发展历程.png

特点	第一阶段	第二阶段	第三阶段	第四阶段
说明	1. 无启动时间，开箱即用 2. 架构相对简单，易扩展，维护方便	1. 无启动时间，开箱即用 2. 函数按照用户分文件夹 3.热点代码写入内存，读取速度快	1.根据业务规则划分服务器区快，例如id 1-100的用户在服务器一组（解决了一个人影响所有人，不过还是会影响他所在的服务区域）	1.完全隔离，资源独立
问题	1.函数多的时候磁盘读取慢	1.由于执行环境没隔离，高并发用户会影响低请求用户逻辑	1.隔离有限，还是会出现个别时候一个函数影响其他	1.基础成本高 2.开发成本高 3.需要预备一些硬件资源
特点	1.简单快捷，云函数支持有限	1.云函数支持数是第一方案的N倍	1.不再一个函数影响所有	1.独立运行无限扩展

自主创新走了一些弯路，在第二阶段升级到第三阶段的时候，我们直接走了第四阶段通过kubernetes+docker容器技术来实现集群编排，通过Go来暴露接口给前端应用灵活购买云函数，续费，用户自主升级配置、github代码拉取等等。

最终由于云函数是免费功能，大部分用户只是少量使用云函数。Serverless本身最求小而美的低成本策略，高额基础成本、维护成本导致当时这块功能全部弃用，重新进入第二阶段，经过优化走出了第三阶段这条技术线路。

得益于一些游戏应用厂家对云函数有更高的要求，我们推出了第四阶段与阿里腾讯今年推出的方案有些类似，用户独立环境，只要有需求，无限资源扩展。根据实验以单秒API并发来控制实例个数。

云函数是如何工作的？

image.png

云函数分为三种调用形式

架构上要实现灵活扩展扩展云函数，需要一套具有动态路由器来管理函数、容器、超时、动态扩展、功能接口等，我们使用的是OpenResty，OpenResty在优酷、淘宝、360等中大型互联网企业都有应用。

在云函数这块，不久的将来我们将推出Java版本云函数，为开发者的需求，我们也在不断创新，推进中国移动互联网软件开发效率。希望未来软件开发服务端真如Amazon.com首席技术官Werner Vogels所说："没有服务器比不管理服务器更容易管理"。