分布式架构—基本思想汇总.docxVIP

分布式架构—基本思想汇总 2021-02-05 在互联网大行其道的今日，各种分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。。凡是涉及到大规模用户、高并发访问的，无一不是分布式。 关于分布式系统，并没有一个标准答案，说某某架构肯定是最好的。不同的业务外形所面对的挑战不一样，使用的架构设计也不一样，通常都需要具体业务具体分析。 但不管那种业务，不管何种分布式系统，有一些基本的思想还是相通的。本文将对这些基本思想进行一个梳理汇总。 分拆 系统分拆 微信的架构师说过一句话：“大系统小做“。对于一个大的简单系统，首先想到的就是对其分拆，拆成多个子系统。每个子系统本人的存储/Service/接口层，各个子系统独立开发、测试、部署、运维。 从团队管理角度讲，也可以不同团队用本人生疏的言语体系，团队之间基于接口进行协作，职责清楚，各司其职。 子系统分拆 拆成子系统之后，子系统内部又可以分层，分模块。当然，这里“系统“，“子系统“，“层“，“模块“ 都只是一个相对概念。在一个系统里面，某个模块简单到肯定程度，会把它抽出来，单独做成一个系统；而在初期，很大简约模块，可能不回拆分，集中在一个系统里面。 这就像一个生物组织，本身是在不断成长、演化、有分有合，不断变化进展的。 存储分拆 Nosql：对于Nosql数据库，比如MongoDB，其天生就是分布式的，很简约实现数据的分片。 Mysql: 对于Mysql，或者其它关系型数据库，就会设计到分库分表。而分库分表，就会涉及到几个关键性的问题：切分维度，join的处理，分布式事务 计算分拆 计算的分拆有2种思路： 数据分拆：一个大的数据集，拆分成多个小的数据集，并行计算。 比如大规模数据归并排序 任务分拆：把一个长的任务，拆分成几个环节，各个环节并行计算。 Java中多线程的Fork/Join框架，Hadoop中的Map/Reduce，都是计算分拆的典型框架。其思路都是相像的，先分拆计算，再合并结果。 再比如分布式的搜索引擎中，数据分拆，分别建索引，查询结果再合并。 并发 最常见的就是多线程，尽可能提高程序的并发度。 比如多次rpc挨次调用，通过异步rpc转化为并发调用； 比如数据分片，你的一个Job要扫描全表，跑几个小时，数据分片，用多线程，功能会加快好几倍。 缓存 缓存大家都不生疏，遇到功能问题，大家首先想到的就是缓存。关于缓存，一个关键点就是：缓存的粒度问题。 比如Tweet的架构，缓存的粒度从小到大，有Row Cache, Vector Cache, Fragment Cache, Page Cache。 粒度越小，重用性越好，但查询需要多次，需要数据拼装； 粒度越大，越简约会失效，任何一个小的地方改动，都可能形成缓存的失效。 在线计算 vs. 离线计算 / 同步 vs. 异步 在实际的业务需求中，并不是全部需要都需要完全实时的： 比如内部针对产品、运营开发的各种报表查询、分析系统； 比如微博的传播，我发了一个微博，我的粉丝延迟几秒才看到，这是可以接受的，由于他并不会留意到晚了几秒； 比如搜索引擎的索引，我发了一篇博客，可能几分钟之后，才会被搜索引擎索引到； 比如领取宝转帐、提现，也并非这边转出之后，对方马上收到； 。。。 这类例子很多。这种“非实时也可以接受“的场景，就为架构的设计赢得了充分的回旋余地。 由于非实时，我们就可以做异步，比如使用消息队列，比如使用后台的Job，周期性处理某类任务； 也由于非实时，我们可以做读写分别，读和写不是完全同步，比如Mysql的Master-Slave。 全量 ＋ 增量 全量/增量其实也是在线/离线的思路： 比如搜索引擎的全量索引 ＋ 增量索引，前者是为了吞吐，后者为了实时； 比如OceanBase数据库，每次更新存在一个小表里面，定期merge； Push vs. Pull 在全部分布式系统中，都涉及到一个基本问题：节点之间（或者2个子系统之间）的形态通知。比如一个节点形态变更了，要通知另外一个节点，都有2种策略： Push: 节点A形态变了， push给节点B Pull: 也就是轮询。节点B周期性的去询问节点A的形态。 这个问题不光消灭在分布式系统中，可以说是编写代码的一个基本问题。对应到面对对象的编程中，也就是常说的“双向关联”这种耦合问题。 A调用B，B再回调A，这种情形，在系统开发中经常消灭。再简单一点，多个模块之间，彼此调用，调用关系跟蜘蛛网一样。 这个问题的消灭，就和Push/Pull的策略亲密相关： A调用B，那规律就会写在B这边；B调用A，规律就会写在A这边。所以是接受自动调用的pull方式，还是回调的push方式，会严峻影响职责在各个模块或者子系统里面的安排。 批量 批量其实也是在线/离线的一种思想，把