泽民博客 ☰ Menu

severless

https://www.jdon.com/soa/serverless.html
什么是Serverless无服务器架构？
　　Serverless不代表再也不需要服务器了，而是说：开发者再也不用过多考虑服务器的问题，计算资源作为服务而不是服务器的概念出现。Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署，你甚至可以管理某个具体功能或端口的部署，这就能让开发者快速迭代，更快速地开发软件。



　　以亚马逊的AWS Lambda为案例，Lambda能让不用思考任何服务器，也就是说，不用你处理服务器上的部署、服务器容量和服务器的扩展和失败容错，还有服务器上选择什么OS操作系统，语言的更新，日志等等问题。你的应用程序只需要和多个第三方的API或服务打交道，也可以自我创建一个无服务器的API。



　　Serverless有以下几个特点：



Serverless意味无维护，Serverless不代表完全去除服务器，而是代表去除有关对服务器运行状态的关心和担心，它们是否在工作，应用是否跑起来正常运行等等。Serverless代表的是你不要关心运营维护问题。有了Serverless，可以几乎无需Devops了。



Serverless不代表某个具体技术，有些人会给他们的语言框架取名为Serverless，Serverless其实去除维护的担心，如果你了解某个具体服务器技术当然有帮助，但不是必须的。



Serverless中的服务或功能代表的只是微功能或微服务，Serverless是思维方式的转变，从过去：“构建一个框架运行在一台服务器上，对多个事件进行响应。”变为：“构建或使用一个微服务或微功能来响应一个事件。”，你可以使用 django or node.js 和express等实现，但是serverless本身超越这些框架概念。框架变得也不那么重要了。



　　Serverless规模扩展性方面由于充分利用云计算的特点，因此其扩展是平滑的，同时由于Serverless是基于微服务的，而一些微功能微服务的云计算是零收费，这样有助于降低整体运营费用。



　　将来下述具体应用将可能使用Serverless架构：



静态网站的管理
替代WordPress(Serverless Blog Project)
个人媒体服务器(less!)
物联网Iot或家庭自动框架或项目 (使用 AWS IoT)

无服务器架构
　　无服务器架构是传统的云计算平台延申，是 PaaS向更细粒度的BaaS和FaaS的发展，Serverless=BaaS+FaaS+…！ Serverless 真正实现了当初云计算的目标！



BaaS是后端即服务，FaaS是函数即服务！根据Martin Fowler网站无服务器架构定义：
BaaS：无服务器首先用于描述显着或完全包含第三方云托管应用程序和服务的应用程序，以管理服务器端逻辑和状态。这些通常是“富客户端”应用程序 - 认为单页网络应用程序或移动应用程序 - 使用庞大的云可访问数据库生态系统（例如，Parse，Firebase），身份验证服务（例如，Auth0，AWS Cognito），以及等等。这些类型的服务以前被描述为“ 后端即服务 ”。
FaaS：无服务器也可以指服务器端逻辑仍然由应用程序开发人员编写的应用程序，但是，与传统体系结构不同，它在无状态计算容器中运行，这些容器是事件触发的，短暂的（可能只持续一次调用），并且完全由第三方。想到这一点的一种方法是“作为服务的功能”或 “FaaS”。AWS Lambda是目前功能即服务平台最受欢迎的实现之一，但还有很多其他也是。
　　Serverless是在传统容器技术和#服务网格上发展起来，更侧重让使用者只关注自己的业务逻辑即可。



　　2018年Google推出Serverless世界的利器：#Knative ，可在任何公有私有云上实现无服务器架构，这样用户使用无服务器编程可以不限于特定的云平台如亚马逊AWS。
　　
　　https://martinfowler.com/articles/serverless.html
　　https://www.jdon.com/53390
　　https://www.jdon.com/49817
　　
　　https://www.jdon.com/52637
　　
　　就在您认为自己理解云计算的时候，出现了一个新概念：无服务器。



外行人对“云”的理解与“无服务器”的定义非常接近，它可以让你挠头并想知道，“等等，它们究竟有何不同？”



什么是云计算？



云计算是一个流行语，已被使用和滥用到可能对不同的人意味着非常不同的事情。为了找到一些共识，让我们看看有关此问题的当局对此有何看法。



来自亚马逊：



“云计算是通过与随收随付你去定价互联网通过云服务平台的按需交付的计算能力，数据库存储，应用程序和其他IT资源。” 来源



以下是微软的定义：



“简而言之，云计算是计算服务的交付 - 服务器，存储，数据库，网络，软件，分析，智能以及更多 - 通过互联网（”云“）提供更快的创新，灵活的资源和规模经济。通常，您只需支付您使用，有助于降低运营成本，更高效地运行您的基础设施云服务，和规模随着业务需求的变化。” 来源



将其归结为基本要素：计算机服务通过互联网提供，您需要为使用的内容付费。这是有效的，它可以扩展。很简单。



云计算有四种类型



根据微软的说法，有四种主要的云计算类型：



基础设施即服务（IaaS）
平台即服务（PaaS）
软件即服务（SaaS）
无服务器
为了专注于手头的问题，我们不会费心深入了解这些云计算类别的定义。但是，为了进一步了解无服务器是什么以及它与其他形式的云计算有什么关系，值得注意的是这四种云计算类别相互叠加，因此它们通常被称为“云计算堆栈” “。



什么是无服务器计算？



“无服务器”有点用词不当，或者至少是一个有点误导性的标签，因为世界上某个地方的大型仓库中，肯定有实际的服务器支持“无服务器”计算。



但是，这个术语指的是什么最终使无服务器如此创新和有价值：使用无服务器，您根本不必考虑服务器。所以，实际上，它是“无服务器的”，虽然不是技术上或字面上的，而且这就是术语的来源。微软表示，“设置，容量规划和服务器管理对你来说是不可见的，因为它们由云提供商处理” ，“无服务器应用程序不需要你配置，扩展和管理任何服务器”。据亚马逊称。



服务器消失（从您关注的列表中）



传统上，如果您是开发人员，则需要为新应用或网站设置和维护服务器做大量工作。如果您不是交易系统管理员，这个过程可能会令人沮丧和耗时。更糟糕的是，如果您犯了错误并且错误地配置了某些内容，则可能会导致严重后果 - 例如安全漏洞，停机时间或资源使用效率低下（您最终支付的费用超过托管费用）。



而且，这正是无服务器如此吸引人的原因 - 所有这一切都得到了解决。为您完成了配置服务器的繁琐工作，您不必担心确保一切安全，最新和优化的持续负担。所有与服务器相关的问题都是从无需服务器的云架构中解决的。



托管资源按需提供



为了进入技术方面的更多技术方面，站点/应用程序的功能被拆分为单独的容器，资源根据需要应用于特定功能。无论您的网站/应用程序需要运行本身，都可以在银盘上进行。当您的应用程序需要更多内存时，它会实时分配更多内存。当您的应用程序收到一千个Web请求时，它会为您提供计算周期和带宽以提供这些请求。您的应用程序需要计算机资源，无服务器架构可确保它在需要时具有所需的功能。而且，这是无服务器的另一个定义特征……



精确配置资源



无服务器提供精确的资源单元以响应应用程序的需求。与传统云计算相比，需要提前分配大量资源，以便在需要时可用。



使用传统的云托管，您可以添加2GB或4GB的RAM，以便您的应用程序有足够的内存可用于峰值使用。使用Serverless，您的应用程序可能会请求并准确分配3.76GB的RAM来完成某项任务。分配正是满足app / site需求所需的。



使用传统的云计算，无论您是否在使用无服务器时，计算机资源都专用于您，您只需从大量资源中动态提取您所需的内容。



只支付您使用的费用



虽然云计算的通用定义是“只为你使用的东西付费”，但无服务器更真实地兑现了这一承诺。当然，当您使用基础架构即服务时，您只需为您要求的服务器资源付费，但无论您的应用程序目前是否使用全部8GB，您仍然需要支付8GB内存。



使用无服务器时，您只需支付执行功能所需的确切资源量。如果您的网站目前只消耗3.39 GB的内存，那就是您需要付出的代价。 对于大多数网站而言，由于需求波动，资源使用会不断变化。无服务器自动适应这些波动（称为弹性的术语），因此您只需支付应用程序时刻使用的内容。



这意味着您的无服务器托管帐单将逐月变化，具体取决于您的网站使用的内容。如果您的月份较慢，您的账单可能会非常低。如果下个月您的流量爆炸，您的账单将会更高。通过这种方式，无服务器计算非常有效。由于您的托管计划会自动调整上下，因此浪费很少。缺点是这种波动会使计费变得不可预测，这使得预算难以预测。对可预测预算有很大价值的组织可能更适合更传统的托管选项，如VPS计划。



