大白话带你理解网站架构发展历程

阅读更多精彩文章，欢迎关注微信公众号：深夜程猿

网站架构发展历程

本文讲的网站架构，更多的是网站的部署架构。对于应用服务的架构不会过多涉及，比如SOA、微服务。

本文会基于一个虚构的故事，力取使用最简单的语言跟大家讲明白一个网站架构的演进历程。

故事的开端

小吴是一名程序员，立志要通过自己的努力，使用技术来作出一点值得自己骄傲的事情。

突然有一天，小吴需要搬家，但是，家里堆积了许多厚重的书籍，大部分书籍是用不到了，但是又不想丢掉，真想可以送人。于是，小吴就想着自己搭建一个这样的网站，供大家来使用。

阶段一

小吴花了一个周末，吧啦吧啦的用代码实现来自己最原始的想法。并打算上线。虽然小吴是一名程序员，但是也明白产品开发MVP的道理。网站开发出来了，总得找一些人来使用看看效果。小吴为了最低成本的验证自己的想法，在阿里云购买来一台很便宜的云服务器，在里面搭建了Tomcat应用服务器、MySQL数据库服务器、Nginx静态资源服务器，并部署了应用服务在Tomcat上面，这样，网站v0.0.1上线了。

现在，小吴的网站的架构如图：

接着，小吴找到了三五个比较好的喜欢阅读的朋友来使用网站。经过几天的使用，朋友对网站使用体验和网站价值表示肯定，同时也提出了一些看法和建议。小吴收集到这些需求后，基于“用户-需求-场景”分析框架进行了需求梳理，并进行了优先级排序。最后，开始了新需求的编码之旅。

阶段二

经过一周的努力，小吴网站的v0.0.2版本开发好了，也上线了。这回，小吴并不满足于几位朋友的使用，于是他经常泡各种阅读社区，想办法曝光自己的网站，并让朋友也介绍一些喜欢阅读的朋友来使用网站。经过一个月的努力，小吴的网站用户过了一千。由于网站用户体验不错，加上网站满足了用户图书赠送、线上以书会友的需求，用户频繁使用和推荐更多朋友使用，网站的访问量越来越多。

但是，用户的访问速度逐渐下降。小吴收到用户反馈后，网站的日访问量在几万～几十万，应用服务器的内存占用、CPU占较高，特别是本地磁盘I/O操作。可以得出，现在最主要的矛盾就是对数据库的访问降低了整个系统的响应速度。于是，小吴就决定把数据库服务独立出去部署在另外一台服务器，文件存储服务也独立出去。小吴购买了云MySQL服务器、云对象存储OSS，经过两天的努力，小吴完成了开发任务和云服务的配置和部署。这样，小吴的网站v0.0.3上线了。

现在，小吴的网站架构如图：

v0.0.3上线后，网站的访问速度恢复正常了。

阶段三

小吴的网站具有自传播效应，加上小吴的持续努力引流，网站的用户越来越多，终于过万了，网站的日访问量十几万～七八十万。但是，网站的访问速度又下降了。小吴又得开始分析问题了。是单台应用服务器不够承担压力？部署多台试试看或者提升服务器的物理配置？但是，这些真的就可以解决网站访问速度慢的问题吗？可以多大程度上提升访问速度？数据库的访问压力怎么样？这时，小吴头大了，因为有太多可能的选择了，但是哪一个在现阶段是更优的呢？

直觉告诉小吴，如果应用服务器负载太大，那么数据库服务器负载也同样会大，经过应用服务器的请求都会落在数据库服务器。现在用户在网站上的行为主要是浏览数据，产生数据只是少数用户。于是，小吴尝试给数据的访问加一层缓存试试看。但问题来了，缓存是加在哪儿呢？应用服务器本地内存？还是远程缓存服务器？

小吴想到，如果通过加缓存还解决不了问题的话，需要对应用服务器进行集群部署，这样如果数据直接缓存在本地应用服务器，以后在集群部署的时候会出现数据一致性问题。所以决定对经常被使用但不会改变的数据可以缓存在本地服务器，对于短期内不会修改但是后续会修改又经常被使用的数据缓存在远程服务器。于是，小吴又开始吧啦吧啦写代码实现了缓存这一需求。购置了远程缓存服务器后，小吴的网站v0.0.4上线了。

现在，小吴的网站架构如图：

新版本上线后，网站访问速度恢复正常了。验证了小吴的判断是正确的了

阶段四

