网站技术架构发展--[1.网站架构演化]

今天想和大家谈谈网站架构的演化！

第一阶段：

最早接触网站大概是2004年吧，那时候大学第一个asp程序，觉得可神奇了，加上用花生壳域名动态映射，居然随处可以访问，虽然很慢，但也得意了好一阵子，其实那时候的网站是下载源码后修改的。

这也是很多小公司做软件时候，起码是开发环境遇到的第一种架构类型吧，可以称之为最简单的架构！



第二阶段：

这种架构针对使用率很低的小数据量、低并发来说算不上错，做好数据、文件的备份，如果不存在性能、内存、存储不足，网站业务经常变化，系统PV忽大忽小等问题的话，也能将就着用了。

像我一样，这种系统在学生中最常见，尤其是毕业答辩时候，很容易部署！甚至都不带修改配置文件滴。

但随着业务的进一步发展，最先增大的一般是数据量，具体点说是数据量中的文件数量(一般部署应用的服务器存储不会很大吧)，于是乎我们想到要进行拆分。

好吧，应用，数据库，文件存储分别拆开。

针对应用，我们更多的会去考虑服务器的计算速度，数据库我们会考虑服务器的内存大小和存储的读取速度，文件服务器我们要考虑更大的存储。然后第二版架构就出来了！



第三阶段：

随着PV和UV的增加，系统中潜在一些热点数据的读取频率极高，而这些数据的修改频率又很低，于是想着怎么样能把这种数据缓存起来，以减轻数据库读取压力，提升系统加载速度，缓存应运而生。这个架构较上边的架构没有多大差异，只是加了本地缓存。



第四阶段：

随着缓存的数据越来越多，缓存对服务器内存的要求进一步增加，而缓存的存在也影响了网站应用对服务器的利用，慢慢的我们尝试把缓存放到一个独立的服务器上形成分布式缓存，这样缓存和应用互不影响，应用依赖缓存并非完全依靠缓存。



第五阶段:

网站的访问量会进一步增加，逐渐会对应用服务器造成压力基于对高可用性和高性能两个维度的考虑，我们尝试把完全相同的应用部署在多台服务器上，通过负载均衡服务器或软件功能进行动态分配，注意，HTTP是无状态的，而网站经常会保存当前用户信息的状态，这里会存在一个多系统session共享的问题，今天我们只讲发展，留着这个话题在后续的架构实现中讲解如何去做。



第六阶段：

做到这一步，应用的性能可以通过扩展应用服务器数量做到调控，通过简单的注册配置便可添加至负载均衡服务来减轻访问量给应用服务器带来的压力，热点数据进行了分布式缓存，文件服务器独立，看似已经基本上符合传统行业使用了。然而，随着传统行业数据的积累，业务的复杂度，数据量的积累，用户需求的刁钻导致很多读取数据很耗性能。而查询避免不了会产生锁，加上开发人员水平不一，结果导致读影响写的问题，对了，将读和写分开是这一步的思路。



第七阶段:

应用一步步的做大，一个系统代码越来越多，维护越来越复杂，经常牵一发而动全身，然后通常情况下，经过细致分析，我们会发现各个模块之间业务基本独立，所要共享的只是一些基础数据和其他系统的主业务数据，而超大的系统的性能、可用性、可维护性、可扩展性都存在不少问题，我们尝试将其进行业务拆分，各个系统拆分成独立系统，管理平台拆成独立系统，采用Dubbo，ESB，接口等方式进行集成，确保系统功能间解耦，主数据共享，分析数据集成。



做到这一步，对于大多数传统行业已经完全够用了，但目前互联网发达的今天，双11，双12,618动辄对电商系统造成的压力岂是传统行业可以比拟的，电商系统是支撑业务发展的主要平台，如果出现宕机对其影响甚大，虽然有高可用架构，但每次促销，电商IT仍如临大敌，所有IT在促销前几天就开始进入没有硝烟的战争，京东技术解密第一章就在大肆渲染这种感觉，个人觉得这种感觉真爽，痛并快乐着。

今天先写到这里，关于CDN，分布式数据库，NoSQL等相关内容这周一定分享出来！

 

同时希望大家关注我的微信公众号共同探讨。