Dapr 还非常年轻，还在快速迭代中，距离被广大开发者和三方厂商所支持还有很长的路要走。但是 Dapr 给我们揭示出一个新的方向：通过关注点分离，让开发者只需关注业务逻辑自身，而分布式架构的系统关注下沉到基础设施中实现；让业务逻辑与外部服务解耦，避免厂商绑定；同时应用和应用运行时是两个独立的进程，通过标准化API进行交互，生命周期解耦，便于升级和迭代。
Serverless 的机遇与挑战
在上一篇文章中，我已经对 Serverless 应用基础设施，如函数即服务（FaaS）， Serverless 容器做了介绍。本文谈谈函数即服务 FaaS 应用在架构方面的一些思考。
FaaS 的核心思维是：开发者不必关心基础设施运维、容量规划或者扩容缩容，只需为使用的云资源和服务付费既可。这个思考的背后是：让开发者避免投入基础设施的运维，尽可能复用现有的云服务能力，让开发时间重新分配到对用户有更有直接影响和价值的事情上，比如健壮的业务逻辑、能吸引用户的界面及快速响应、可靠的 API 上。
在软件架构层面中， FaaS 将复杂的业务逻辑拆解成一系列细粒度的函数，并通过事件驱动的方式触发调用。函数之间是松耦合的，可以通过如下两种典型的模式进行协同、组合。
Workflow Orchestration 工作流编排：以阿里云 Serverless 工作流为例，可以通过一个声明式的业务流程来编排任务。这种方式简化了开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作，让开发者聚焦于业务逻辑开发。
随着产品功能迭代，还需要重新走一遍全部流程。在这个流程里，业务需求来自很多团队，包括产品团队、运营团队、市场团队等，橙色标注的文字是一个产品经理一定要重点关注的节点和事项（如下图所示）。
从业务需求到需求规范，一定要做统一收口，如果没有线上工具化的体系，可以指定一个人，让他做统一收口，收口完成之后要形成公司或者部门内部比较完整的指标字典和维度字典。与此同时，一定要对指标字典进行拆分，看看哪些是公共性指标（跨部门或者公司级别）和个性化指标。
这样的方式是极为脆弱的，开发者稍有疏忽就会导致链路信息丢失，甚至影响到正常的业务逻辑。所以非手工埋点的自动链路信息采集，成为了业界的主流，其中包括两种实现方式：
SDK方式: 通过引入链路追踪SDK自动生成链路数据，并自动上报。对于底层框架没有公开API的情况，监控逻辑的注入会比较复杂，有可能需要开发者针对具体的底层框架预先做好适配工作。
对于技术实力非常强的互联网企业，会有专门的技术团队负责全链路监控项目，在使用开源产品的过程中如果遇到任何问题，都可以通过自身的技术实力进行修复和弥补。但对于绝大多数使用者而言，这些挑战所带来的都是漫长而痛苦的体验。
