架构师学习笔记(一)

第一章 架构师设计篇

 为什么一个测试工程师要学习架构？

测试人员也会经常参与需求设计和方案讨论，这方面的知识可以提高自己的对整体方案的理解，能够对别人的方案提出更好的值得思考的问题。

1.1 架构师的能力

1.  架构完整解决方案

• 具体业务场景
• 架构如何选型
• 架构如何设计
• 架构如何折中
• 架构上线问题如何解决
  • Feed系统
    • PUSH
    • PULL

  推荐书籍 ：《深入分布式缓存》   

  分析朋友圈和微博 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