概述Serverless是一种“无服务器架构”模型，不需要关心程序运行环境、资源和数量，只需要专注于业务逻辑技术。在基于Serverless开发Web应用时，架构师总是试图将传统的解决方案移植到Serverless上，尽管在保持传统开发模式的开发体验的同时，也有可能享受到新的Serverless技术带来的红利。然而Serverless技术带来的改变可能不止这些，它可能是颠覆整个传统Web应用开发模式的革命性技术。开发模型业务应用的开发模型是一个从集成到拆分前后端，再到前后端集成的过程。注：后面提到的后端特指后端业务逻辑。早期All-in-one是没有前后端概念的。那时候的应用都是单机版的，所有的业务逻辑都是写在一起的。开发人员无需关心网络请求。这一时期的工程师完全专注于业务代码的开发。随着业务规模的增长，暴露出很多问题：高并发问题高可用问题说明：业务应用升级困难等一些问题不是本文关注的，就不一一列举了。现在，拆分前端+后端业务逻辑的高可用高并发运维：注：Serverless技术已经有一段时间了，不但没有解决开发体验的问题，反而带来了更多的开发经验问题，所以，我不会在这里强调无服务器技术。解决问题：高并发。通过分布式部署、多级负载均衡等技术，解决业务的高并发问题。高可用性。通过主从架构等技术解决业务的高可用问题。解决一个问题会带来一堆问题：拆分业务应用程序。业务应用为了解决高可用和高并发，引入了分布式架构，通过负载均衡和主从模式来保证高可用和高并发的问题，但是这种方案对业务应用有侵入性，导致内部高集成应用是分为前端和后端污染业务代码。高可用、高并发、运维相关的逻辑与后端业务逻辑交织在一起，使得后端技术门槛更高，导致需要多名后端工程师掌握所有后端技术和增加联调成本。前后端联合调试工作越来越繁重，成为提高工程开发效率的瓶颈。新的功能和BUG需要前后端工程师的配合才能完成。如果你是全栈开发工程师，一定深有体会。很多BUG一眼就能看出是前端问题还是后端问题。前后端技术发展速度不匹配。随着技术的快速发展，后端技术相对稳定，前端只能被动适应后端，大大降低了前端最新技术的用户体验。最理想的方式是前后端整体考虑，整体开发。不要让前端写一百行代码就实现了后端只需要优化一行代码就限制了代码抽象的问题。因为实现的是同一个业务需求，前后端代码关联度高。如果能把前后端代码之上的代码逻辑抽象出来，一定能大有作为。同时，代码的开发和维护也得到了质的提升。前后端分离，迫使我们在前端或者后端抽象代码。抽象出来的代码可能是片面的、重复的，增加了技术复杂度。前后端分离，前后端工程师独立工作，形成自己的技术栈，包括语言、工具、概念，单个工程师很难维护整个业务应用，也让前后端工程师互相排斥对方的技术栈。随着时间的推移，技术栈的差异越来越大。一个项目再小，至少需要两个工程师，全栈开发工程师又是另外一回事，增加了运维成本。需要专门的运维工程师进行运维。虽然通过技术手段降低了运维成本，但目前的运维成本仍然很高，难度也很大。这也是为什么小的创业公司喜欢全栈开发工程师，因为在创业初期，对高可用和高并发的需求不是那么迫切，所以运维也比较简单。全栈开发工程师的使用，不仅缩短了项目交付周期，还降低了公司的运营成本，这对于小型初创公司来说非常重要。重要的。未来整合将回归到整合的前端+后端+Serverless+平台服务=>业务应用+Serverless+平台服务：注：共享逻辑是前后端共享逻辑。端层面的代码是抽象的，前后端融合之后，这件事情就变得简单自然了。带来困惑：前后端分工不好吗？以往，将一个复杂的问题分解成多个简单的子问题，在不侵入业务应用的情况下，无法实现高并发和高可用。这是一个很好的解决方案，也是一个无法解决的解决方案。前后端分工带来的成本问题越来越突出。既然Serverless透明的解决了高并发和高可用的问题，为什么还要从技术维度来划分呢？不是建议按业务维度划分吗？后端还是难，控制前端的门槛还高？虽然端代码逻辑没有被高并发和高可用所胁迫，但是还是会比较难，比如AI。我相信现在可能存在这样的困难业务，未来会有相关的开发包或者平台服务来为我们解决，让这些困难的技术能够大众化。困难的技术交给专业人士。重拾初心：回归业务，前后端融合。Serverless技术的出现，解决了高可用、高并发、运维等问题。作为工程师，我们是否应该回过头来找到自己的初衷：专注于业务代码。让原来的后端业务代码和前端代码重新合并。那么，前后端一体化不就是我们遗失已久的应用开发终极解决方案吗？Serverless的现状已经做到了以下两点：工程师只需要关心业务逻辑技术，有接近传统应用开发的经验（解决历史遗留问题，可能还有一定距离）传统应用框架食之无味，弃之可惜：目前很多用户已经感受到了Serverless带来的高可用、高并发、免运维的好处。用户可以很自然地想到，如果能把现有的开发框架移植到Serverless上就好了。Serverless平台自然会为现有框架提供迁移解决方案。要解决的问题是将传统方案移植到Serverless上，让用户在Serverless上有传统的开发体验。问题：解决了第二阶段开发模式出现的问题。详见：《解决一个问题带来一堆问题》。前后端一体化的不足如下：基于Serverless的前后端一体化框架其中，基于Serverless的前后端一体化框架解决了前后端-结束整合问题；该工具屏蔽了Serverless平台细节，并提供一致的部署和运行体验。未来，开源社区会涌现出一大批基于Serverless的前后端集成框架和工具。Webassembly让前后端一体化，打破了开发语言的限制，可以使用任何开发语言来开发前后端，比如java，go。由于javascript是为前端而生的，typescript是目前活跃的前端开发语言，前后端统一使用typescript。其他语言可以通过webassembly技术被typescript语言调用。这可能是最好的选择。想要成为流行的基于Serverless的前后端整合框架，需要具备以下特点：开源不绑定社区化运营，形成标准模式简单总结Serverless技术让我们能够迈向新世界大门的左脚，请让我们基于Serverless的前后端集成框架帮助我们迈出右脚。同时，请不要再叫我前端开发工程师，我是业务应用开发工程师。Q&A：前后端整合是否需要将前后端代码发布到同一个地方？A：没有，分开发布。统一的工具负责前端和后端发布任务。前端可以发到CDN，后端可以发布到serverless平台。例如：阿里云函数计算。Q：以后是不是没有后端工程师了？答：是的。前端工程师只是做前后端的业务逻辑代码，后端工程师做真正的后端。到时候后端工程师会更专业，前端工程师可能会变成应用开发工程师（现在这么叫）。对于中小企业来说，可能大部分都是应用开发项目，很少或者没有专业的后端工程师。Q：为什么不搭建一个类似expressjs的web应用框架呢？A：expressjs框架是在没有Serverless背景的情况下设计的，没有考虑Serverless给我们带来的技术架构变化。如果我们需要expressjs这样的框架，我们完全可以将expressjs框架迁移到Serverless上运行，不需要重新构建一个。问：为什么是nodejs框架？A：Nodejs和前端js使用同一种语言，可以让前后端的融合更加极致。Webassembly也可以让任何语言跑在前端，也可以实现前后端同种语言，不过js是为前端而生的，更有亲和力。但是其他语言可以通过webassembly编译成中间语言，nodejs使用vm调用其他语言提供的函数。不排除未来会有新的运行环境替代nodejs，更适合多语言和serverless场景。Q：前后端一体化的极致感受是什么？A：前后端代码在一个项目中都是用同一种语言编写的，在本地定义一个后端接口方法，前端调用后端就像调用本地方法methods（对于本地没有定义的后端接口也是如此，比如跨组件、对外服务），前后端可以抽象出更通用的逻辑，比如工具类等，一个开发人员无需太多即可维护整个项目项目多语言切换是痛苦的。
