Spring Cloud分布式微服务整体架构

去饭店吃饭就是一个完整的业务，饭店的厨师、配菜师、传菜员、服务员就是分布式；厨师、配菜师、传菜员和服务员都不止一个人，这就是集群；分布式就是微服务的一种表现形式，分布式是部署层面，微服务是设计层面。

如果聊分布式这块的技术，围绕Dubbo来拷问的，但是呢，现在其实非常流行的是Spring Cloud，Dubbo和Spring Cloud以及阿里系的一些技术，现在正在融合，Spring Cloud Alibaba，只不过现在用的公司暂时还没那么多而已

做一下对比,其实底层架构原理是类似的

Dubbo，RPC的性能比HTTP的性能更好，并发能力更强，经过深度优化的RPC服务框架，性能和并发能力是更好一些

很多中小型公司而言，其实稍微好一点的性能，Dubbo一次请求10ms，Spring Cloud耗费20ms，对很多中小型公司而言，性能、并发，并不是最主要的因素

Spring Cloud这套架构原理，走HTTP接口和HTTP请求，就足够满足性能和并发的需要了，没必要使用高度优化的RPC服务框架

Dubbo之前的一个定位，就是一个单纯的服务框架而已，不提供任何其他的功能，配合的网关还得选择其他的一些技术

Spring Cloud，中小型公司用的特别多，老系统从Dubbo迁移到Spring Cloud，新系统都是用Spring Cloud来进行开发，全家桶，主打的是微服务架构里，组件齐全，功能齐全。网关直接提供了，分布式配置中心，授权认证，服务调用链路追踪，Hystrix可以做服务的资源隔离、熔断降级、服务请求QPS监控、契约测试、消息中间件封装、ZK封装

剩是剩在功能齐全，中小型公司开箱即用，直接满足系统的开发需求

Spring Cloud原来支持的一些技术慢慢的未来会演变为，跟阿里技术体系进行融合，Spring Cloud Alibaba，阿里技术会融入Spring Cloud里面去

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

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

大白话 + 现场画图

上网看一些博客资料，或者是买一些Spring Cloud的书，可能没考虑过一个事儿，第一篇必须是用非常通俗的语言，把一个系统如果用Spring Cloud来做分布式架构的话，那么他需要用到Spring Cloud哪些组件，为什么

跟着书或者博客，直接上手开始搭建demo，开始做起来了

分别用Dubbo和Spring Cloud做两个最基本的Demo工程，用电商背景来搭建几个服务

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

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

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

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

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

我们不会让每个视频太长，按照我们大纲来讲，说是60讲，粗略的大纲，其实最终会拆分成可能上百讲，Spring Cloud架构原理，我们就要分为上下两讲来说

Spring Cloud

Eureka：服务注册中心

Feign：服务调用

Ribbon：负载均衡

Zuul/Spring Cloud Gatway:网关

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

微服务那块，网关

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

Hystrix、链路追踪、stream、很多组件，Hystrix这块东西，其实是会放在高可用的环节去说的，并不是说一个普通系统刚开始就必须得用的，没有用好的话，反而会出问题，Hystrix线路熔断的框架，必须得设计对应的一整套的限流方案、熔断方案、资源隔离、降级机制，配合降级机制来做