web前后端架构演变以及对产品的影响

你有没有遇到过这种情况？

1、由于某个产品涉及到的开发比较多，不知道需求该向哪方提？

2、想快速理清一个产品的架构？

3、不了解哪些产品模块已经存在了，想要复用？

通过了解整个技术架构和调用链，可以帮助产品理清产品架构，了解不同层的开发内容、了解公共可复用的模块有哪些。

下面聊聊近代前后端的技术架构。

01

单一模式

单一模式指的是一个前端只对应一个后台的模式。这种模式的优点是比较简单纯粹，缺点是后台全部的逻辑都写在一个项目中，包括业务逻辑和数据库操作。还有本身可以复用的模块也得不到复用，比如登录、发短信、发模版消息等等，随着业务的发展，项目复杂度会越来越高，开发效率低下，故障排查困难，一个小功能可能会影响整个系统。

小结：这种模式适用于比较简单小巧，对其他业务项目没什么依赖的项目，比如日志管理平台、内部数据资产管理平台等。产品提需求也比较简单，直接找到负责这个平台的前后端开发就可以了。

02

微服务模式

微服务模式指的是多个前端可以对应一个接入层，一个接入层对应多个后台的模式。多个后台也叫微服务。这个模式也是现在用的最多的模式。看下图：

接入层一般只做鉴权、登录、还有接口的转发（指的是调用微服务接口），这些微服务怎么拆分，粒度到多细，都是需要根据业务场景来做的，一般公共服务会拆成一个微服务，比如统一登录、发消息服务。独立性强的业务也会拆成一个微服务，比如支付服务。

比如一个用户购买商品的下单操作，请求会先到接入层做是否登录的校验，如果没有登录，则直接给用户返回登录页。如果已经登录，则接入层会调用下单业务微服务的下单接口，把用户的参数透传过去，这时该微服务就会处理相关逻辑和操作数据库，然后把操作结果返回到接入层，接入层再把结果透传返回给前端。

接入层的开发一般会归属于前端同学，后台同学专注底层服务。

小结：微服务的出现解决了单一模式的耦合度高，项目臃肿，排查问题困难、复用率低的问题。因为微服务把许多可重用的模块分散到了各个微小的服务中，比如统一登录、统一消息发送。微服务得到了自治，排查问题也会变得简单。

对于微服务架构，产品在提需求时，建议要了解有哪些模块化的服务可以直接调用，还有不同层对应的开发人员。

随着公司业务的增长，微服务架构也暴露了一些问题。一个前端项目就对应一个接入层项目，后面会发现接入层项目越来越多。存在重复开发的、资源占用过多、维护困难等问题。serverless架构就此诞生了。

03

serverless模式

serverless可以分成server和less两个单词来看，意思就是少服务器的或者无服务器的意思。

serverless = Fass(Function as a service) + Bass(Backend as service)

Fass是函数即服务，Bass是后端即服务。

简单理解就是前端想调用接口时，直接调用后台同学写好在服务厂商上的函数，然后函数再调用底层的一些公共微服务。

看下图：

1、Fass

Fass是服务商提供一个平台给用户自主开发函数，自主调用，不需要搭建和维护基础框架。

比如前端同学想要调用一个下单接口，后端同学把下单接口函数写在服务商平台上供给前端直接调用，就不需要自己去额外搭建一个后台服务了。

2、Bass

Bass是第三方服务商提供一些基础功能给后端服务，比如腾讯云云开发中，微信小程序鉴权登录、发短信服务等。小程序鉴权登录是一个比较复杂的过程，如果直接调用第三方厂商提供好的功能，可以大大提高开发效率。

小结：这种serverless架构在近几年比较流行，它的优点是环境统一不需要搭建服务器环境、丰富的第三方服务调用（比如发短信、小程序登录）等。当然它也有缺点，它与云厂商强绑定、开发调试和测试函数比较麻烦。

最后的小结：这三种模式，目前市面上都存在着，单一模式比较适合与其他业务耦合度低，比较独立的项目。微服务模式适用比较广泛，一般都可以用，也是目前用的最广泛的一种模式。serverless模式诞生还不久，适合小程序云开发，定时任务、报表统计等。