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可以很好的避开这一点。