架构演进

架构演进

一.开发环境 & 生产环境

1.1 开发环境

平时在写代码时, 大多都在是Win10/Win7/Mac, 这些系统统称为开发环境, 为了更高效的开发App, 会安装很多软件.

会导致OS不安全, 稳定性降低

 

1.2 生产环境

在生产环境中, OS不会采用 Win10/Mac , 这类相对不安全的OS , 生产环境是要面向全体 User,

一般会采用专业的 OS,

这类OS市面上使用的都是基于 Linux 的OS, 也有Win版的服务器OS

Tips1, Learn how to use Linux

 

二.WEB1.0 & WEB 2.0 阶段

2.1 WEB1.0 时期

在WEB1.0时期, 由于带宽限制. 这时期项目内容和用户数量相对较少.

甚至部分项目不需要对外开放, 对安全和稳定性需求也不太高.

单体架构足以应对.

 

2.2 WEB2.0 时期

随之到来的WEB2.0 时期, 实现了拨号上网, 带宽大大提升, 用户量页提升, 门户网站开始活跃

此时项目就开始需要考虑安全性和稳定性了.

在基于 1.0 时期的单体架构时, 无法满足当前对项目需求

在单体架构的基础上搭建集群.

在搭建集群后, 可以有效提升项目稳定性, 增加并发量.

2.3 集群搭建后问题

1. 解决平均分发用户请求问题, 缓解服务器因用户量剧增的压力

2. 编写项目时, 用户 log 成功后, 会将用户标识存储到 session 中. 在搭建集群后的数据共享问题.

3. 当数据量过于庞大, 如何避免去直接查询数据库, 提升查询效率.

4. 针对大家在搜索数据时, where content like '%{xxx}%' 如何解决?

5. ....

针对上述问题, 需要用到三门技术.

Nginx - 解决用户请求平均分发

Redis - 解决数据共享并实现缓存问题

ElasticSearch - 解决搜索数据的功能.

三.垂直架构

比如项目包含了三个模块: 用户模块, 商品模块, 订单模块

商品模块压力过大, 一般最直接有效的方式就是搭建集群. 在单体架构的基础上搭建, 效果不太理想

随着版本更迭, 项目功能愈发丰富, 最严重会导致项目无法启动

单体架构特征: 低内聚, 高耦合.

为了解决上诉问题, 研究出垂直架构

上图所示:

服务器1: 只做用户模块; 服务器2: 只做商品模块; 服务器3: 只做订单模块;

服务器2中可以搭建多个商品模块应用

四.分布式架构

4.1 项目迭代

随着项目不断迭代, 新老功能之间需要相互交互, 服务器和服务器之间需要通讯.

项目一般分为三层, Controller , Service , DAO.

导致程序变慢的主要原因: Service和DAO的交互. [模块直接访问数据库, 因后期数据量过大, 直接数据查询较慢]

在搭建集群时, 确实针对三层都搭建集群, 效果不太理想.

架构从垂直架构演变为分布式架构.

分布式架构落地的技术.

国内通讯的方式有两种:

Dubbo [阿里系] RPC

SpringCloud HTTP

五.分布式架构常见问题

5.1 服务之间的异步通讯

使用分布式架构之后, 服务之间的通讯都是同步的.

在一些非核心业务的功能, 希望能够实现异步通讯.

为了实现服务之间的异步通讯, 需要学习 MQ-RabbitMQ

 

 

5.2 服务之间通讯地址的维护

由于服务量的增加, 由于每个服务的访问地址都是同一个.

访问方式__ 协议://地址:端口 __

由于模块数量繁多, 并且模块搭建的集群数量增加, 会导致其他模块需要维护各种 ip 地址等信息,

导致项目的维护性极低, 耦合性变高, 更难以实现负载均衡功能.

需要使用一个技术来解决当前问题:

Eureka 注册中心帮助我们管理服务信息.

Robbin 可以帮助我们实现 服务 之间的负载均衡

这里是Controller 模块去找 Eureka 主动去要已注册服务的地址.不是直接访问

 

5.3 服务降级

在上述的架构中, 如果说订单模块出现问题.

只要涉及到订单模块的功能, 全部无法使用.

可能会导致服务器提供的线程池耗尽, 给用户提示都无法做到.

为了解决上述问题, 使用 Hystrix 处理.

Hystrix 提供线程池隔离方式, 避免服务器线程池耗尽, 在一个服务无法使用时, 可以提供断路器的方式来解决.

Eureka, Robbin, Hystrix 都是 SpringCloud 中的组件.

5.4 海量数据

海量数据会导致数据库无法存储全部的内容.

即便数据库可以存储海量的数据, 在查询数据时, 数据库的响应时及其缓慢.

在用户高并发的情况下, 数据库有时页无法承受住

为了解决上述问题, 可以基于 MyCat 实现数据库的分库分表.

六.微服务架构

6.1 微服务架构

虽然已经将每个模块独立开发,

但每个模块都有自己最大的压力, 比如商品模块压力最大问题: 商品的查询.

针对单独模块, 再次拆分项目的方式就可以称之为微服务架构, 微服务架构也是分布式架构

例如: 将商品模块的查询商品功能, 单独拆分出来.

6.2 模块过多,运维成本上升

为了解决模块过多, 运维成本增加的问题

采用Docker容器化技术来帮助我们实现管理.

后期在学习时, 也需要安装大量软件. 可以使用Docker来安装软件.

6.3 分布式架构下的其他问题

分布式架构解决问题的同时, 也带来一些问题

1. 分布式事务:

   最传统的操作事务的方式, 是通过Connection 链接对象的方式操作, Spring也提供了声明式事务的操作.

   为了解决事务的问题, 后续会使用到 RabbitMQ 或者 LCN 方式来解决

2. 分布式锁:

   传统锁方式, Synchronized 或 Lock 锁, 在分布式环境下, 传统的锁是没有效果的. 为了解决锁的问题, 后续会使用到 Redis 或者 Zookeeper来解决.

3. 分布式任务:

   在传统定时任务下, 由于分布式环境问题, 可能会造成任务重复执行, 一个比较大的任务, 需要拆分.

   为了解决类似问题, 后续会使用到 Redis + Quartz 或者 Elastic-Job

4.