网站架构变迁 _网站架构

网站架构变迁Intro从最早的 html 的学习到现在从单体应用迁移到微服务架构，所经历的网站架构也一直在变化，想写一篇关于网站架构变迁的文章。
单服务器最早的我们的网站只有一台服务器，网站应用 + 数据库 + 网站文件都在同一台服务器上，有的时候一台服务器上也会有多个网站。
这个阶段的服务器上除了 Web Server，还会装一个数据库服务器，网站文件一般是放在网站目录下保存的

文章插图

数据库服务器 + 网站服务器数据库和应用分离，数据库使用独立的数据库服务器，网站服务器上只有网站，不在安装数据库服务器。
【网站架构变迁】一般的网站服务器的瓶颈在于内存和CPU，而数据库服务器瓶颈大多是在IO方面，所以分离之后对于网站服务器我们在扩容的时候可以更加关注于加大服务器内存，加多核处理器，而数据库服务器在可以更加关注于提高服务器 IO 。

文章插图

数据库服务器 + 网站服务器 + 文件服务器这个阶段在上一阶段的基础上进一步把文件分离出来了，这样网站迁移起来就不需要再迁移网站上传的文件了，而且文件服务器升级的时候往往是提高存储的容量

文章插图

网站集群 + 负载均衡网站发展到一定的规模，我们就可能会遇到一些系统瓶颈，除了升级服务器的配置外，我们也可以做网站集群，因为单一服务器配置升级到一定程度之后再想升级成本就会很高，相比之下做网站集群性价比会更高一些，可扩展性更好，而且做集群的话可以防止单点故障导致网站不可用，

文章插图

既然是集群，多台服务器同时工作就会遇到一个请求交由哪个服务来处理的问题，一般的我们会在网站集群前加一个负载均衡器，由负载均衡器根据一定的负载均衡算法选择要处理的网站服务器

文章插图

网站集群 + 负载均衡 + 分布式缓存上面我们引入了网站集群+负载均衡，对于服务器 Session 可以指定使用 IPHash 或类似的负载均衡策略，但是如果不支持 IPHash 类的负载均衡算法，就需要支持分布式 Session 的支持，一般的分布式的 Session 我们可以借助分布式缓存来实现，而且可能会有一些内存缓存，如果使用网站服务集群的话，就要考虑使用分布式缓存了，否则会导致数据的不一致，一台服务器的缓存数据更新了，其他的缓存数据还是旧数据，就会造成很多问题，所以分布式缓存就很有必要引入了

文章插图

网站集群 + 负载均衡 + 分布式缓存 + 数据库读写分离数据达到一定的规模之后，数据库容易成为系统的瓶颈，除了引入缓存来解决之外，我们可以让数据库做读写分离，读操作走从库，写操作走主库

文章插图

服务化架构上面的模式，对于网站应用来说，都是一个单体应用，从服务化架构开始，开始真正的从单体架构迁移到分布式架构
单体应用发展到一定程度，应用的复杂度越来越高，代码耦合度也会逐渐增加，从项目的角度来说，项目越来越大，项目维护也会变得越来越难，冲突也会越来越多，项目加载编译运行需要的时间也越来越长，从部署的角度来说，不同的 API 之间会相互影响，我只改了某一个 API 但是部署的话只能全部更新。

文章插图

于是服务化就应运而生，服务化将原来的单体架构拆分成了分布式架构，每一个服务只负责自己相关的业务逻辑，每一个服务都是一个小单体

文章插图

微服务架构微服务架构 1.0在服务化的基础上进一步演化出来了微服务架构，微服务是服务化的进一步发展，微服务是去 "ESB" 的更细致的服务化
“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构"---- Martin Fowler的博客