总结



无服务器托管提供了一些与常见云计算相比的独特优势，使其成为许多企业的有吸引力的选择：



无需管理服务器或与服务器交互
根据需要提供计算资源以自动扩展站点
资源是精确分配而不是分块
您只需为消耗的资源付费



https://www.jdon.com/52600
过去几年我一直在无服务器社区中试图弄清楚如何帮助其他人理解“无服务器”意味着什么。对于我来说，最近几个月谈论无服务器一直试图避免谈论技术，并试图开始讨论该方法的商业价值。我甚至写过关于其中一些内容的博客：



云2.0:代码不再是王者，无服务器已经废除了它



我注意到的一件事是，过去几年我以各种不同的方式改变了自己的想法。我现在对特定的技术选择不太感兴趣，对组织内部如何实施技术的战略方法更感兴趣，以及组织需要实现的过渡以接受无服务器的思维模式。



然后昨天我偶然发现了斯沃德利在2016年写回一篇关于组织的普遍学说的文章。我意识到了……



无服务器是一种学说



什么是学说？为了我们的目的，一个学说是你从经验中学到的一套原则，并编成了一些书面形式，例如一套最佳实践……就像我的最佳实践博客文章……



考虑到“无服务器作为一种学说”，我认为当有人将任何技术或服务称为“无服务器”时，我发现它真的令人沮丧。最常见的例子是当有人说“无服务器”这个词的意思是“作为服务的函数”或FaaS时 - 它没有。FaaS是无服务器方法的主要支持技术之一，FaaS本身并不是无服务器的。



让我再说一遍：



FaaS不是无服务器的



让我解释…



无服务器特点：




  1. 将您的想法从代码转移到配置



无服务器应用程序不是由代码定义，而是由定义资源的配置定义，以及触发将这些资源粘合在一起的少量代码的事件。



代码变得更加关注独特的业务逻辑



配置定义非业务关键应用程序。




  1. 将您的思维从高量代码行转移到低量代码行



今天的代码是明天的技术债务



在我的世界中，最好是零代码（全部在配置中）



我们越可以转向配置，我们需要的代码行越少




  1. 将您的想法从架构服务转移到消费服务



如果存在可以做我们想要的服务，那么我们就有理由想要构建该服务。



因此，除非业务至关重要，否则不要构建该服务。




  1. 将您的想法从拥有工作量转移到不再使用工作量



在运行系统时，您应该只关注业务关键系统。其他一切都不重要。



没有实例，服务器或容器，除非没有其他方法



如果我不需要，为什么我要再管理这些了！除非它是关键业务，否则这些是技术预算中最大的浪费时间之一！



向上和向下缩放应尽可能由服务处理



向上和向下缩放至关键是关键。



这包括基本上配置服务器以在其上运行某些内容的服务。在AWS上运行RDS数据库之类的东西在这一点上是有问题的，因为您必须配置实例，并且缩放是手动的。这也是为什么RDBMS通常不合适存在我的无服务器应用程序视图中的原因 。



数据层应该是特定于应用程序的 - 没有“一刀切”的方法



这个对我来说是关键的，它只是挑战“一切都必须是RDBMS”的假设。



有没有说你不能使用RDBMS，但记得要顾及缩放和管理学说太多。



但是，在过去几年中我遇到的几乎所有场景中，应用程序数据层都有比RDBMS更好的解决方案。



没有有效的业务案例，没有新的服务或技术



我经常让开发人员来找我说“我能做到这一点的唯一方法就是使用X服务/技术”。但愿这永远不会成真。



我的回答是将他们送走并要求他们写一个“业务案例”。在他们编写了一个业务案例（通常需要几个，因为他们不知道是什么）后，我告诉他们离开并确定他们是否可以使用当前的技术堆栈来实现他们所需要的。答案几乎总是肯定的，或者如果不是，它通常是一种完全不同的技术。



例如，我有一个开发人员来问我是否可以使用RedShift，我把他送走了，经过一轮“商业案例”宾果游戏，他意识到他可以使用雅典娜来实现同样的目标。它没有服务器，符合原则。



开发人员需要了解他们必须证明决策的合理性，当他们意识到他们必须了解他们所处的业务时，他们往往会成为更好的开发人员。



企业中的所有技术人员都在那里提供商业价值



企业中的人的工作不是提供技术，而是提供商业价值。



这应该是显而易见的，但对大多数开发人员来说并非如此。



现在，对我而言，无服务器是一种学说



https://www.jdon.com/48109



https://www.jdon.com/colorUML.html
https://baijiahao.baidu.com/s?id=1657961534715524713&wfr=spider&for=pc



Kubernetes 和 Serverless 之间有什么区别？



Serverless 是一种云模型，可以帮助你摆脱服务器和基础架构的束缚。其目的是省却一定的成本，缩短产品上市的时间，减少运维与开发团队之间的摩擦。具体来说，你可以想象有一堵墙能够吸收你的代码，并负责执行代码，这堵墙就是无服务器。



你提供代码，供应商负责所有其他工作。



最常见的 Serverless 实现是带有SDK的无状态容器，负责将你的代码集成到系统中，并根据资源的使用情况向你收费。在大多数情况下，我们只需将我们的函数上传到云（函数即服务，Functions as a Service，即FaaS），然后通过HTTP调用这些函数。主流云提供商都提供了类似的云体验：



亚马逊：AWS Lambda（https://aws.amazon.com/lambda/）
微软 Azure：Azure Functions（https://azure.microsoft.com/en-us/services/functions/）
谷歌云：Cloud Functions（https://cloud.google.com/functions/）
当然并不是真的没有服务器。只不过你看不到它们，因为它们被供应商藏了起来，并用它们来提供服务。服务器仍在运行，但是你看不到内存、CPU 或磁盘空间。你只需关注代码，将精力放在真正需要的地方。



那么，什么是 Kubernetes？你可以将 Kubernetes 视为运行分布式系统的框架，这些系统源自 Docker 镜像。Kubernetes 能够满足规模扩展的需求，还能够管理好部署以及负载平衡。Kubernetes 利用简洁且可重复使用的 YAML 文件来书写配置，部署出来的环境可轻松复制。



Kubernetes 是非常便捷的基础设施。



你只需要更改一些配置文件，就可以全权掌控容器实例（服务和Pod）、网络以及部署。Kubernetes 的功能包括扩展规模、故障转移以及部署模式等等。



与无服务器同样，Kubernetes 可以帮助系统管理员轻松地完成复杂的体系结构。这项技术可以将费时费力的传统部署转变成智能快捷的方式。无运维的时代就要来了！



Kubernetes 有哪些优点？



Kubernetes 最大的优势在于，你可以像处理常规服务器一样处理集群，同时还无需管理物理机器。从逻辑上讲，服务器和集群组件是对等的关系。你可以把 Pod 和服务当成虚拟机来实例化。此外，你还拥有网络、存储等等。因此，你可以通过操控底层的集群来深入控制所有组件。



与无服务器平台相比，Kubernetes 的优势如下：



与过往技术有良好的兼容性。如果你正在使用容器，那么毫不费力就可以移动到 Kubernetes上；如果你没有使用容器，那么也只需将应用程序组件容器化。
良好的控制。
供应商的限制较少，Kubernetes 就是单纯的 Kubernetes，而 Docker 容器也只是 Docker 容器而已。从理论来讲，你只需点一下鼠标即可将基础架构移动到其他地方。
可以微调每个组件的功能。
可在自建的基础设施上运行（比如可以用于开发环境，或者极端情况，或者只是你想尝试些疯狂的东西）。
成本预测。你只需支付集群资源的费用，比无服器更好预测。



Serverless 的优点是什么？



Kubernetes 在减少系统管理员工作方面迈出了一大步，但还没有减少到零。Serverless 可以从根本上避免所有系统管理组件，你唯一需要关心的就是源代码。就好像一组乐高积木，将它们拼在一起。每一块都可以单独运行，你只需要让积木块之间正确沟通即可，仅此而已。由于 FaaS 解决方案需要思想上的转变，因此似乎很难实施。在这种情况下，你可以采用一些“软”Serverless解决方案——无需更改即可直接托管你的应用程序。Heroku 就是这类的一个解决方案，它从服务器和传统的开发运维中进行了抽象，提供了无运维、无服务器的体验，可以促进应用程序的开发，减轻所有托管负担。



