需要在架构中冗余服务，也就是说有多个服务的副本。这需要使用到的具体技术有：
- 负载均衡 + 服务健康检查–可以使用像 Nginx 或 HAProxy 这样的技术；
- 服务发现 + 动态路由 + 服务健康检查，比如 Consul 或 ZooKeeper；
- 自动化运维，Kubernetes 服务调度、伸缩和故障迁移。
对服务进行解耦和拆分，这需要使用到以前的相关技术。
- bulkheads 模式：业务分片 、用户分片、数据库拆分。
- 自包含系统：所谓自包含的系统是从单体到微服务的中间状态，其把一组密切相关的微服务给拆分出来，只需要做到没有外部依赖就行。
- 异步通讯：服务发现、事件驱动、消息队列、业务工作流。
- 自动化运维：需要一个服务调用链和性能监控的监控系统。
让整个架构接受失败的相关处理设计，也就是所谓的容错设计。这会用到下面的这些技术。
-
错误方面：调用重试 + 熔断 + 服务的幂等性设计。
-
一致性方面：强一致性使用两阶段提交、最终一致性使用异步通讯方式。
-
流控方面：使用限流 + 降级技术。
-
自动化运维方面：网关流量调度，服务监控。
-
冗余服务。通过冗余服务的复本数可以消除单点故障。这需要服务发现，负载均衡，动态路由和健康检查四个功能或组件。
-
服务解耦。通过解耦可以做到把业务隔离开来，不让服务间受影响，这样就可以有更好的稳定性。在水平层面上，需要把业务或用户分片分区（业分做隔离，用户做多租户）。在垂直层面上，需要异步通讯机制。因为应用被分解成了一个一个的服务，所以在服务的编排和聚合上，需要有工作流（像 Spring 的 Stream 或 Akka 的 flow 或是 AWS 的 Simple Workflow）来把服务给串联起来。而一致性的问题又需要业务补偿机制来做反向交易。
-
服务容错。服务容错方面，需要有重试机制，重试机制会带来幂等操作，对于服务保护来说，熔断，限流，降级都是为了保护整个系统的稳定性，并在可用性和一致性方面在出错的情况下做一部分的妥协。
此文章为5月Day20学习笔记，内容来源于极客时间《左耳听风》，强烈推荐该课程！
