分布式系统架构.docx

分布式系统架构关于分布式系统架构对于软件架构，更多的是一种思想，即内功修为。在道与术层面，则更偏重道的修炼，道的深度决定架构的境界。相对而言，术是手段，随不同的环境应运而生，就像太极剑法和独孤九剑，能做到随境而变。架构是一种权衡没有一种架构可以应用到所有环境，也没有一个技术或框架可以解决所有问题，即使是针对同一种场景也往往存在多种解决方案。在架构的时候，更多的是方案和手段的权衡，例如高可用性、高并发性、一致性本身就存在一定的矛盾;而异步还是同步、是否需要事务、如何应用事务、缓存、拆分、容灾、发布等等，每一项都需要从各种技术实现中进行权衡。细化到框架，ActiveMQ、RocketMQ、Kafka、Redis、ZooKeeper等等都可以实现消息队列模型，具体使用哪个就需要结合场景进行权衡了。分与合天下大事，合久必分、分久必合，在解决高并发分布式的问题时绝大部分都在使用分与合的思想。当数据量很大、并发量很多的时候就需要考虑拆分(分而治之)，例如分层设计、横向拆分、纵向拆分、分IDC、分库分表...等等。并且这些拆分本身就是分层的，例如在DNS层可以将流量按照地域或运营商分配到不同的IDC、业务层可以将业务处理逻辑分配到多个子系统、系统层可以根据用户进行横向拆分、而存储层可以根据规则将数据分配到不同的库不同的表;另外读写分离、热点分离、独立出缓存层也体现了分布式系统架构中分的思想。为什么要做这么多的拆分，拆分就是为了化多为少，在单节点处理能力有限的情况下，通过横向拆分提供无线的扩展能力，当巨大的流量通过拆分后，每个节点要处理的QPS就会下降;拆分是为了化繁为简，简化单节点的复杂度，现在的微服务(当然微服务引发的服务治理需要另说)、二阶段事务提交，就是将复杂的业务通过多维度的拆分降解单节点复杂度的手段。拆多了就要合，hadoop将复杂的任务分解到一个个的mapreducejob处理和聚合后，处理效率得到了极大的提升，而这种分解必然伴随着聚合。而在有些业务场景，两类节点相互调用非常频繁，通过合并将原本的RPC调用转换为本地JVM调用，则可以很大的提升系统性能。隔离隔离也是一种思想，其中也包含了分的意思，例如灰度、压测隔离、动静隔离、多版本发布等。转换路由与转换，可以看做是分思想的衍生物。分的太多，就需要能将请求转发到正确的位置，此外也需要将各种通信格式与协议进行转换。重复与唯一(幂等)幂等伴随着请求的靠套投递而产生，在发送请求时可能会存在如下几个场景：接收端不一定要接收、接收端只能接收一次、接收端可重复接收。对于配置推送平台，大多场景要求接收端可重复接收配置信息，但只保存最后一次消息即可;而对于一笔付款请求，如果重复发送，接收端要控制只能处理一次(即要进行幂等控制)。最终一致在分布式系统架构中，面对事务性业务有两种选择，一种是分布式事务、一种是最终一致性处理。分布式事务控制比较复杂，一般采用二阶段提交的方式，其思想是要么成功要么失败，注意要么失败是指其中有一步出错就全部回滚，看似是保证了数据一致性但实际业务却失败了。而最终一致性相对于分布式事务的核心思想是让业务尽可能成功，即当业务处理过程中可能会存在中间步骤失败的情况，但通过补偿逻辑可以保障失败的步骤后续继续执行，此时就应该尽可能的标记业务成功。并行与串行将大量的计算分散到多个节点、多个进程、多个线程进行并行处理，是应对大数据计算的常用技巧。而伴随并行的就是串行(或者说是并发锁)的处理，在分布式环境，并发锁的可以通过数据库、zookeeper等进行实现。主动与被动主动与被动主要是针对客户端如何获取服务端内容的场景，典型的就是消息队列中的推模式(push)和拉模式(pull)。具体底层实现上，无外乎轮询、长链接等等，其中使用轮询不一定就是拉模型，很多推模型其底层也是通过轮询实现的。同步与异步同步与异步也是经常要面临抉择的事情，异步可以减少系统的阻塞，例如Ajax、消息队列(还可以达到消峰填谷的作用)等等。此外流式计算与离线计算，也可以看做是同步与异步的衍生技术。再深一层次，会衍生批量计算、全量、增量等思想。点到为止限流：当巨大的流量打过来时，通过牺牲部分请求处理可保证整个系统可用;降级：当面对流量高峰时(例如大促)往往将次要的服务停掉，以便节省资源给主要服务;另外当某个服务不可用时，直接返回默认结果也是降级的一种表现;熔断：对于金融系统，当出现bug时可能会造成资损，此时需要旁路系统进行不断的核对，当发现异常时能够及时终止处理。对于以上几个方面，系统要能做到自动限流、自动降级和自动熔断。以上一切问题都是由于量(数据量、请求量等等)产生的，当量很小时不需要架构，通过增加内存、CPU、机器等都能解决;当量增加到一定的程度时，才需要考虑架构，而架构的道与术却又是“道可道，非常道，名可名，非常