大型互联网技术架构1－架构概述

我会带着你远行 2022-09-21 11:53 337阅读 0赞

![Center][]

上图坐标指向硅谷，最近开始研究互联网分布式架构，风口浪尖，高大上；特与极客朋友们分享，共勉。

**互联网架构**

近些年来，互联网的高速发展，大数据时代，Booming Years，我们作为技术极客，需要跟得上节奏，趋势。

**1 大型网站特性**

大型网站，无论是电商还是社交网站等通常都具有以下特性，如高并发，低延迟，海量数据，可扩展性，HA 7\*24；用数据来说明的话就是：Google日均UV数3亿，日均PV高达35+亿；Facebook周上传图片10亿以上；淘宝双十一，第一分钟UV高达1000万。而这些都是我们传统应用无法想象，无法望其项背的。

**2 架构演化**

还记得一位美国老板说过，"Project is evolutionary not revolutionary!". 互联网领域也是一样的。随着业务的发展，并发量，数据存储量等；系统开始演进，分而治之。其实，计算机世界包括硬件，网络，软件无不是引入新的层，对象，服务；从而分而治之来化繁为简解决问题的；而真实世界的事又何尝不是如此呢？当然，分而治之，拆分解决了一些问题，但是又会引入另外一种复杂/交互的问题。当然，分而治之，拆分解决了一些问题，但是又会引入另外一种复杂/交互的问题。

1.一台服务器： 曾经记得若干年前的互联网，或者其实现在的小型网站都是以经典的LAMP组合即搞定，即Linux, Apache, MySQL, PHP，甚至应用＋文件 ＋ 数据库全部在一台服务器搞定。

2.三台服务器： 随着业务发展，并发量，数据存储量等都不能满足时，开始拆分；首先将应用与数据分离；拆成三台服务器：应用服务器，文件服务器和数据库服务器。其中，应用服务器需要计算，因此需要更强大CPU;数据库服务器则需要快速磁盘与数据缓存；而文件服务器则需要更大硬盘。

3.引入缓存：继续改进，引入缓存机制改进访问解决热门业务。目前架构：

![Center 1][]

4. 集群：到了步骤3，看起来一切不错。可随着业务量，访问量的继续飙升，正所谓快乐的烦恼，应用服务器吃不消，直接宕机，导致所有业务瘫痪，正所谓单点问题。我们引入集群，解决单点问题，提供可扩展性。我们稍微看一下目前的架构：

![Center 2][]

注意，此时我们需要引入负载均衡器来协调用户访问哪一个应用服务器；如果有钱的主可以选择F5, 或者LVS, Nginx等。至此，一起看起来都是那么完美。

5.数据库读写分离：随后而来的是，网站的访问瓶颈在高并发下继续存在。究其原因，虽然引入缓存解决了大部分数据读访问，让然会有一部分读操作如缓存么有命中，或者缓存过期之类的需要访问数据库，当然，所有的写操作都需要直接访问数据库；如何解决？继续分而治之了。目前主流数据库都已经提供了主从热备功能，自动备份同步；我们正好可以利用此功能。读都走从数据库，写走主数据库。如此，巧妙的解决了读写分离。

![Center 3][]

6.引入反向代理与CDN:继续提升访问速度，提供更好用户体验。这里强调一下，网站访问速度/延迟与用户流失率正相关。目前主要主流手段为CDN与反向代理；二者原理都是基于缓存机制。区别在于，CDN是部署在网络供应商机房，而反向代理则不熟在自己网站机房。

![Center 4][]

可以看出，引入CDN与反向代理都是希望尽早返回数据给用户。科普一下：**CDN（Content Delivery Network）**是个古老的东西，在互联网发展之初就已经出现了。一群MIT的精英份子发现如果要让任何地方的人都可以很快的打开自己的网站的话，就需要象在世界各地盖教堂一样，把自己的网页发布到离信众最近的地方去。所以，他们用一种简单的缓存镜像的办法实现了这种发布。最早的入主这个教堂网络的是Yahoo！CDN在利用DNS的转授权来引导最终访问者找到最理想的缓存或者镜像站点，它是基于域名的一种服务。**反向代理****：反向代理（Reverse Proxy）**方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。目前用的最广的要算是Nginx，出自俄罗斯人Igor Sysoev之手笔。

