你们公司用的Dubbo？那你再额外说说Spring Cloud的核心架构原理？

作为合格的工程师，行业里主流的分布式服务技术栈，Dubbo和Spring Cloud两种，有的公司他是用Dubbo的，不用Spring Cloud的，有的公司是用Spring Cloud的，不用Dubbo的，他们是代表了两种主流技术栈

Java工程师，Dubbo和Spring Cloud起码是基本原理，都有一定的了解

比如说，现在我们有一个电商系统

用户现在需要下单购买一些东西这样子，订单系统、库存系统、仓储系统、积分系统

不太可能说用单块的架构，电商系统你想支撑多少用户量？10万注册用户，日活1000用户来你这里来购买？

百万级用户，十万级日活，单块系统就不太合适了，背后有几十个人的团队在协作开发，此时单块系统是绝对不合适的

梳理和明确一个概念：电商系统，拆分为了多个子系统，一次下订单的请求需要多个子系统协作完成，每个子系统都完成一部分的功能，多个子系统分别完成自己负责的事情，最终这个请求就处理完毕

Spring Cloud

Eureka：服务注册中心

Feign：服务调用

Ribbon：负载均衡

Zuul/Spring Cloud Gatway:网关

这么多的系统，电商系统包含了20个子系统，每个子系统有20个核心接口，一共电商系统有400个接口，这么多的接口，直接对外暴露，前后端分离的架构，难道你让前端的同学必须记住你的20个系统的部署的机器，他们去做负载均衡，记住400个接口

微服务那块，网关

灰度发布、统一熔断、统一降级、统一缓存、统一限流、统一授权认证