LINUX安全加固

 PIM系统架构浅析
 

    我们真的需要分布式吗？
    在回答这个问题之前我简单解释下，集群和分布式的区别，现下很多人都觉得集群和分布式没有任何区别，并且他们完全等同，另一帮人是搞不清楚这俩者的区别与关系。
    我认为集群和分布式应用还是有区别的。分布式应用一般来说可由多个节点共同构成，并且每个节点完成各自独立的事情，这里的事情是不同的，并且是不固定的，这个任务的分配以及结果的综合统计有Master来完成。



    而集群是指由多个节点共同构成，并且每个节点完成一个的业务逻辑，无需Master来分配任务，或是综合统计各个节点的作业结果。



 
    在提出这个问题之前我解释下分布式是什么概念。分布式是众多计算界名词中的一个比较流行的名词。其利用多个Martin Fowler 在《企业应用架构模式》一书中，曾经说过：“能不用分布式的情况下就不要用分布式”，可见当应用变为分布式Java 应用后，会很大程度的增加应用实现的技术复杂度。我个人也是反对分布式应用的，毕竟我们架构的目的是在于解决更常见的问题，提供更简单有效的方法，而不是为罕见的问题寻求解决方案，或是将简单的问题搞的很复杂。
    在当今大多数的Java应用中都或多或少的存在着被过度工程的现象，我自己是很反对过度工程的，过度工程知会让项目增加复杂度，本来一个人可以搞定的事情，现在俩个人都搞不定了，增加后期的维护人员的学习成本。容易给项目组带来风险，由于复杂的技术引入必然会引入很多未知的错误，不管是来自自身的还是来自外部的。
    首先看下传统集群的实现方法，传统集群的实现方法往往是在众多节点的前端加入负载均衡来达到分发、故障检测，但是传统的负载均衡有一个弊端，无法实现根据内容交换，也就是第四层交互。但是在现实的应用中往往需要有会话的支持，也就是一个业务请求由多次交互完成，这就造成了传统的集群架构影响到应用的开发，需要开发人员能够在编写代码之前做到对架构的了解，并且采用一个解决方案来迎合这种架构。比如说MemoryCache、或是Apache自身提供的Session复制。但是这种解决方案增加开发成本和维护成本，并且对硬件的要求也上了一个层次。
    故障检测：一般集群的实现的一个基本要点就是实现故障检测，没有故障检测就不能很好的保证整个集群的正常工作。当然，现有的集群方案中一般都有故障检测而且实现也较为简单，一般都是采用发送心跳消息来探测节点的可用性，该方法，既简单又实用。



    扩展性支持：当业务量随着时间的推移，业务量大幅度的增长，使用简单的性能调优已经不能满足整个系统的正常运行，这个时间可以通过动态的添加节点来完成系统扩容。但是需要做到对其他节点来说该过程完全是透明的，对整个业务的运行也没有任何干扰。该功能也是集群方案中一个比较重要的功能点，而该功能的实现可说也是比较容易的。往往是架构的透明性越高，可扩展性也是越好。



    负载均衡：通常负载均衡的一个很重要的前提就是实现负载的分发，并且能够进行故障检测，系统告警。其中负载的分发的实现非常重要，可以说对整个集群架构的好坏取决于该功能点的实现已经完成程度。负载的分发最好能够根据实际环境来动态调整。常见的分发策略包括：轮询分发、随即分发、根据各个节点的负载分发。还有一些重要的工作负载均衡要参与进来，例如使用“会话粘滞”技术以确保来至同一个用户的请求会被转发到同一个节点上。使用健康检查或者是心跳监测技术来防止将请求发送到一个故障的节点上。有时负载均衡还参数“失败转移”的工作。



    容错：高可用的数据不必是严格正确的数据。当其中一个节点出现故障，在集群中冗余的其他节点可以处理新到的请求。这样就保证了服务器依然可用。但是在节点出现故障的那一刻，正在被处理的请求就可能无法得到正确的处理。那么带有容错功能的集群就可以确保请求能够被正确处理以及响应，哪怕是服务器出现了错误。



 
    下面来看下DSS的集群架构。





    可扩展性：可以动态添加节点，节点之间相互透明，没有任何联系。也可以动态删除节点。
    故障检测：由负载均衡来完成，主要使用端口探测来完成。负载均衡会定时的探测节点的监听端口是否在正常状态，并且可以有数据交互。
    负载均衡：DSS集群架构采用轮询分发机制，但是具有第四层交换功能，可以将带有会话信息的请求发送到同一节点上。当然这是由硬件来实现，性能也比较高，也正是因为该功能使得DSS各个节点之间可以完全隔绝。DSS集群在新到请求的分发策略是轮询。当产生会话以后DSS发返回给客户端一个下次请求的URL，此URL为http://IP:port/syncer?sid=1400xxxxxx，轻重sid后面的部分为URL重写后的会话id，DSS通过此URL来实现会话，并且负载均衡根据sid后面的4位数字完成分发，实现了会话粘滞功能。而新产生的请求都是http://IP:port/syncer，所以这种新的请求都会被分发到新一台节点上。
    DSS集群在压力的分担上基本可以完成均衡分发，但这种情况也不是绝对的，因为每个节点上的压力和诸多因素构成，比如该节点正在受理的会话数，每个会话的最大存活时间，节点的能力等等因素。DSS集群只能保证分发到每个DSS节点的会话数量基本相等，但是对每个会话的处理时间每个节点上正在受理的会话数量以及每个节点的能力差异，都是毫无感知的。
    我们真的需要完全负载均衡吗？
    负载均衡只是一个相对的概念，越是想实现的完美，相应的成本也会高，包括实现成本，后后续的维护成本，我觉得一个复杂集群会给后续的维护成本大幅提高。
    事实证明，DSS集群能够在大多数情况，实现良好的压力分担。



