博客

  • 负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?来源:cnblogs.com/Courage129/p/14383897.html

    • Nginx特点
      • 正向代理与反向代理
      • 负载均衡
      • 动静分离
    • Nginx的优势
      • 可操作性大
      • 网络依赖小
      • 安装简单
      • 支持健康检查以及请求重发
    • LVS 的优势
      • 抗负载能力强
      • 配置性低
      • 工作稳定
      • 无流量

    今天总结一下负载均衡中LVS与Nginx的区别,好几篇博文一开始就说LVS是单向的,Nginx是双向的,我个人认为这是不准确的,LVS三种模式中,虽然DR模式以及TUN模式只有请求的报文经过Director,但是NAT模式,Real Server回复的报文也会经过Director Server地址重写:

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    首先要清楚的一点是,LVS是一个四层的负载均衡器,虽然是四层,但并没有TCP握手以及分手,只是偷窥了IP等信息,而Nginx是一个七层的负载均衡器,所以效率势必比四层的LVS低很多,但是可操作性比LVS高,后面所有的讨论都是基于这个区别。

    为什么四册比七层效率高?

    四层是TCP层,使用IP+端口四元组的方式。只是修改下IP地址,然后转发给后端服务器,TCP三次握手是直接和后端连接的。只不过在后端机器上看到的都是与代理机的IP的established而已,LVS中没有握手。

    7层代理则必须要先和代理机三次握手后,才能得到7层(HTT层)的具体内容,然后再转发。意思就是代理机必须要与client和后端的机器都要建立连接。显然性能不行,但胜在于七层,人工可操作性高,能写更多的转发规则。

    Nginx特点

    Nginx 专为性能优化而开发,性能是其最重要的要求,十分注重效率,有报告 Nginx 能支持高达 50000 个并发连接数。

    另外,Nginx 系列面试题和答案全部整理好了,微信搜索Java技术栈,在后台发送:面试,可以在线阅读。

    正向代理与反向代理

    正向代理 :局域网中的电脑用户想要直接访问服务器是不可行的,服务器可能Hold不住,只能通过代理服务器来访问,这种代理服务就被称为正向代理,特点是客户端知道自己访问的是代理服务器。

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    反向代理 :客户端无法感知代理,因为客户端访问网络不需要配置,只要把请求发送到反向代理服务器,由反向代理服务器去选择目标服务器获取数据,然后再返回到客户端。

    此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器地址,隐藏了真实服务器 IP 地址。

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    负载均衡

    客户端发送多个请求到服务器,服务器处理请求,有一些可能要与数据库进行交互,服务器处理完毕之后,再将结果返回给客户端。

    普通请求和响应过程如下图:

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    但是随着信息数量增长,访问量和数据量增长,单台的Server以及Database就成了系统的瓶颈,这种架构无法满足日益增长的需求,这时候要么提升单机的性能,要么增加服务器的数量。

    关于提升性能,这儿就不赘述,提提如何增加服务器的数量,构建集群,将请求分发到各个服务器上,将原来请求集中到单个服务器的情况改为请求分发到多个服务器,也就是我们说的负载均衡。

    图解负载均衡:

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    关于服务器如何拆分组建集群,这儿主要讲讲负载均衡,也就是图上的Proxy,可以是LVS,也可以是Nginx。假设有 15 个请求发送到代理服务器,那么由代理服务器根据服务器数量,这儿假如是平均分配,那么每个服务器处理 5 个请求,这个过程就叫做负载均衡。

    动静分离

    为了加快网站的解析速度,可以把动态页面和静态页面交给不同的服务器来解析,加快解析的速度,降低由单个服务器的压力。

    动静分离之前的状态

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    动静分离之后

    负载均衡 LVS vs Nginx 对比!还傻傻分不清?

    图片

    光看两张图可能有人不理解这样做的意义是什么,我们在进行数据请求时,以淘宝购物为例,商品详情页有很多东西是动态的,随着登录人员的不同而改变,例如用户ID,用户头像,但是有些内容是静态的,例如商品详情页,那么我们可以通过CDN(全局负载均衡与CDN内容分发)将静态资源部署在用户较近的服务器中,用户数据信息安全性要更高,可以放在某处集中,这样相对于将说有数据放在一起,能分担主服务器的压力,也能加速商品详情页等内容传输速度。

    Nginx的优势

    可操作性大

    Nginx是一个应用层的程序,所以用户可操作性的空间大得多,可以作为网页静态服务器,支持 Rewrite 重写规则;支持 GZIP 压缩,节省带宽;可以做缓存;可以针对 http 应用本身来做分流策略,静态分离,针对域名、目录结构等相比之下 LVS 并不具备这样的功能,所以 nginx 单凭这点可以利用的场合就远多于 LVS 了;但 nginx 有用的这些功能使其可调整度要高于 LVS,所以经常要去触碰,人为出现问题的几率也就大

    网络依赖小

    nginx 对网络的依赖较小,理论上只要 ping 得通,网页访问正常,nginx 就能连得通,nginx 同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;LVS 就比较依赖于网络环境,目前来看服务器在同一网段内并且 LVS 使用 direct 方式分流,效果较能得到保证。另外注意,LVS 需要向托管商至少申请多于一个 ip 来做 visual ip

    安装简单

    nginx 安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。LVS 的安装和配置、测试就要花比较长的时间,因为同上所述,LVS 对网络依赖性比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦的多

    nginx 也同样能承受很高负载且稳定,但负载度和稳定度差 LVS 还有几个等级:nginx 处理所有流量所以受限于机器 IO 和配置;本身的 bug 也还是难以避免的;nginx 没有现成的双机热备方案,所以跑在单机上还是风险比较大,单机上的事情全都很难说

    支持健康检查以及请求重发

    nginx 可以检测到服务器内部的故障(健康检查),比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前 LVS 中 ldirectd 也能支持针对服务器内部的情况来监控,但 LVS 的原理使其不能重发请求。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,nginx 会把上传切到另一台服务器重新处理,而 LVS 就直接断掉了。

    LVS 的优势

    抗负载能力强

    因为 LVS 工作方式的逻辑是非常简单的,而且工作在网络的第 4 层,仅作请求分发用,没有流量,所以在效率上基本不需要太过考虑。LVS 一般很少出现故障,即使出现故障一般也是其他地方(如内存、CPU 等)出现问题导致 LVS 出现问题

    配置性低

    这通常是一大劣势同时也是一大优势,因为没有太多的可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率

    工作稳定

    因为其本身抗负载能力很强,所以稳定性高也是顺理成章的事,另外各种 LVS 都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,LVS 会自动判别,所以系统整体是非常稳定的

    无流量

    LVS 仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的 IO 性能不会受到大流量的影响

    LVS 基本上能支持所有应用,因为 LVS 工作在第 4 层,所以它可以对几乎所有应用做负载均衡,包括 http、数据库、聊天室等。

  • Spring 中经典的 9 种设计模式,打死也要记住啊!

    Spring 中经典的 9 种设计模式,打死也要记住啊!文章来源:http://t.csdn.cn/MxOO5

    目录

    • 1.简单工厂(非23种设计模式中的一种)
    • 2.工厂方法
    • 3.单例模式
    • 4.适配器模式
    • 5.装饰器模式
    • 6.代理模式
    • 7.观察者模式
    • 8.策略模式
    • 9.模版方法模式

    Spring 中经典的 9 种设计模式,打死也要记住啊!

    Spring中涉及的设计模式总结

    Spring 中经典的 9 种设计模式,打死也要记住啊!

     

    1.简单工厂(非23种设计模式中的一种)

    实现方式:

    BeanFactory。Spring中的BeanFactory就是简单工厂模式的体现,根据传入一个唯一的标识来获得Bean对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。

     

    实质:

    由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。

    实现原理:

    bean容器的启动阶段:

    • 读取bean的xml配置文件,将bean元素分别转换成一个BeanDefinition对象。

    • 然后通过BeanDefinitionRegistry将这些bean注册到beanFactory中,保存在它的一个ConcurrentHashMap中。

    • 将BeanDefinition注册到了beanFactory之后,在这里Spring为我们提供了一个扩展的切口,允许我们通过实现接口BeanFactoryPostProcessor 在此处来插入我们定义的代码。

      典型的例子就是:PropertyPlaceholderConfigurer,我们一般在配置数据库的dataSource时使用到的占位符的值,就是它注入进去的。

    容器中bean的实例化阶段:

    实例化阶段主要是通过反射或者CGLIB对bean进行实例化,在这个阶段Spring又给我们暴露了很多的扩展点:

    • 各种的Aware接口 ,比如 BeanFactoryAware,对于实现了这些Aware接口的bean,在实例化bean时Spring会帮我们注入对应的BeanFactory的实例。
    • BeanPostProcessor接口 ,实现了BeanPostProcessor接口的bean,在实例化bean时Spring会帮我们调用接口中的方法。
    • InitializingBean接口 ,实现了InitializingBean接口的bean,在实例化bean时Spring会帮我们调用接口中的方法。
    • DisposableBean接口 ,实现了BeanPostProcessor接口的bean,在该bean死亡时Spring会帮我们调用接口中的方法。

    设计意义:

    松耦合。 可以将原来硬编码的依赖,通过Spring这个beanFactory这个工厂来注入依赖,也就是说原来只有依赖方和被依赖方,现在我们引入了第三方——spring这个beanFactory,由它来解决bean之间的依赖问题,达到了松耦合的效果.

    bean的额外处理。 通过Spring接口的暴露,在实例化bean的阶段我们可以进行一些额外的处理,这些额外的处理只需要让bean实现对应的接口即可,那么spring就会在bean的生命周期调用我们实现的接口来处理该bean。[非常重要]

    2.工厂方法

    实现方式:

    FactoryBean接口。

     

    实现原理:

    实现了FactoryBean接口的bean是一类叫做factory的bean。其特点是,spring会在使用getBean()调用获得该bean时,会自动调用该bean的getObject()方法,所以返回的不是factory这个bean,而是这个bean.getOjbect()方法的返回值。

    例子:

    典型的例子有spring与mybatis的结合。

    代码示例:

    Spring 中经典的 9 种设计模式,打死也要记住啊!

    说明:

    我们看上面该bean,因为实现了FactoryBean接口,所以返回的不是 SqlSessionFactoryBean 的实例,而是它的 SqlSessionFactoryBean.getObject() 的返回值。

    3.单例模式

    • Spring依赖注入Bean实例默认是单例的。
    • Spring的依赖注入(包括lazy-init方式)都是发生在AbstractBeanFactory的getBean里。getBean的doGetBean方法调用getSingleton进行bean的创建。

    • 分析getSingleton()方法

    public Object getSingleton(String beanName){
        //参数true设置标识允许早期依赖
        return getSingleton(beanName,true);
    }
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        //检查缓存中是否存在实例
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            //如果为空,则锁定全局变量并进行处理。
            synchronized (this.singletonObjects) {
                //如果此bean正在加载,则不处理
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    //当某些方法需要提前初始化的时候则会调用addSingleFactory 方法将对应的ObjectFactory初始化策略存储在singletonFactories
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        //调用预先设定的getObject方法
                        singletonObject = singletonFactory.getObject();
                        //记录在缓存中,earlysingletonObjects和singletonFactories互斥
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }
    
    • getSingleton()过程图

    ps:spring依赖注入时,使用了 双重判断加锁 的单例模式

    Spring 中经典的 9 种设计模式,打死也要记住啊!

     

    总结

    单例模式定义: 保证一个类仅有一个实例,并提供一个访问它的全局访问点。

    spring对单例的实现: spring中的单例模式完成了后半句话,即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例,这是因为spring管理的是任意的java对象。

    4.适配器模式

    实现方式:

    SpringMVC中的适配器HandlerAdatper。

     

    实现原理:

    HandlerAdatper根据Handler规则执行不同的Handler。

     

    实现过程:

    DispatcherServlet根据HandlerMapping返回的handler,向HandlerAdatper发起请求,处理Handler。

    HandlerAdapter根据规则找到对应的Handler并让其执行,执行完毕后Handler会向HandlerAdapter返回一个ModelAndView,最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。

    实现意义:

    HandlerAdatper使得Handler的扩展变得容易,只需要增加一个新的Handler和一个对应的HandlerAdapter即可。

    因此Spring定义了一个适配接口,使得每一种Controller有一种对应的适配器实现类,让适配器代替controller执行相应的方法。这样在扩展Controller时,只需要增加一个适配器类就完成了SpringMVC的扩展了。

    5.装饰器模式

    实现方式:

    Spring中用到的包装器模式在类名上有两种表现:一种是类名中含有Wrapper,另一种是类名中含有Decorator。

     

    实质:

    动态地给一个对象添加一些额外的职责。

    就增加功能来说,Decorator模式相比生成子类更为灵活。

    6.代理模式

    实现方式:AOP底层,就是动态代理模式的实现。

    • 动态代在内存中构,不需要手动编写代理类

    • 态代理:需要手工编写代理类,代理类引用被代理对象。

    实现原理:

    切面在应用运行的时刻被织入。一般情况下,在织入切面时,AOP容器会为目标对象创建动态的创建一个代理对象。SpringAOP就是以这种方式织入切面的。

    织入:把切面应用到目标对象并创建新的代理对象的过程。

    7.观察者模式

    实现方式:

    spring的事件驱动模型使用的是 观察者模式 ,Spring中Observer模式常用的地方是listener的实现。

     

    具体实现:事件机制的实现需要三个部分,事件源,事件,事件监听器

    (1)ApplicationEvent抽象类[事件]

    • 继承自jdk的EventObject,所有的事件都需要继承ApplicationEvent,并且通过构造器参数source得到事件源.

    • 该类的实现类ApplicationContextEvent表示ApplicaitonContext的容器事件.

    • 代码:

    public abstract class ApplicationEvent extends EventObject {
        private static final long serialVersionUID = 7099057708183571937L;
        private final long timestamp;
        public ApplicationEvent(Object source) {
        super(source);
        this.timestamp = System.currentTimeMillis();
        }
        public final long getTimestamp() {
            return this.timestamp;
        }
    }
    

    (2)ApplicationListener接口[事件监听器]

    • 继承自jdk的EventListener,所有的监听器都要实现这个接口。

    • 这个接口只有一个onApplicationEvent()方法,该方法接受一个ApplicationEvent或其子类对象作为参数,在方法体中,可以通过不同对Event类的判断来进行相应的处理。

    • 当事件触发时所有的监听器都会收到消息。

    • 代码:

    public interface ApplicationListener<E extends ApplicationEventextends EventListener {
         void onApplicationEvent(E event);
    }
    

    (3)ApplicationContext接口[事件源]

    • ApplicationContext是spring中的全局容器,翻译过来是”应用上下文”。

    • 实现了ApplicationEventPublisher接口。

    • 责:负责读取bean的配置文档,管理bean的加载,维护bean之间的依赖关系,可以说是负责bean的整个生命周期,再通俗一点就是我们平时所说的IOC容器。

    • 代码:

    public interface ApplicationEventPublisher {
            void publishEvent(ApplicationEvent event);
    }
    
    public void publishEvent(ApplicationEvent event) {
        Assert.notNull(event, "Event must not be null");
        if (logger.isTraceEnabled()) {
             logger.trace("Publishing event in " + getDisplayName() + ": " + event);
        }
        getApplicationEventMulticaster().multicastEvent(event);
        if (this.parent != null) {
        this.parent.publishEvent(event);
        }
    }
    

    (4)ApplicationEventMulticaster抽象类[事件源中publishEvent方法需要调用其方法getApplicationEventMulticaster]

    • 属于事件广播器,它的作用是把Applicationcontext发布的Event广播给所有的监听器.

    • 代码:

    public abstract class AbstractApplicationContext extends DefaultResourceLoader
        implements ConfigurableApplicationContextDisposableBean {
        private ApplicationEventMulticaster applicationEventMulticaster;
        protected void registerListeners() {
        // Register statically specified listeners first.
        for (ApplicationListener<?> listener : getApplicationListeners()) {
        getApplicationEventMulticaster().addApplicationListener(listener);
        }
        // Do not initialize FactoryBeans here: We need to leave all regular beans
        // uninitialized to let post-processors apply to them!
        String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.classtruefalse);
        for (String lisName : listenerBeanNames) {
        getApplicationEventMulticaster().addApplicationListenerBean(lisName);
        }
      }
    }
    8.策略模式

    实现方式:

    Spring框架的资源访问Resource接口。该接口提供了更强的资源访问能力,Spring 框架本身大量使用了 Resource 接口来访问底层资源。

     

    Resource 接口介绍

    source 接口是具体资源访问策略的抽象,也是所有资源访问类所实现的接口。

    Resource 接口主要提供了如下几个方法:

    • getInputStream(): 定位并打开资源,返回资源对应的输入流。每次调用都返回新的输入流。调用者必须负责关闭输入流。
    • exists(): 返回 Resource 所指向的资源是否存在。
    • isOpen(): 返回资源文件是否打开,如果资源文件不能多次读取,每次读取结束应该显式关闭,以防止资源泄漏。
    • getDescription(): 返回资源的描述信息,通常用于资源处理出错时输出该信息,通常是全限定文件名或实际 URL。
    • getFile: 返回资源对应的 File 对象。
    • getURL: 返回资源对应的 URL 对象。

    最后两个方法通常无须使用,仅在通过简单方式访问无法实现时,Resource 提供传统的资源访问的功能。

    Resource 接口本身没有提供访问任何底层资源的实现逻辑,针对不同的底层资源,Spring 将会提供不同的 Resource 实现类,不同的实现类负责不同的资源访问逻辑。

    Spring 为 Resource 接口提供了如下实现类:

    • UrlResource: 访问网络资源的实现类。
    • ClassPathResource: 访问类加载路径里资源的实现类。
    • FileSystemResource: 访问文件系统里资源的实现类。
    • ServletContextResource: 访问相对于 ServletContext 路径里的资源的实现类.
    • InputStreamResource: 访问输入流资源的实现类。
    • ByteArrayResource: 访问字节数组资源的实现类。

    这些 Resource 实现类,针对不同的的底层资源,提供了相应的资源访问逻辑,并提供便捷的包装,以利于客户端程序的资源访问。

    9.模版方法模式

    经典模板方法定义:

    父类定义了骨架(调用哪些方法及顺序),某些特定方法由子类实现。

    最大的好处:代码复用,减少重复代码。除了子类要实现的特定方法,其他方法及方法调用顺序都在父类中预先写好了。

    所以父类模板方法中有两类方法:

    共同的方法: 所有子类都会用到的代码

    不同的方法: 子类要覆盖的方法,分为两种:

    • 抽象方法:父类中的是抽象方法,子类必须覆盖
    • 钩子方法:父类中是一个空方法,子类继承了默认也是空的

    注:为什么叫钩子,子类可以通过这个钩子(方法),控制父类,因为这个钩子实际是父类的方法(空方法)!

    Spring模板方法模式实质:

    是模板方法模式和回调模式的结合,是Template Method不需要继承的另一种实现方式。Spring几乎所有的外接扩展都采用这种模式。

     

    具体实现:

    JDBC的抽象和对Hibernate的集成,都采用了一种理念或者处理方式,那就是模板方法模式与相应的Callback接口相结合。

    采用模板方法模式是为了以一种统一而集中的方式来处理资源的获取和释放,以JdbcTempalte为例:

    public abstract class JdbcTemplate {
         public final Object execute(String sql){
            Connection con=null;
            Statement stmt=null;
            try{
                con=getConnection();
                stmt=con.createStatement();
                Object retValue=executeWithStatement(stmt,sql);
                return retValue;
            }catch(SQLException e){
                 ...
            }finally{
                closeStatement(stmt);
                releaseConnection(con);
            }
        }
        protected abstract Object executeWithStatement(Statement   stmt, String sql);
    }

    引入回调原因:

    JdbcTemplate是抽象类,不能够独立使用,我们每次进行数据访问的时候都要给出一个相应的子类实现,这样肯定不方便,所以就引入了回调。

    回调代码

    public interface StatementCallback{
        Object doWithStatement(Statement stmt);
    }
    

    利用回调方法重写JdbcTemplate方法

    public class JdbcTemplate {
        public final Object execute(StatementCallback callback){
            Connection con=null;
            Statement stmt=null;
            try{
                con=getConnection();
                stmt=con.createStatement();
                Object retValue=callback.doWithStatement(stmt);
                return retValue;
            }catch(SQLException e){
                ...
            }finally{
                closeStatement(stmt);
                releaseConnection(con);
            }
        }
    
        ...//其它方法定义
    }
    

    Jdbc使用方法如下:

    JdbcTemplate jdbcTemplate=...;
        final String sql=...;
        StatementCallback callback=new StatementCallback(){
        public Object=doWithStatement(Statement stmt){
            return ...;
        }
    }
    jdbcTemplate.execute(callback);

    为什么JdbcTemplate没有使用继承?

    因为这个类的方法太多,但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接,那么我们怎么办呢?

    我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码,而且这段代码会用到JdbcTemplate中的变量。怎么办?

    那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法,我们去实现这个方法,就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate,从而完成了调用。