你们的系统使用了哪种服务框架？为什么要这样技术选型？

前言

如果将要系统进行服务化，必然会涉及到将整块系统拆分为一个个独立的小系统，也就是服务拆分。既然是服务拆分，必然会涉及到服务管理和服务调用等一系列的问题，所以，服务框架的选择将直接影响到后拆分后系统的稳定性，健壮性，开发的便利性。

框架选择

目前市面流行的服务框架一般是两个spring cloud 和 dubbo。但是从近来这几年微服务的大量流行，默认spring cloud的趋势越来越明显。

下面开始这两个框架选型对比：

功能对比	spring cloud	dubbo
并发性能	spring cloud 使用的是http协议，性能与dubbo对比稍微差点	dubbo是一款优秀的RPC框架，并发能力比springcloud强
注册中心	有全家桶配置中心。eurake nacos,亦可以选择zookeeper	一般选择zookeeper
分布式配置中心	nacos/ spring cloud config	阿波罗
网关	zuul / srping cloud gateway	需引入其他网关组件
负载均衡	ribbon	自带负载均衡
熔断功能	hystrix	需引入其他熔断框架
社区活跃度	活跃、版本更新快	不活跃

总结

所以现在一般都会选择spring cloud 全家桶做微服务，因为spring cloud胜在功能更全，有一些列可以开箱即用的组件，满足服务化后的各种场景需求。

或者说dubbo就是一个纯正的RPC框架，对于服务之间远程调用，性能非常优秀，并发高，响应快，但是也仅仅是一个RPC框架，如果需要其他的功能，则需要引入其他 的组件，因此在引入其他组件的过程中，可能会带来更多的问题。
所以对于易用性这一块，spring cloud已经集成了各方面微服务所需要的组件，上手更快，拆坑更少，团队上手更容易，学习成本更低。可以开箱即用，快速上手

综上：在服务框架的技术选型上，spring cloud更胜一筹