Spring Cloud 我的心得 理论

 

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的压力就更大了。

 

http://www.javashuo.com/article/p-wqencyrn-mo.html

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

不一样的模块放放在不一样的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能够很好的避开这一点。