反脆弱
======


* 混乱猴子（Chaos Monkey），在一天的特定时段随机停掉服务器或机器。知道这可能会发生在生产环境，意味着开发人员构建系统时不得不为它做好准备。
* 混乱大猩猩（Chaos Gorilla）用于随机关闭整个可用区（AWS 中对数据中心的叫法）
* 延迟猴子（Latency Monkey）在系统之间注入网络延迟。


让软件拥抱和引发故障，并构建系统来应对::

    当失败发生后从失败中学习的重要性，并在错误真正发生时采用不指责文化。
    作为这种学习和演化过程的一部分，开发人员被进一步授权，他们每个人都需要负责管理他的生产服务。


“理解分布式系统所需的思维方式上的转变”
“事情将会失败”
“你的系统正分布在多台机器上（它们会发生故障），通过网络（它也是不可靠的）通信，这些都会使你的系统更脆弱，而不是更健壮。”
“在分布式架构下，准备好如何应对各种故障的发生是非常重要的”::

    1. 超时
    2. 断路器
    3. 舱壁 （bulkhead）
      3.1 共用「连接池」: 连接池被一个微服务占满，所有的请求都等待。
      3.2 关注点分离: 一个微服务的2个功能，一个有问题被断路影响另一个。
      舱壁最重要，超时和断路器能够帮助你在资源受限时释放它们，但舱壁可以在第一时间确保它们不成为限制。
      实现拒绝请求的舱壁，以避免资源达到饱和，这被称为减载 （load shedding）。
      有时拒绝请求是避免重要系统变得不堪重负或成为多个上游服务瓶颈的最佳方法。
    4. 隔离

Jeff Dean 在他的演讲“Challenges in Building Large-Scale Information Retrieval Systems”::

    2009 年 WSDM 会议:
    设计应该“考虑 10 倍容量的增长，但超过 100 倍容量时就要重写了”。

自动伸缩::

    响应型伸缩和预测型伸缩

微服务架构原则::

    1. 围绕业务建模
    2. 自动化的文化
      微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。
      解决这个问题的一个关键方法是，拥抱自动化文化。
      前期花费一定的成本，构建支持微服务的工具是很有意义的。
      自动化测试 必不可少，因为相比单块系统，确保我们大量的服务能正常工作是一个更复杂的过程。
    3. 隐藏内部实现细节
    4. 一切都去中心化
    5. 独立部署
    6. 隔离失败
    7. 高度可观察