共计 2723 个字符，预计需要花费 7 分钟才能阅读完成。
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 等指数来实现利用的动静扩容，压力大的时候主动扩容，减少节点，压力小的时候主动缩放，缩小服务节点。
More#
所有脱离业务的架构设计，都是耍流氓。
架构不是欲速不达的，架构是演变进去的。
如果本文对你有帮忙，别忘记给我个 3 连，点赞，转发，评论，
咱们下期见！答案获取形式：已赞 已评 已关~
学习更多 JAVA 常识与技巧，关注与私信博主（666）