읽기 카탈로그
- 한하십시오 서버를 사용하지 더 서비스는 무엇입니까?
- 2 : 건축과 기존 모델의 차이점은 무엇입니까?
- 세 : 서버없는 장점과 단점?
- 4 : 서버를 사용하지 않는 애플리케이션 시나리오 무엇?
한하십시오 서버를 사용하지 더 서비스는 무엇입니까?
서버를 사용하지 않는 중국어 의미는 "서버없는"입니다하지만 정말 개발자가 더 이상 문제가 서버에 많은 생각을 할 필요가 없지만, 서버의 제거를 의미하지 않는다는 것을 의미하지만, 우리는 아마존을 사용하는 등, 타사 백 엔드 서버 자원에 의존 웹 서비스 (AWS) 람다. 코드를 실행하는 컴퓨팅 서비스는 다음 서버를 사용하지 않는 아키텍처는 서비스 (FAAS) 두 가지 기술, 같은 서비스 (BAAS) 및 기능으로 백엔드로 나누어은 개발자에 의해 구현 서버 측 로직을 실행하는 서버를 사용하지 않는 이벤트에 의해 트리거되는 무 컴퓨팅 용기는 완전히 제삼자에 의해 관리.
BAAS는 무엇입니까?
영어 BAAS는 중국 의미로 번역 : 그 해당 응용 프로그램 아키텍처를 관리 할 수있는 서비스 제공 서버의 응용 프로그램 논리와 국가로 구성된 타사 클라우드 서버와 API의 큰 숫자의 구성, 백엔드 서비스입니다. 예를 들어, 주로 전면과 후면 끝 상호 작용에서 우리의 전형적인 단일 페이지 응용 프로그램 SPA 및 모바일 APP 리치 클라이언트 응용 프로그램, RestAPI의 호출을 기반으로. 그냥 같은 일반적인 인증, 클라우드 데이터 / 파일 저장, 메시지 푸시, 응용 프로그램 데이터 분석과 같은 적절한 API 기능을 완료하기 위해 서비스 제공 업체에 문의하십시오.
FAAS는 무엇입니까?
FAAS는 호출 할 수 있습니다 서비스 기능. 개발자가 직접 제 3 자 기관이 제공 한 무 상태 컴퓨팅 컨테이너에서 실행, 서비스 비즈니스 로직 코드를 배포 할 수 있습니다, 개발자들은이 이벤트에 의해 트리거되는 코드를 서버에주의를 지불하지 않고, 사업에 코드를 작성하고 실행해야합니다. 달성 가장 FAAS 중 하나 AWS 람다.
서버를 사용하지 않는 응용 프로그램 아키텍처는 BAAS와 FAAS 함께 응용 프로그램 사용자는 구축 마침내 함께 FAAS 플랫폼 및 타사 서비스와 BAAS에서 실행되는 입자 크기의 함수로 작성된 응용 프로그램 코드의 비즈니스 로직에 집중해야하고, 완전한 시스템. 전체 시스템은 서버 프로세스에 대한 걱정없이 완전히이다.
2 : 건축과 기존 모델의 차이점은 무엇입니까?
전통적인 아키텍처 모드는 일반적인 웹 응용 프로그램에서, C / S 아키텍처를 사용하는 것입니다, 서버는 HTTP 요청 처리 프런트 엔드를 수신, 또는 데이터베이스 쿼리를 저장하기 전에, 데이터는 결국 백엔드를 반환, 복수의 층을 통해 적용 할 수있다 응답. 예를 들어이 JSON 등의 다른 형식이 될 수 있습니다. 그는 그런 다음 아래 그림과 같이, 다시 클라이언트로 응답합니다 :
전통적인 개발 모델, 개발 과정에서 : 디자이너 페이지 -> 서버 측과 프론트 엔드 개발자는 서버 후 개발, 개발 -> 서비스 배포 -> 배포 후 서비스가 완료되면, 즉, 연방 수사 국 (FBI)의 전면과 후면 끝 - 연방 수사 국 (FBI)의> 전면과 후면 끝 -> 전방 시험의 후단 완료 FBI는 -> 시험 시험 때문에 라인을 완료 할 필요 -> - 라인, 온라인 필요한 유지 보수 작업 및 유지 보수, 따라서 종료 후 -> 동작 및 유지. (가) 온라인 여러 가지의 서로 다른 역할을 필요에 전통적인 개발 모드에서 응용 프로그램을 개발, 처음부터 할, 통신 비용은 매우 큰, 그리고 운영 및 유지 보수 과정은 서버를 균형 계정에 부하를 데리고, 서비스, 클러스터링, 캐싱, 필요
메시징 이러한 것들에 중복 데이터 전송 때문에, 종래의 전류 모드에서 상기 문제의 존재. 당신은 위에서 설명한 프로세스의 다음 개략도를 사용할 수 있습니다. 아래 그림과 같이 :
서버를 사용하지 않는 구조에서, 애플리케이션의 비즈니스 로직 아키텍쳐는 독립 기능 컴포넌트 복수 형성 FAAS을 기반으로한다. 그리고 FAAS에서, 외부 서비스를 제공하기 위해 API 서비스의 형태로, 백엔드 어플리케이션이 기능으로 분할되고, 우리는 함수의 완료 후에 서버를 사용하지 않는 서비스에 배포 작성해야합니다. 우리는 모든 서버의 후속 작업에 대한 상관 없어. 그런 다음 전체 프로세스는 우리가 프론트 엔드 엔지니어가 모든 개발 작업을 완료하는 데 필요한 유일한 역할은 통신 비용을 줄일 것이다. 아래 그림과 같이 따라서, 우리는 개략적으로 다음 절차 프로젝트를 사용할 수 있습니다 :
프런트 엔드 엔지니어들은 일반 지원 다른 언어로 AWS 람다, AWS에서 코드를 작성 살고, 백엔드 서비스를 작성하는 서버리스에 살고있다.
람다 서비스 컴퓨팅이 이벤트에 대한 응답으로 대규모 병렬 방식으로 코드를 실행할 수 있습니다. 람다 강력한 API와 웹 서비스의 다양한 사용을 사용하여 개발자는 신속하게 느슨하게, 확장이 가능하고 효율적인 아키텍처 시스템을 결합 구축 할 수 있습니다.
注意：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)