浅谈分布式系统

1. 单机架构

2. 分布式是什么

3. 数据库分离和负载均衡

4. 理解负载均衡

5. 数据库读写分离

6. 引入缓存

7. 数据库分页分表

8. 引入微服务

单机架构

        所谓的单机架构就是一台服务器负责一个应用程序的所有流程；如图的就是一个单机服务器，由应用服务部分构成完成业务的处理，由数据库服务完成数据的存储，而我们最常接触到的就是MySQL数据库，MySQL是客户端服务器结构程序，本体就是一个MySQL服务器；

        单机架构别看结构简单，但却也是最被广泛使用的，主要是随着硬件的快速发展，一个好的服务器已经能够支持很高的并发和非常大的存储；

        但是如果业务进一步发展，用户量和数据量水涨船高，一台主机/服务器难以应付的时候，就需要引入更多的主机，引入更多的硬件资源；

分布式是什么

        玩过电脑都知道，一台主机的资源是有限，包括不限于cpu，内存，网络......，而一个服务器接收处理一个请求就要消耗一部分资源，十个请求就要消耗十部分资源，当服务器在同时处理很多的请求的时候，就有可能会因为某个资源的不足而导致服务器处理请求缓慢，甚至崩溃，而要解决也很简单，无非开源，节流，节流是指软件层面的优化，实际就是突破程序的瓶颈，而程序的优化也不是那么简单的，有可能有经验的程序员看到问题就能够优化，而经验不足的就不能解决，即使发现了，也有时候不能优化程序，这就跟程序员的技术有关了；而开源指的就是引入更多的硬件资源，就像如果是内存不够就多插几条内存条，硬盘不够就拓展硬盘之类的，但是一台主机的硬件资源的拓展也是有上限，当一个主机拓展突破上限了，就意味着要引入更多的主机了，这就是分布式系统；

        但是分布式系统并不是说引入几个主机就完事的，还需要程序进行调整和优化来适配多台服务器，引入分布式系统可以说是无奈之举，万不得已才引入的；更多的主机会导致程序的复杂程度上升，乃至以指数级别的上涨，就会导致出现bug的概率上升；

        所以各位程序员不要对分布式系统趋之若鹜，一台主机能够搞定的事情，就不要引入多台主机，搞分布式系统了，不要忘记了写程序的初心；

数据库分离和负载均衡

        前面说到分布式，最简单的分布式就是把单机架构的应用服务和数据库服务分开，分别用单独的应用服务器和数据库服务器负责，然后根据不同的服务器的特点针对性的进行优化；

         对于应用服务器它更消耗cpu和内存，所以我们可以给应用服务器换更好的CPU和更大的内存，对于应用服务器他需要的是更好的存取速度和存储空间，所以我们可以换更大的硬盘，乃至固态硬盘；以这种方式来是现实分布式更高的性价比；

        当需求进一步提高，我们就可以引入更多的应用服务器来处理需求，以及引入负载均衡器和对需求进行管理和分配以实现更快，更准确的处理需求；

        当用户发送需求的时候，首先会经过负载均衡器 （网关服务器），是一个单独的服务器，由负载均衡器来对需求进行分配给各个应用服务器，可以是很多个应用服务器，不止图中的两个，如果一时间有10000个需求，负载均衡器就会视情况可能给两个应用服务器分别分配5000个需求，这样子就相对于一个应用服务器处理10000个请求好得多，准确，快速得多；

理解负载均衡

        那有人就会问了，那负载均衡器不是要负责那么多需求吗？它能负责得过来吗？实际上负载均衡器不是因为性能要比应用服务器好多少，是因为负载均衡器分配一个需要并不会消耗太多的性能，而应用服务器是实实在在的处理需求，消耗的资源就会相对多一点；就能生活中的例子来说，分配任务比完成任务要困难，要耗时间得多；

        但是负载均衡器也是存在性能上限的，并不能无上限的分配需求给应用服务器，这时候我们就要引入更多的负载均衡器了......

数据库读写分离

        用来处理请求的应用服务器经过以上的部署，已经能应对高并发和很高的处理速度多了，但是数据库服务器还是一个，随着应用服务器处理的请求越来越多，访问数据库次数就短时间会增加很多，数据库一旦访问量大的时候就很容易撑不住的，比应用服务器更敏感，为了解决这样的问题，也是一样开源，节流，但是我只讲开源，前面处理很多的请求的采用的是引入更多的应用服务器，数据库服务器的开源方法就是引入“数据库读写分离”，将存储服务分为两个服务器，一个负责写（主），一个负责读（从），对于数据库的操作：增删改都是写，查是读，但是实际的业务读数据的频次相比较写数据会更频繁，所以有时候会引入更多的读服务器；而读写服务器会定时同步内容；

