本文从项目工程的角度进行讲解，技术角度请参考另一篇文章p/...）这篇文章总结了我在实际开发多个Serverless全栈项目的经验，主要针对中小型项目。大家可以直接借鉴我的经验，也可以根据实际情况进行调整。第一步：决策Serverless项目管理的艺术就是如何在有限的条件下发挥其优势，避免其劣势。因此，我们需要先确定Serverless在中小型项目中的优势和劣势。(1)Serverless的优势是成本低：对于小型项目来说，Serverless的成本可以说是极低的。虽然我们的技术人员对成本不是很关心和负责，但??是对于中小型项目的公司层面的决策来说，成本是一个无法回避的问题。人员要求低（专注于开发）：不再需要配置、管理和优化服务器环境，代码上传即可直接使用。颠覆性的性能优化（性能好方便）：这是我最看重的优势，也是必须要发挥的优势。传统服务器的调优和配置是针对整个项目层面的。如果某个接口出现性能瓶颈，需要拉取整个项目的配置。但是，Serverless可以优化单个API接口级别的性能。比如我们只能提升首页和热门活动的性能配置。这是其他传统项目需要付出高昂的开发成本才能实现的，而Serverless却可以极其轻松地实现。安全性：Serverless由于其独特的特性，注定了与传统安全性截然不同的安全性。目前主流的系统入侵、DDos攻击等网络攻击大多直接针对Serverless不生效甚至失败，也没有发现专门针对Serverless的攻击工具。此外，Serverless本身提供了一些安全机制，比如腾讯云SCF的单一功能独享配额、所有功能共享配额、API网关认证等，合理使用后可以以低成本实现高安全性。功能专属配额设置页面（二）Serverless的缺点：它的缺点需要生态解决实践少：Serverless虽然是2014年出来的，但感觉真正用上也有三四年的事情了，而且它的使用率也很高，大部分是项目或者个人自己玩票，全栈项目就更少了。同时，有实践经验的人缺乏传道的时间和渠道，市面上的书籍主要是理论性的。因此，业界还没有成熟权威的工程理论来指导ServerlessDevSecOps，这对项目经理本身提出了更高的要求，甚至对项目经理能否准确评估风险并做出大胆决策提出了额外的要求。框架很少：目前还没有原生的无服务器框架。部署麻烦：不用说，这是一个缺陷，但也是最好的解决方案。就像10多年前JavaScript异军突起后出现的jQuery等框架一样，Serverless的劣势对开发者来说是机会，大胆尝试先找到解决方案的人也将引领Serverless。第二步：项目方案选择（1）云服务商选择在项目开始之前，我们需要选择一个服务商。市场上有很多Serverless服务商，选择哪家服务商是所有项目负责人的首选。事实上，对于大型服务提供商，您可以选择任何一家。我个人是腾讯云云功能的深度用户（所以别问我，只推荐腾讯云），所以本文的体验也是基于腾讯云的。当然，各个平台的调优存在一定差异，但都是大同小异，可以借鉴。(2)云功能选择腾讯云的云功能分为“WEB功能”和“事件功能”两大类，每一大类的部署方式包括“镜像部署”和“代码部署”。对于中小型项目，我推荐“事件函数”+“代码部署”。WEB功能：在我看来，“WEB功能”是很难扩大云功能市场份额的东西。即使在最开始的时候，云功能也没有这个“WEB功能”。的。厦门良超科技有限公司创始人兼CEO张果（iGuo知名）也提到，“WEB功能”其实是一种妥协。WEB功能是将整个项目部署在一个云功能中，这样会让我们无法利用Serverless的“界面级管理”和“安全”两大优势，失去了Serverless最大的特性，而只能得到“框架支持”。》这个功能很不划算，其实框架支持对于Serverless中的中小型项目来说并不重要，甚至可有可无，详见下面的描述部署方式的选择：代码部署就是直接将代码部署到cloud.镜像部署就是在本地把一个工程做成镜像上传到腾讯云的“容器镜像服务”，然后推送到云端的功能，其实腾讯云内置的扩展已经满足了技术要求大部分项目的需求，一些没有直接内置的扩展也可以通过第三方包直接实现，除了复杂的项目，代码部署已经满足了大部分项目的需求了。“代码部署”方式保持了云端和本地的高度一致性，即使云端出现问题也可以在本地快速轻松地恢复。同时部署操作简单，维护方便，速度快，性能好，方便本地或云端调试。因此，建议仅在“代码部署”不满足项目需求时才使用“镜像部署”。我认为：Serverless应用的极致体验是本地helloworld开发，相当于项目开发。第三步：框架选择以PHP为例。中小型项目使用Serverless。传统的框架很可能成为障碍。你不觉得很奇怪吗？项目采用的框架的目的是从工程角度更高效、更方便、更高性能地开发和维护项目。之所以需要框架，是因为相对于服务端开发，本地程序开发考虑的因素少，比如不需要担心性能，大并发等。框架为我们做了很多工作，帮助我们解决线上项目的需求。但在Serverless中，框架已经失去了大部分对普通项目的价值和意义。性能弱化：在Serverless中，我们实际使用的不是服务器，而是算力。由于云函数本身提供的计算能力是相当强的，即使是质量很差的代码也能承受。框架的高性能实际上被削弱了。.并发减弱：对于中小型项目，大部分业务执行时间很短。高并发的压力不是来自于高效算法的压力，而是来自流量和计算资源的瞬时增长超过了服务器提供的能力。云函数的每次调用可以说是物理隔离的，所以云函数其实相当于“自动无限扩展”的计算和网络资源，所以不怕高并发。其实框架高并发方面的优化需求其实是可有可无的。功能失效：在Serverless中，传统的连接池失效，我们需要创建一个原始的连接池。各大云服务商的数据库也针对云函数的大量连接需求进行了优化，直接提供了2000+并发连接的支持。学习成本：中小型项目对技术要求不高，没有庞大的业务链条。快速和简单是要求。任何框架，无论多么简单，都需要学习成本，而大多数技术开发者只是在百度的用法下开始使用，并不会深入研究。所以，越小的项目，当框架本身不满足或者出现问题的时候，框架本身就成了最大的障碍。对于中小型项目，有些人为了框架而使用框架。框架不支持：如上所述，大多数语言不支持框架“事件函数”。Serverless没有原生框架。Serverless技术架构说明：要充分发挥Serverless的优势，必须采用多功能部署，即微服务架构模型。Serverless最终最好的归宿一定是微服务架构模型。目前的传统框架只是在原生框架之前的临时过渡。传统微服务框架一般针对大型项目，学习和入门成本高。中小型项目的微服务其实很简单。我们并没有真正使用微服务框架，而是像写一个本地的helloworld一样开发项目。部署时，一个API接口，一个云函数。我们要的是微服务带来的好处，而不是他的麻烦。因此，我们应该采用的模式是：传统架构+传统开发+微服务部署。最简单的方法是使用一个简单的框架，然后将与客户端交互的每个API作为一个单独的函数进行部署。一个高效的Serverless开发框架必须支持本地单元测试，单元测试的效果必须等同于部署后的执行效果。因为不方便测试的框架会让开发者偷懒，等功能部署好再测试，很容易造成很多返工问题。单元测试的实现逻辑可以参考我上一篇文章。所以在我看来，对于中小型项目，在不使用框架不影响团队协作和效率的情况下，没有必要使用框架（传统框架与云功能匹配不好），或者写一个简单的你自己的共同项目一个结构或框架就可以了。以API接口为单位进行部署，部署后直接形成微服务。开发时只需要特别注意整个项目中没有session即可。API接口在执行时，在物理上相互隔离，数据不互通。我项目中使用的框架是自研的Serverless框架，在很多项目中都有使用。这个框架在很好的利用了云函数的各种特性的同时，不但没有增加开发的难度，反而降低了，低到让我觉得有点LOW。如图：xxxxapi.php：这是接口文件，位于项目根目录下。是所有按功能拆分的云函数的执行入口，比如adminapi.php下的sendadminsms函数。部署时，云函数调用sendadminsms，API网关为：/admin/sendadminsms。注意：多个接口文件中的函数名称不能重复，因为云端的云函数名称不能重名。ctrl目录：类似其他项目的控制模块，负责业务代码。例如：AdminCtrl.php。model目录：数据库模块，负责数据库操作，如：AdminModel.php。vendor中的simplescf：核心库我专门为腾讯云函数开发了一套核心库，实现了云函数的动态调用、动态控制、单元测试的执行、数据库封装、日志处理以及非常方便的ORM数据库封装（支持TCB免费数据库）等，类似微信云云开发的SCF版本。微信云的云开发是非常受限的。本框架可以同时支持WEB、小程序、APP。整体调用顺序：部署后客户端-->API网关-->xxxapi.php入口函数--->ctrl处理业务逻辑-->模型处理数据。项目非敏感部分截图Step4：项目分工进度在Serverless项目管理中，不能简单的按照传统的功能模块划分任务，而是以API为单位指定负责人，工作量进行评估。测试也以API为单位。如果项目涉及协作，一个完整的流程建议：PM预先创建每个API，并制定输入和输出参数。轻创是预先定义调用入口函数；深度创建不仅创建了入口函数，还将DEMO代码部署到云端，深度创建可以有效的让前后台异步开发。安排API接口负责人，制定开发计划。每个人负责的API任务尽可能是通用的。比如这个人基本负责raceapi.php接口文件里面的功能。将项目的公共功能提炼成公共模块。建立良好的单元测试，让本地化测试（单元测试TDD）高保真模拟云端执行，是非常重要的。第五步：项目部署Serverless部署基本分为三种：管理后台、Serverless框架CLI和SDK。管理后台：要打开网页，要给会员账号密码，要登录，可能多人同时需要，就是两个字“麻烦”。ServerlessFrameworkCLI：需要一个yaml配置文件，需要自己修改配置。如果配置错误，您的项目可能会被刷新，您需要提供密钥，或者进行某种二维码扫描。这真是中国特色，真想吐槽。作为我的重度用户，我偶尔会错误配置并刷新现有配置。为此，我差点把桌子砸了。SDK：你别想了，你会自己研究SDK部署吗？一个触发器可能需要两个产品SDK的配合。因为我是腾讯云Function的devops开发者，我是SDK的重度用户，但是我觉得单个项目开发者不会去做这个东西！没有足够的时间浪费在雇人为您部署它！项目中采用微服务模式进行部署。可能有几百个API，也就是几百个云函数。顶多我一个项目部署了近300个云函数。如果用CLI部署，我是不是要折腾300个yaml？，中间如果要更新某个功能代码，就得配置更新代码的yaml。如果我想同时更新多个功能代码怎么办？这三百你不能出错。这么一想，CLI对于我们这个小项目来说还是很尴尬的。那么CLI有什么优势呢？可以和CI完美结合，通过CI可以实现项目的自动部署，所以对于大型项目很有用，但是对于小项目，单元测试都不写，你还跟我说CI？所以整体上，大家觉得中小项目在部署这个工作上会不会遇到很大的问题。我的方案是自己搭建一个GUI部署工具，一键更新（二级部署，更新功能代码），隐式实现项目管理工作的引导功能。将近2个月后，该工具将开源供大家免费使用。作者：Sheldor，知乎账号：小竹君，欢迎关注，了解更多Serverless实战经验。