Serverless 会终结 Kubernetes 吗？



现如今，Serverless还是一项很新的技术，第一版的 AWS Lambda 于2014年发布。同年，Docker 也迈出了第一步（第一版于2013年发布，但我不确定发布时是否可以投入生产环境）。而 Kubernetes 诞生于2014年。因此，我们可以说，Serverless与容器几乎同时问世，不分伯仲。从这个角度来看，Serverless并非诞生于 Kubernetes 之后，因此我们不能认为Serverless将取代容器。二者只是Web应用程序中实现托管的两种不同的方法。也许在某些情况下，你可能更喜欢Serverless，而有些时候则会更喜欢 Kubernetes。那么具体选择哪个呢？不得不说这要视具体情况而定。普通的咨询师与优秀的咨询师之间的区别就在于，优秀的咨询师了解许多互补的解决方案，并能够根据实际情况找到最佳解决方案。



总结



在本文中，我们分别讨论了这两种解决方案的优点，你可以根据对这两项技术的了解找到适合自身的最佳解决方案。你可以使用谷歌云等大型云服务，实现任何解决方案。你需要花点时间尝试一下这些工具，并了解它们的优点和缺点。



云函数 SCF 简介
云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。SCF 是实时文件处理和数据处理等场景下理想的计算平台。



https://cloud.tencent.com/product/scf?fromSource=gwzcw.3483713.3483713.3483713&utm_medium=cpc&utm_id=gwzcw.3483713.3483713.3483713



https://baijiahao.baidu.com/s?id=1637926048198595596&wfr=spider&for=pc
Serverless 是一种“无服务器架构”模式，它无需关心程序运行环境、资源及数量，只需要将精力聚焦到业务逻辑上的技术。基于 Serverless 开发 web 应用，架构师总是试图把传统的解决方案移植到 Serverless 上，虽然可以做到既拥有 Serverless 新技术带来的红利，又能维持住传统开发模式的开发体验。但是，Serverless 技术带来的改变可能不止这些，可能是颠覆整个传统 web 应用开发模式的革命性技术。



开发模式



业务应用的开发模式发展是从一体到分裂为前后端，再到前后端融合为一体过程。



注意：后面所说的后端特指后端业务逻辑。



早期，一体



没有前后端的概念，那时候的应用都是单机版，所有的业务逻辑都写一起，开发人员不需要关心网络请求，这个时期的工程师完全专注于业务代码的开发。随着业务规模的增长，也暴露了很多问题：



高并发问题
高可用问题
说明：业务应用升级困难等一些问题，不是本篇文章所关心，所以就不一一列举出来。



现在，分裂



前端 + 高可用高并发运维裹挟着的后端业务逻辑：



说明：现在 Serverless 技术已经出现有一段时间了，不但没有解决开发体验的问题，反而带来更多开发体验问题，所以，在这里我并没有突出 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 的前后一体化框架帮我们迈出右脚。同时，请别再叫我前端开发工程师，我是业务应用开发工程师。




  1. 无服务器（Serverless）计算是什么
    serverless
    云计算涌现出很多改变传统IT架构和运维方式的新技术，比如虚拟机、容器、微服务，无论这些技术应用在哪些场景，降低成本、提升效率是云服务永恒的主题。



过去十年来，我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现，带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们看作某种形式的商品——厂商提供服务，我们掏钱购买。



过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，做到当访问时，调入相关资源开始运行，运行完成后，卸载所有开销，真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。



Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。



国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出Serverless产品，Serverless也从概念、愿景逐步走向落地，在各企业、公司应用开来。




  1. 理解Serverless技术—FaaS和BaaS
    Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术，分为两类：FaaS和BaaS。



2.1 FaaS（Function as a Service，函数即服务）
FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。



FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。



FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。



在迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。



相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。



FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。



大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。



2.2 BaaS（Backend as a Service，后端即服务）
BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。理解BaaS，需要搞清楚它与PaaS的区别。



首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。



BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。




  1. 无服务器（Serverless）计算如何工作？
    与使用虚拟机或一些底层的技术来部署和管理应用程序相比，无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。



拿计算来讲，这种抽象有一个特定函数和抽象的触发器，它通常是一个事件。以数据库为例，这种抽象也许是一个表，而触发器相当于表的查询或搜索，或者通过在表中做一些事情而生成的事件。



比如一款手机游戏，允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时，请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数，或者无服务器函数，这些函数再从数据库表中获取到数据流，返回包含前五名分数的一定格式的数据。



一旦构建完成，应用程序的功能就可以在基于移动和基于 Web 的游戏版本中重用。



这跟设置服务器不同，不是必须要有Amazon EC2实例或服务器，然后等待请求。环境由事件触发，而响应事件所需的逻辑只在响应时执行。这意味着，运行函数的资源只有在函数运行时被创建，产生一种非常高效的方法来构建应用程序。




  1. 无服务器（Serverless）适用于哪些场景？
    serverless
    在现阶段，Serverless主要应用在以下几个场景。首先在Web及移动端服务中，可以整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。在IoT场景下可高效的处理实时流数据，由设备产生海量的实时信息流数据，通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，通过上传事件触发多个函数，分别完成高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便大家思考。



4.1 场景一：应用负载有显著的波峰波谷
Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。



业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。



4.2 场景二：典型用例 - 基于事件的数据处理
视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。



开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。




  1. Serverless 的问题
    对于企业来说，支持Serverless计算的平台可以节省大量时间和成本，同时可以释放员工，让开发者得以开展更有价值的工作，而不是管理基础设施。另一方面可以提高敏捷度，更快速地推出新应用和新服务，进而提高客户满意度。但是Serverless不是完美的，它也存在一些问题，需要慎重应用在生产环境。



5.1 不适合长时间运行应用
Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，应用将会需要一个启动时间，即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求，那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用，又会比较消耗资源。这就需要我们对它做优化，如果频繁调用，这个资源将会常驻内存，第一次冷启之后，就可以一直服务，直到一段时间内没有新的调用请求进来，则会转入“休眠”状态，甚至被回收，从而不消耗任何资源。



5.2 完全依赖于第三方服务
当你所在的企业云环境已经有大量的基础设施的时候，Serverless 对于你来说，并不是一个好东西。当我们采用某云服务厂商的 Serverless 架构时，我们就和该服务供应商绑定了，那么我们再将服务迁到别的云服务商上就没有那么容易了。



我们需要修改一下系列的底层代码，能采取的应对方案，便是建立隔离层。这意味着，在设计应用的时候，就需要隔离 API 网关、隔离数据库层，考虑到市面上还没有成熟的 ORM 工具，让你既支持Firebase，又支持 DynamoDB等等。这些也将带给我们一些额外的成本，可能带来的问题会比解决的问题多。



5.3 缺乏调试和开发工具
当我使用 Serverless Framework 的时候，遇到了这样的问题：缺乏调试和开发工具。后来，我发现了 serverless-offline、dynamodb-local 等一系列插件之后，问题有一些改善。然而，对于日志系统来说，这仍然是一个艰巨的挑战。



每次你调试的时候，你需要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器，并不能总是快速地定位出问题在哪。后来，找了一个类似于 log4j 这样的可以分级别记录日志的 Node.js 库 winston。它可以支持 error、warn、info、verbose、debug、silly 六个不同级别的日志，再结合大数据进行日志分析过滤，才能快速定位问题。



5.4 构建复杂
Serverless 很便宜，但是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂，并且难以阅读及编写（JSON 格式），虽然CloudFomation提供了Template模板，但想要使用它的话，需要创建一个Stack，在Stack中指定你要使用的Template,然后aws才会按照Template中的定义来创建及初始化资源。



而Serverless Framework的配置更加简单，采用的是 YAML 格式。在部署的时候，Serverless Framework 会根据我们的配置生成 CloudFormation 配置。然而这也并非是一个真正用于生产的配置,真实的应用场景远远比这复杂。




  1. 总结
    云计算经过这么多年的发展，逐渐进化到用户仅需关注业务和所需的资源。比如，通过K8S这类编排工具，用户只要关注自己的计算和需要的资源（CPU、内存等）就行了，不需要操心到机器这一层。



Serverless架构让人们不再操心运行所需的资源，只需关注自己的业务逻辑，并且为实际消耗的资源付费。可以说，随着Serverless架构的兴起，真正的云计算时代才算到来了。



任何新概念新技术的落地，本质上都是要和具体业务去结合，去真正解决具体问题。虽然Serverless很多地方不成熟，亟待完善。不过Serverless自身的优越特性，对于开发者来说，吸引力是巨大的。相信随着技术的飞速发展，Serverless在未来还有无限可能！



