单体到分布式到微服务

本文主要是介绍单体到分布式到微服务，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

业务驱动着技术发展是亘古不变的道理。最开始的时候，业务量少、复杂度低，采取的技术也相对简单，能够基本满足用户对功能的需求。随着 IT 信息化的普及，更多交易被放到了网络上，增加的信息量和频繁的业务访问就变成了需要解决的问题。因此，逐渐产生了缓存、集群等技术手段，同时对业务扩展性和伸缩性的要求也变得越来越高。高并发、高可用、可伸缩、可扩展、够安全一直都是架构设计所追求的目标。下面我们来看一下架构设计经历了哪些阶段，以及每个阶段分别解决了哪些问题，又引出了哪些新问题。

步骤

应用与数据一体模式：

1、访问人数有限
2、基本没有高并发的特性
3、部署成本较低
4、单个应用和数据库在单体服务器上
在这里插入图片描述

应用与数据分离模式：

1、应用和数据库都要占用一台机器的资源，当前这台机器性能出现问题。
2、业务应用和数据存储分开，放在两台机器上了在这里插入图片描述

缓存与性能的提升

1、用户对某些数据的请求量特别大，热点数据
2、受到数据库io性能的影响
3、客户端服务器，应用服务器本地缓存，缓存服务器缓存
在这里插入图片描述

服务器集群并发处理

1、并发问题：并发就是指多个用户同时请求应用服务器。如果说原来的系统面对的只是大数据量，那么现在就需要面对多个用户同时请求
2、银行柜台
在这里插入图片描述

数据库读写分离

1、数据库写的时候会加锁很慢，读的时候很快，写的时候会排队。写影响读了。读的操作多。

2、主库用来写操作，通过binlog形式将数据更新到从库中。
在这里插入图片描述

反向代理和CDN

1、人们对网络安全和用户体验的要求也越来越高，索引引入好反向代理服务器
在这里插入图片描述
2、客户端就可以从离自己最近的网络节点获取资源，大大提升了用户体验和传输效率

在这里插入图片描述
CDN 的加入明显加快了用户访问应用服务器的速度，同时减轻了应用服务器的压力，原来必须直接访问应用服务器的请求，现在不需要经过层层网络，只要找到最近的网络节点就可以获取资源。但从请求资源的角度来看，这种方式也有局限性，即它只对静态资源起作用，而且需要定时对 CDN 服务器进行资源更新。反向代理和 CDN 的加入解决了安全性、可用性和高性能的问题。

分布式数据库与分库分表

在这里插入图片描述
● 对于数据表来说，当表中包含的记录过多时，可将其分成多张表来存储。例如，有 1000 万个会员记录，既可以将其分成两个 500 万，分别放到两张表中存储，也可以按照业务对表中的列进行分割，把表中的某些列放到其他表中存储，然后通过外键关联到主表。注意被分割出去的列通常是不经常访问的数据。● 对于数据库来说，每个数据库能够承受的最大连接数和连接池是有上限的。为了提高数据访问效率，会根据业务需求对数据库进行分割，让不同的业务访问不同的数据库。当然，也可以将相同业务的不同数据放到不同的数据库中存储。

业务拆分

1、解决了数据存储问题
2、应用分开部署，之前是一个应用分开部署，将一个应用拆成多个部署到不同非服务器中。

在这里插入图片描述

分布式和微服务

分布式：拆了就行。

微服务：细粒度的垂直拆分。

● 拆分目的不同：提出分布式设计是为了解决单体应用资源有限的问题，一台服务器无法支撑更多的用户访问，因此将一个应用拆解成不同的部分，然后分别部署到不同服务器上，从而分担高并发的压力。微服务是对服务组件进行精细化，目的是更好地解耦，让服务之间通过组合实现高性能、高可用、可伸缩、可扩展。

● 拆分方式不同：分布式服务架构将系统按照业务和技术分类进行拆分，目的是让拆分后的服务负载原来单一服务的业务。微服务则是在分布式的基础上进行更细的拆分，它将服务拆成更小的模块，不仅更专业化，分工也更为精细，并且每个小模块都能独立运行。● 部署方式不同：分布式架构将服务拆分以后，通常会把拆分后的各部分部署到不同服务器上。而微服务既可以将不同的服务模块部署到不同服务器上，也可以在一台服务器上部署多个微服务或者同一个微服务的多个备份，并且多使用容器的方式部署。
在这里插入图片描述