维基百科技术架构演进分析

互联网系统涉及的行业与领域千差万别，本质上就是将现实中的线下场景迁移到了线上，利用计算机系统为人们提供更加快捷的服务。可以这样理解，互联网就是一个强大的工具，比以往任何工具都具有规模效应。原有的门店只能接待方圆几公里以内的客户，而现在则是全世界都有可能是其消费客户。

互联网有一个通用的法则，就是“规模决定一切”。互联网带来的规模效应，将我们原有的认知提升了很多个数量级。原来销售商品，能够达到上亿销量额的时间需要花费很长时间。而现在，一名主播通过独有的方式，借助互联网工具，短时间内就完成了。

既然互联网具有如此巨大的效应，那么，就会非常想要了解全世界的站点，访问量排名靠前的都是什么公司。当然，也有一点私心，那就是了解顶尖的互联网公司的软件架构是如何实现的。要知道互联网带来的规模效应，导致系统面临巨大的挑战，诸如高性能、高并发、高可用、海量数据、安全、成本等挑战。他们的站点是抗住巨大的用户访问的。

为此，我搜索了全球访问量排名靠前的站点，发现维基百科赫然列在全球第五的位置，位于谷歌、Facebook、YouTube、Baidu 之后。惊讶的地方在于，相比于其他高访问量的站点，维基百科的研发维护人员实际上也就十几个人，系统的服务器也都是捐献出来的硬件设备，数量不多，而且性能质量肯定不是非常好。这就带给我极大的好奇，相比于那些财大气粗的互联网巨头，维基百科是怎么利用极其有限的资源为全球用户提供了高质量的服务。这是一个值得思考的问题。

为了更好了解维基百科是如何进行架构演变的，故将其发展分为创立阶段、发展阶段、成熟阶段。这样也更能够理解维基百科怎么成为今天的样子的。

一、创立阶段

相比于传统的软件系统，互联网下的系统应用已经无法一次性设计，永远交付使用了。这是时代发展的需要，是经济社会快速发展的必然。因此，对于维基百科创立之初，实际上，肯定与许多的互联网创业公司一样，先构建基本的系统架构，基于一个核心的创新业务需求点，迅速投入市场，吸引第一批用户，进而验证模式的可行性和有效性。还有一点，互联网遵循渐进式发展，系统需要根据用户需求不断循环迭代。

因此，这一阶段，怎么简单，怎么来，怎么快速，怎么来。软件架构设计部署如下：

为什么这么认为。维基百科 2001 年创立，那个时候，实际上，互联网用户的规模还没有达到很高的程度，并且整个世界都刚刚经历过互联网泡沫。单体机应用实现系统快速上线运行即可。数据库也是单机运行即可。

这应该就像谷歌最开始从斯坦福大学实验室开始，Facebook 从扎克伯格哈佛宿舍开始，阿里巴巴从马云的家里开始一样。

二、发展阶段

随着第一阶段的成功，维基百科的业务受到了用户认可，大量的用户不断涌入维基百科，直接或者间接使用维基。这里需要补充说明一点，影响互联网系统架构的两个重要因素，一个是业务的复杂度，另一个就是用户规模。对于维基百科而言，业务复杂度不高，主要是提供用户查阅信息使用。因此，保证信息词条的正确性，以及如何更加快速响应用户访问请求，这是维基需要思考的问题。

能够编辑词条信息的用户和操作，相比于查阅的用户和操作，肯定非常少。实际上，这也不是对访问用户提供的功能，更像是一个管理系统，针对文章内容进行编辑更新操作。那么，只有拥有权限的人，才能去操作。对于这部分，系统不会有什么太大的压力。当然，随着内容的增加，拥有编辑词条权限的用户越来越多。但是，无论如何变化，阅读的用户数量远远大于编辑的用户数量。

保证信息的读操作，就是非常重要的一环。此时，为了应对大量的用户访问，就需要对系统架构进行升级，对维基业务进行完善。

