问题描述 闲话少叙，先上代码。
public function main() { Util util = new Util(); util.print(); } public class Util { public static provider = new Provider(); public Util() { # do sth } public void print() { # print sth } } public function Provider() { public Provider() { loadData(); } private void loadData() { # load data } } 大概使用逻辑是这样，在调用入口，实例化Util对象并调用他的print方法。 这个时候，获取到了一个runtime exception：class Util not defined。
类明明就摆在那里，为什么会报异常呢？ 大家如果了解了类静态成员变量的初始化过程，就一眼看出来问题。
首先，provider是在Util类被加载的时候初始化的，要早于Util的实例化。
其次，如果provider初始化失败，会导致Util类加载失败，在实例化的时候就会抛异常。
问题的直接原因是在Provider的构造过程，由于构造函数执行了loadData的动作，这里就存在一些不确定因素，会导致错误的发生，从而影响到了Util的加载。
改进思路 精简类初始化的过程，优先保证对象能实例化成功，从而再执行数据加载的逻辑。可以利用Spring的PostConstruct注解来实现实例化和数据加载动作的分离。
API网关和负载均衡器都是微服务体系结构中非常重要的组件，但它们却发挥着不同的作用，各司其职。
API网关是所有API请求的唯一入口，其为微服务提供了路由、限流、熔断、认证和鉴权、API版本控制等功能。向上对客户端隐藏了底层微服务的复杂性，向下还对各个领域服务提供防腐层的作用。在宏观上讲，通过上述功能，API网关将不确定性（流量的不确定性、用户行为的不确定性等等）转化为确定性，极大提高了系统的可靠程度。
这篇文章的初衷，是记录拜读由Nathan Bronson, Aleksey Charapko, Abutalib Aghayev, and Timothy Zhu共同发表的论文Metastable Failures in Distributed Systems的收获，这篇论文描述了一个在大规模分布式系统中很常见的失败场景：亚稳定失败（metastable failures），它们为什么通常在高负载分布式系统中发生，以及解决问题的思路框架：如何识别和从亚稳定失败中恢复，甚至如何避免发生亚稳定失败。