gydtep

API 应该是被优先设计的：我们知道用户需求是复杂多变的，比如从桌面到移动端，应用的展现方式和操作流程都有可能不同；然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言，API 的接口是更加稳定的，而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。

gydtep

API 应该是声明式，可描述/自描述的：通过规范化的描述，API 易于沟通、易于理解、易于验证，简化开发协同。支持服务的消费者和提供者并行开发，加速开发周期。支持不同的技术栈的实现，比如对于同一个 API 接口，其服务实现采用 Java 。前端应用可以使用 JavaScript ，而服务器端应用可以使用 Golang 进行服务调用等等。这样可以让开发组织可以根据自己的技能栈和系统要求灵活选择合适的技术。

gydtep

API 应该具备 SLA ：API 作为服务间的集成界面，与系统的稳定性息息相关。SLA 应该作为 API 设计的一部分，而不是部署后再考虑。在分布式系统中，稳定性风险无处不在，通过 API 优先的设计模式，我们对独立的服务进行稳定性架构设计、容量规划；我们还可以对独立的 API 进行故障注入、稳定性演练，来消除系统性的稳定性风险。

gydtep

在传输层协议， gRPC 选择了 HTTP/2，相较于 HTTP/1.1，其传输效率有了很大提升。此外 HTTP/2 作为一个成熟的开放标准，具备丰富的安全、流控等能力，同时拥有良好的互操作性。gRPC 不仅可以用于 Server 端服务调用，也可以支持浏览器、移动 App 和 IoT 设备与后端服务的交互。gRPC 在功能上已经具备完整的 RPC 能力，也提供了扩展机制来支持新的功能。

gydtep

谈事件驱动架构 （EDA - Event Driven Architecture），我们首先来解释一下什么是事件。事件是指对已经发生的事情、状态变化等的记录。它们是不可变的（无法更改或删除），并且按其创建顺序排序。相关各方可以通过订阅已发布的事件来获取有关这些状态变化的通知，然后使用所选择的业务逻辑根据这些信息采取操作。

gydtep

。如果需要修改或升级某些实例，就是创建一批新的实例进行替换。这种模式的可以减少了配置管理工作的负担，保障系统配置变更和升级可以可靠地重复执行，避免令人头疼的配置漂移问题；易于解决部署环境间的差异，让持续集成与持续部署过程变得更流畅；支持更好的版本管理，在部署出错时可进行快速回滚，

gydtep

自包含可观测性
分布式系统所面对的最大挑战之一就是可观测性。可观测性可以帮助我们解系统当前的状态，并作为应用自愈，弹性伸缩和智能运维的基础。

gydtep

消息队列 AMQP 版由阿里云基于 AMQP 标准协议自研，完全兼容 RabbitMQ 开源生态以及多语 言客户端，打造分布式、高吞吐、低延迟、高可扩展的云消息服务。

gydtep

伴随着容器技术逐步标准化，进一步促进了容器生态的分工和协同。基于 Kubernetes，生态社区开始构建上层的业务抽象，比如服务网格 Istio、机器学 习平台 Kubeflow、无服务器应用框架 Knative 等。

gydtep

Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提 供了分布式应用管理的核心能力：

资源调度：根据应用请求的资源量 CPU、Memory，或者 GPU 等设备资源，在集群中选择合适的节点来运 行应用；