系统最先感受到访问压力的就是数据，尤其用户大量的读操作。为了加快用户响应，将数据库进行读写分离。随着用户访问继续增加，查阅的数据大多数是相同的数据，没有必要每次都需要去访问数据库，故增加缓存应用，存储静态数据，进而加快响应。

随着维基百科的发展，拥有的信息和访问用户越来越多。此时，可以采用负载均衡，增加应用服务器数量，构建应用服务器集群，进而分摊用户访问数量，减小单台应用服务器压力。

发展阶段系统架构部署图如下：

三、成熟阶段

这个阶段，维基百科的用户规模和业务需求已经趋于稳定。同时，经过创立、发展阶段的累积，系统的架构不断得到升级改进。这个阶段主要是针对各个环节，进行进一步的优化，主要目的就是提供用户更加快速的服务。系统在 PV、DUA、TPS、QPS 等性能指标的辅助下，不断完善系统。

由于维基百科是面向全球用户，实现异地多活，构建多个数据中心，根据用户访问地址，就近选择数据中心，此时，就需要针对负载均衡升级。首先搭建 DNS 负载均衡，用户通过域名访问 DNS 服务器，DNS 负载均衡通过地址列表，进而选出距离用户最近的数据中心 IP 地址。

维基使用了 GeoDNS 作为 DNS 负载均衡服务器。

但是，我们指导 DNS 负载均衡只能针对访问用户进行地理划分，也不能进行负载均衡算法设置，非常机械，不够灵活。这是其缺点。因此，对于维基百科负载均衡，实际上是构建了三层。第一层使用 DNS 进行地理划分，第二层则使用 LVS 软件负载均衡，第三层，则继续使用 LVS。对于软件负载均衡，LVS 达到几十万级别，相比于 Nginx 的万级，性能要好很多。

由于大量用户访问维基百科，就是用于查阅之用，故维基在第二层与第三层之间，构建了反向代理服务器，使用 Squid Caching Layers 反向代理服务器，用于缓存静态页面数据。反向代理服务器，就是用于存储静态数据，当用户请求系统，反向代理缓存具有用户需要访问的数据，则反向代理服务器直接返回数据，将数据返回给用户，而不是将请求继续发送至应用服务器。这样也减小了应用服务器的计算压力。

在这里，为什么不适用 CDN。我认为，还是基于成本考虑，毕竟维基百科主要收入还是来自于捐赠，不能像盈利的互联网机构那样，拥有雄厚的资金，故没有必要，也没有资金再去移动运营商那里搭建 CND 服务器。

为了增加用户搜索的精准度，使用搜索引擎，提高用户查询的效率。我们知道，关系型数据 MySql 进行模糊查询的时候，性能非常低，基于 MySql 存储引擎以及索引结构，也无法提高模糊搜索的性能。而搜索引擎就是专门针对搜索而开发的中间件，对于搜索有着强大的功能。维基百科的搜索引擎采用 lucene。

数据库数据增加到一定程序，会超出 MySql 容量，故采用扩容的方式，提升数据存储的大小。同时，也为搜索引擎提供数据来源。

缓存系统也会采用分布式缓存系统，提升缓存容量。

对于维基百科，采用了反向代理，将缓存的数据返回给用户。但是，由于某些词条编辑更新，需要及时通知反向代理服务器，告知数据无效，故构建了消息通知服务，即 Invalidation notification。

以下便是今天维基百科的系统架构图。应用服务器是基于 PHP 语言进行开发的。

以上内容便是，我对于维基百科架构演进的一点思考。为什么我要这么做呢？因为我觉得当今的架构答案不重要，重要的是，系统是怎么来的，是如何进行架构升级，如何进行技术选型的，如何方案选择的。这个过程更加重要，没有这个思维的过程，记住再多的答案又有何用。要知道今天的社会变化非常快，你理解的答案，过一段时间就不再是答案了。

因此，这个思维过程更加重要，更加值得学习和刻意训练。

最后，非常感谢你的阅读，我自己的水平有限，文章肯定有很多错误的地方。能够看出错误的地方，也说明你很厉害，知道那个点不对，那个点还行，也希望能够指出来，帮助我进步。