一个好的架构师可以做到以下几点：
根据需求设计事件驱动型架构、微服务架构和/或多层架构
确定架构设计中使用的组件的扩展策略
根据要求确定实现松耦合所需的AWS服务
确定何时使用容器
确定何时使用无服务器技术和模式
根据要求推荐合适的计算、存储、联网和数据库技术
将专用AWS服务用于工作负载
纵向扩缩与横向扩缩
在多个可用区进行水平扩展
松耦合
ELB负载均衡器类型
ELB使用案例
ELB常见功能
解耦架构的消息队列（Amazon SQS）
适用于秒杀系统
解耦架构的发布/订阅消息的收发（Amazon SNS）
在微服务架构中，不同的服务之间应该尽可能地解耦，以便每个服务可以独立开发部署和拓展。解耦还可以应用于系统的各个层级，包括应用程序层、数据层和基础设施层，从而提高系统的弹性和可靠性。
在使用AWS或类似的云计算平台时，解耦也是一个关键的设计原则。通过合理的架构设计和使用适当的AWS服务，可以实现系统的解耦，从而获得更好的性能、可用性和可维护性。例如，将应用程序拆分微服务，并使用AWS的服务进行消息传递、数据存储和计算，可以帮助实现系统的解耦。
解耦示例: 将Amazon S3 与 Amazon SNS结合使用
Amazon SNS与Amazon SQS的对比
SOA架构（Service-Oriented Architecture，面向服务的架构）是一种软件设计和开发范例，其核心思想是将应用程序设计为一组相互独立且可重用的服务。这些服务通过标准化的接口进行通信，可以被动态地组合和重组以满足不同的业务需求。
在SOA架构中，服务是系统的基本构建块，每个服务都代表一个特定的业务功能或过程。这些服务通过网络进行通信，可以跨越不同的平台和技术栈。通常，SOA架构中的服务以Web服务的形式提供，使用标准的通信协议（如SOAP或REST）进行通信。
SOA架构的关键特点包括：
松耦合性：服务之间的耦合度低，每个服务都是独立的，可以单独开发、部署和更新，而不会对其他服务产生影响。
可重用性：由于服务是独立的，它们可以被多个应用程序或业务流程重用，从而提高了开发效率和系统的灵活性。
标准化的接口：每个服务都有清晰的接口定义，通常使用标准的通信协议和数据格式，使得不同平台和技术栈的应用程序可以无缝地与之交互。
面向业务需求：SOA架构将重点放在满足业务需求上，通过将系统拆分成可管理的服务，使得系统更容易理解、维护和扩展。
微服务是一种架构的方式和设计的理念。就是把一个项目中大的部分去拆分成微小的服务。然后它们能够独立去开发、独立的部署、独立的上线、独立的运维和独立的DB。服务和服务之间可以通过API去交互
容器与微服务
在AWS上运行容器
无服务器（托管给云服务器产商）
就跟水电一样按需按量使用
AWS无服务器产品
API Gateway（API 网关） 微服务器中内部独立部分的交互方法
Amazon EventBridge（事件桥）：源、规则、目标
AmazonEventBridge是一项托管的事件总线服务，可以轻松地将应用程序地事件数据从一个源床送到一个目标。它允许开发人员通过简单地方式建立应用程序之间的解耦，从而实现更加可靠和可拓展的架构。
EventBridge允许您定义事件规则，这些规则确定了如何将事件从一个源传送到一个或多个目标。事件源可以是AWS服务、SaaS应用程序、自定义应用程序、或者任何能够生成事件的系统。目标可以是AWS Lambda函数、Amazon SNS主题、Amazon SQS队列、Kinesis流、以及其他支持的服务。
事件驱动示例： CloudWatch告警自动响应。
Amazon CloudWatch
AWS CloudTrail是一项AWS提供的服务，用于跟踪、记录和存储与AWS账户相关的活动和事件
AWS CloudTrail
一个好的架构师可以做到以下几点：
确定自动化策略以确保基础设施的完整性
确定在跨AWS区域或可用区提供高可用性/或容错架构时所需的AWS服务
实施设计以缓解单点故障
实施策略以确保数据的持久性和可用性（例如，备份）
使用AWS服务来提高旧式应用程序和不是为云构建的应用程序的可靠性（例如，在无法更改应用程序的情况）
将专用AWS服务用于工作负载
示例：多区域高可用性和DNS
Amazon EBS
使用AWS Backup自动创建快照
Amazon EFS
Amazon FSx
Amazon S3的对象复制
通过多可用区域部署实现数据库的高可用性
使用Amazon Aurora进行扩缩
Amazon DynamoDB全局表
灾难恢复
恢复点目标（RPO）和恢复时间目标（RTO）
用于灾难恢复的基本AWS服务和功能
比较AWS上的常用灾难恢复实践
可靠性设计原则
