1.分布式项目为什么会崛起 有那些优势 什么是分布式项目

在没有分布式项目之前，一个系统所有的功能可能都是在一个项目中创建的，拿商城项目来说明
商城项目组成部分（基础数据，用户，商品，订单，支付，一些辅助的排程/脚本服务）

在没有分布式项目之前，这些可能都是写在同一个项目中，然后把项目放到不同的服务器 A/B/C服务器。最前端有一个NGINX服务器，负责做负载均衡，客户端请求的是Nginx服务器，由Nginx把请求转发到A/B/C服务器，来减轻 在高并发的情况下，单服务器的压力。

1.1什么是分布式项目,我们先来看下 传统项目和分布式项目的结构图

传统项目

分布式项目

从项目结构图中可以看出，传统项目所有模块都创建在一个项目中的，而分布式项目是按照不同的模块创建不同的项目，模块和模块之间的耦合度得到了解耦，

1.DB风险

项目发布也不需要整个项目发布，只需要发布对应的模块项目即可，分了模块数据库也得到了划分，假设那一天 某个程序员不小心把数据库给删除了，在传统项目中所有模块都是放在同一个数据库的，这样就会导致整个系统的DB都没了，而分布式项目项目划分了模块，数据库也得到了切割，即使删除也是删除一个模块的数据库，虽然这样也是灾难性的操作，不过这样也降低了风险。

2.发布风险

项目发布如果设计到修改文件过多，是需要真个项目发布，假设需要发布用户模块的一个bug，而小A在修复订单模块bug的时候，没测试就提交了代码，这个时候发布就会把bug发布到正式环境，从而影响到客户使用，可能你会说不是有人会check代码吗？发布前都要做文件检测的，是人都会有犯错和疏漏，我们要在源头把风险降低到最低。

说道这里就想起来最近阿里的一件事情，一个实习生把阿里云的一个xx删了，导致阿里云系统出现故障。

3.项目解耦&降低访问并发量

传统项目，当访问订单接口的时候，还是会访问整个系统所在的tomcat服务。用数据来说 比如有一万个用户访问订单模块，这时候并发是一万，对于tomcat来说是很有压力，即使前端有Nginx做了负载，不过有的时候还是会存在丢失数据的情况。如果这个时候还有其他模块的访问量，那么对于tomcat的压力就更大了。

https://blog.csdn.net/hll814/article/details/50935765

大禹治水分而治之，分布式项目也是这样道理。

不同的模块放放在不同的tomcat里面，即使订单模块服务挂了，也不会影响到登录和用户模块的访问。

Spring Cloud 流程图

个人理解的 spring cloud 流程，如有不对 欢迎留言...

// 注册中心管理器private java.util.List<String> service = new ArrayList<String>();public static void main(String[] args) {// 客户端请求zuul("/user/userInfo/getInfoById");}/*** zuul 路由/网关 接受客户端请求 转发到对应的服务**/public static void zuul(String url) {// 1.匹配url 定位serviceId 【equals只是一个象征性的假设 匹配规则是xxx开头的url 转发到xxx服务】if (url.equals("/user/**")) {// 转发到【用户服务】 serviceId 【serviceId对应一个项目 每个项目都有一个serviceId】
        }if (url.equals("/order/**")) {// 转发到【订单服务】 serviceId 【serviceId对应一个项目 每个项目都有一个serviceId】
        }if (url.equals("/basedata/**")) {// 转发到【基础数据服务】 serviceId 【serviceId对应一个项目 每个项目都有一个serviceId】
        }// ...很多个if判断
}/*** serviceId 服务ID/名称 当项目启动的时候 会把服务注册到注册中心【eureka】 注册中心统一管理服务**/public void setService(String serviceId) {service.add(serviceId);}//zuul 等同于nginx的 根据URL匹配不同的服务/*http {server {server_name example.com;location /mail/ {proxy_pass http://example.com:protmail/;}location /com/ {proxy_pass http://example.com:portcom/main/;}location / {proxy_pass http://example.com:portdefault;}}}*/

2.介绍

spring cloud核心组成部分

1.路由 Zuul

简介

Zuul是Netflix基于JVM的路由器和服务器端负载均衡器。最常用的场景是替换Nginx反向代理后台微服务供前端UI访问。

Zuul使用Ribbon来定位一个通过发现转发的实例，所有请求都以hystrix命令执行，所以故障将显示在Hystrix指标中。

注：Zuul不包括发现客户端，因此对于基于服务ID的路由，需要在类路径中提供其中一个路由

Zuul的能力：

智能路由：通过与Eureka整合，将自身注册到服务中心，可以获到所有其他微服务实例信息。Zuul默认通过以服务名作为ContextPath来创建路由映射，可以满足大多数情况需要，特殊路由可以通过配置来实现,在Zuul默认路由规则小节有详细描述。

2.注册中心

收集袋，所有的服务进行统一收集,相当于放到同一个代码块，代码块里面的变量是可以直接拿到的。

3.配置中心

所有配置不配置在本地，而是配置在GIT里面,从GIT获取配置信息。

也可以把配置中心搞错一个集群，在并发获取配置文件的时候，可以减轻单服务的压力。

配置文件放本地和放到git上，除了方便管理还有一点是 在使用@value注解获取配置信息的时候，如果配置文件中信息发生变化，需要重启服务，这个一般是不可取的。

简单的来说 spring cloud 配置中心 解耦了@value注解对配置文件读取的操作。

4.断路器监控(Hystrix)

当程序访问接口，接口所依赖的服务出现故障，会导致访问时间过长，线程消耗，堵塞 系统宕机。

用Hystrix可以很好的避开这一点。