分布式简单理解

基本概念

应⽤(Application)/系统（System）
为了完成⼀整套服务的⼀个程序或者⼀组相互配合的程序群。⽣活例⼦类⽐：为了完成⼀项任
务，⽽搭建的由⼀个⼈或者⼀群相互配的⼈组成的团队。

模块（Module）/组件（Component）
当应⽤较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于
理解。⽣活例⼦类⽐：军队中为了进⾏某据点的攻克，将⼈员分为突击⼩组、爆破⼩组、掩护⼩组、通信⼩组等。

分布式（Distributed）
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如Web服务器与
数据库分别⼯作在不同的服务器上，或者多台Web服务器被分别部署在不同服务器上。⽣活例⼦类
⽐：为了更好的满⾜现实需要，⼀个在同⼀个办公场地的⼯作⼩组被分散到多个城市的不同⼯作场地中进⾏远程配合⼯作完成⽬标。跨主机之间的模块之间的通信基本要借助⽹络⽀撑完成。

集群（Cluster）
被部署于多台服务器上的、为了实现特定⽬标的⼀个/组特定的组件，整个整体被称为集群。⽐如
多个MySQL⼯作在不同服务器上，共同提供数据库服务⽬标，可以被称为⼀组数据库集群。⽣活例⼦类⽐：为了解决军队攻克防守坚固的⼤城市的作战⽬标，指挥部将⼤批炮兵部队集中起来形成⼀个炮兵打击集群。

分布式vs集群
。通常不⽤太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即⼯作在不同服务器上并且通过⽹络通信配合完成任务；⽽集群更在意逻辑形态，即是否为了完成特定服务⽬标。

主（Master）/从（Slave）
集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。⽐如
MySQL集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库。

中间件（Middleware）
⼀类提供不同应⽤程序⽤于相互通信的软件，即处于不同技术、⼯具和数据库之间的桥梁。⽣活
例⼦类⽐：⼀家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变⼤，成⽴⼀个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。

评价指标（Metric）

可⽤性（Availability）
考察单位时间段内，系统可以正常提供服务的概率/期望。例如：年化系统可⽤性=系统正常提供
服务时⻓/⼀年总时⻓。这⾥暗含着⼀个指标，即如何评价系统提供⽆法是否正常，我们就不深⼊了。平时我们常说的4个9即系统可以提供99.99%的可⽤性，5个9是99.999%的可⽤性，以此类推。我们平时只是⽤⾼可⽤（HighAvailabilityHA）这个⾮量化⽬标简要表达我们系统的追求。响应时⻓（ResponseTimeRT）指⽤⼾完成输⼊到系统给出⽤⼾反应的时⻓。例如点外卖业务的响应时⻓=拿到外卖的时刻-完成点单的时刻。通常我们需要衡量的是最⻓响应时⻓、平均响应时⻓和中位数响应时⻓。这个指标原则上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断

吞吐（Throughput）vs并发（Concurrent）
吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同⼀时刻⽀持的请求最⾼
量。例如⼀条辆⻋道⾼速公路，⼀分钟可以通过20辆⻋，则并发是2，⼀分钟的吞吐量是20。实践
中，并发量往往⽆法直接获取，很多时候都是⽤极短的时间段（⽐如1秒）的吞吐量做代替。我们平时⽤⾼并发（HightConcurrnet）这个⾮量化⽬标简要表达系统的追求

架构演变

单机架构

首先如果我们需要尽快上线我们的项目，那单机系统就是最好的选择，单机系统里面不仅有应用服务，还有存储数据的数据库，他们共同在一台机器上合作为客户提供服务

就是这样的单机服务就已经能满足很大的需求了，基本上很多的服务都是采用这种单机服务，因为在如今硬件发展得如此之快的时代，一台机器就已经能支持很大的高并发场景。

集群架构

当并发量变得更大，大到我们能感觉服务器已经有明显的卡顿，再大服务就挂了的时候，这时候就需要对我们的服务进行优化。如何优化呢？

垂直扩展/纵向扩展ScaleUp：通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。这
种⽅案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增⻓
关系是⾮线性的，意味着选择性能2倍的硬件可能需要花费超过4倍的价格，其次硬件性能提升是
有明显上限的。

⽔平扩展/横向扩展ScaleOut：通过调整软件架构，增加应⽤层硬件，将⽤⼾流量分担到不同的
应⽤层服务器上，来提升系统的承载能⼒。这种⽅案的优势在于成本相对较低，并且提升的上限空
间也很⼤。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验。

相较于水平扩展，垂直扩展的方案上限会更高，毕竟只要你有钱，就可以买更多的服务器。将客户分流到各个服务器上每个服务器的压力就变小。
那么将用户分流到各个服务器上的这个服务器我们称之为负载均衡服务器。
那么其实像这样的多个机器协作运行的服务我们就能称之为分布式系统。

读写分离/主从分离架构

当我们用负载均衡分流用户时，只是将降低了服务器的压力，但是数据库呢？数据库的压力并不会减小！那么此时我们就可以搞两个数据库服务器，一个进行读，一个进行读取，试想一下在大部数据我们是修改得比较多呢还是查询得得比较多呢？那肯定是查询比较多！举个简单例子对于像用户信息这些信息，在每次加载的时候其实只是做了查询的工作，而这些数据大部分都是做的查询，频率还比较高，而修改个人信息这种事一般都是因人而异，一些人可能几年都没有过自己的头像。

所以我们让用来做查询服务的服务器性能就搞好点，而用来修改的发数据库服务器就搞一般的！这样就完成了主从分离架构

冷热分离架构

在计算机中有个二八原则，就是20%的热点数据能满足80%用户需求，这些热点数据需要大量去访问。MySQL确实很强，但是还是太吃cpu资源了，有没有更快的数据库呢？有的有的redis就是很好的选择，不仅访问速度快，而且还是开源的。所以我们就能将热点数据存储到redis上。需要热点数据的用户就在redis服务器上访问。

垂直分库

随着业务的数据量增⼤，⼤量的数据存储在同⼀个库中已经显得有些⼒不从⼼了，所以可以按照
业务，将数据分别存储。⽐如针对评论数据，可按照商品ID进⾏hash，路由到对应的表中存储；针对⽀付记录，可按照⼩时创建表，每个⼩时表继续拆分为⼩表，使⽤⽤⼾ID或记录编号来路由数据。只要实时操作的表数据量⾜够⼩，请求能够⾜够均匀的分发到多台服务器上的⼩表，那数据库就能通过⽔平扩展的⽅式来提⾼性能。其中前⾯提到的Mycat也⽀持在⼤表拆分为⼩表情况下的访问控制。这种做法显著的增加了数据库运维的难度，对DBA的要求较⾼。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是⼀个逻辑的数据库整体，数据库⾥不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由⽹关和消息队列来实现，查询结果的汇总可能由数据库接⼝层来实现等等，这种架构其实是MPP（⼤规模并⾏处理）架构的⼀类实现。

微服务

随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微
服务，然后互相之间对数据的直接访问进⾏隔离，可以利⽤Gateway、消息总线等技术，实现相互之间的调⽤关联。甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务。

简单来所微服务这个方法其实是来解决人多的方案，将各个板块分给各个小组来做