漫谈分布式架构的几种套路

原文作者/原文公众号：一名叫大蕉的程序员

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前，大家先思考一个问题，为什么要进行分布式架构？

大多数的开发者大多数的系统可能从来没接触过分布式系统，也根本没必要进行分布式系统架构，为什么？因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候，根本没必要进行分布式架构。那如果业务量上来了，一般会怎么解决呢？

首先考虑的就是机器升级。机器配置的垂直扩展，首先要找到当前性能的瓶颈点，是CPU，是内存，是硬盘，还是带宽。砸钱加CPU，砸钱换SSD硬盘，砸钱换1T内存，这通常是解决问题最直接也最高效的方法。带宽不够？加带宽，1G不够用100G。CPU 8核不够？搞32核96核。这是绝大多数公司能思考到的第一个方案，也是最高效最快最安全的方法，立竿见影。

其次就是系统拆分，将所提供服务的主流程以及支线流程梳理出来，按照流程进行系统拆分。如同一棵树，核心业务作为主干流程，其他系统按照需要进行拆分，如同树的开枝散叶。所采取的方式有这么一些，按前后端进行拆分，按照领域拆分，按团队拆分，当然通常来说这些拆分基本都要跟着组织架构走。

再不行就进行技术升级，更换更加高效或者场景适合的技术。比如从 Oracle 更换到HBase。从A数据库连接池更换到B数据库连接池。技术的变革对于业务量的支持也是非常巨大的，同一台机器不同的技术，效能发挥的程度可以说有天壤之别。

最后的最后手段才会考虑分布式架构，实在是砸不出这么多钱了，实在是没办法了。因为分布式架构肯定会带来非常多非常多的一致性问题，原本只需要访问一台机器，现在需要访问N台，那么这N台机器的一致性怎么保证，以前撑死搞个主从备份就算完了，定时同步一下数据就好，现在N台设备的数据怎么管理，甚至这个集群本身怎么管理，都会成为一个致命的问题。

所以只有等业务量到达一定程度了，单台机器扛不住了，才会开始堆钱升级机器，系统拆分，换技术，继续堆钱升级机器，系统拆分...周而复始，发现成本太高或者技术已经到达上线了。最后没办法，就选择分布式架构了。

但是分布式架构的优势也是明显的，用一群低廉的设备，来提供一个高性能高吞吐量的稳定的系统，下面开始说说常见的分布式集群的架构。

1、纯负载均衡形式

在集群前面，前置一个流量分发的组件进行流量分发，整个集群的机器提供无差别的服务，这在常见的 web 服务器中是最最常见的。目前比较主流的方式就是整个集群机器上云，根据实时的调用量进行云服务器弹性伸缩。常见的负载均衡有硬件层面的 F5、软件层面的 nginx 等。

2、领导选举型

整个集群的消息都会转发到集群的领导这里，是一种 master-slavers，区别只是这个 master 是被临时选举出来的，一旦 master 宕机，集群会立刻选举出一个新的领导，继续对外提供服务。使用领导选举型架构的典型的应用有 ElasticSearch，zookeeper。

3、区块链型

整个集群的每一个节点都可以进行记录，但是记录的内容要得到整个集群 N 个机器的认可才是合法的。典型的应用有 Bit Coin，以及 Hyperledger。

4、master-slaver型

整个集群以某台 master 为中枢，进行集群的调度。交互是这样，一般会把所有的管理类型的数据放到 master 上，而把具体的数据放到 slaver 上，实际进行调用的时候，client 先调用 master 获取数据所存放的 server 的 信息，再自行跟 slave 进行交互。典型的系统有 Hadoop。集群，HBase 集群，Redis 集群等。

5、规则型一致性Hash

这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表，在查询之前使用规则引擎进行库和表的确认，再对具体的应用进行访问。为什么要用一致性 Hash ？其实用什么都可以，只是对于这类应用来说一致性 Hash 比较常见而已。

好了，至此，已经把我所知道的大部分分布式集群的套路说完了，总结一下。

1、升级机器配置是最直接的升级方式。不到万不得已不会使用分布式

2、分布式的核心就是业务拆分以及流量分发。

开年福利

小编推荐：

分布式架构与微服务平台是当今IT界的关键技术，也是资深软件工程师和系统架构师必须掌握的核心技术。《架构解密：从分布式到微服务》以从传统分布式架构迁移到基于容器技术的微服务架构为主线，全面、透彻地介绍了与分布式架构及微服务相关的知识和技术。

《架构解密：从分布式到微服务》一开始并没有提及分布式的枯燥理论，而是讲述了一段精彩的IT发展史，其中重点讲述了大型机、UNIX小机器的没落与X86平台的崛起，从而巧妙地引出CPU、内存、网络、存储的分布式演进过程，这恰恰是分布式软件系统赖以运行的“物质基础”。

然后简明扼要地介绍了进行系统架构所必需的网络基础，并详细介绍了分布式系统中的经典理论、设计套路及RPC通信，对内存、SOA架构、分布式存储、分布式计算等进行了深度解析，最后详细介绍了全文检索与消息队列中间件，以及微服务架构所涉及的重点内容。 

《架构解密：从分布式到微服务》是Leader-us多年架构经验的倾情分享，主要面向关注分布式架构及微服务，以及有志于成为实力派架构师的IT人士。 

送书规则

1、本次活动还是在评论区随机抽取一名幸运吃瓜群众！

2、截止日期：2018年01月02日23时z0分，幸运的小伙伴名单评论区留言会置顶，获奖的小伙伴请在一个工作日内在公众号界面联系我，发送手机号、姓名、收货地址，逾期则认为放弃处理；

3、注意啦：经常关注Java后端技术公众号留言点赞的小伙伴会自带红蓝buff加成哦！

最近热文阅读：

1、为什么要有Spring？

2、为什么要有Spring AOP？

3、2017年IT人期末考试卷，能考60分就是自己人!

4、Spring历史版本变迁和如今的生态帝国

5、大型网站应用之海量数据和高并发解决方案总结一二

6、Java大型互联网公司经典面试题，论JDK源码的重要性的无限思考

7、使用Jenkins配置SpringBoot的自动化构建

更多精彩，从关注《Java后端技术》公众号开始！