前言:
分布式系统中一些比较关键的设计模式，其中包括容错、性能、管理等几个方面。
- 容错设计又叫弹力设计，其中着眼于分布式系统的各种“容忍”能力，包括容错能力(服务隔离，异步调用，请求幕等性)、可伸缩性(有/无状态的服务)、一致性(补偿事务、重试)、应对大流量的能力(熔断、降级)。可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。
- 管理设计会讲述一些管理分布式系统架构的一些设计模式，比如网关方面的，边车模式，还有一些刚刚开始流行的，如ServiceMesh相关的设计模式。
- 性能设计篇会讲述一些缓存、CORS、索引表、优先级队列、业务分片等相关的架构模式。
一 认识故障和弹力设计
容错主要是为了可用性，描述可用性有公式:
MTTF 是Mean Time To Failure，平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF越长。
(注意:从字面上来说，看上去有Failure的字样，但其实是正常运行的时间。这就是多少个9)
1.1 故障原因
1.网络问题。网络连接出现问题，网络带宽出现拥塞!
2.性能问题。数据库慢SQL、Java Full GO、硬盘I0过大、CPU飙高、内存不足....
3.安全问题。被网络攻击，如DDoS等，
4.运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题...
5.管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步。
6.硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题
总结:故障是正常的，我们要把处理故障的代码当成正常的功能做在架构里，写在代码里。
二 隔离设计(Bulkheads)
在分布式软件架构中，我们同样需要使用类似的技术来让我们的故障得到隔离。这就需要我们对系统进行分离 一般来说，对于系统的分离有两种方式，一种是以服务的种类来做分离，一种是以用户来做分离。
2.1 服务分离
如上图所示，用户，商品，社交业务都已经用服务隔离开
SK:引申到VOD，主功能的库，可以与计费，统计分开，这样不会互相影响。
FE:在亚马逊，每个服务都有自己的一个数据库，每个数据库中都保存着和这个业务相关的数据和相应的处理状态。而展开每个服务从一开始就准备好了对外暴露。同时，这也是微服务所推荐的架构方式。
缺点:
- 内部服务之间交互需要再做设计，例如后续会讲到的异步通信，特别是涉及事务的场景
- 降低性能
2.2 用户请求分离
如上图所示，即为按用户请求分离，其中实例改为集群级分离。
这种分离和上面按功能的分离可以融合。说白了，这就是所谓的“多租户”模式，
对于一些比较大的客户，我们可以为他们设置专门独立的服务实例，或是服务集群与其他客户隔离开来；对于一些比较小的用户来说，可以让他们共享一个服务实例，这样可以节省相关的资源。
SK:独占型，配额高，多收费；共享型，配额少，收费少;
通常来说多租户的做法有三种:
- 完全独立的设计。每个租户有自己完全独立的服务和数据。--比较简单，就是在不同集群隔离
- 独立的数据分区，共享的服务。多租户的服务是共享的，但数据是分开隔离的。--一般采用这种折衷方案，比较复 杂
- 共享的服务，共享的数据分区。每个租户的数据和服务都是共享的。--比较简单，但是相当于没有按照服务去做隔离而已
2.3 总结:
- 我们需要定义好隔离业务的大小和粒度，过大和过小都不好。这需要认真地做业务上的需求和系统分析;
- 无论是做系统板块还是多租户的隔离，你都需要考虑系统的复杂度、成本、性能、资源使用的问题，找到一个合适的均衡方案。
摘录自左耳听风
