微服务健康度模型
微服务可靠性设计模型
机器学习
Spring 技术包围圈
dubbo架构图
从左往右看，分为两部分，左半边蓝色背景的部分代表服务消费者，右半边绿色背景的部分代表服务提供者。
从上往下看又分为九层。看左边，九层按功能来划分又被分为了三大类，分别是面向用户的 biz，框架核心 RPC 以及负责远程传输的 Remoting，看图的右边按面向人群又划分为了两类，上面两层是面向用户的API，而下面七层是面向扩展提供者的SPI。
图中的线代表对象与对象之间不同的关系，紫色代表继承、黑色代表依赖、蓝色虚线代表服务注册、服务订阅的过程，也就是上面讲的部署阶段，红色代表一次完整的RPC调用，也就是运行阶段。顺着红色的线，可以体验一次完整的 RPC 调用是如何进行的。
一次rpc的执行链路
首先从图的左边开始，用户从 Proxy 层发起一次RPC调用，Dubbo 从 Registry 层拿到服务的地址列表，再通过 Cluster 层选择其中的一个作为目标地址，再流经Protocol 决定的执行链，最后将服务信息，包括要调用的服务名、方法名、参数等序列化，再经过应用协议编码，通过 Transport 层发送到网络上。右边的服务提供者从网络上收到数据以后，从下往上，依次通过应用协议解码、反序列化得到要调用的服务信息，再经由执行链，最终通过 Invoker 找到目标服务的目标方法，执行并返回结果。
设计原则
Dubbo秉承高内聚、低耦合的设计，这一点体现在架构图中九层的清晰划分上，也体现在依赖的方向上。线条的方向永远是从上指向下，没有循环依赖和反向依赖的出现。Dubbo还有一个很重要的设计哲学就是平等对待第三方的扩展，即Dubbo内建的功能也是通过同样的扩展机制提供出来的，第三方的扩展和内建功能可以相互取代。正是由于Dubbo将第三方扩展当成框架的一等公民，为未来基于这个机制建立生态带来了可能性。
内容反垃圾机制