云计算机经过这么多年的发展，逐渐进化到用户仅需关注业务和所需的资源。通过Swarm、K8S这些编排工具，容器服务让开发者的体验达到很完美的境界。我曾经觉得Docker可以替代虚机，用户只要关注自己的计算和需要的资源就行，不需要操心到机器这一层。但是因为Docker对资源的隔离不够好，各大云厂商的做法还是一个Docker对应一台虚机，不仅成本高，给用户暴露虚机也多余了。



用户为什么需要关注业务运行所需要的CPU、内存、网络情况？还有没有更好的解决方案？Serverless架构应运而生，让人们不再操心运行所需的资源，只需关注自己的业务逻辑，并且为实际消耗的资源付费。可以说，随着Serverless架构的兴起，真正的云计算时代才算到来了。



容器在开发模式方面并没有提出新的想法，大家还是在用传统的那一套开发模式，需要写一个大而全的后端服务。与之对比，Serverless架构是事件驱动的，这样让后端的开发体验变得跟前端和移动端很类似了。针对不同客户的需求，先让其购买好相关的资源，然后一个个填坑，给不同的产品添加各种事件处理逻辑就行。这就跟iOS开发一样，界面写出来，然后处理一个个事件就好了，大家都很容易理解这种开发模式。



image.png
AWS Lambda体验
AWS在2014年11月的re:Invent大会上推出Lambda，经过将近三年的发展，已经达到了非常完善的程度。Lambda主要有三个作用。



跟API Gateway结合起来，方便快捷地提供API服务。
串联关键产品，比如在DDB插入一条新数据之后，触发Lambda执行，读取新记录送给搜索引擎建索引。
扩展功能，比如Cognito User Pool提供非常多的点，方便用户在登录的时候增加自己的处理逻辑。



image.png
AWS Lambda支持多种语言开发，比如C#、Java、Node.js和Python，拥有广泛的群众基础。



AWS Lambda在除北京之外的所有region均可用。AWS中国支持的产品可以参考：地区表。



image.png
Serverless Reference Architecture: Mobile Backend是一个非常好的实例，讲述了如何通过Serverless架构实现一个App。



这个App的主要功能类似Evernote，支持上传图片，编写和上传文章。功能非常简单，但是涉及到的产品非常多，玩法也非常老练。



1 2 3
image.png
image.png
image.png
整个demo用到的云产品和它们相互之间的关系如下图所示。除了Lambda本身，IAM、API Gateway等产品也发挥了巨大的作用。



$ tree cloudformation lambda-functions
cloudformation
├── config-helper.template
├── mobile-backend-no-cloudfront.template //去除CloudFront相关配置的template文件。在CloudFormation控制台上传该文件。
└── mobile-backend.template //如果CloudFront可用的话，上传这个template文件也OK。
lambda-functions //Lambda代码已经压缩好并放到一个公共的S3 bucket里面，所以不用管这些代码。
├── search
│ └── index.js //CloudSearch搜索接口的代码
├── stream-handler
│ └── index.js //DDB触发建索引的代码
└── upload-note
└── index.js //新增文章接口的代码，主要是写DDB。
image.png
配置
CloudFormation真的很方便，template上传之后，相关的资源就创建和设置好了。cloudformation目录下有两个template文件，只需上传mobile-backend.template，它会把config-helper.template加载好。阿里云对应的产品是：资源编排ROS。



image.png
看起来API Gateway、Cognito、CloudSearch这几款个产品对CloudFormation支持的并不好，所以还需要通过文章中那么多命令行和Web控制台上的设置。



为了能运行这些命令，要把AWS CLI配置好，region设置为us-east-1（弗吉尼亚北部），因为文章中存放Lambda代码压缩包的S3也是在us-east-1区域的。



$ aws configure

AWS Access Key ID [******X3CA]:
AWS Secret Access Key [******Qo3J]:
Default region name [us-east-1]:



$ cat ~/.aws/config
[default]
region = us-east-1
配置里面的一些坑
一个坑是CloudFront可能没有初始化好，导致CloudFormation创建失败。懒得去配置了，所以我干脆删除了CloudFormation里面CloudFront相关的配置。这样并不会影响体验。



image.png
image.png
CloudFormation有一个资源创建失败后，会rollback。它把资源的创建当做一个事务来处理，全部成功才行。



image.png
客户端使用Swift 2.3写的。因为代码也比较简单，所以Convert到3.0就行。后面接着会报Ambiguous use of ‘continue’错误，类似下面这样的代码使用一对小括号括住block就行。



let noteApiClient = APINotesApiClient(forKey: “USEast1NoteAPIManagerClient”)
noteApiClient?.notesPost(noteRequest).continue ({ (task) -> AnyObject! in



if let error = task?.error {

    print("Failed creating note: [\(error)]")

}

if let exception = task?.exception {

    print("Failed creating note: [\(exception)]")

}

if let noteResponse = task?.result as? APICreateNoteResponse {

    if((noteResponse.success) != nil) {

        print("Saved note successfully")

    }else {

        print("Unable to save note due to unknown error")

    }

}

return task }) 程序运行起来之后，Upload Image到S3没有问题。但是上传文章的时候会报forbidden的错误。Xcode里面会打印下面这个错误。通过Charles抓包，发现服务器端给了错误提示。


image.png
需要在Usage Plans里面Add API Stage里面操作一下，API和Stage对上就好了。文章中没有提到这个配置。



image.png
一些技术细节
App直接面对API Gateway和S3，要先从Cognito Identity Pool获取到一个id（Unauthenticated），这个Pool对应MobileClientRole角色，可以看一下这个角色的具体配置，主要是针对S3和API Gateway相关action的allow 。这里直接使用了API Gateway生成的SDK，结合Cognito Identity Pool用着也挺方便。API Gateway也支持使用Cognito UserPool做验证器，不需要SDK，用起来更加简单一些，详细信息可以参看：对AWS Cognito的一些理解
。



image.png
image.png
/notes的post接口交给NotesApiFunction Lambda来处理，在控制台可以看得很清楚。



image.png
DDB变动会触发执行DynamoStreamHandlerFunction这个Lambda，从配置里面也可以很清楚看到这个trigger。



image.png
效果
S3里面可以看到图片。



image.png
Dynamo DB里面可以看到Post数据。



image.png
但是CloudSearch里面Searchable Documents却一直都是0。



image.png
可以看看DynamoStreamHandlerFunction这个Lambda的数据，发现调用都失败了。



image.png
去CloudWatch里面看看。提示TypeError: Cannot read property ‘S’ of undefined。



image.png
对着stream-handler/index.js看了一下，发现拿到Dynamo DB的数据之后，要通过.S将其转型为字符串类型。再对着文档看看，其实是没有毛病的，所以这个问题还不知道怎么解决。



function createSearchDocuments(records) {
var searchDocuments = [];



for(var i = 0; i<records.length; i++) {

    var record = records[i];



    if (record.eventName === "INSERT") {

        var searchDocument = {

            type : 'add',

            id : record.dynamodb.Keys.noteId.S,

            fields : {

                headline : record.dynamodb.NewImage.headline.S,

                note_text : record.dynamodb.NewImage.text.S

            }

        };

        searchDocuments.push(searchDocument);

    }

}

return searchDocuments; } 这个问题突然就消失了，建索引和检索功能都正常了，amazing~


image.png
image.png
费用
Lambda根据使用内存和调用次数收费。内存最低是128MB。具体信息请参看：Lambda 定价详情。



image.png
image.png
这个App使劲玩，花不了几块钱的。Lambda累计运行了240秒，没有花钱，主要是S3和数据传输花了点钱。



image.png
image.png
Serverless成功的关键
拥有丰富的产品，并且打通所有的云产品，是Serverless成功的前提条件。Lambda不适合处理复杂的业务逻辑，比较适合作为胶水代码，粘合关键的产品。另外就是Lambda不管怎么完善，可能只能解决80%的问题，剩下20%的逻辑需要用户自己写服务，通过docker发布，然后给Lambda或者用户使用。这种混合的编码方式可能是未来的主流开发模式。