随着用户越来越多，网站的访问速度又下降了。这时候，小吴又开始了冷静的分析：在数据访问层加上了缓存，应该不会是数据访问这一环节出现的瓶颈。访问速度下降的瓶颈很可能出现在应用服务器这一层。小吴查看了应用服务器的CPU和内存使用情况，发现大部分时间应用服务器的CPU使用率高达80%，内存占用率一直巨高不下。很明显，应用服务器单点部署已经是网站系统性能的瓶颈了。办法很简单，小吴采用集群部署应用服务的方式来解决。

经过两天的捣鼓调整，小吴网站的架构如图：

在应用服务器前面加上来一层负载均衡调度器，通过负载均衡算法分发用户请求到不同的应用服务器集群节点上面。经过调整，网站的访问速度又恢复正常了，甚至比之前的更快了。哈哈，又解决了一次难题～～小吴会心一笑！！

其实，这个架构存在负载均衡调度器单点问题，解决方法是负载均衡调度器主备部署，主节点宕机，备节点接替主节点工作。

阶段五

经过阶段四的努力，小吴的网站扛住了半年的用户增长压力。随着用户越来越多，网站的数据也越来越大。又半年过去了，小吴的网站访问速度又变慢了。小吴尝试通过加应用服务器集群节点，但没有什么改善。很明显，这次是在数据访问层面出现瓶颈了。随着用户数据量越来越多，缓存服务器缓存的数据对于用户访问的数据的覆盖率越来越低了，较多请求直接落在了MySQL数据库上面。小吴识别到了现阶段主要矛盾是数据库的访问，于是小吴在提升数据库服务器性能和数据库读写分离的选择下，选择了数据库读写分离。因为通过更加廉价的物理服务器的水平扩展会比提升物理服务器性能的纵向扩展要更加低成本。这阶段，小吴也对缓存服务器作了主从。如果缓存服务器宕机，所有的请求直接落在数据库上面，这会瞬间降低网站的访问速度的。又经过一番努力，小吴改造好了网站架构并上线。

现在，小吴的网站的架构如图：

到这里，网站已经具备大型网站系统架构雏形了。在上面的五个阶段的架构中，只是介绍了大致的系统架构，但是比如，服务高可用、高性能、数据安全等一些细节不会深入讲解。本文目标是用大白话让大家对网站系统架构演进历程有个理解。其实，对于服务高可用、数据可用性等这些问题，我们基于现有的架构做一些更细节的优化就可以了。比如阶段二如何保持数据可用性，其实在数据库可以进行主备配置，主库进行数据的读写，备库只进行从主库同步数据，。在主库宕机后，备库接替主库进行数据的读写。

阶段六

经过阶段五的优化后，小吴的网站访问速度有了质的提高。网站用户继续增长，数据也越来越多。期间小吴通过添加集群节点方式保持了网站的响应速度。

但是，随着网站的版本迭代，前端页面越来越多，需要加载的东西也越来越多。有些请求，在很长一段时间内返回内容是不变的。这样，一年又过去了。小吴的网站的访问速度又出现变慢的趋势了，小吴通过继续添加应用服务集群节点的方式改善效果不明显，可见，瓶颈出现在数据库层面和静态资源的访问。但是，目前所有的业务数据表都在同一个数据库中。现阶段可以进行数据库的拆分和应用服务的拆分，按照业务维度进行拆分服务和数据库。这样就可以不同业务的数据库使用不同的数据库服务器，可以使用多台服务器分担数据库读写压力，同时应用服务拆分处理可以在不同的集群部署，也分担了更多的请求压力。但是，如果这么做，开发成本和服务器成本较高。

再经过一番分析，小吴了解到主要是前端页面很多请求耗费了一些响应时间，同时一些静态文件没有做好缓存。于是，这次小吴觉得添加CDN和缓存代理服务器。CDN主要是对前端页面静态文件的加速处理，缓存代理服务器主要是缓存一些请求响应的数据。经过一番努力，网站架构改造完成，又上线了网站。

现阶段，小吴的网站架构如图：

结束语

在阶段六的网站架构，如果再进一步演进，我觉得就是我们现在的微服务架构了。通过拆分服务，核心服务部署在更多集群节点，较少访问的服务可以使用更少和更低廉的服务器部署，这样提升了服务器资源利用率，成本更低。同时不同的服务访问不同的数据库，这样数据库分散在不同的服务器上，分散了数据库的访问请求。

阶段一到阶段六是网站架构的演进进程。当然，更多的细节没有考虑进去，比如数据库选型、缓存选型。当然，还有更多可以谈的，但是本文目标是让大家对网站架构发展进程有个理解就可以了，本文就不会继续深入讨论网站架构的演进以及更细节的东西了。

感谢大家的阅读，欢迎评论区写下阅读后的体会和对本文不足之处的指出。

参考资源

• 李智慧《大型网站技术架构：核心原理和案例分析》

阅读更多精彩文章，欢迎关注微信公众号：深夜程猿