软件开发编程门户 › 首页 ›网站开发› 后端开发 › 查看内容

网站架构变迁

2024-11-19 22:30| 发布者: admin| 查看: 62| 评论: 0

摘要: 网站架构变迁 Intro 从最早的 html 的学习到现在从单体应用迁移到微服务架构，所经历的网站架构也一直在变化，于是想写一篇关于网站架构变迁的文章。单服务器最早的我们的网站只有一台服务器，网站应用 + 数据库 + ...

网站架构变迁

Intro

从最早的 html 的学习到现在从单体应用迁移到微服务架构，所经历的网站架构也一直在变化，于是想写一篇关于网站架构变迁的文章。

单服务器

最早的我们的网站只有一台服务器，网站应用 + 数据库 + 网站文件都在同一台服务器上，有的时候一台服务器上也会有多个网站。

这个阶段的服务器上除了 Web Server，还会装一个数据库服务器，网站文件一般是放在网站目录下保存的

single server

数据库服务器 + 网站服务器

数据库和应用分离，数据库使用独立的数据库服务器，网站服务器上只有网站，不在安装数据库服务器。

一般的网站服务器的瓶颈在于内存和CPU，而数据库服务器瓶颈大多是在IO方面，所以分离之后对于网站服务器我们在扩容的时候可以更加关注于加大服务器内存，加多核处理器，而数据库服务器在可以更加关注于提高服务器 IO。

数据库服务器 + 网站服务器 + 文件服务器

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

网站集群 + 负载均衡

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

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

网站集群 + 负载均衡 + 分布式缓存

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

网站集群 + 负载均衡 + 分布式缓存 + 数据库读写分离

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

服务化架构

上面的模式，对于网站应用来说，都是一个单体应用，从服务化架构开始，开始真正的从单体架构迁移到分布式架构

单体应用发展到一定程度，应用的复杂度越来越高，代码耦合度也会逐渐增加，从项目的角度来说，项目越来越大，项目维护也会变得越来越难，冲突也会越来越多，项目加载编译运行需要的时间也越来越长，从部署的角度来说，不同的 API 之间会相互影响，我只改了某一个 API 但是部署的话只能全部更新。

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

微服务架构

微服务架构 1.0

在服务化的基础上进一步演化出来了微服务架构，微服务是服务化的进一步发展，微服务是去 "ESB" 的更细致的服务化

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

当项目进行服务化改造的时候，这个过程并不是一蹴而就，一拍脑袋就成功了。要把项目服务化，需要解决很多的问题，例如：

服务之间怎么调用？订单服务想要调用到商品服务的数据，怎么调用？怎么调用更加的稳定，更加高效？【服务调用技术】

服务之间怎么负载均衡？订单服务要调用商品服务，商品服务可能有很多个，怎么负载均衡【负载均衡技术】

服务怎么被管理？服务怎么定位？有故障了怎么处理？【服务注册与发现技术】

故障怎么监控？微服务系统中业务模块很多，组件也很多，不同组件的指标不同，那么这些组件怎么进行监控【监控技术】

故障怎么定位？微服务架构中，一个用户的请求会涉及到多个内部服务的调用，那么如何定位问题呢？【链路追踪技术】

日志怎么分析处理？业务模块多了，日志也就多了，直接查看日志文件已经变的不显示了，那么如何对日志进行分析查找呢？【日志分析技术】

权限管理？微服务拆分服务之后，会有很多服务对外暴露接口，这些接口如何进行统一的权限处理呢？【网关技术】

服务调用出现问题怎么处理？当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。怎么解决呢？【服务熔断，降级，限流】

微服务架构 2.0

基于 Kubernetes + ServiceMesh 的云原生微服务架构

微服务 2.0 更多的注重服务的治理，2.0 阶段，微服务架构引入了 ServiceMesh（服务网格）的概念通过 SideCar(侧边车)的方式实现一些对应用无侵入的管理，

使得服务治理更加通用，借助 Service Mesh 可以更方便的管理服务间调用，更好的做流量控制等

追本溯源，服务网格从无到有可分为三个演化阶段（参见下图）。

第一个阶段，每个服务各显神通，自行处理对外通讯。

第二个阶段，所有服务使用统一的类库进行通讯。

第三个阶段，服务不再关心通讯细节，统统交给边车进程，就像在TCP/IP协议中，应用层只需把要传输的内容告诉TCP层，由TCP层负责将所有内容原封不动的送达目的端，整个过程中应用层并不需要关心实际传输过程中的任何细节。

Kubernetes 让微服务更简单，使用 Kubernetes 就无需关注服务的注册发现了，服务部署自动服务注册发现，无需在应用代码里向服务中心注册，kubernetes 让微服务的缩放更为简单，你也可以配置根据应用的 CPU 等指数来实现应用的动态扩容，压力大的时候自动扩容，增加节点，压力小的时候自动缩放，减少服务节点。