カタログを読みます
ワン：なしサービスサーバレスは何ですか？
サーバレス中国の意味は、「サーバレス」であるが、それは本当に意味の開発者は、もはや問題のサーバーに多くの思考を与える必要があり、それは、サーバーの除去を意味するものではありませんが、私たちは、このようなアマゾンを使用するなど、サードパーティのバックエンドサーバのリソースに依存しているということではありません開発者によって実装され、それが実行されているサービス（FAAS）などのWebサービス（AWS）ラムダ。コードを実行するコンピューティングサービスは、サーバレスアーキテクチャはサービス（BAAS）としてバックエンドに分割されていると機能二つの技術、サーバレスは、サーバ側ロジックイベントによってトリガされるステートレス計算容器は、完全に第三者によって管理します。
バースは何ですか？
英語でのバースは、中国の意味に翻訳：それは、そのアプリケーションのアーキテクチャは、管理するためのサービスプロバイダによってサーバー上のアプリケーション・ロジックおよび状態からなるサードパーティのクラウドサーバとAPIの多数で構成され、バックエンドサービスです。例えば、主にフロントとリアエンドインタラクティブで私たちの典型的な単一ページのアプリケーションSPAおよびモバイルAPPリッチクライアントアプリケーション、RestAPIの呼び出しがベース。ちょうどそのような共通の認証、クラウドデータ/ファイルストレージ、メッセージのプッシュ、アプリケーション・データ分析などの適切なAPI関数を完了するために、サービスプロバイダに連絡してください。
FAASとは何ですか？
FAASを呼び出すことができます。サービス機能。開発者は、直接第三者によって提供さステートレスコンピューティングコンテナで実行されている、サービスのビジネス・ロジック・コードをデプロイすることができ、開発者はサーバのみに注意を払うことなく、ビジネスにコードを書き、それがイベントによってトリガされたコードを実行する必要があります。達成最高FAASの一つであるAWSラムダ。
サーバレスアプリケーションアーキテクチャバースとFAASは一緒アプリケーションで、ユーザーが唯一の粒子サイズの関数として記述されたアプリケーションコードのビジネスロジックに集中する必要がFAASプラットフォームとサードパーティのサービス上で実行され、バース一緒に、そして最終的に構築します完全なシステム。全体のシステムは、サーバ・プロセスを心配することなく、完全です。
2：建築と伝統的なモデルの違いは？
伝統的なアーキテクチャモードは、一般的なWebアプリケーションで、C / Sアーキテクチャを使用することで、サーバはHTTPリクエスト処理のフロントエンドを受信する、またはデータベースクエリを保存する前に、データは、最終的にバックエンドを返し、複数の層を介して適用することができます応答。例えば、それはJSONなどの他の形式であってもよいです。彼は、その後、以下に示すように、クライアントに応答します。
伝統的な開発モデル、開発プロセスでは：>サービスの展開- - - >サーバー側とフロントエンド開発者はサーバーの後に開発、開発しているデザイナーのページ>導入後のサービスが終了し、それは、FBIの前端と後端である- > FBIの前端と後端- >試験の前後端部がFBI、終了する- >操作およびメンテナンス-必要な保守作業および保守、従って完了後>オンライン、オンライン- >テストを、テストので、ラインを完了する必要があります。伝統的な開発モードでは、アプリケーションの開発、オンライン最初からにやっていることは通信コストが非常に大きい、異なるものの異なる役割を必要とし、運用・保守プロセスを考慮にサーバー、サービス、クラスタリング、キャッシング、ロードバランシング取る必要
メッセージングをこれらの事に冗長データ伝送など、従来の電流モードで上記の問題が存在します。あなたは上記のプロセスを以下の概略図を使用することができます。下図のように：
サーバレスアーキテクチャでは、アプリケーションのビジネスロジックアーキテクチャは、独立した機能コンポーネントを複数形成FAASに基づいています。そして、FAASで、外部のサービスを提供するAPIサービスの形で、バックエンド・アプリケーションは機能に分割され、我々は唯一の機能の完了後にサーバーレスサービスを展開して書き込む必要があります。私たちは、任意のサーバのその後の動作を気にしないでください。そして、全体のプロセスは、我々は、フロントエンドエンジニアは、すべての開発作業を完了するために必要な唯一の役割は、通信コストを削減します。以下に示すようにそのため、我々は、概略的に次の手順でプロジェクトを使用することができます。
フロントエンドエンジニアは、一般的なバックエンドサービスを、書くためにサーバレスに住んでいるサポート異なる言語でAWSラムダ、AWSで書き込みコードを生きています。
ラムダは、サービスを計算することは、イベントに応答して、大規模並列様式でコードを実行することができます。ラムダと強力なAPIとWebサービスの様々な使用を使用することにより、開発者はすぐに疎結合、スケーラブルかつ効率的なアーキテクチャのシステムを構築することができます。
注意：Lambda是什么？它是一种计算服务，它在AWS基础上执行用javascript、node.js、Python、C#或java编写的代码，源代码将被打包并部署到孤立的容器中，该容器有单独分配的内存、磁盘空间和处理器。代码、配置和依赖项的组合被称作为Lambda函数。
三：serverless优缺点？
优点有如下：
1. 降低创业公司启动成本
当一家创业公司的时候，在开发web的时候，我们需要版本管理服务器、持续集成服务器、测试服务器、应用版本管理仓库等作为基础服务。
线上运行的时候，为了应对大量的请求，我们还需要一个好的数据库服务器。当我们应用面向普通的用户时，我们需要：
1.1 邮件服务，用于发送提醒，注册等服务。
1.2 短信服务，用于注册，登录等用户授权操作。
如上一些对于大公司来讲，都有现成的基础设施。可是对于创业公司来讲。这都需要一些启动成本。但是如果我们使用serverless就可以降低这些成本。
2. 减少运营成本
对于创业公司来讲，他们没有基础设施，没有财力，也可能没有能力去建设基础设施，采用云服务是最好的选择，可以为他们节省大量的资金。
他们只要将精力放在对用户价值的产品之上即可，他们不需要自己去搭建服务器，因此会有更多的时间去开发业务功能。而采用函数计算的serverless与云服务器最大的区别是：云服务器需要一直运行，比如说月费或年费要多少钱租，但是serverless是按需计费的，如果有请求到来的时候，才运行函数，否则的话，是不需要钱的。
3. 降低开发成本
serverless会提供一系列的配套服务，比如 我们只需要在配置文件上写下数据库的表名，那么数据就会存储到对应的数据库里面，并且会提供一系列的函数计算模板，我们只需要写好我们的配置即可，那么这一系列的东西都可以自动，高效的完成任务。
4. 实现快速上线
对于一些传统项目来讲，我们在本地开发需要部署环境，到开发环境或测试环境，我们还是需要部署环境。但是serverless可以在部署上有优势，并且很轻松的实现上线。因为serverless内部相当于有 内建自动化部署功能，并且在该里面都是由供应商提供的功能，每次我们写完业务代码后，我们只需要运行下即可，在AWS Lambda 函数计算里面，函数一般在上传后几秒钟内，就能做好调用准备。
5. 系统安全性更高。
要保持服务器一直运行不是件容易的事情，并且还需要考虑黑客不同类型的攻击，但是有serverless后，我们不需要考虑这些问题了，这些问题第三方供应商已经会帮我解决这些问题的。
6. 能适应微服务架构和扩展性能力强
Serverless 的背后是 诸如 AWS Lambda 这样的 FaaS（Function as a Services）。
对于传统应用来说，要应对更多的请求的方式，就是部署更多的实例。然而，这个时候往往已经来不及了。而对于 FaaS 来说，我们并不需要这么做，FaaS 会自动的扩展。它可以在需要时尽可能多地启动实例副本，而不会发生冗长的部署和配置延迟。
以亚马逊的AWS Lambda为案例，Lambda能让我们不用思考任何服务器，也就是说，不用我们处理服务器上的部署，服务器的容量和服务器的扩展和失败容错，还有服务器上选择什么OS操作系统，语言的更新，日志等等问题。你的应用程序只需要和多个第三方的API或服务打交道，也可以自我创建一个无服务器的
API。
缺点有如下：
1. 不适合长时间运行应用
serverless 在请求到来的时候才运行，当应用不运行的时候会进入 "休眠状态"，下次当请求来临时，应用将会需要一个启动时间，可以叫 冷启动，如果我们的应用需要一直长期不间断的运行，处理大量的请求，那么可能就不适合使用serverless来架构了，如果这种情况下，我们需要使用像EC2这样的云服务器会是一个更好的选择。
EC2相当于我们自己买了一辆车，在Lambda 相当于我们租了一辆车。如果我们长期租车的话，那么肯定比买车更贵，但是租车可以减少一部分车维护成本。
2. 完全会依赖于第三方服务
如果我们所有和应用相关的服务放在第三方服务上的话，就可能会涉及到安全性问题，因此我们可以将不重要的API或服务放在serverless上。
当然如果我们自己有服务设施的话，那肯定使用自己的设施服务的，当我们自己使用serverless架构的时候，那么我们就已经和供应商绑定了。
如果这个时候我们将服务迁到别的云服务商上就没有那么容易了。
3. 缺乏调式和开发工具，排查问题困难。
4. 无法用于高并发运用。
为每个请求启动一个进程开销太高，流量瞬间爆发容易超时。比如淘宝的双十一支付宝高峰期，每秒处理交易笔数8万多笔，也就意味着我们的系统内每秒有8万多个进程创建又被销毁。那么这样就会造成系统开销很大。解释和第一点一样的原理。
四：使用serverless的应用场景有哪些？
Serverless 适合构建比较简单的应用，比如上传一张图片，对一段音频/视频进行编码或解码，对请求返回一小段数据等。
Serverless架构主要有以下特点：
1. 实现了细粒度的计算资源分配。
2. 不需要预分配资源。
3. 具备真正意义上的高度扩容和弹性。
4. 按需使用，按需计费。
因此以下应用将可能使用serverless架构：
1. 静态网站的管理。
2. 替代WordPress(Serverless Blog Project)
3. 个人媒体服务器(less!)
4. 物联网Iot或家庭自动框架或项目 (使用 AWS IoT)