我们不解析dubbo，只是根据产品的需求进行总结，具体内容请参考官网资料。
当我们的应用在17个应用协同下完成整体业务处理后，实施给我们带来了难题。怎么去降低实施成本？我们的第一个需求是怎么降低配置，让配置不那么容易出错。在微服务大行其道的今天，或多或少让人与想到微服务化。
我们真的需要微服务化来支持我们的业务吗？
现在来看我们会采用微应用化，让我们的组件更为内聚的同时实现可快速扩展。
配置中心是我们第一个需要的组件，将用来降低实施过程中的重复配置事项，让我们的配置尽可能集中在少量的区域中。
配置中心北京的团队已经使用了nacos，我们将直接接受。但最近也同步研究了下zookeeper/apollo/console等中间键，都经过了生产环境的验证。zookeeper、nacos、apollo由于有java源码，快速的审视了下源码实现。
由于内部系统中的各个组件的压力是不一致的，客户也对应用的性能/可用性等提出了疑问，我们根据运行情况，将会把核心服务进行多实例存活部署，所以将采用类似微服务的服务注册与服务发现机制，为后续核心组件多实例提供运行基础。
dubbo3在dubbo2的基础上，提供了应用级的服务注册与发现机制，降低注册中心与应用客户端由于接口膨胀带来的服务地址解析压力。这与我们的产品需求是一致的，我们的应用拆分将采用业务独立级别构建，所以到应用级别对我们来说是比较有意愿的。
其实北京的团队已经采用了openfeign作为rpc框架，我们也将接受现实，那为什么会研究dubbo呢？出于对技术负责任的态度，openfeign对比dubbo确实够轻量级的，但作为技术底座。我们还是需要多研究类似的解决方案，综合评价实现细节。
dubbo核心是解决rpc功能，作为微服务底座，同时提供了服务自理相关的实现，结合第三方的配置中心与服务注册中心，形成一个体系化的微服务解决方案。
我们不追求全面微服务化，我们将根据需要，引入配置中心与注册中心，降低我们的实施成本的同时为业务扩展搭好基于应用级的服务多活实例，以便在业主单位业务扩展过程中，预留横向扩展能力。
围绕dubbo的相应体系，进行了较为全方位的梳理。后续我们将进一步对dubbo进行深化理解，希望把dubbo中的对价组件化与SPI机制引入到我们的业务体系中，实现按照需要组合组件：如提供工作流平台的等量替换/提供报表平台的等量替换等功能。
