SpringBoot 学习—4

架构选型

前后端分离

架构演变

系统架构并非刚开始就很完善，而是随着用户访问和业务增加而慢慢改善的。

Tomcat：Web服务器。

以淘宝为例，一开始也是单一服务的架构，此时，所有的服务器资源部署在一台服务器上，将Tomcat、数据库和资源文件部署在一台服务器上面。这种成为 all in one。优点：开发成本低，运行成本低。但当用户量增加时，应用服务器会抢占服务器资源，导致整个服务宕机。

第一次优化方案：

将服务器资源分开放在几台服务器上，分担压力。

资源服务器一般小的架构会付费存储在其他的地方。
当用户量再次出现瓶颈时，出现在应用服务器和数据库服务器上，

第二次优化：

应用层

会多加几台服务器，进行一个水平的扩展，组成应用服务器。对于用户来说，访问时使用的都是统一的一个域名，但我们的不同的服务器肯定时不同的IP，所以，需要在用户和服务器之间加一个中间层，一般选用负载均衡，通过负载均衡分发到不同的服务器上。这是在应用服务器上做的一个演变。

数据库层

对于高频的数据访问，希望它不要这么频繁的访问数据库，——>利用分布式的缓存服务器。
对于一些只有在秒杀时用到的数据，且这些数据访问量是非常大的，那可以将这些数据放在缓存里面，为数据库降低压力，当缓存中没有时，再去访问数据库。

但是，缓存也不能存储所有的数据，当数据量大到再次击穿数据库时，此时单台数据库无法支撑，需要多台数据库，将数据库进行读写分离操作，一台用于读操作，一台用于写操作，使用同步工具进行数据的同步。

但是最好呢，还是给它集群化，

应用层的剥离（前后端的分离）

前端：只负责如何更好的进行人机交互，关注业务流程，。美观。消耗内存和带宽。
后端：只负责如何更高效、稳定的跟计算机打交道。关注算法数据、运算逻辑。扩展性、可用性、性能。只关注咋有效的消耗CPU即可。

应用的拆分

大应用拆成小应用

写在最后：任何一个架构，一开始都不是完美的，都是随着用户量增加，业务功能增加，慢慢演化，慢慢增加我们的高性能、高并发、安全性、缓存、、、、但是我们要开发一个应用，一定要有一个最基础的起步架构，前后端分离对当前微服务当道的架构是最好的。将前后端分离作为切入点，后续可以轻松开启微服务改造之旅。