互联网公司分布式集群架构图入门解析

二、中型公司网络架构

狗子的公司越办越大，越来越多的用户开始使用他的软件看各种足球咨询，而且，用于用户的基数变大了，每天增长的用户数量都在变多，以前可能是每天有十个新用户，那么现在就是每天有了一百个新用户。在一个晚上的服务器宕机事故出现之后，狗子终于意识到，自己的单台服务器应对日益庞大的用户群已经开始体力不支了。于是，他用了之前积攒下来的收益，又购入了三台服务器，并且用其中一台服务器单独运行数据库，作为数据库服务器。

那么现在问题来了，这四台服务器怎么一起使用，同时服务于一个网站的运营呢?

解决方案有两个：

1.三个服务器同时运行相同的代码，在代码页设置三个用户入口，如果用户进入一个入口发现进不去，就选择另一个入口，每个入口对应一台服务器

这样做的好处是简单方便，直接把代码往另外两个服务器一拷贝 然后更改一些其中的设置，再设置三个入口就行了。但是缺点也是很明显的，显然用户的第一反应都是点击第一个入口，只有当第一个入口进不去的时候才会选择另外两个服务器，而且等到以后用户数量越来越大，难道我们要设置几十几百个入口让用户一个一个去试吗？这显然又是一个被用户追着拿刀砍的行为。（当程序员可以体验死亡如风，常伴吾身的感觉）所以，这个方法显然不太现实，不过这个方法也是有它的应用场景的，比如说在一些学校的官网的在校生入口，由于在校生是毕业一批又新来一批，所以用户体量不会有太大的增长，因此才可以使用这个方法。这种方法的架构图是这样的：

2.负载均衡

狗子咨询了一些在中大型互联网公司的学长，终于找到了一种解决这个问题还不像第一种方法那样容易有生命危险的办法，那就是nginx。

nginx是个什么东西呢？是用来做服务器负载均衡的，说白了就是当用户发送请求的时候，先经过nginx这个中间人，nginx会去感受哪个服务器比较闲，就会把请求发送到这个比较闲的服务器上去，这样运行多了，就可以做到每个服务器相对的负担比较平衡，这就是负载均衡。nginx可以放在服务器本机，也可以放在单独的一个服务器中，nginx这个中间人会向各个服务器分发请求，并且nginx的性能十分高超，每秒百万级以下数量的请求都可以处理。你可能要问了，如果狗子把nginx单独放在一个服务器上，那么他的三台服务器怎么对应到同一个域名上呢？他是否需要给每个nginx分发的服务器也就是那三台购买三个域名呢？当然不用，事实上，现在我们对外的公共ip已经变成了安装nginx的服务器的ip了，也就是说，我们只要把域名映射到这个nginx服务器就可以了，然后nginx中会有配置，我们只要在配置中写下三个服务器的ip，nginx以后就能把请求分发过去了。那么，我们现在的架构图就变成了下图这样：

狗子还想对服务器做做优化，像是session这种东西，只是简简单单的一个session请求，却要耗费服务器那么多的性能，有没有一种方法，能够对这方面做一些改进呢？

当然有，解决方案就是redis。

redis的作用

redis是一种数据库，我们比较熟知的数据库有mysql，sqlServer，oracle等，那么这个redis又是个什么玩意？
redis和上述几种数据库不同，它是缓存数据库，也就是说，redis是致力于短时存储的，redis并不是从硬盘中拿取和处理数据，它对数据的处理都是在内存中，由于内存的数据处理速度不知道比磁盘高到哪里去了，所以redis的性能也是碾压mysql，sqlServer，oracle这种数据库的，这无关于软件优劣，纯粹是因为硬件层面的因素。不过redis因为是在内存中，因此只要机器一关闭，内存中redis存储的东西就会消失了，不过redis也可以将数据持久化存储到mysql这些数据库中，但是一涉及到对硬盘的操作，redis的性能就下来了。因此，我们的redis常常是用来存储像是用户的登录状态这种短时需要的数据，而去把用户登录注册的时间备份到硬盘上的数据库。那么，我们现在的架构图就变成了如下这样：

