网站架构变迁

网站架构变迁

Intro

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

单服务器

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

这个阶段的服务器上除了 Web 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 等指数来实现应用的动态扩容，压力大的时候自动扩容，增长节点，压力小的时候自动缩放，减小服务节点。

More

一切脱离业务的架构设计，都是耍流氓。

架构不是一蹴而就的，架构是演化出来的。

笔者经验有限，文中若是有错误，还望指出，万分感谢

Reference

• https://www.zhihu.com/question/37808426
• https://www.zhihu.com/question/65502802
• https://juejin.im/entry/5bd6846ee51d452f7110cfeb
• https://zhuanlan.zhihu.com/p/35179248
• https://www.infoq.cn/article/microservices-post-kubernetes