03.dubbo第二次梳理后的思考

dubbo的详细文档请参考官方资料，文档 | Apache Dubbo.

当我们下dubbo的源代码进行分析时，整体设计较为清晰，各个jar提供相对独立的服务板块。并且在整体项目中，采用了SPI模式，让整个体系形成了松散的组合形式，让各个组织在使用过程中，可以根据自身的现状使用合适的组件完成相应的工作。

来自官网的扩展加载图。

在微服务框架中，核心工作是统一配置/服务注册与发现/rpc调用/对象传输序列化/服务治理等。并且各自有不同的实现，dubbo采用的提供基础API定义+平行化扩展能力，使整体体系中的各个组件可以独自扩展，实现不依赖特定平台的效果。

序列化API与实现：

 RPC API与实现：

 

远程调用API与实现

 

 服务注册发现API与实现

元数据API与实现

容器API与实现

配置中心实现

 

从以上各组件的不同实现来看，不同的组织可用根据自身的需求引入相应的组件即可，实现在已有的平台集成上快速引入体系化的微服务集成支撑组件。

引入dubbo后，微服务改造将进入快车道......

但有个问题，为什么微服务框架的设计者没都反对在项目初期进行微服务？从dubbo的源码分析过程就能理解，单应用与微服务直接是相同的。对于客户来说，解决实际问题就行，而微服务的引入，带来了横向扩充的同时，也同时引入了产品的复杂性。从单应用的单调用，到微服务的跨进程多可能端的调用，引入的复杂性在项目初期可以直接掩盖带来的便利性。

我们从2020年起，已经走过了业务构建过程，正在考虑降低配置风险，引入平行扩展基座，所以将分步推进，逐步引入统一配置中心/rpc框架/服务治理等相关服务，以便解决整个产品不断发展的需要。