gydtep
发表于 2020-11-18 07:26:35
让开发者避免投入基础设施的运维，尽可能复用现有的云服务能力，让开发时间重新分配到对用户有更有直接影响和价值的事情上，比如健壮的业务逻辑、能吸引用户的界面及快速响应、可靠的 API 上。
gydtep
发表于 2020-11-18 07:43:55
Workflow Orchestration 工作流编排：以阿里云 Serverless 工作流为例，可以通过一个声明式的业务流程来编排任务。
gydtep
发表于 2020-11-18 10:46:01
相对而言，API 的接口是更加稳定的，而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。
gydtep
发表于 2020-11-18 11:03:31
API 应该是声明式，可描述/自描述的：通过规范化的描述，API 易于沟通、易于理解、易于验证，简化开发协同。支持服务的消费者和提供者并行开发，加速开发周期。
gydtep
发表于 2020-11-18 14:10:23
事件驱动架构实现了事件的生产者和消费者的彻底解耦。生产者无需关注事件如何被消费，同时消费者无需关注事件的生产方式；我们可以动态添加更多消费者而不影响生产者，可以增加消息中间件对事件进行动态路由和转换。
gydtep
发表于 2020-11-18 14:36:34
事件驱动架构的另一个重要优点是提升了系统的可伸缩性。事件生产者在等待事件消费时不会被阻塞，并且可以采用 Pub/Sub 方式，让多个消费者并行处理事件。
gydtep
发表于 2020-11-18 16:48:37
支付宝的支付业务背后有一百多个业务处理节点，在微服务时代，其背后可能有几百个甚至上千个业务节点，假设每个节点的可用率都是5个9，把几百个甚至几千个节点的可用率乘起来就会使得整体的可用率非常小。
gydtep
发表于 2020-11-18 20:35:26
首先，签约业务是异步的，在设计时不应被纳入系统的核心链路。另外，签约服务需要与网关和商户服务进行信息同步，仍可能导致网关和商户服务宕机，比如修改商户的鉴权信息可能使签约不成功。因此，签约服务需要实现灰度设计。
gydtep
发表于 2020-11-18 21:18:56
值得一提的是，现在的分布式数据库能够实现RPO等于0，使得当数据出问题时不发生数据丢失，其基本原理就是存储多个数据副本，并且当数据出现故障时，可以在多个副本间切换，数据恢复速度非常快。
gydtep
发表于 2020-11-19 11:28:03
由于会员信息的查询遵循了较为固定的范式，因此可以将会员信息的查询功能前置到收单服务，从而使收单服务不需要访问会员信息，而可以直接访问会员信息所依赖的服务。这本质上也是通过应用层设计来减小高可用的成本。
