Serverless常见的设计模式

服务定义

import com.faas.function.*;
import reactor.core.publisher.Mono;

public class ExampleFunction implements RxFn<String, String> {

  public Mono<String> apply(String s, Context context) {
    context.getLogger().log("hello " + s);
    return Mono.just("Hello " + s);
  }
}

spec-version: 1.0
group: middleware
name: faas-test4
runtime: java8
handler: com.faas.demo.ExampleFunction

timeout: 50000
memory: 2048MB
cpu: 2

MicroServices Pattern |微服务模式

在微服务模式中，每个作业或功能都在一个单独的Lambda函数中隔离运行，其中每个Lambda函数也将具有单个http端点，该端点用作该函数执行与访问的入口点。

service: serverless-social-network
provider: aws
functions:
  usersCreate:
    handler: handlers.usersCreate
    events:
      - http: post users/create
  commentsCreate:
    handler: handlers.commentsCreate
    events:
      - http: post comments/create

微服务模式的优势为：

• 关注点完全分离。每个作业/操作都在一个单独的部署单元（即单独的Lambda函数）中，允许您单独修改应用程序的组件，而不会影响整个系统。这是一种非常敏捷和安全的模式，特别是在生产中。
• 每个Lambda函数处理一个事件，使您的函数易于调试，因为通常只有一个预期的结果。
• 这种关注点的分离对于自治团队来说也是很好的。他们可以独立地将功能推向生产。

微服务模式的劣势为：

• 您将最终获得许多功能，这些功能难以管理并且可能导致大量的认知开销。Lambda函数往往比传统的微服务更精细，所以为它们做好准备！
• 性能可能会变慢。当函数处理单个作业时，它们被调用得更少，从而导致更多的冷启动。
• 由于必须配置多个功能，因此部署速度会变慢。
• 您可以快速达到CloudFormation模板文件大小限制，尤其是在您使用自定义资源时。

Services Pattern |服务模式

在服务模式中，单个Lambda函数可以处理通常通过数据模型或共享基础结构依赖关系的一些（~4）作业，譬如Users数据模型上的所有操作都在单个Lambda函数中执行，并为所有CRUD操作创建多个HTTP端点。

service: serverless-social-network
provider: aws
functions:
  users:
    handler: handler.users
      events:
        - http: post users
        - http: put users
        - http: get users
        - http: delete users
  comments:
    handler: handler.comments
      events:
        - http: post comments
        - http: put comments
        - http: get comments
        - http: delete comments

您可以通过解析代码中的事件主体来检查传入的HTTP请求的路径和方法，然后执行正确的操作以作为响应。这就像在Lambda代码的开头有一个小路由器。

服务模式的优势为：

• 这将导致您需要管理的Lambda函数减少。
• 一些关注点仍然存在。
• 团队仍然可以自主工作。
• 更快的部署。
• 从理论上讲，性能更好。当多个作业在Lambda函数中时，Lambda函数更有可能被更频繁地调用，这意味着Lambda将保持温暖并且用户将遇到较少的冷启动。

服务模式的缺陷为：

• 调试变得稍微复杂一些，因为Lambda函数正在处理多个作业，并且具有不同的结果。
• 需要创建路由器以根据请求方法或端点调用正确的逻辑。
• 由于在同一Lambda函数中放置多个操作，因此功能大小更大。

Monolithic Pattern |巨石模式

在Monolithic Pattern中，您的整个应用程序都被塞入单个Lambda函数中。在我们的示例应用程序中，我们的整个应用程序都在一个Lambda函数中，所有HTTP端点都指向该Lambda函数。

service: serverless-social-network
provider: aws
functions:
  socialNetwork:
    handler: handler.socialNetwork
      events:
        - http: post users
        - http: put users
        - http: get users
        - http: delete users
        - http: post comments
        - http: put comments
        - http: get comments
        - http: delete comments

巨石模式的好处：

• 单个Lambda函数更容易理解和管理。它更像是一种传统的设置。
• 快速部署，具体取决于总代码大小。
• 从理论上讲，性能更快。您的单个Lambda函数将被频繁调用，您的用户不太可能遇到冷启动。

巨石模式的缺点：

• 需要在Lambda函数中构建更复杂的路由器，并确保它始终指向调用适当的逻辑。
• 理解表现更难。Lambda函数将运行各种持续时间。
• 由于功能更大，您可以轻松地在实际应用中达到Lambda大小限制。

GraphQL模式

Graph Pattern类似于Monolithic Pattern，但它允许您利用GraphQL将整个REST API及其所有端点减少为1-2个端点。因此，整个应用程序将由一个函数和一个处理GraphQL查询的1-2个端点组成。然后GraphQL将以您需要的任何形式获取正确的数据。

service: serverless-social-network
provider: aws
functions:
  socialNetwork:
    handler: handler.socialNetwork
      events:
        - http: get query

GraphQL模式的好处：

• 使用单个Lambda函数和整个应用程序的单个端点非常容易管理。
• 从理论上讲，性能更快。您的单个Lambda函数将被频繁调用，您的用户不太可能遇到冷启动。
• 由于您只有一个功能和一个端点，因此快速部署
• 按执行付费，零管理，图形API !!!它没有比那更有效率！

GraphQL模式的缺点：

• 由于功能庞大，您可以轻松地在实际应用中达到Lambda大小限制。
• 你必须学习GraphQL。