image.png
Serverless的主要优点
开发者更加专注于业务逻辑，开发效率更高。开发一个典型的服务器端项目，需要花很多时间处理依赖、线程、日志、发布和使用服务、部署及维护等相关的工作，基于Serverless架构则不需要操心这些工作。
用户为实际使用的资源付费。用户购买的ECS使用时间一般不到5成，但是为另外5成闲置时间付费了。Lambda按照运行的时间收费，成本会低很多。
NO Architecture，NO Ops。架构师的责任是设计一个高可用、高扩展的架构。运维负责整个系统稳定可靠地运行，适当缩减和增加资源。大型云厂商能保证产品的高可用，Serverless架构本身就是高扩展的。Serverless不再需要服务器端的工作人员，给客户节省了大量的资源。架构师和运维的同学应该好好思考一下未来的出路了。架构师可以转型去做销售，整理用户的需求，然后写写CloudFormation的template就好了。
还是成本。IT行业一些领先的公司基础设施非常完善，开发工程师写好代码，然后通过发布平台发布，感觉也是挺方便的。比起Serverless的架构，成本还是要高不少。
机器成本。日常、预发、线上，1+1+2=4台服务器少不了。
时刻要关注业务数据，盘点资源，看看是否需要扩容和缩减资源。扩容容易，缩减难，造成大量资源闲置。
全链路压测是不是很烦？
Serverless的主要缺点
排查问题困难，因为逻辑散落在各处，一个操作可能触发成百上千个Lambda执行。AWS的X-Ray和CloudWatch等产品可以帮助用户排查问题。



image.png
准备runtime需要时间，流量瞬间爆发容易导致超时。



带状态的Lambda写起来很困难。



Lambda运行有诸多资源限制，比如运行时长、内存、磁盘、打开的文件数量等。



image.png
厂商锁定。云计算是赢者通吃的行业，大而全的云厂商优势巨大，Serverless加剧了这种趋势。以前用户还需要自己写很多服务器端的逻辑，迁移的时候，把服务器端代码重新部署一下。采用Serverless架构之后，代码都是各个平台的Lambda代码片段，没法迁移。从客户的角度来看，是不希望自己被某家云厂商所绑架的。所以云计算行业需要做很多标准化的工作，方便用户无缝在各种云之间迁移。



阿里云对Serverless的支持情况
阿里云在今年四月份南京云栖大会上推出了自己的Serverless产品：函数计算，目前只支持API Gateway和OSS，并且只能在华东2区域使用。还没有形成体系，很难满足用户多样的需求。



推广Serverless不是一件容易的事情，一是现有产品上云要接入的东西有点多，比如售卖、权限、风控、服务等级等，未来还需要接入Serverless。开发团队很累。第二个是，现有大量的产品要一个个去推动做改造，不是一件容易的事情。



不过阿里云也在很努力完善对Serverless的支持，未来可期。函数计算携手API网关轻松实践Serverless架构



image.png
云栖社区有一些相关的文章：阿里云 Serverless Computing，讲得非常好，可以了解一下。



MBaaS/MPaaS为什么不赚钱？
移动开发领域最早有一些厂商提供移动推送、Crash收集分析、移动数据分析等基础服务，也就是MPaaS。然后逐渐有一些厂商开始提供数据库、存储、配置等相关的服务，管理员在Web控制台上操作，移动端直接使用这些服务，不需要经过服务器端中转，这就是MBaaS。



目前移动开发领域的服务提供商，比如Facebook的Parse（已关闭）、Firebase（已被Google收购，现在很强大）、国内的LeanCloud都发展得不好。我觉得主要还是因为产品线不够丰富，只能满足一些小App或者App发展初期的需要。MBaaS/MPaaS依托主流云厂商丰富的产品线，通过类似Lambda机制将这些产品串联起来，应该会有不错的发展。



2016年12月初，当时我正在以一名 DevOps 咨询师的身份参与某客户的 DevOps 转型项目。这个项目是提升该部门在 AWS （Amazon Web Services）云计算平台上的 DevOps 能力。



自助服务的应用系统基于 Ruby on Rails 框架开发，前端部分采用 AngularJS 1.0，但是没有采用前后端分离的设计，页面代码仍然是通过 ERB 组合而成。移动端则采用 Cordova 开发。为了降低开发难度和工作量， 移动端的应用内容实际上是把 AngularJS 所生成的 Web 页面通过响应式样式的方式嵌入到移动端。但因为经常超时，所以这款 APP 体验并不好。



整套 Rails 应用部署在 AWS 上，并且通过网关和内部业务系统隔离。BOSS 系统采用 SOAP 对外暴露服务，并由另外一个部门负责。因此，云上的应用所做的业务是给用户展现一个使用友好的界面，并通过数据的转化和内部 BOSS 系统进行交互。系统架构如下图所示：



image
应用的交互流程如下



