通过公共lambda或每个微服务的公共DynamoDB

这两种方法都具有优点&缺点:

直接访问DynamoDB -好的一面

• 其他Lambda函数的作者可以在自己的阶段上进行构建。速度较快的团队可以冲刺,而不是等待速度较慢的团队
• 如果一个lambda函数行为不端/失败,其他lambda函数仍然与其解耦,并且爆炸半径受到限制

直接访问DynamoDB -坏的一面

• 编写类似内容的工作在不同的lambda实例中是重复的。
• 每个lambda都可以编写自己的逻辑,并在实现中引入差异。这可能是有意设计的,但也可能是一个开发人员误解了需求
• 如果这个DynamoDB被其中一个消耗的Lambda的错误编码所毒害,那么其他Lambda也可能宕机。
• 很难衡量储备容量,一些Lambda在读取单位时很容易变得贪婪。

中介Lambda -好的一面

• 减少为不同消费者实施类似逻辑所需的工作量
• 如果管理DynamoDB的共享lambda正在执行审计跟踪存储之类的操作,那么您将能够轻松地测量所需的read&写入容量单位。
• 如果它与消费者解耦,那么故障可以减少并包含在其中。

中介Lambda -坏的一面

• 如果使用lambda的lambda期望返回值,那么这个共享lambda很容易成为单点故障。
• 管理这个lambda的团队和消费团队之间需要更多的沟通。政治可以很容易地通过这个Lambda:D引入
• 如果消耗团队的开发速度比这个共享lambda的所有者快得多,那么如果集成做得不好,它很容易成为其他团队的障碍。