第一章 架构师设计篇
为什么一个测试工程师要学习架构?
测试人员也会经常参与需求设计和方案讨论,这方面的知识可以提高自己的对整体方案的理解,能够对别人的方案提出更好的值得思考的问题。
1.1 架构师的能力
1. 架构完整解决方案
- 具体业务场景
- 架构如何选型
- 架构如何设计
- 架构如何折中
- 架构上线问题如何解决
- Feed系统
- PUSH
- PULL
- Feed系统
推荐书籍 :《深入分布式缓存》
分析朋友圈和微博 Feed流系统的不同设计
2. 架构背后的哲学思考
- 为什么要这么设计
- 其他方案为啥不优雅
- 基于Redis实现分布式锁
Redis分布式锁只能解决99%的问题, redis分布式锁master不挂是没有问题的, 但是此时两个线程来申请锁,其中一个已经从master拿到锁了,另一个线程还没有拿到锁,这个时候master挂了,master没有同步锁到slave库,这个是时候slave变成master,另一个线程就会拿到锁,就会两个线程都拿到锁。
写有关CAP模型的文档;
参考文档 : https://blog.csdn.net/LucasLi2016/article/details/109687537
Redis模型 :AP模型 :保证可用性的
分布式锁 : CP模型 : 保证一致性的
1.2 互联网架构的演进
https://blog.csdn.net/chaoyuehu/article/details/90480592
互联网架构从简到繁的演进经历了单体架构-水平分层架构/SOA架构-微服务架构以及最新的service mesh的演进过程。如下图:
1.2.1 Monliths单体架构
【单体架构图】
【单体架构图演进】
优点 :业务场景简单,功能不复杂,研发人员较少,创业公司初期, 对性能要求非常苛刻(单服务没有微服务的网络开销)
缺点 : 系统耦合性高,技术选型单一 ,开发效率越来越低
解决 :
数据库存储量大的问题思路
- 拆分
- 垂直拆分(分库)
- 水平拆分(分表)
架构同理
- 垂直拆分方向(业务维度):
- 水平方向拆分 (功能维度):
1.2.2 水平分层架构
水平架构分层逻辑
- 水平方向物理分成多个独立进程
- 网关层
- 业务逻辑层
- 数据访问层
- 数据存储层
- 每层逻辑解耦
分离思想设计原则
- 展示服务与网关服务分离:
- 前后端分离的设计思想,后端服务返回的数据不做任何显示处理,例如时间戳,后端返回的应该UTC的时间戳,而不是具体的时间格式。
- 网关服务与逻辑服务分离:
- 网关服务负责请求的路由,鉴权,流控 ,降级,熔断等,
- 逻辑服务与数据服务分离:
- 通过数据服务层可以更方便的操作数据库,还有开一个好处是其他服务也可以直接调用数据访问层,获取数据。
每层服务的功能
网关层功能
- 功能1 :请求鉴权
- 发布商品,登录鉴权
- 功能2 :数据完整性检查
- 数据包 : 定长的Header + 变长Body, Header有可能有特定的head,检查有没有填写,不检查具体值
- 功能3:协议转换
- Json->HashMap
- Json->Protobuf/Thrift
- 功能4 :路由转发
- 根据实际业务类型转发到不同的业务逻辑层
- 服务治理
- 限流,降级,熔断等
网关服务的技术选型: Zuul(BIO)--推荐 ,Spring Cloud Gateway (Netty-NIO), Nginx(epoll-NIO) , Tyk (Go语言 AIO)
业务逻辑层
- 登录业务
- 发布业务
- 具体业务
数据访问层
- 功能1:CRUD
- 业务逻辑的增删改查接口,优秀实践 : 代码不升级,通过配置数据库表,查询条件,返回数据。抽象数据层。
- 功能2:ORM
- Mybatis3
- 功能3:Sharding -- 最难搞
- 分库分表 Sharding-JDBC
- 功能4:屏蔽底层存储差异性
- Mysql/MongoDB
- Redis
数据库发展: RDBMS(oracle/msyql) -->NoSql(MongoDB)-->NewSql (不需要关注分库分表)
同步架构与异步架构
上游服务与下游服务之间加入MQ,同步架构可变成异步架构
上游服务通过下游服务写DB为什么比上游写MQ慢?
都是写磁盘,写DB与写MQ比MQ慢的原因, DB是随机写,MQ是顺序写,追加的。
异步架构
- 目的:提升吞吐量
- 异步手段 :消息队列
- 使用场景: 请求类型 , 是不是所有请求都能用MQ?
- 查询请求:查询请求为保证一致性,最好不用MQ,
- 写请求:写请求可以用MQ,但不是所有写请求都可以用MQ,根据一致性的要求强的不能用MQ,例如充值场景。一致性要求低的,可以使用。
水平分层架构的分层级别
分层过多:
- 请求路径变长
- 平均响应延迟变高
- 定位问题复杂
- 运维成本增加
分层过少:
- 单体架构
分层适中:
- 网关层
- 异步消息队列层
- 业务逻辑层
- 数据访问层
- 数据存储层
分层架构的缺点
缺点: 每个层的粒度比较粗
1.2.3 面向服务架构
SOA(Service Oriented Architecture)“面向服务的架构”: 他是一种设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用,而非采用进程内调用的方式。
SOA面向服务架构图
缺点:
- 业务垂直方向拆分,每个服务还是一个单体服务
- 对ESB严重依赖
- 数据的一致性问题
1.2.4 微服务架构
知乎经典回答 : https://www.zhihu.com/question/65502802
微服务架构:
- 需求层间 :为了满足某种需求(性能需求,数据一致性需求),需要采用微服务架构,没必要为了微服务而微服务。
- 组织架构:组织架构适合微服务开发,组织是以微服务的作为一个管理团队运作。
- 目的 : 快速迭代,持续交付,节省成本。
微服务之间的需要调用如何处理 ?
A服务的接口需要B服务的接口数据,
- 调用方式1 : 直接调用B服务的接口,可以直接调用,也可以通过网关路由调用,
- 调用方式2: 直接调用B的数据访问层,可以获得数据.
两种方式的比较 : 如果有数据访问层,调用获取数据,这种最优,因为同一层之间的服务调用,会出现调用依赖,而且最终会形成网格调用,项目发展越久,之间的调用会越来越复杂,B服务如果不稳定,也会影响A的稳定性,所以直接调用数据访问层会比较好一点。
微服务架构与SOA架构的区别
https://blog.csdn.net/zpoison/article/details/80729052