Serverless中微服务应该是多大？

微服务（MicroService）是软件架构领域业另一个热门的话题。如果说微服务是以专注于单一责任与功能的小型功能块为基础，利用模组化的方式组合出复杂的大型应用程序，那么我们还可以进一步认为Serverless架构可以提供一种更加“代码碎片化”的软件架构范式，我们称之为Function as a Services（FaaS）。

而所谓的“函数”（Function）提供的是相比微服务更加细小的程序单元。例如，可以通过微服务代表为某个客户执行所有CRUD操作所需的代码，而FaaS中的“函数”可以代表客户所要执行的每个操作：创建、读取、更新，以及删除。当触发“创建账户”事件后，将通过AWS Lambda函数的方式执行相应的“函数”。从这一层意思来说，我们可以简单地将Serverless架构与FaaS概念等同起来。

在Serverless中，经常会将“Function as a Services（FaaS）”的概念与你所选择的编程语言中的函数语句混淆。

我们正在进入一个无法画出完美界限的领域，但是经验表明，使用非常小的Serverless功能并不是一个好主意。

你应该记住的一件事是，当决定将（微）服务分拆为单独的功能时，你将不得不应对Serverless困境。只要有可能，将相关逻辑保持在单个功能中就会有很多好处。

决策过程也应考虑到拥有单独的微服务的优势。

如果我分拆这个微服务，

这将使不同的团队独立工作吗？ 我可以从细粒度的资源分配或选择性可伸缩性功能中受益吗？ 如果不是，则应该考虑将该服务与所需的组件等捆绑在一起。