引入缓存

        数据库天然就有一个特性就是响应速度慢，有时候就不能很好的响应，做过项目都知道，有时候在前端要显示必须从数据库获取的信息的时候，会隔一段时间才显示出来，还有的要获取的数据是存储在硬盘里的，没有权限获取等等情况；

        我们会把数据分为“冷热数据”，经常会被访问到的就是热点数据，这样的数据会遵循一个原则：“二八原则”，就是20%的数据就能支持80%的访问需求，在实际业务中会是“一九”（原来的二八原则是指世界上20%的人掌握80%的财富；

        为了能尽快的获取到热点数据，我们会引入一个缓存服务器来专门存放热点数据，Redis就是在这里使用的，缓存服务器速度比数据库快很多，但是没有办法衡量到底快多少。缓存服务器的优点是速度快，缺点也有就是空间小，价格贵；那有没有空间大的呢？那就是更贵的缓存服务器啦；

        引入缓存虽然说可以提高响应速度，但是也要带来一些难题，就是缓存和数据库的数据同步问题，缓存服务器存的只是数据库的一小部分数据，全部的数据还是存在数据库的，一旦涉及数据库数据的修改，涉及到的缓存服务器的数据也要修改，这就有可能因为处理不当，导致两部分的数据没有同步。虽然引入缓存提高了速度，但是也引入了更加繁琐的数据同步问题。

        要想达到一个效果，就要付出一定的代价。

数据库分页分表

        前面讲数据库分离的时候应对的高的请求量，但是我们不仅仅要处理高的请求量，还要关注数据量，一个请求涉及到数据量可能有很多，很多的的请求涉及到数据量就更不可计数了，一个数据库的容量可以有几十TB，但是也有不够的情况，例如现在很活的短视频，数据库存的就是视频数据，这就不是简简单单的存一张照片，一个变量那么少了，所以但一个数据库服务器不够存的就是，我们就会给数据库的每一个表都安排一个数据库服务器，可以视情况再分为主数据库和从数据库，但请求涉及到哪个表就去访问哪个数据库就可以了，这就是数据库分库；

        那么也会有一个数据库服务器存不下一张表的情况，这样我们就会给这个表再次细分，然后安排相对于数量的数据库服务器来存放这个表的一部分，这就是数据库分表；

        当然数据库的分库分表都要根据具体的业务场景来进行设计，业务是基础，业务决定用什么技术来解决问题，一切要以业务为出发点；

引入微服务

        随着业务的发展，应用服务器的代码也会越来越多，越来越复杂，变得更加难以维护，这时候我们就会根据业务拆分成很多部分，每个部分负责一部分功能，这样原本很大的程序代码就会被拆分成很多个功能单一，更小的服务器，也会变得更加容易维护，这样的一个功能单一的服务器就是微服务。

        如图，原先的一个应用服务器就要负责用户，商品，交易相关的所有业务，拆分成微服务之后部署就变成了用户单独一个服务器集群，商品单独一个服务器集群，交易一个服务器集群，服务器的种类和数量也随着增加了；

        引入微服务实际是企业为了解决“人”的问题 ，原先所有功能都集成成一个应用服务器的时候，所有人的代码都是凑在一起，不利于企业管理，所以就自然而然的分组出来，一个小组负责一部分功能，这样就有利于管理，也可以在出现了问题就可以更好的定性；

        引入微服务的代价

        1.系统性能下降。原先所有的功能都处在同一个服务器上，各个模块之间功能的调用直接进程调用即可，分成微服务之后，服务器之间的通信就要用到网络通信了，我们都之后数据的交换速度，cpu>内存>硬盘>网络，可想而知网络通信有多慢，自然而然就会影响到系统的性能。不过好在现在硬件的发展非常的迅猛，已经有万兆网卡了，这就比硬盘的速度要快得多了，但是有王兆网卡，你就得有万兆的交换机，万兆的路由器，万兆的网线，这都是钱啊！！！

        2.系统的复杂程度上升，出现问题的概率也会提高。需要专门的完善的运维人员和监控中心来负责维护系统，这也都是钱！！！

        当然引入微服务也是有好处的：

        1.解决了“人”的问题，有利于更好的管理很多的人。

        2.更方便各个功能的复用，每一个微服务都会单独部署到一个服务器上，这就有利于功能的调用和复用，提高功能的复用率。而且我们也可以根据功能的特点，对服务器的硬件进行更好的优化，提高性价比。

        但是我们要知道微服务并不是终点，分布式也不是，我们并不需要每一个系统都去使用微服务和分布式，这只会增加写bug的概率和维护的难度，以及带来很多不必要的支出。学习微服务和分布式并不是为了炫技，而是在我们需要使用的时候，不至于手忙脚乱