互联网架构发展流程，从单体到微服务

最新推荐文章于 2022-06-21 16:52:21 发布

同行直呼被骗

最新推荐文章于 2022-06-21 16:52:21 发布

阅读量700

点赞数 2

本文链接：https://blog.csdn.net/weixin_43031156/article/details/108297099

版权

这里写目录标题

互联网架构发展流程，从单体到微服务

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

在这里插入图片描述

一、单一应用架构

通俗理解：以一个应用为单位部署在一个或者多个服务器上面
所有的模块和代码都放在一起。技术不分层，这是互联网最早的架构，也是互联网发展的最早时期，所有的代码和业务都放在JSP里面，比如，JSP里面就有sql标签。
在这里插入图片描述
优点：
开发和维护简单，像一些小医院里面的系统，使用量少，业务量和逻辑简单，满足基本的功能即可。开发这样的系统是，几个人即可完成。像这样的系统就很适合这样的架构。

缺点：
1、不具备维护性：如果是一个稍微大一点的系统时，维护起来就特别的吃力，因为所有的东西都写在了JSP页面中。
2、容错性差：容错性（指系统在发生故障时仍然能够运行的能力），因为所有的东西都写在JSP里面，当发生异常的时候，用户可能可以看到异常信息。一些的异常可能会导致整个服务的宕机。

all in one产生的问题解决方案：
1、分层开发（提高可维护性），三层设计模式。
2、MVC设计模式。
3、服务器分离部署(代码和数据库放在不同的服务器上)。’
在这里插入图片描述
特点：
1、MVC分层提高了维护性，解决了容错性问题。
2、数据库和项目分离部署。

但是随着用户访问量的增加，MVC需要解决三高问题（高并发，高可用，高性能）
因此有了集群（统一业务部署在不同的服务器上）的解决方案：
在这里插入图片描述
特点：解决了高并发，高可用的问题
因为项目部署到不同的服务器上会有session不一致的问题。所以将所有服务器的session存到redis中。

数据库方面的优化：

随着系统的并发能力的提高，数据库的压力不断增大，所以数据库方面的架构也需要优化。
解决方案：1、读写分离 2、主从复制 3、分库分表

一、读写分离/主从复制：主从数据库之间进行数据同步，主数据库进行增删改操作，从数据库进行查操作。
引入全文检索，但是引入了读写分离也不能改变数据库对大数据量查询效率慢的问题。对模糊查询也不是特别的优秀。针对这个问题引入了全文检索服务器功能。
引入缓存，随着数据量的进一步增加，数据库压力进一步增大，所以为数据库增加缓存（redis）应运而生。

二、分库分表：引入mycat，随着时间的增加，数据表里面的数据持续增加。这样数据库的查询效率会随之降低。比如，一张表有一千条数据，另一张表有一百万条数据。这两张表的查询效率是不一样的。
数据库表水平/垂直拆分：
垂直：提高单表的查询能力，比如添加索引，sql语句优化。
user(id,name,age,birth,addr,idcard,height…)
按照热数据/冷数据拆分：
user(id,name,age,birth)
user_info(id,addr,idcard,heigth…)
水平：按照需求进行拆分，比如，中国联动，查询表可以按照省份拆分，这就大大减少了单表的数据量。用到mycat、sharing-jdbc、drds等中间件(中间件就是解决方案)。
在这里插入图片描述
单体架构总结：
产生的问题：
1、不断增加服务器可以解决问题，但是不可以解决忙闲不均的问题，这样买服务器和维护服务器的成本就会过高。
2、可维护性差：因为是把单一应用复制粘贴到不同的服务器（通俗理解），需要修改，那么全部服务器上的应用都要做修改。
3、可扩展性差：要增加一个服务器，还需要配置环境。
4、协同开发不方便：修改同一个地方的代码会出现代码冲突的问题。
5、随着业务的增加需要不断地买服务器。

二、垂直应用架构

如何解决单体模式带来的问题呢？
按照功能把项目拆分成互不相干的独立的多个模块，然后独立部署。
在这里插入图片描述
解决问题：
1、维护性（如果要修改功能的话，直接修改某一个模块就可以了）
2、功能扩展（随着业务的增加，我们要增加一个功能的话，我们只需要增加一个web项目就可以了）
3、协同开发（不同的团队维护他们自己的web项目就可以）
4、部署内容（业务需求大的功能多部署几个，业务需求小的就少部署几个，解决了服务器忙闲不均的问题）

产生的新问题：
1、客户对前端页面需求经常更改。（但是页面和后台代码不相干，如果前端页面修改了，后台代码重新部署）
2、随着业务的增加，模块之间需要相互调用，比如，用户模块购买商品，需要调用支付模块，商品模块，物流模块。

三、分布式服务架构

将一个业务拆分成多个子业务部署在不同的服务器上（前后端分离）。就是把垂直模块拆分为前端和后台模块。
前后端分离：解决页面的不断修改问题。
RPC远程调用：解决模块之间的相互调用。
在这里插入图片描述
产生的新问题：
1、分布式事务：用户购买了一个商品，商品减一，物流加一，支付加一，但是他们在不同的服务器上，不在同一个事务内。
2、分布式锁问题：支付成功之后，商品减一，库存减一。
3、分布式session问题：在商品模块登录了，在支付模块怎么知道他登录了？
4、分布式日志问题

随着服务的增加，服务和服务之间的调用非常的频繁、混乱（如上图所示），其实一个服务根本不知道其他有什么服务。
当服务越来越多，容量的评估和小服务资源浪费的问题逐渐显现。比如，用户模块访问量小，部署了10台服务器，支付模块访问量多，部署了3台服务器。因为他们的访问量都是动态变化的。不知道他们的访问量是多少。

四、流动计算架构（SOA微服务）

SOA：面向服务架构
分布式服务治理中间件（dubbo/springcloud）：
在这里插入图片描述
这就解决了以上两个问题
问题一：服务之间频繁相互调用混乱，SpringCloud的Eureka实现服务的注册与发现，用户模块如果想调用商品模块就不用去找哪里有商品模块可以调用，只要注册Eureka，通过Eureka找到商品模块就可以了。
问题二：当服务越来越多，容量的评估和小服务资源浪费的问题逐渐显现。微服务通过统一的管理就可以知道各个服务之间的访问量。比如，springcloud的robbin实现服务之间的负载均衡。