7.分布式文件/数据库系统：继续开刀，当然所用的变革都是因为时机到了，业务发展，我们的系统从而随着演进，可不是为了演进而演进啊。文件系统比较简单，引入分布式文件服务器。数据库则较难，不得已才拆分。拆分数据库后，需要引入统一数据访问模块。

![Center 5][]

8 . NoSQL与搜索引擎：著名的NoSQL终于登场，关系型数据再怎么拆分，随着数据量的增加，仍然面临性能瓶颈，如多表关联，全表扫描等棘手问题。NoSQL表示无压力，如HBase，源自互联网，天然为互联网而生，天生俱有分布式，可伸缩性。

9.业务分拆：好吧，能想的技术架构都已经用了，都已经8板斧了，没辙了。只好开刀业务，哈哈。其实，业务包括业务条线，业务流程，如果能把业务规划的很好，包括流程，可以解决很多问题，包括性能；比如分时抢购促销等。回到业务拆分，通常根据业务场景，如电商业务包括了首页，商铺，订单，交易，购物车等产品线来拆分。可拆分之后，如何串联起来呢？ 应用之间通常采用几种办法，如通过超链接；消息队列；又或者是通过同一个数据库来关联共享。

![Center 6][]

10. 分布式服务：出大招了，正所谓分久必合。拆了这么多，这么细，必然造成复杂度指数级提升，部署，维护越来越困难，而且一定是有很多共同的功能，如用户管理，登陆管理，产品管理，交易支付等公共业务。好吧，整合服务，通过分布式服务调用业务服务。

![Center 7][]

到此，此架已经可以解决绝大多数互联网问题，当然，看图容易，真实实现架构则需耗费大量人力，物力，财力。阿里当年也经过了数十年的演变才至此。

**3. 互联网架构**

我们来看一张完整的分布式互联网架构图吧：

![Center 8][]

清楚么？可以看出，创新的业务产生了创新的技术，是业务与技术的完美结合。此处提一点，不要本末倒置，有些在业务方向还没有搞清楚的情况下，就盲目搭建大型互联网架构，可谓有钱 ＋ 烧钱。还有一些小型初创，为了技术而技术，盲目模仿Facebook, BAT，得不偿失。

另外，互联网技术发展到此处，已经进入云计算，容器服务阶段；中小企业再野不用，也不需要从新造轮子，直接用大公司提供的云计算，容器服务可，从而专心业务发展。

好了，抛砖引玉，简单聊了一下，小朋友醒了，要开始“三陪”了。注：很多想法参考自网上，以及技术丛书。

![Center 9][]

**公众号：技术极客TechBooster**

[Center]: /images/20220721/d6bb1c97cbb247148e36775570ef30e0.png
[Center 1]: /images/20220721/95d794d252634ecf9275ba6421a0e26c.png
[Center 2]: /images/20220721/d61215ce870b41a293ca232bf716debc.png
[Center 3]: /images/20220721/89158672ec58466bacaa777ca9351f4f.png
[Center 4]: /images/20220721/4cae8ea2d8ab4483b1e02d268c04bcb8.png
[Center 5]: /images/20220721/79c60845e28245f5aed389a18c25a3d4.png
[Center 6]: /images/20220721/9eb0816cb16548a68b7fda47b3307d28.png
[Center 7]: /images/20220721/b569b4e41ac44a0db66ceab7e1737ce6.png
[Center 8]: /images/20220721/e9d809c9b4e64ff1abc27faa03497971.png
[Center 9]: /images/20220721/b6afaaf6860a41da9561cb8cbf3e6b5e.png