服务器控件的优点和缺点
Serverless, the new buzzword in town has been gaining a lot of attention from the pros and the rookies in the tech industry. Partly due to the manner in which cloud vendors like AWS have hyped the architecture, from conferences to meetups to blog posts to almost everywhere. But serverless is not just about the hype, it promises the possibility of ideal business implementations which sounds quite pleasant to the ears and probably light on the budget as well.
没有服务器，城镇中的新流行语已引起了技术行业的专业人士和新手的广泛关注。 部分原因是像会议这样的云供应商大肆宣传了该架构，从会议到聚会到博客文章乃至几乎所有地方。 但是，无服务器化不只是炒作，它还有望实现理想的业务实施，这听起来很令人耳目一新，并且可能还减少了预算。
“Focus on your application, not the infrastructure”
“专注于您的应用程序 ，而不是基础架构 ”
Sounds relieving though, knowing a lot of your daylight hours go into implementing, maintaining, debugging, and monitoring the infrastructure. With all of that infrastructure heavy lifting out of the way, we really can focus on the business goals our applications serve. A lot of productive efforts could be channeled in the right direction, where they were meant to be ideally. Maybe it sounds too good to be true, but this is the way things should have been. At least for those of you who cant afford to spend a lot of time caught up in the web of intricacies in modern complex infrastructure.
尽管听起来很轻松，但您知道很多时间都花在了实施，维护，调试和监视基础结构上。 随着所有这些基础架构的繁重工作，我们确实可以专注于应用程序服务的业务目标。 可以在正确的方向上进行许多富有成效的工作，而这些工作本来是理想的。 也许听起来真是太好了，但事实就是这样。 至少对于那些无力花费大量时间陷于现代复杂基础架构复杂网络中的人们而言。
Expectations apart, Serverless is really breaking ground in its path to disrupt your server infrastructure. Serverless is already used in production by companies like Netflix, Reuters, AOL, and Telenor. Industry-wide adoption is constantly increasing. Serverless is all set to take up its own place, but don’t expect Serverless to conquer your infrastructure completely. There will be use cases where serverless might prove to be the wrong choice.
除了期望之外，Serverless在破坏服务器基础架构的道路上确实开创了先河。 Netflix，路透社，AOL和Telenor等公司已经在生产中使用Serverless。 行业范围内的采用率正在不断提高。 无服务器已经准备好占据自己的位置，但是不要指望无服务器会完全征服您的基础架构。 在某些情况下，无服务器可能被证明是错误的选择。
那么，什么是无服务器？ (So, What is Serverless?)
Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. A serverless application runs in stateless compute containers that are event-triggered, ephemeral (may last for one invocation), and fully managed by the cloud provider. Pricing is based on the number of executions rather than pre-purchased compute capacity, isn’t it the ideal framework for that project you have been planning since a long time? Well, go ahead do it.
无服务器是一种云计算执行模型，其中云提供商动态管理服务器的分配和供应。 无服务器应用程序在无状态计算容器中运行，这些容器是事件触发的，短暂的(可能持续一次调用)，并由云提供商完全管理。 定价基于执行次数而不是预先购买的计算能力，这不是您长期以来一直在计划的那个项目的理想框架吗？ 好吧，继续吧。
Serverless applications are event-driven cloud-based systems where application development rely solely on a combination of third-party services, client-side logic and cloud-hosted remote procedure calls (Functions as a Service).
无服务器应用程序是基于事件的基于云的系统，其中应用程序开发仅依赖于第三方服务，客户端逻辑和云托管的远程过程调用(功能即服务)的组合 。
Most of the cloud providers have invested heavily in serverless and thats a lot of money; with the given massive promotion and realistic offering you can safely assume serverless to be one of the most used cloud services in upcoming years. Here are some of the currently available cloud services:
大多数云提供商在无服务器上投入了巨资，这笔钱很多。 借助大规模的推广和切合实际的产品，您可以放心地假设无服务器将成为未来几年最常用的云服务之一。 以下是一些当前可用的云服务：
传统与无服务器架构 (Traditional vs. Serverless Architecture)
For years your applications have run on servers which you had to patch, update, and continuously look after late nights and early mornings due to all the unimaginable errors that broke your production. As long as you managed them, the whole responsibility of their proper functioning was on you. Serverless tends to be unlike the aforementioned, you no longer need to worry about the underlying servers. Reason being, they are not managed by you anymore and with management out of the picture the responsibility falls on the Cloud vendors. But regardless the cool features of Serverless in some cases, the traditional architecture outshines it.
多年来，由于所有无法想象的错误使您的生产中断，因此您的应用程序一直在必须修补，更新并连续监视深夜和清晨的服务器上运行。 只要您对它们进行管理，它们正常运行的全部责任就在您身上。 无服务器趋向于不同于前述，您不再需要担心底层服务器。 原因是，它们不再由您管理，并且由于管理不合理，责任由云供应商承担。 但是在某些情况下，不管Serverless的酷功能如何，传统体系结构都比它更好。
价钱 (Pricing)
One of the major advantages of using Serverless is reduced cost, for years the cost of provisioning servers and maintaining that 24x7 server team which blew a hole in your pocket is gone. The cost model of Serverless is execution-based: you’re charged for the number of executions. You’re allotted a certain number of seconds of use that varies with the amount of memory you require. Likewise, the price per MS (millisecond) varies with the amount of memory you require. Obviously, shorter running functions are more adaptable to this model with a peak execution time of 300-second to 15-minutes for most Cloud vendors.
使用Serverless的主要优点之一是降低了成本，多年来节省了配置服务器和维持24x7服务器团队的工作成本，这使您无所适从。 Serverless的成本模型是基于执行的：您需要为执行次数付费。 您分配了一定的使用秒数，该秒数随所需的内存量而变化。 同样，每MS的价格(毫秒)随所需的内存量而变化。 显然，对于大多数云供应商而言，运行时间较短的功能更适合此模型，峰值执行时间为300秒至15分钟。
The winner here is Serverless Architecture.
这里的赢家是无服务器架构。
联网 (Networking)
The downside is that Serverless functions are accessed only as private APIs. To access these you must set up an API Gateway. This doesn’t have an impact on your pricing or process, but it means you cannot directly access them through the usual IP, snap!
缺点是无服务器功能只能作为私有API访问。 要访问这些文件，您必须设置一个API网关。 这对您的价格或流程没有影响，但是这意味着您不能直接通过常规IP直接访问它们，快点！
The winner here is Traditional Architecture.
获奖者是传统建筑。
第三方依赖性 (3rd Party Dependencies)
Most, if not all of your projects have external dependencies, they rely on libraries that are not built into the language or framework you use. You often use libraries with functionality that includes cryptography, image processing, etc., these libraries can be pretty heavy. Without system-level access, you must package these dependencies into the application itself.
大多数(如果不是全部)项目都具有外部依赖关系，则它们依赖于未在您使用的语言或框架中内置的库。 您经常使用具有加密，图像处理等功能的库，这些库可能非常繁重。 如果没有系统级访问，则必须将这些依赖项打包到应用程序本身中。
Reinventing the wheel isn’t always a good idea.
重新发明轮子并不总是一个好主意。
The winner here is based on the context. For simple applications with few dependencies, Serverless is the winner; for anything more complex, Traditional Architecture is the winner.
此处的赢家基于上下文。 对于几乎没有依赖关系的简单应用程序，Serverless是胜利者。 对于任何更复杂的事情，传统建筑都是赢家。
环境环境 (Environments)
Setting up different environments for Serverless is as easy as setting up a single environment. Given that it’s pay per execution, this is a large improvement over traditional servers, you no longer need to set up dev, staging, and production machines. Eventually you’d lose count of all the environments, at some point.
为Serverless设置不同的环境就像设置单个环境一样容易。 由于它是按执行付费的，因此与传统服务器相比，这是一个很大的改进，您不再需要设置开发，暂存和生产机器。 最终，在某些时候您将失去所有环境的计数。
The winner here is Serverless Architecture.
这里的赢家是无服务器架构。
超时 (Timeout)
With Serverless computing, there’s a hard 15-minute timeout limit for AWS Lambda. Too complex or long-running functions aren’t good for Serverless, but having a hard timeout makes it impossible to perform certain tasks. A hard limit on this time makes Serverless unusable for applications that have variable execution times, and for certain services which require information from an external source. This is likely to change in the future.
借助无服务器计算， AWS Lambda的硬超时限制为15分钟 。 过于复杂或运行时间长的功能对于无服务器来说不是一件好事，但是超时时间很长，无法执行某些任务。 严格的时间限制使得Serverless无法用于具有可变执行时间的应用程序以及某些需要来自外部源的信息的服务。 将来这可能会改变。
The clear winner here is Traditional Architecture.
显而易见的赢家是传统建筑。
规模 (Scale)
Scaling process for Serverless is automatic and seamless, but there is a lack of control or entire absence of control. While automatic scaling is great, it’s difficult not to be able to address and mitigate errors related to new Serverless instances.
Serverless的扩展过程是自动且无缝的，但是缺少控制或完全没有控制。 尽管自动缩放效果很好，但是很难解决和减轻与新的无服务器实例有关的错误。
It’s a tie between Serverless and Traditional Architecture.
这是无服务器架构和传统架构之间的纽带。
功能即服务(FaaS) (Functions as a Service (FaaS))
FaaS is an implementation of Serverless architectures where engineers can deploy an individual function or a piece of business logic. They start within milliseconds (~100ms for AWS Lambda) and process individual requests within a 300-second to 15-minute timeout imposed by most cloud vendors.
FaaS是无服务器架构的实现，工程师可以在其中部署单个功能或业务逻辑。 它们在毫秒(AWS Lambda约为100ms)内开始，并在大多数云供应商施加的300秒至15分钟的超时时间内处理单个请求。
FaaS原理： (Principles of FaaS:)
- Complete management of servers 全面管理服务器
- Invocation based billing 基于调用的计费
- Event-driven and instantaneously scalable 事件驱动且可即时扩展
FaaS的主要特性： (Key properties of FaaS:)
独立的服务器端逻辑功能 (Independent, server-side, logical functions)
FaaS are similar to the functions you’re used to writing in programming languages, small, separate, units of logic that take input arguments, operate on the input and return the result.
FaaS与您以前用编程语言编写的功能类似，它们是小的独立逻辑单元，它们采用输入自变量，对输入进行运算并返回结果。
无状态 (Stateless)
With Serverless, everything is stateless, you can’t save a file to disk on one execution of your function and expect it to be there at the next. Any two invocations of the same function could run on completely different containers under the hood.
使用Serverless，一切都是无状态的，您无法在函数的一次执行中将文件保存到磁盘，而期望它在下一次执行时存在。 相同功能的任何两个调用都可以在后台完全不同的容器上运行。
短暂的 (Ephemeral)
FaaS are designed to spin up quickly, do their work and then shut down again. They do not linger unused. As long as the task is performed the underlying containers are scrapped.
FaaS旨在快速启动，执行其工作然后再次关闭。 他们不会流连忘返。 只要执行了任务，便会废弃基础容器。
事件触发 (Event-triggered)
Although functions can be invoked directly, yet they are usually triggered by events from other cloud services such as HTTP requests, new database entries or inbound message notifications. FaaS are often used and thought of as the glue between services in a cloud environment.
尽管可以直接调用功能，但是它们通常是由其他云服务的事件触发的，例如HTTP请求，新数据库条目或入站消息通知。 FaaS经常被使用，并被认为是云环境中服务之间的粘合剂。
默认可扩展 (Scalable by default)
With stateless functions multiple containers can be initialised, allowing as many functions to be run (in parallel, if necessary) as needed to continually service all incoming requests.
使用无状态功能，可以初始化多个容器，从而允许根据需要运行尽可能多的功能(如有必要，可以并行运行)以连续服务所有传入请求。
由云供应商完全管理 (Fully managed by a Cloud vendor)
AWS Lambda, Azure Functions, IBM OpenWhisk and Google Cloud Functions are most well-known FaaS solutions available. Each offering typically supports a range of languages and runtimes e.g. Node.js, Python, .NET Core, Java.
AWS Lambda，Azure Functions，IBM OpenWhisk和Google Cloud Functions是最著名的FaaS解决方案。 每个产品通常都支持多种语言和运行时，例如Node.js，Python，.NET Core，Java。
无服务器应用 (The Serverless App)
A Serverless solution consists of a web server, Lambda functions (FaaS), security token service (STS), user authentication and database.
无服务器解决方案由Web服务器，Lambda函数(FaaS)，安全令牌服务(STS)，用户身份验证和数据库组成。
Client Application — The UI of your application is rendered client side in Modern Frontend Javascript App which allows us to use a simple, static web server.
客户端应用程序 -您的应用程序的UI在Modern Frontend Javascript App中呈现为客户端，这使我们能够使用简单的静态Web服务器。
Web Server — Amazon S3 provides a robust and simple web server. All of the static HTML, CSS and JS files for our application can be served from S3.
Web服务器 -Amazon S3提供了强大而简单的Web服务器。 可以从S3提供我们应用程序的所有静态HTML，CSS和JS文件。
Lambda functions (FaaS) — They are the key enablers in Serverless architecture. Some popular examples of FaaS are AWS Lambda, Google Cloud Functions and Microsoft Azure Functions. AWS Lambda is used in this framework. The application services for logging in and accessing data will be built as Lambda functions. These functions will read and write from your database and provide JSON responses.
Lambda函数(FaaS) -它们是无服务器体系结构中的关键促成因素。 FaaS的一些流行示例是AWS Lambda，Google Cloud Functions和Microsoft Azure Functions。 此框架中使用了AWS Lambda。 用于登录和访问数据的应用程序服务将作为Lambda函数构建。 这些函数将从您的数据库读取和写入，并提供JSON响应。
Security Token Service (STS) — generates temporary AWS credentials (API key and secret key) for users of the application. These temporary credentials are used by the client application to invoke the AWS API (and thus invoke Lambda).
安全令牌服务(STS) -为应用程序的用户生成临时AWS凭证(API密钥和秘密密钥)。 客户端应用程序使用这些临时凭证来调用AWS API(从而调用Lambda)。
User Authentication — AWS Cognito is an identity service which is integrated with AWS Lambda. With Amazon Cognito, you can easily add user sign-up and sign-in to your mobile and web apps. It also has the options to authenticate users through social identity providers such as Facebook, Twitter or Amazon, with SAML identity solutions, or using your own identity system.
用户身份验证 -AWS Cognito是与AWS Lambda集成的身份服务。 借助Amazon Cognito，您可以轻松地将用户注册和登录添加到您的移动和Web应用程序。 它还具有通过SAML身份解决方案或使用您自己的身份系统通过社交身份提供商(例如Facebook，Twitter或Amazon)对用户进行身份验证的选项。
Database — AWS DynamoDB provides a fully managed NoSQL database. DynamoDB is not essential for a serverless application but is used as an example here.
数据库 -AWS DynamoDB提供了完全托管的NoSQL数据库。 DynamoDB对于无服务器应用程序不是必需的，但在此处用作示例。
无服务器架构的好处 (Benefits of Serverless Architecture)
从业务角度 (From business perspective)
- The cost incurred by a serverless application is based on the number of function executions, measured in milliseconds instead of hours. 无服务器应用程序产生的成本基于函数执行的数量，以毫秒为单位而不是小时。
- Process agility: Smaller deployable units result in faster delivery of features to the market, increasing the ability to adapt to change. 流程敏捷性：较小的可部署单元可以更快地将功能交付市场，从而增强适应变化的能力。
- Cost of hiring backend infrastructure engineers goes down. 雇用后端基础架构工程师的成本下降了。
- Reduced operational costs 降低运营成本
从开发人员的角度 (From developer perspective)
- Reduced liability, no backend infrastructure to be responsible for. 降低了责任，无需后端基础架构负责。
- Zero system administration. 零系统管理。
- Easier operational management. 简化运营管理。
- Fosters adoption of Nanoservices, Microservices, SOA Principles. 促进采用纳米服务，微服务，SOA原则。
- Faster set up. 设置更快。
- Scalable, no need to worry about the number of concurrent requests. 可扩展，无需担心并发请求的数量。
- Monitoring out of the box. 开箱即用的监视。
- Fosters innovation. 促进创新。
从用户角度 (From user perspective)
- If businesses are using that competitive edge to ship features faster, then customers are receiving new features quicker than before. 如果企业利用竞争优势更快地发布功能，则客户比以前更快地接收新功能。
- It is possible that users can more easily provide their own storage backend(i.e Dropbox, Google Drive). 用户可以更轻松地提供自己的存储后端(例如Dropbox，Google云端硬盘)。
- It’s more likely that these kinds of apps may offer client-side caching, which provides a better offline experience. 这些类型的应用程序更有可能提供客户端缓存，从而提供更好的脱机体验。
无服务器架构的缺点 (Drawbacks of Serverless Architecture)
从业务角度 (From business perspective)
- Reduced overall control. 减少总体控制。
- Vendor lock-in requires more trust for a third-party provider. 供应商锁定要求第三方提供更多信任。
- Additional exposure to risk requires more trust for a third party provider. 额外的风险承担需要第三方提供商更多的信任。
- Security risk. 安全风险。
- Disaster recovery risk 灾难恢复风险
- Cost is unpredictable because the number of executions is not predefined 成本不可预测，因为执行次数未预先定义
- All of these drawbacks can be mitigated with open-source alternatives but at the expense of cost benefits mentioned previously 所有这些缺点都可以使用开源替代方案来缓解，但要以前面提到的成本优势为代价
从开发人员的角度 (From developer perspective)
- Immature technology results in component fragmentation, unclear best-practices. 不成熟的技术会导致组件碎片化，最佳实践尚不清楚。
- Architectural complexity. 体系结构的复杂性。
- The discipline required against function sprawl. 防止功能蔓延的纪律。
- Multi-tenancy means it’s technically possible that neighbour functions could hog the system resources behind the scenes. 多租户意味着从技术上讲，邻居功能可能会在后台占用系统资源。
- Testing locally becomes tricky. 本地测试变得棘手。
- Significant restrictions on the local state. 对当地州的重大限制。
- Execution duration is capped. 执行期限是有上限的。
- Lack of operational tools 缺乏操作工具
从用户角度 (From user perspective)
- Unless architected correctly, an app could provide a poor user experience as a result of increased request latency. 除非正确设计架构，否则应用程序可能会因请求延迟增加而导致用户体验差。
无服务器框架 (Serverless Frameworks)
Serverless platforms need infrastructures where they can be executed, provider agnostic frameworks provide a platform agnostic way to define and deploy Serverless code on various cloud platforms or commercial services.
无服务器平台需要可以执行的基础架构，不可知的提供商框架提供了一种平台不可知的方式，可以在各种云平台或商业服务上定义和部署无服务器代码。
Serverless Framework (Javascript, Python, Golang)
无服务器框架 (JavaScript，Python，Golang)
Apex (Javascript)
Apex (JavaScript)
ClaudiaJS (Javascript)
ClaudiaJS (Javascript)
Sparta (Golang)
斯巴达 (Golang)
Gordon (Javascript)
戈登 (Javascript)
Zappa (Python)
Zappa (Python)
Up (Javascript, Python, Golang, Crystal)
上 (Javascript，Python，Golang，Crystal)
摘要 (Summary)
Serverless architecture is certainly very exciting, but it comes with a bunch of limitations. As the validity and success of architectures depend on the business requirements and by no means solely on technology. In the same way, Serverless can shine when used in proper place.
无服务器架构无疑是非常令人兴奋的，但是它有很多限制。 架构的有效性和成功取决于业务需求，而绝不仅取决于技术。 同样，在适当的地方使用Serverless可以发光。
Take a look at the awesomeness that is Serverless, it's time to take a peek at what Serverless looks from the inside. Here are few links to get you started on your Serverless journey.
看一下Serverless的强大之处，现在是时候看看Serverless从内部看的样子了。 这里有一些链接可帮助您开始无服务器之旅。
serverless/examplesServerless Examples - A collection of boilerplates and examples of serverless architectures built with the Serverless…github.com
serverless / examples Serverless示例-用Serverless构建的样板和无服务器架构示例的集合… github.com
anaibol/awesome-serverlessawesome-serverless - :cloud: A curated list of awesome services, solutions and resources for serverless / nobackend…github.com
anaibol / awesome-serverless awesome-serverless- ：cloud：无服务器/无后端的精选服务，解决方案和资源的精选列表…… github.com
Building Serverless Contact Form For Static WebsitesHandling static forms with AWS serverless lambda functionshackernoon.com
为静态网站构建无服务器联系表单 使用AWS无服务器lambda函数处理静态表单 hackernoon.com
I hope this article helped in the understanding of Serverless Computing. I’d love to hear about how you use Serverless in your projects. Share the knowledge, help it reach more people.
我希望本文有助于理解无服务器计算。 我很想听听您如何在项目中使用Serverless。 分享知识，帮助它吸引更多人。
翻译自: https://www.freecodecamp.org/news/what-is-serverless-architecture-what-are-its-pros-and-cons/
服务器控件的优点和缺点
282
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
