最新Java微服务项目该选择什么技术架构

一个完整的微服务项目，应该包含以下几种类型的必要组件：

注册中心：Euraka、Zookeeper、Nacos

分布式配置中心：Spring Cloud Config、Nacos、Disconf

熔断降级：Hystrix，Sentinel、Resilience4j

服务通信RPC：Feign、OpenFeign、Dubbo

分布式事务：Setea

负载均衡：Ribbon、LoadBalancer、Dubbo

API网关：zuul、Spring Cloud Gateway、Dubbo Proxy、Nginx

我们知道现今有Spring Cloud Netflix系列、Spring Cloud官方系列、Spring Cloud Alibaba系列组件，由于Netflix系列从2018年开始就都不再维护，所以如果是一个新项目，就应该尽量避免使用此系列的组件，防止后续更换组件带来的困扰。所以Euraka、Hystrix、Feign、Ribbon、Zuul都可以直接被舍弃了。

Spring Cloud Config是Spring官方推荐的分布式配置中心，但是由于自身的一些问题，以及在其他配置中心光芒的掩盖下，也日渐无人问津。

Nginx很多人将其归为网关，其实在微服务的架构下，Nginx是针对集群，进行多个项目间的路由转发，而真正的分布式API网关如GateWay和Dubbo等，则是主要针对分布式，进行项目内路由的转发。所以Nginx为必选项，API网关需要另外考虑。

那么剩下的组件就还剩下：

注册中心：Zookeeper、Nacos

分布式配置中心：Nacos、Disconf、Apollo、Diamond

熔断降级：Sentinel、Resilience4j

服务通信RPC：OpenFeign、Dubbo

分布式事务：Setea

负载均衡：LoadBalancer、Dubbo

API网关：Spring Cloud Gateway、Dubbo Proxy

我们经过分析发现，其实最后剩下的，大致可以分为两类：Spring Cloud Alibaba系列相关组件；以及Spring Cloud官方对于过时的Netflix的替代组件；

当然，两种类型没有明显的界限区分，完全可以混搭，并且不会有什么问题，每个组件都很好的兼容了其他组件，也由此让人更加头皮发麻，不知如何抉择。

方案一：

注册中心：Nacos

分布式配置中心：Nacos

熔断降级：Sentinel

服务通信RPC：OpenFeign

分布式事务：Seata

负载均衡：LoadBalancer

API网关：Spring Cloud Gateway

理由：经典的Spring Cloud Alibaba一套。服务通信并没有Dubbo，而是使用OpenFeign。由于OpenFeign在2020年之后的版本，不再默认支持Ribbon和Hystrix，反而默认支持LoadBalancer承载负载均衡功能，所以负载均衡就不需要犹豫了。而熔断降级组件Hystrix的缺失，按道理使用Spring Cloud官方推荐的Resilience4j，或者使用Alibaba系列的Sentinel都是可以的，但是考虑到Resilience4j只包含限流降级的基本场景，对于非常复杂的企业级服务架构可能无法很好地 cover 住；同时 Resilience4j 缺乏生产级别的配套设施（如提供规则管理和实时监控能力的控制台），所以选择Sentinel。

方案二：

注册中心：Zookeeper

分布式配置中心：Zookeeper

熔断降级：Sentinel

服务通信RPC：Dubbo

分布式事务：Seata

负载均衡：Dubbo LB

API网关：Dubbo Proxy / Spring Cloud GateWay

理由：Dubbo系列也是众多大公司的选择，一般选择Dubbo作为RPC通信框架，注册中心和配置中心都会选择Zookeeper，两者孟不离焦，焦不离孟，Zookeeper也是Dubbo官网中明确表示推荐的注册中心。至于熔断降级，Dubbo本身是自带降级功能的，但是不完善，同时也缺失熔断功能，所以需要集成其他熔断降级组件，同出一源的Sentinel自然就是最好的选择。Dubbo 里面默认集成了负载均衡的算法和实现，所以无需另外集成负载均衡组件。网关的话，可以选择Dubbo Proxy或者Spring Cloud GateWay，此方案的网关可以根据自己想法酌情考虑，甚至不使用网关也可以，无法给出肯定推荐。

针对方案二，还有个变种，那就是替换Zookeeper，使用Nacos替换。有许多项目也是舍弃Zookeeper，拥抱Nacos。正如以下爱奇艺的Dubbo实践所言，Zookeeper并不是微服务注册中心的最佳选型，它的主要缺点包括：

1、无法横向扩展；
2、作为一个一致性的系统，在网络分区会产生不可用；

爱奇艺在 Dubbo 生态下的微服务架构实践

结语

每个公司都有自己的基础环境，基础环境不同，就会对技术选型产生极大影响。所以如美团、滴滴、饿了么等等公司，要么另起炉灶，要么是对这些微服务组件进行私人定制，使得更加符合公司环境。而如果公司没有那么大的体量，可以参考以上最新的微服务选型推荐。

–我是“道祖且长”,一个在互联网"苟且偷生"的Java程序员
“如果感觉博客对你有用，麻烦给个点赞、评论、收藏，谢谢”

最新Java微服务项目该选择什么技术架构

一个完整的微服务项目，应该包含以下几种类型的必要组件：

方案一：

方案二：

结语

最新Java微服务项目该选择什么技术架构相关推荐

最新文章

热门文章