Welcome to 9ilk's Code World

       

(๑•́ ₃ •̀๑) 个人主页:        9ilk

(๑•́ ₃ •̀๑) 文章专栏：     Docker 

---

单机架构

   所谓单机架构是指只有一个服务器工作，它既负载应用服务又负责数据库服务。在用户量和数据量较小的场景下，单机架构是可以支持较高的并发和较大的数据存储的，而且部署简单成本低，但是如果业务持续增长，并发量提高，是会达到性能瓶颈的，数据库和应用服务存在严重的资源竞争。

应用数据分离架构

        在单机架构的问题上，我们一般会有两个方向的解决方案。一个是节流，在软件上优化，通过性能测试，判断哪个环节导致性能下降再去对症下药；另一种方式是开源，引入更多的硬件资源，我们对一台主机引入更多的资源，单台主机引入的硬件资源达到上限，就需要引入多台主机了，一旦引入多台主机就可以称这样的系统为"分布式系统"。分布式系统会导致系统的复杂度大大提高，出现问题概率更大，因此是无奈之举。

        和之前架构的主要区别在于将数据库服务独立部署在同一个数据中心的其他服务器上，应用服务通过网络访问数据，这样可以对不同服务（应用/数据）给不同主机配备不同的硬件资源，可以最小代价的提高系统的承载能力。同时应用和数据解耦，不会因为应用而把数据库搞坏，有一定的容灾能力。缺点是硬件成本也是会一定变高的，而且单个应用仍然不足以支持海量并发请求，高并发的时候站点响应变慢。

应用服务集群架构

        该架构在之前架构基础上引入更多的应用服务节点，用户的请求会先到达负载均衡器，负载均衡器通过选择的负载均衡算法（比如RR轮转、能者多劳算法、一致性哈希散列等）将请求分摊到不同的应用服务节点。一般情况，负载均衡器对于请求量的承担能力是要远超过应用服务器的，而且负载均衡器要完成的是任务的分配不是执行，压力会小点，但是也有可能出现请求量大到负载均衡器扛不住的情况，那时需要引入更多的负载均衡器。

        这种架构确实能处理较高的请求量，同时应用服务具备一定的高可用性，支持横向扩展，但是随之数据服务器容易达到性能瓶颈，无法应对海量数据请求。

读写分离架构

        数据库为了保证数据的一致性，因此不能盲目像应用服务一样扩展。采取的解决方案是一台数据库作为主数据库，主要进行数据库的写入和读取操作，而其他数据库作为从数据库，进行数据库的读取操作，主数据库写入之后往从数据库同步更新，这样子数据库的读请求就能被其他数据库分担，实际场景中读请求是比写居多的，而写操作也得到一定提升，同时一个从数据库挂了，还可以从其他数据库读。

        这种架构虽然分摊了数据库的读请求，但是需要考虑写之后同步的时延成本，此时可能会导致主从数据库数据不一致。同时实际场景中热点数据是会被频繁读取的，因此可能会达到数据库的负载加大，毕竟数据库是写磁盘，IO效率不高。

冷热分离架构

        根据二八原则，20%的数据能够支持80%的访问量，因此该架构引入了缓存，缓存虽小但快，应用服务器读取数据的时候先读取缓存，缓存中有数据则直接取走，不存在才从从数据库中读取，这能大幅度降低对数据库的访问请求，性能提升，有缓存服务器帮数据库服务器负重前行。

        但是需要考虑的问题是，应用程序修改主数据库的时候，也得同步修改缓存，此时可能修改失败，进一步造成缓存击穿、缓存失效、缓存雪崩等问题，这是引入缓存服务器需要考虑带来的后果。同时如果数据量进一步增大，一台主机可能存不下这么多数据，即单库/单表体量太大，此时需要更多主机存储，把数据库进一步拆分，即"分库分表"。

垂直分库架构

        本来一个数据库服务器，这个数据库服务器上有多个数据库(指的是逻辑上的数据库集合 create database)，现在可以引入多个数据库服务器，每个数据库服务器存储一个或一部分数据库，这解决的是数据存储问题而不是并发问题。

分库分表： 通过将大表或大数据库拆分为多个小的库或表，从而提高数据库的处理能力。分库指的是将数据分布到不同的数据库中；分表指的是将单个大表拆分成多个小表（通常按某些规则，如按时间、ID等拆分）。

分布式数据库 : 数据分散存储在多个物理节点（服务器）上，通过网络连接在一起的数据库系统

  这种架构能使数据库吞吐量大幅提升，不再是瓶颈，但是跨库join、分布式事务等问题，这些需要对应的去进行解决，最主要的问题是应用的代码整体耦合在一起，修改一行代码需要整体重新发布，此时需要引入微服务架构。

微服务架构

       之前应用服务器一个服务器内部做了很多业务，这会导致一个服务器的代码越来越复杂，为了更方便代码的维护，此时就可以将这样一个复杂服务器拆分成多个功能更单一更小的服务器，即微服务，这会导致服务器的种类和数量增加。

        微服务的出现主要是解决人的问题，毕竟一个服务器变复杂，就需要更多人维护，人变多就需要配套进行管理，组织好这些人，就需要划分好组织结构，分成多组，每个组按照功能拆分成多组微服务，相互之间独立升级迭代，单个应用职责更清晰。

        微服务虽方便了代码的维护，灵活性容错性高，支持多种编程语言，但与之对应，随着业务不断发展，应用和服务部署会变得越来越复杂，运维复杂度高，这需要引入容器编排解决。

容器编排架构

该种架构下，可以借助容器化技术(如docker)将应用/服务可以打包为镜像，通过容器编排工具(如k8s)来动态分发和部署镜像，服务以容器化方式运行，容器之间已经打包好所需要的环境/依赖信息 , 容器之间相互隔离。

    这样每一个微服务打包到容器之中，相互协作来完成系统功能，通过容器编排工具完成部署运维，一键式部署，工作量减小，这无疑使得部署、运维简单快速，而且容器之间隔离性好（文件系统、网络等互相隔离），同时轻松支持滚动更新(版本除了升级还能回退)。

小结

1. 架构必须这么演进吗？

看团队技术栈的储备。

2. 架构必须是这么几个吗？

不是，我们可以认为分库是一个架构，分表是一个架构，分布式数据库是一个架构...

3. 如何决策是否演进？

结合实际业务，团队，成本等，满足业务需求即可。

4. Docker的核心作用？

1. 完成核心打包
2. 容器化的运行。