FaasJS vs MVC

今天想跟大家讲一下 FaasJS 背后的设计理念:

使用 Function + Folder 来高效构建和迭代复杂的业务应用。

作为开发人员,需要面对两种复杂性:业务复杂性和规模复杂性。

而解决复杂性,最好的办法就是拆分。

MVC 框架的做法是将一个单体应用拆分为多个单体应用,然后通过容器集群来提供服务,以此来拆分和解耦业务和规模,提升吞吐量和稳定性。

但这种方式有三个缺点:

  1. 规划单体应用的拆分需要对业务架构和技术架构都有较深的理解,且工作量和工作难度都不低;
  2. 单体应用的高内聚特性,会导致随着业务增长,再次面临需要拆分的情况;
  3. 随着应用数量的增多,开发环境和测试环境所需的依赖关系变得越发错综复杂,部署和运维的难度也越来越大。

简单来说,以拆分应用的方式来解决复杂性问题,其实是把复杂性转移到了运维层面,并且会导致运维层面的复杂性指数上升。

那 FaasJS 是如何降低这种复杂性指数上升的情况的呢?

首先在运维层面,FaasJS 的部署对象是 FaaS 集群,其基本单位是函数,这会带来以下好处:

  • 原子化部署:按需部署,快速部署。
  • 原子化隔离:每个函数锁定部署时的依赖关系,不会被动升级。
  • 原子化监控:细粒度的了解每个函数的运行状态和并进行调控。

接下来在开发层面,FaasJS 主要使用以下方式来降低复杂性:

  1. 面向业务流程编程,用函数替代类;
  2. 以文件夹形式直观的隔离业务领域;
  3. 以函数为单位进行拆分,使得复杂性可以以较平滑的线性来增长。

MVC 为了实现高内聚,使用了分层架构和面向对象编程,但随着层级越来越多,类的继承关系越来越复杂,复杂度呈指数上升的趋势。

FaasJS 采用面对业务流程的函数式编程,彻底将每个业务流程控制为可预测的输入/输出函数,以此来控制开发和测试的复杂性。

同时,使用文件夹形式来划分云函数,不仅可以让整体架构更直观,而且使得拆分和重构更为灵活。

在 FaasJS 中,每个文件夹都可以进行独立配置,子文件夹可以继承父系文件夹的配置,云函数代码中的配置可以覆盖文件夹配置。

从而在配置层面提供了直观的继承和隔离,并且随着云函数部署到线上,配置文件会锁定在部署时的状态,不用担心被篡改。

综上所述,FaasJS 基于 Serverless 技术,使用 Function + Folder 来大幅简化代码的迭代和重构成本,使得业务可以快速更新,所以 F 也同时代表了 Fast(虽然在性能层面,Serverless 语境下,Node.js 的性能优势相对不那么突出)。

本文分享自微信公众号 - 寂静小站(zfbencom)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券