浏览器或者移动端通过域名（由 AWS Route 53托管）转向 CDN（采用 AWS Cloudfront）。
CDN 根据请求的内容类别进行区分，静态文件（图片，JS，CSS 样式等），会转向 AWS S3 存储。动态请求会直接发给负载均衡器 （AWS Elastic Load Balancer）。
负载均衡器会根据各 EC2 计算实例的负载状态将请求转发到不同的实例上的 Ruby On Rails 应用上。每一个应用都是一个典型的 MVC Web 应用。
EC2 上的应用会将一部分数据存储在关系型数据服务(AWS RDS，Relational Database Service）上，一部分存储在本地文件里。经过应用的处理，转换成 SOAP 请求通过 网关发送给 BOSS 系统处理。BOSS 系统处理完成后会返回对应的消息。
根据业务的需要，一部分数据会采用 AWS ElastiCache 的 Redis 服务作为缓存以优化业务响应速度。



团队痛点
这个应用经历了多年的开发，前后已经更换过很多技术人员。但是没有人对这个应用代码库有完整的的认识。因此，我们对整个团队和产品进行了一次痛点总结：



组织结构方面
运维团队成为瓶颈，60 个人左右的开发团队只有 4 名 Ops 支持。运维团队除了日常的事务以外，还要给开发团队提供各种支持。很多资源的使用权限被限制在这个团队里，就导致各种问题的解决进度进一步拖延。



image
随着业务的增长，需要基础设施代码库提供各种各样的能力。然而 Ops 团队的任何更改都会导致所有的开发团队停下手头的进度去修复更新所带来的各种问题。



应用架构方面
应用架构并没有达到前后端分离的效果，仍然需要同一个工程师编写前后端代码。这样的技术栈对于对于开发人员的要求很高，然而市场上缺乏合适的 RoR 工程师，导致维护成本进一步上升。经过了三个月，仍然很难招聘到合适的工程师。



多个团队在一个代码库上工作，新旧功能之间存在各种依赖点。加上 Ruby 的语言特性，使得代码中存在很多隐含的依赖点和类/方法覆盖，导致了开发进度缓慢。我们一共有 4 个团队在一个代码库上工作，3个团队在开发新的功能。1 个团队需要修复 Bug 和清理技术债，这一切都要同时进行。



技术债方面
代码库中有大量的重复 Cucumber 自动化测试，但是缺乏正确的并行测试策略，导致自动化测试会随机失败，持续集成服务器 （Jenkins）的 slave 节点本地难以创建，导致失败原因更加难以查找。如果走运的话，从提交代码到新的版本发布至少需要 45 分钟。如果不走运的话，两三天都无法完成一次成功的构建，真是依靠人品构建。



基础设施即代码（Infrastructure as Code）建立在一个混合的遗留的 Ruby 代码库上。这个代码库用来封装一些类似于 Packer 和 AWS CLI 这样的命令行工具，包含一些 CloudFormation 的转化能力。由于缺乏长期的规划和编码规范，加之人员变动十分频繁，使得代码库难以维护。



此外，基础设施代码库作为一个 gem 和应用程序代码库耦合在一起，运维团队有唯一的维护权限。因此很多基础设施上的问题开发团队无法解决，也不愿解决。



我参与过很多 Ruby 技术栈遗留系统的维护。在经历了这些 Ruby 项目之后，我发现 Ruby 是一个开发起来很爽但是维护起来很痛苦的技术栈。大部分的维护更改是由于 Ruby 的版本 和 Gem 的版本更新导致的。此外，由于 Ruby 比较灵活，人们都有自己的想法和使用习惯，因此代码库很难维护。



image
虽然团队已经有比较好的持续交付流程，但是 Ops 能力缺乏和应用架构带来的局限阻碍了整个产品的前进。因此，当务之急是能够通过 DevOps 提升团队的 Ops 能力，缓解 Ops 资源不足，削弱 DevOps 矛盾。



DevOps 组织转型中一般有两种方法：一种方法是提升 Dev 的 Ops 能力，另一种方法是降低 Ops 工作门槛。在时间资源很紧张的情况下，通过技术的改进，降低 Ops 的门槛是短期内收益最大的方法。



微服务触发点：并购带来的业务功能合并
在我加入项目之后，客户收购了另外一家业务相关的企业。因此原有的系统要同时承载两个业务。恰巧有个订单查询的业务需要让当前的团队完成这样一个需求：通过现有的订单查询功能同时查询两个系统的业务订单。



这个需求看起来很简单，只需要在现有系统中增加一个数据源，然后把输入的订单号进行转化就可以。但由于存在上述的痛点，完成这样一个简单的功能的代价是十分高昂的。几乎 70% 的工作量都和功能开发本身没有关系。



在开发的项目上进行 DevOps 转型就像在行进的汽车上换车轮，一不留心就会让所有团队停止工作。因此我建议通过设立并行的新团队来同时完成新功能的开发和 DevOps 转型的试点。



这是一个功能拆分和新功能拆分需求，刚好订单查询是原系统中一个比较独立和成熟的功能。为了避免影响原有各功能开发的进度。我们决定采用微服务架构来完成这个功能。



构建微服务的架构的策略
我们并不想重蹈之前应用架构的覆辙，我们要做到前后端分离。使得比较小的开发团队可以并行开发，只要协商好了接口之间的契约（Contract），未来开发完成之后会很好集成。



这让我想起了 Chris Richardson 提出了三种微服务架构策略，分别是：停止挖坑，前后端分离和提取微服务。



停止挖坑的意思是说：如果发现自己掉坑里，马上停止。



原先的单体应用对我们来说就是一个焦油坑，因此我们要停止在原来的代码库上继续工作。并且为新应用单独创建一个代码库。所以，我们拆分策略模式如下所示：



image
在我们的架构里，实现新的需求就要变动老的应用。我们的想法是：



构建出新的业务页面，生成微服务契约。
根据 API 契约构建出新的微服务。
部署 Web 前端到 S3 上，采用 S3 的 Static Web Hosting （静态 Web 服务） 发布。
部署后端微服务上线，并采用临时的域名和 CDN 加载点进行测试。
通过更新 CDN 把原应用的流量导向新的微服务。
删除旧的服务代码。
我们原本要在原有的应用上增加一个 API 用来访问以前应用的逻辑。但想想这实际上也是一种挖坑。在评估了业务的复杂性之后。我们发现这个功能如果全新开发只需要 2人2周（一个人月）的时间，这仅仅占我们预估工作量的20%不到。因此我们放弃了对遗留代码动工的念头。最终通过微服务直接访问后台系统，而不需要通过原有的应用。



在我们拆微服务的部分十分简单。对于后端来说说只需要修改 CDN 覆盖原先的访问源（Origin）以及保存在 route.rb 里的原功能访问点，就可以完成微服务的集成。



构建出新的业务页面，生成微服务契约
结合上面的应用痛点和思路，在构建微服务的技术选型时我们确定了以下方向：



前端框架要具备很好的 Responsive 扩展。
采用 Swagger 来描述 API 需要具备的行为。
过消费者驱动进行契约测试驱动微服务后端开发。
前端代码库和后端代码库分开。
前端代码框架要对持续交付友好。
因此我们选择了 React 作为前端技术栈并且用 yarn 管理依赖和任务。另外一个原因是我们能够通过 React-native 为未来构建新的应用做好准备。此外，我们引入了 AWS SDK 的 nodejs 版本。用编写一些常见的诸如构建、部署、配置等 AWS 相关的操作。并且通过 swagger 描述后端 API 的行为。这样，后端只需要满足这个 API 规范，就很容易做前后端集成。



image
部署前端部分到 S3 上
由于 AWS S3 服务自带 Static Web Hosting （静态页面服务） 功能，这就大大减少了我们构建基础环境所花费的时间。如果你还想着用 Nginx 和 Apache 作为静态内容的 Web 服务器，那么你还不够 CloudNative。



虽然AWS S3 服务曾经发生过故障，但 SLA 也比我们自己构建的 EC2 实例处理静态内容要强得多。此外还有以下优点：



拥有独立的 URL，很容易做很多 301 和 302 的重定向和改写操作。
和 CDN（CloudFront）集成很好。
很容易和持续集成工具集成。
最大的优点：比 EC2 便宜。
根据 API 契约构建出新的微服务
在构建微服务的最初，我们当时有两个选择：



采用 Sinatra （一个用来构建 API 的 Ruby gem） 构建一个微服务 ，这样可以复用原先 Rails 代码库的很多组件。换句话说，只需要 copy 一些代码，放到一个单独的代码库里，就可以完成功能。但也同样会面临之前 Ruby 技术栈带来的种种问题。



采用 Spring Boot 构建一个微服务，Java 作为成熟工程语言目前还是最好的选择，社区和实践都非常成熟。可以复用后台很多用来做 SOAP 处理的 JAR 包。另一方面是解决了 Ruby 技术栈带来的问题。



然而，这两个方案的都有一个共同的问题：需要通过 ruby 语言编写的基础设施工具构建一套运行微服务的基础设施。而这个基础设施的搭建，前前后后估计得需要至少 1个月，这还是在运维团队有人帮助的情况下的乐观估计。



所以，要找到一种降低环境构建和运维团队阻塞的方式避开传统的 EC2 搭建应用的方式。



这，只有 Lambda 可以做到！



基于上面的种种考量，我们选择了 Amazon API Gateway + Lambda 的组合。而 Amazon API Gateway + Lambda 还有额外好处：



支持用 Swagger 规范配置 API Gateway。也就是说，你只要导入前端的 Swagger 规范，就可以生成 API Gateway。
可以用数据构建 Mock API，这样就可以很大程度上实现消费者驱动契约开发。
通过 Amazon API Gateway 的 Stage 功能，我们无需构建 QA 环境，UAT 环境和 Staging 环境。只需要指定不同的 Stage，就可以完成对应的切换。
Lambda 的发布生效时间很短，反馈很快。原先用 CloudFormation 构建的 API 基础设施需要至少 15 分钟，而 Lambda 的生效只需要短短几秒钟。
Lambda 的编写很方便，可以采用在线的方式。虽然在线 IDE 并不很好用，但是真的也写不了几行代码。
Lambda 自动根据请求自扩展，无需考虑负载均衡。
虽然有这么多优点，但不能忽略了关键性的问题：AWS Lambda 不一定适合你的应用场景！



很多对同步和强一致性的业务需求是无法满足的。所以，AWS Lambda 更适合能够异步处理的业务场景。此外，AWS Lambda 对消耗存储空间和 CPU 很多的场景支持不是很好，例如 AI 和 大数据。（PS: AWS 已经有专门的 AI 和大数据服务了，所以不需要和自己过不去）



对于我们的应用场景而言，上文中的 Ruby On Rails 应用中的主要功能（至少60% 以上）实际上只是一个数据转换适配器：把前端输入的数据进行加工，转换成对应的 SOAP 调用。因此，对于这样一个简单的场景而言，Amazon API Gateway + Lambda 完全满足需求！



image
部署后端微服务
选择了Amazon API Gateway + Lambda 后，后端的微服务部署看起来很简单：



更新 Lambda 函数。
更新 API 规范，并要求 API 绑定对应 Lambda 函数处理请求。
但是，这却不是很容易的一件事。我们将在下一篇文章《Serverless 风格微服务的持续交付》中对这方面踩过的坑详细介绍。



把原应用的请求导向新的微服务
这时候在 CDN 上给新的微服务配置 API Gateway 作为一个新的源（Origin），覆盖原先写在 route.rb 和 nginx.conf 里的 API 访问规则就可以了。CDN 会拦截访问请求，使得请求在 nginx 处理之前就会把对应的请求转发到 API Gateway。



当然，如果你想做灰度发布的话，就不能按上面这种方式搞了。CloudFront 和 ELB 负载均衡 并不具备带权转发功能。因此你需要通过 nginx 配置，按访问权重把 API Gateway 作为一个 upstream 里的一个 Server 就可以。



删除旧的服务代码
不要留着无用的遗留代码！



不要留着无用的遗留代码！



不要留着无用的遗留代码！



重要且最容易被忽略的事情要说三遍。斩草要除根，虽然我们可以保持代码不动。但是清理不再使用的遗留代码和自动化测试可以为其它团队减少很多不必要的工作量。



最终的架构
经过6个人两个月的开发（原计划8个人3个月），我们的 Serverless 微服务最终落地了。当然这中间有 60% 的时间是在探索全新的技术栈。如果熟练的话，估计 4 个人一个月就可以完成工作。



最后的架构如下图所示：



image
在上图中，请求仍然是先通过域名到 CDN （CloudFront），然后：



CDN 根据请求点的不同，把页面请求转发至 S3 ，把 API 请求转发到 API Gateway。
前端的内容通过蓝绿部署被放到了不同的 S3 Bucket 里面，只需要改变 CDN 设置就可以完成对应内容的部署。虽然对于部署来说蓝绿 Bucket 乍看有一点多余，但这是为了能够在生产环境下做集成在线测试准备的。这样可以使环境不一致尽可能少。
API Gateway 有自己作用的 VPC，很好的实现了网络级别的隔离。
通过 API Gateway 转发的 API 请求分成了三类，每一类都可以根据请求状况自扩展。
身份验证类：第一次访问会请求 ElastCache（Redis），如果 Token 失效或者不存在，则重新走一遍用户验证流程。
数据请求类：数据请求类会通过 Lambda 访问由其他团队开发的 Java 微服务，这类微服务是后台系统唯一的访问点。
操作审计类：请求会记录到 DynamoDB （一种时间序列数据库）中，用来跟踪异步请求的各种日志。
API Gateway 自己有一些缓存，可以加速 API 的访问。
消息返回后，再有三类不同的请求的结果统一通过 API Gateway 返回给客户端。
Serverless 风格微服务架构的优点
由于没有 EC2 设施初始化的时间，我们减少了至少一个月的工作量，分别是：



初始化网络配置的时间。
构建 EC2 配置的时间。
构建反向代理和前端静态内容服务器的时间。
构建后端 API 应用基础设施的时间。
构建负载均衡的时间。
把上述内容用 Ruby 进行基础设施即代码化的时间。
如果要把 API Gateway 算作是基础设施初始化的时间来看。第一次初始化 API Gateway 用了一天，以后 API Gateway 结合持续交付流程每次修改仅仅需要几分钟，Serverless 风格的微服务大大降低了基础设施配置和运维门槛。



此外，对于团队来说，Amazon API Gateway + Lambda 的微服务还带来其它好处：



开发效率高，原先至少 45 分钟的开发反馈周期缩短为 5 分钟以内。
无关的代码量少，需要维护的代码量少。除了专注业务本身。上游和 API Gateway 的集成以及下游和后端服务的集成代码量很少。
应用维护成本低。代码仅仅几十行，且都为函数式，很容易测试。避免了代码库内部复杂性的增加。
此外，我们做了 Java 和 NodeJs 比较。在开发同样的功能下，NodeJS 的开发效率更高，原因是 Java 要把请求的 json 转化为对象，也要把返回的 json 转化为对象，而不像 nodejs 直接处理 json。此外， Java 需要引入一些其它 JAR 包作为依赖。在 AWS 场景下开发同样一个函数式微服务，nodejs 有 4 倍于 java 的开发效率提升。



最后
Serverless 风格的微服务虽然大大减少了开发工作量以及基础设施的开发维护工作量。但也带来了新的挑战：



大量函数的管理。
SIT，UAT 环境的管理。
持续交付流水线的配置。
面对基础设施集成带来的测试。
这让我们重新思考了 Serverless 架构的微服务如何更好的进行持续交付。



一：什么是serverless无服务？



serverless中文的含义是 “无服务器”，但是它真正的含义是开发者再也不用过多考虑服务器的问题，但是并不代表完全去除服务器，而是我们依靠第三方资源服务器后端，比如使用 Amazon Web Services(AWS) Lambda. 计算服务来执行代码，那么Serverless架构分为 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 两种技术，Serverless 它是由开发者实现的服务端逻辑运行在无状态的计算容器中，它是由事件触发，完全被第三方管理的。



什么是BaaS?



Baas 的英文翻译成中文的含义：后端即服务，它的应用架构由大量第三方云服务器和API组成的，使应用中关于服务器的逻辑和状态都由服务提供方来管理的。比如我们的典型的单页应用SPA和移动APP富客户端应用，前后端交互主要是以RestAPI调用为主。只需要调用服务提供方的API即可完成相应的功能，比如常见的身份验证，云端数据/文件存储，消息推送，应用数据分析等。



什么是FaaS?



FaaS可以被叫做：函数即服务。开发者可以直接将服务业务逻辑代码部署，运行在第三方提供的无状态计算容器中，开发者只需要编写业务代码即可，无需关注服务器，并且代码的执行它是由事件触发的。其中AWS Lambda是目前最佳的FaaS实现之一。



Serverless的应用架构是将BaaS和FaaS组合在一起的应用，用户只需要关注应用的业务逻辑代码，编写函数为粒度将其运行在FaaS平台上，并且和BaaS第三方服务整合在一起，最后就搭建了一个完整的系统。整个系统过程中完全无需关注服务器。



回到顶部
二：与传统模式架构区别？



传统的架构模式是使用C/S架构的，在典型的web应用程序中，服务器接收前端的HTTP请求处理，在保存或查询数据库之前，数据可能会经过多个应用层，最终后端会返回一个响应。比如它可以是JSON形式或其他格式等。然后他会将响应返回给客户端，比如如下图所示：



在传统开发模式中，开发流程：设计师设计页面 -> 服务端开发 和 前端分别开发，服务器开发完成后，-> 服务部署 ->服务部署完成后，就是前后端联调 -> 前后端联调 -> 前后端联调完成后就是测试了，-> 测试， 测试完成需要上线，因此 -> 上线，上线完成后，需要运维维护，因此 -> 运维。在传统开发模式中，开发一个应用程序，从开始到上线需要不同的角色来做不同的事情，沟通成本非常大，并且运维过程中需要考虑到 服务器的负载均衡、事务、集群、缓存、
消息传递和数据冗余等等这些事情，在目前传统模式中存在如上问题。可以使用如下示意图来看下如上流程。如下图所示：



在Serverless架构中，应用业务逻辑是基于FaaS架构形成多个相互独立的功能组件的。并且以API服务的形式向外提供服务，在FaaS中，后端的应用被拆分成为一个个函数，我们只需要编写完成函数后部署到serverless服务即可。后续我们也不用关心任何服务器的操作。那么整个流程就只需要我们一个前端工程师的角色来完成所有的开发工作，那么沟通成本降低了。因此我们可以使用如下示意图来表示项目流程，如下所示：



前端工程师是居于serverless去写后端服务的，典型的就是居于 AWS Lambda 中编写代码，AWS中支持不同的语言。
Lambda计算服务它能够以大规模并行的方式执行代码来响应事件。通过使用Lambda以及使用各种功能强大的API和Web服务，开发者可以快速的构建松耦合，可扩展性及高效的架构体系。



注意：Lambda是什么？它是一种计算服务，它在AWS基础上执行用javascript、node.js、Python、C#或java编写的代码，源代码将被打包并部署到孤立的容器中，该容器有单独分配的内存、磁盘空间和处理器。代码、配置和依赖项的组合被称作为Lambda函数。



回到顶部
三：serverless优缺点？



优点有如下：




  1. 降低创业公司启动成本



当一家创业公司的时候，在开发web的时候，我们需要版本管理服务器、持续集成服务器、测试服务器、应用版本管理仓库等作为基础服务。
线上运行的时候，为了应对大量的请求，我们还需要一个好的数据库服务器。当我们应用面向普通的用户时，我们需要：



1.1 邮件服务，用于发送提醒，注册等服务。
1.2 短信服务，用于注册，登录等用户授权操作。



如上一些对于大公司来讲，都有现成的基础设施。可是对于创业公司来讲。这都需要一些启动成本。但是如果我们使用serverless就可以降低这些成本。




  1. 减少运营成本



对于创业公司来讲，他们没有基础设施，没有财力，也可能没有能力去建设基础设施，采用云服务是最好的选择，可以为他们节省大量的资金。
他们只要将精力放在对用户价值的产品之上即可，他们不需要自己去搭建服务器，因此会有更多的时间去开发业务功能。而采用函数计算的serverless与云服务器最大的区别是：云服务器需要一直运行，比如说月费或年费要多少钱租，但是serverless是按需计费的，如果有请求到来的时候，才运行函数，否则的话，是不需要钱的。




  1. 降低开发成本



serverless会提供一系列的配套服务，比如 我们只需要在配置文件上写下数据库的表名，那么数据就会存储到对应的数据库里面，并且会提供一系列的函数计算模板，我们只需要写好我们的配置即可，那么这一系列的东西都可以自动，高效的完成任务。




  1. 实现快速上线



对于一些传统项目来讲，我们在本地开发需要部署环境，到开发环境或测试环境，我们还是需要部署环境。但是serverless可以在部署上有优势，并且很轻松的实现上线。因为serverless内部相当于有 内建自动化部署功能，并且在该里面都是由供应商提供的功能，每次我们写完业务代码后，我们只需要运行下即可，在AWS Lambda 函数计算里面，函数一般在上传后几秒钟内，就能做好调用准备。




  1. 系统安全性更高。



要保持服务器一直运行不是件容易的事情，并且还需要考虑黑客不同类型的攻击，但是有serverless后，我们不需要考虑这些问题了，这些问题第三方供应商已经会帮我解决这些问题的。




  1. 能适应微服务架构和扩展性能力强



Serverless 的背后是 诸如 AWS Lambda 这样的 FaaS（Function as a Services）。



对于传统应用来说，要应对更多的请求的方式，就是部署更多的实例。然而，这个时候往往已经来不及了。而对于 FaaS 来说，我们并不需要这么做，FaaS 会自动的扩展。它可以在需要时尽可能多地启动实例副本，而不会发生冗长的部署和配置延迟。



以亚马逊的AWS Lambda为案例，Lambda能让我们不用思考任何服务器，也就是说，不用我们处理服务器上的部署，服务器的容量和服务器的扩展和失败容错，还有服务器上选择什么OS操作系统，语言的更新，日志等等问题。你的应用程序只需要和多个第三方的API或服务打交道，也可以自我创建一个无服务器的
API。



缺点有如下：




  1. 不适合长时间运行应用



serverless 在请求到来的时候才运行，当应用不运行的时候会进入 “休眠状态”，下次当请求来临时，应用将会需要一个启动时间，可以叫 冷启动，如果我们的应用需要一直长期不间断的运行，处理大量的请求，那么可能就不适合使用serverless来架构了，如果这种情况下，我们需要使用像EC2这样的云服务器会是一个更好的选择。



EC2相当于我们自己买了一辆车，在Lambda 相当于我们租了一辆车。如果我们长期租车的话，那么肯定比买车更贵，但是租车可以减少一部分车维护成本。




  1. 完全会依赖于第三方服务



如果我们所有和应用相关的服务放在第三方服务上的话，就可能会涉及到安全性问题，因此我们可以将不重要的API或服务放在serverless上。
当然如果我们自己有服务设施的话，那肯定使用自己的设施服务的，当我们自己使用serverless架构的时候，那么我们就已经和供应商绑定了。
如果这个时候我们将服务迁到别的云服务商上就没有那么容易了。





  1. 缺乏调式和开发工具，排查问题困难。




  2. 无法用于高并发运用。





为每个请求启动一个进程开销太高，流量瞬间爆发容易超时。比如淘宝的双十一支付宝高峰期，每秒处理交易笔数8万多笔，也就意味着我们的系统内每秒有8万多个进程创建又被销毁。那么这样就会造成系统开销很大。解释和第一点一样的原理。



回到顶部
四：使用serverless的应用场景有哪些？



Serverless 适合构建比较简单的应用，比如上传一张图片，对一段音频/视频进行编码或解码，对请求返回一小段数据等。



Serverless架构主要有以下特点：




  1. 实现了细粒度的计算资源分配。

  2. 不需要预分配资源。

  3. 具备真正意义上的高度扩容和弹性。

  4. 按需使用，按需计费。



因此以下应用将可能使用serverless架构：




  1. 静态网站的管理。

  2. 替代WordPress(Serverless Blog Project)

  3. 个人媒体服务器(less!)

  4. 物联网Iot或家庭自动框架或项目 (使用 AWS IoT)



具体的应用基本如下：



发送通知：



诸如 PUSH Notification、邮件通知接口、短信，这一类服务来说，他们都需要基础设施来搭建。并且，他们对实时性的要求相对没有那么高。
即使在时间上晚来几秒钟，用户还是能接受的。在我们所见到的短信发送的例子里，一般都会假设用户能在 60 秒内收到短信。因此，在这种时间 1s 的误差，用户也不会恼火的。而对于 APP 的消息推送而言，这种要求就更低了，用户反而不太希望能收到这样的推送。



WebHook



当我们没有服务器，又想要一个 Webhook 来触发我们一系列的操作的时候。我们就可以考虑使用 Serverless，我们不需要一直就这么支付一个服务器的费用。通过 Serverless，我们就可以轻松完成这样的工作，并且节省大量的费用。



数据统计分析



数据统计本身只需要很少的计算量，但是生成图表，则可以定期生成。



在接收数据的时候，我们不需要考虑任何延时带来的问题。50~200 ms 的延时，并不会对我们的系统造成什么影响。



Trigger 及定时任务



对于哪些需要爬虫来抓取和生成的程序来说，Serverless 可能是一个不错的舞台。



尽管，这样的工作也可以由云服务器来做，我们只需要定时的启动一下服务器。通过服务器中的自启动脚本来做相应的事，但是当我们完成了一系列的工作之后。我们需要将数据存储在一个远程的服务器上。而为了让系统中的其它应用，也能直接访问这些数据。那么，我们可能会考虑使用一个云数据库。这个时候，Serverless 应用看上去更具有吸引力。



Chat 机器人



聊天机器人，也是一个相当好的应用场景。



But，由于国内的条件限制（信息监管），这并不是一件容易的事。因此，从渠道（如微信、blabla）上，都在尽可能地降低这方面的可能性。



但是，我们还可以做一个微信公众号的服务。当用户输入一个关键词时，做出相应的回复，这实质上和聊天机器人是差不多的。



https://serverless.com/



Serverless 是一种“无服务器架构”模式，它无需关心程序运行环境、资源及数量，只需要将精力聚焦到业务逻辑上的技术。基于 Serverless 开发 web 应用，架构师总是试图把传统的解决方案移植到 Serverless 上，虽然可以做到既拥有 Serverless 新技术带来的红利，又能维持住传统开发模式的开发体验。但是，Serverless 技术带来的改变可能不止这些，可能是颠覆整个传统 web 应用开发模式的革命性技术。



开发模式
业务应用的开发模式发展是从一体到分裂为前后端，再到前后端融合为一体过程。



注意：后面所说的后端特指后端业务逻辑。



早期，一体



没有前后端的概念，那时候的应用都是单机版，所有的业务逻辑都写一起，开发人员不需要关心网络请求，这个时期的工程师完全专注于业务代码的开发。随着业务规模的增长，也暴露了很多问题：



高并发问题
高可用问题
说明：业务应用升级困难等一些问题，不是本篇文章所关心，所以就不一一列举出来。



现在，分裂
前端 + 高可用高并发运维裹挟着的后端业务逻辑：



说明：现在 Serverless 技术已经出现有一段时间了，不但没有解决开发体验的问题，反而带来更多开发体验问题，所以，在这里我并没有突出 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
Q：前后端一体化需要将前后端代码发布到同一个地方吗？
A：不需要，分开发布，通过统一的工具负责前后端发布任务，前端可以发到 CDN，后端可以发布到 Serverless 平台，如：阿里云函数计算。



Q：未来是不是没有后端工程师？
A：有的。前端工程师只是把前端和后端的业务逻辑代码给做了，后端工程师去做真正的后端，那时候的后端工程师将会更加专业，前端工程师可能会变成应用开发工程师（暂且这么称呼）。对于中小型企业，可能大部分是应用开发工程，有少量甚至没有专业的后端工程师。



Q：为什么不做一个类似 expressjs 这样的 web 应用框架？
A：expressjs 框架是在没有 Serverless 背景下设计的，没有考虑 Serverless 给我们带来的技术架构变革，如果需要类似 expressjs 的这样的框架，我们完全可以将 expressjs 框架迁移到 Serverless 上运行，没有必要再造一套。



Q：为什么是 nodejs 框架？
A：nodejs 和 前端 js 使用的同一种语言，可以将前后端一体化做到更加极致，webassembly 也可以让任何语言在前端运行，也能做到前后端语言一致，但是 js 是为前端而生的，更有亲和力。但是其他语言可以通过 webassembly 编译成中间语言，nodejs 通过 vm 来调用其他语言提供的功能。也不排除未来会有一种新的运行环境来取代 nodejs，更加适配多语言和 Serverless 这种场景。



Q：前后端一体化的极致是一种什么感觉？
A：前后端代码都在一个项目中用同一种语言来写，在本地定义一个后端接口方法，前端就像调用本地方法一样调用后端方法（不是在本地定义的后端接口也是一样，比如跨组件、外部服务），前后端可以抽象更多的公共逻辑，比如工具类等等，一个开发人员就能维护好整个项目，没有了多项目多语言的切换痛苦。


Category web