节点之间相互独立，没有任何干扰，无需使用共享内存来交互sessesion或是session复制，session复制不稳定，而且需要消耗一定的内存来存储session信息，并且为了达到安全的目的，往往需要的集群中至少可以找个俩分session的拷贝，防止单台节点故障后，该节点上缓存的session信息丢失，所以session缓存往往需要更多内存来支持。
    缓存复制需要消耗带宽，在带宽有限的情况下，极有可能造成网络拥塞。
    在PIM系统中，非常巧妙的利用URL重写避免了分布式应用，达到了大大简化编程，提高开发效率，降低维护难度的要求。以DSS为例，现网中DSS架构使用单机集群方式部署。在此文中将会列举3个DSS节点作为讲解使用，实际运营环境是有30台DSS节点。
每个节点相互独立，其他节点对于它本身是透明的，有效的消除了单个节点故障不会影响整个业务的运行。这里的故障检测由负载均衡来完成。如果其中DSS2发生故障，负载均衡会将新的请求发送到DSS1和DSS3。从而达到故障检测、一个节点出现故障不会影响整个业务。
PIM系统在该点的实现上还不是很成熟。PIM的负载分发策略是轮询分发。轮询分发实现青睐也比较简单，而且在大多数情况下能够使压力分担均匀。DSS集群前端采用RedWare硬件来实现负载均衡，有较高的性能，并且有一定的灵活性，可以根据TCP体中固定的标示来进行分发，也就是实现会话粘滞。也是这种特性使得DSS集群架构使得DSS各个节点之间完全透明，使得应用开发简化。
    容错：DSS集群在容错性上面也有极好的表现。当其中某个节点宕机，负载均衡会进行故障探测，并将该节点上的请求转发到其他节点。这里要说明的是，如果是带有会话信息的请求，该请求不会被转发到其他节点。这里只限于新产生的会话。
    让我们来看看DSS集群这种简单的方式有没有意义？
    先让我们看一个”完美”的容错集群解决方案。如下图所示，当任何一个节点上产生新的会话时，该会话信息会被复制到第三方容器中，进行保存。当节点1出现故障，该会话的后续请求会被分发其他节点，其他节点会首先判断是否存在该用户的会话信息，如果不存在就到第三方容器中获取该会话的拷贝，这样就实现了完美的容错集群。



 



    实现会话转移有几种主流的方案：
1 数据库持久化方案



       这种方案无疑会对性能产生问题。数据库的事务成本是很高的，特别是在会话数量激增或是数量巨大的时候，对数据库的压力也是不小的。大部分的应用都提倡减少会话中对象的数量，这样就使应用的设计和框架受到了限制，尤其是当需要在会话中缓存用户数据的情况下。
       特点：
       易于实现。将请求处理和会话备份分离，使得集群更健壮、更易于管理。
       失败可以转移到其他的主机，因为数据库是可以共享使用的。
       即使整个集群都发生故障，会话数据都可以保留下来。
       对于DSS这种解决方案并不可行，DSS的业务需求要求其在会话中缓存大量大对象，这使用和数据库交互的成本大增。
2 内存复制方案
       由于在数据库持久化有性能方面的限制，所以许多应用服务器厂商提供了，内存复制解决方案。



【问题总结】
    应该在项目的初期或是一开始就做好集群的准备，以建立大规模的应用。选择能够满足需求的合适的服务器，同时也要选择适用于集群环境的第三方软件或者是架构。然后设计一个适当的框架，让你真正从集群中受益，而不是折磨。