微服务设计：规模化微服务

我们也可以在试图阻止不可避免的故障上少花一点时间，而花更多时间去优雅地处理它。许多组织使用流程和控制来试图阻止故障的发生，但实际上很少花费心思想想如何更加容易地在第一时间从故障中恢复过来。

假设一切都会失败，会让你从不同的角度去思考如何解决问题。

通过让软件拥抱和引发故障，并构建系统来应对，这只是Netflix做的一部分事情。它还知道当失败发生后从失败中学习的重要性，并在错误真正发生时采用不指责文化。作为这种学习和演化过程的一部分，开发人员被进一步授权，他们每个人都需要负责管理他的生产服务。

你的系统正分布在多台机器上（它们会发生故障），通过网络（它也是不可靠的）通信，这些都会使你的系统更脆弱，而不是更健壮。

超时是很容易被忽略的事情，但在使用下游系统时，正确地处理它是很重要的。给所有的跨进程调用设置超时，并选择一个默认的超时时间。当超时发生后，记录到日志里看看发生了什么，并相应地调整它们。

超时和断路器能够帮助你在资源受限时释放它们，但舱壁可以在第一时间确保它们不成为限制。

在一个负载均衡器后，放置多台主机运行你的微服务实例。对于微服务的消费者来说，你不知道你是在跟一个微服务实例通信，还是一百个。

在开始一个新项目时，我们往往不知道真正想要构建的是什么，也不知道它是否会成功。我们需要快速实验，并以此了解需要构建哪些功能。如果在前期为准备大量的负载而构建系统，将在前期做大量的工作，以准备应对也许永远不会到来的负载。

让你的域名条目指向负载均衡器，接着由它来指向服务实例。当你部署一个新的实例时，可以从负载均衡器中移除旧的实例，并添加新的实例。有些人使用DNS轮询调度，DNS条目会指向一组机器。这种技术存在很严重的问题，因为底层主机对客户端是不可见的，因此当某个主机有问题时，很难停止对该主机的请求路由。

当你只有单个节点时，使用DNS直接引用主机就可以了。但对于那些有多个主机实例的情况，应该将DNS条目解析到负载均衡器，它可以正确地把单个主机移入和移出服务。

Zookeeper最初是作为Hadoop项目的一部分进行开发的。它被用于令人眼花缭乱的众多使用场景中，包括配置管理、服务间的数据同步、leader选举、消息队列和命名服务。

Zookeeper依赖于在集群中运行大量的节点，以提供各种保障。这意味着，你至少应该运行三个Zookeeper节点。Zookeeper的大部分优点，围绕在确保数据在这些节点间安全地复制，以及当节点故障后仍能保持一致性上。