分布式架构的套路No.74

标签: | 发表时间:2018-01-01 18:24 | 作者:
出处:http://mp.weixin.qq.com

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


大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么?因为在访问量或者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、分布式的核心就是业务拆分以及流量分发。






相关 [分布 架构 套路] 推荐:

分布式架构的套路No.74

- -
今天小蕉跟大伙一起聊聊分布式系统的架构的套路. 在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构. 大多数的开发者大多数的系统可能从来没接触过分布式系统,也根本没必要进行分布式系统架构,为什么. 因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候,根本没必要进行分布式架构. 那如果业务量上来了,一般会怎么解决呢.

网站的分布式架构

- - 互联网的那点事
互联网的网站和大部分企业管理软件一样都是使用B/S架构模型,但是大型的公共网站B/S架构会更加复杂,对架构人员的要求更高,今天我想在自己博客里聊聊我设计的网站的B/S技术架构. 不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图:. 在传统B/S架构的企业管理系统里,技术架构往往就是一个工程项目,各个逻辑分层都是该工程的业务逻辑模块.

FastDFS分布式文件系统架构

- - 企业架构 - ITeye博客
FastDFS分布式文件系统架构.            FastDFS是一个开源的分布式文件系统,她对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题. 特别适合以文件为载体的在线服务,如相册网站、视频网站等等. 二、 FastDFS系统架构.

案例分析:基于消息的分布式架构

- - 简单文本
美国计算机科学家,LaTex的作者Leslie Lamport说:“分布式系统就是这样一个系统,系统中一个你甚至都不知道的计算机出了故障,却可能导致你自己的计算机不可用. ”一语道破了开发分布式系统的玄机,那就是它的复杂与不可控. 所以Martin Fowler强调:分布式调用的第一原则就是不要分布式.

基于Dubbo框架构建分布式服务

- - 简单之美
有关Dubbo服务框架的简单使用,可以参考我的其他两篇文章(《基于Dubbo的Hessian协议实现远程调用》,《基于Dubbo的Hessian协议实现远程调用》,后面参考链接中已给出链接),这里主要围绕Dubbo分布式服务相关配置的使用来说明与实践. 首先,根据Dubbo文档,我们引用文档提供的一个架构图以及各组件关系说明,如下所示:.

分布式会话跟踪系统架构设计与实践

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

分布式领域架构师要掌握的技术

- - hellojavacases微信公众号网站
分布式系统无疑是持久的热门话题,但其实如果不是一定有必要,强烈建议不要进入分布式领域,在集中式的情况下很多问题都会简单不少,技术人员千万不要因为外界火热的例如微服务,就把自己的产品的也去做改造,一定要仔细判断是否有必要,不要为了技术而技术,那么在必须分布式的情况下(访问量、存储量或开发人数),一个分布式领域的合格的架构师要掌握哪些技术呢,这篇文章就聊聊这个话题.

分布式MySQL数据库TDSQL架构分析(转)

- - 数据库 - ITeye博客
腾讯计费平台部为了解决基于内存的NoSQL解决方案HOLD平台在应对多种业务接入时的不足,结合团队在MySQL领域多年应用和优化经验,最终在MySQL存储引擎基础上,打造一套分布式SQL系统TDSQL. 腾讯计费平台部托管着公司90%以上的虚拟账户,如QB、Q点、包月服务、游戏的二级账户等,为了保证能顺畅支撑公司各大业务的实时在线交易,并且在各种灾难场景下数据是一致并且可用的,对系统的可用性、一致性切换要求非常高,因此计费团队历来都非常重视高一致性存储系统的建设.

缓存的进化之路—Couchbase的分布式架构

- - 午夜咖啡
本文从缓存的演进,分析了Couchbase分布式缓存的架构. 单机时代一切都是美好的,缓存只是为了解决磁盘访问速度问题,大多数本地缓存基本上都是个HashMap.存储型应用内部都会内置一个缓存,复杂度一般不在缓存本身,而在于存储型应用提供的访问方式.(比如mysql缓存的复杂在于sql查询转换成缓存的key-value查询).

微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.