又过了一段时间，随着用户体量越来越大，数量级达到了上万上十万的时候，狗子发现一直以来，自己都忽略了一个问题，尽管自己增加了服务器，加了负载均衡，还启用了redis缓存数据库，为了使用户访问的速度增加还有让服务器的负载不那么大，但是，网站处理数据的方式本质上是对数据库进行增删改查，而现在我们的数据库服务器只有一台，数据库处理数据本身就是一项复杂耗费内存的工作，现在的一台数据库服务器更是杯水车薪，因此，在中小型公司的网站架构中，最先撑不住的往往是数据库服务器。

当然，狗子又有了解决办法。他又购入了两台服务器当作数据库服务器，然后把数据库进行了分库分表的操作，分别把数据存在三台数据库服务器上。当然狗子觉得这还不够，因此，他又使用了一种技术，将数据库进行了读写分离。

读写分离理解起来很简单，和它的字面意思一样，就是把从数据库中写入数据和从数据库中拿取数据进行分离，以此来达到减少数据库服务器负担的作用。用来读取数据的服务器和用来写入数据的服务器会在用户进行操作之后延迟一段时间进行数据同步，一般来说延迟时间不会太长，很可能用户都不会觉察到。那么，我们现在的架构图就变成了下图这样：

可以看到，我们的图上新出现了“集群”这个词，不错，互联网经常提及的xxx集群终于在我们眼前解开了神秘面纱，也就是多台服务器同时协同处理事务，就可以称作一个服务器集群。

三、大型公司网络架构

时光飞逝，转眼间五年的时间过去了，狗子已经从一个中小型互联网公司的小老板摇身一变成了一个上市公司总裁，和马云马化腾等it行业巨佬互动成了他的日常，他的一句话可以动摇it界，他的网站也拥有了上亿的用户。。。。。

到了这种程度，狗子的公司网络架构已经变成了下图这样：
（内容比较多，看不清记得放大哦）

能支持上亿人访问的服务器肯定不止这么几个，只是象征性地画了几个。同时，我们把redis服务器与mysql服务器进行了连线，是因为我们前面说过redis可以将数据存入持久性数据库，这里我们可以用来记录登录时间之类的信息。同时，图中的mysql服务器是重叠在一起的，不要以为仅仅只有两台服务器。

随着公司变为巨头，狗子的经验不断累积，他发现自己的公司虽然体量很大，开发的产品越来越多，功能越来越全面，但是总是有那么一部分的功能是重复的。假如在一个新的页面或者产品中，刚开始开发时有那么10%是和以前开发过的页面或者产品的功能是重复的，那么，等到这个新东西的功能开发接近完善的时候，就可能会有70%的功能和从前开发的一样。仔细想想这是一件很可怕的事情，狗子居然画了70%的开发时间和开发成本在做以前早就做过的事情。

这狗子就不能忍了，于是他想到了一个好办法，既然面向对象编程语言中有封装的这种概念，把代码的重复部分封装起来便于重复使用，那么产品和产品之间为何不能封装相同的东西便于使用呢？

于是，他开始实现微服务的概念，解释起来可能一上来比较难于接受，我们先来看，刚刚我们的架构图中的产品实际上可以看成一整个系统，假设这个系统叫做系统A。那么，我们现在开发出来了其它的各种产品或者各种页面，也可以看作是新的系统B和系统C。现在，系统ABC之间有很多重复的部分，于是，我们想到了将这些重复的部分放到一起，供三个系统同时调用。那么实际上，这个重复的部分就是被封装起来的微服务，微服务是一种模块化开发，把产品的功能提炼成多个模块，在开发时把模块拼接起来，就可以省去大量的工作。为了实现一个模块，模块中也需要带有服务器集群等东西。听了这些，我们下面的架构图看起来应该没有那么难懂了：

这些是一种开发理念，一种思想，有了这种思想，才能在成千上万的用户需求之间找到共通，提升开发效率，节省成本。

这种理念的具体实现就是目前非常常用的Rpc框架，有兴趣的小伙伴可以去了解一下，比较常用的一个是dubbo，一个是spring cloud，如果读者有幸能进入比较大型的互联网公司，接触到其中的源码的话，会发现他们的项目都是互相依赖的，这种互相依赖的关系的实现就是基于rpc框架和maven，在完成需求代码的时候，常常需要顺着一条线去浏览修改好几个相关的项目，在项目运行的时候，都是通过http协议调用rpc框架中相互依赖的项目的，这样的好处也是显而易见的，就是我们前面说的那些，解耦，降低项目开发重复度，节省开发成本，便于维护。