曾宪杰《大型网站系统与JAVA中间件实践》阅读记录

这本书适合对于分布式不了解 不明白概念的人 入手
并没有将源码 将原理 只是将整体的架构用通俗的语言讲解一遍
有点像一位老大哥在一个下午拿着图纸给你讲讲画画 什么叫分布式
最后终于懂了 整体的概念 为什么要这样设 有了整体的思想 和一些名词的认知
看似简单 但是作者精炼的总结 和专业的解释 像教科书一样精确 不至于拖沓也不至于不清晰 非常棒

第一章 分布式系统介绍

分布式定义：在网络上 多个节点组成的一个系统，各节点之间通过消息传递互相通信 并且协调行动完成系列操作
这一章将分布式的产生背景 从硬件到软件

背景阐述单核到多核的年代
单线程-》单进程多线程-》多线程-》多机多线程
线程和进程的区别
结构上：进程由线程组成
通信：线程notify wait 进程之间通信需要事件通知/回调
对共享资源操作：线程sychronized 进程互斥锁（分布式）
通信共享资源：线程在同一进程内本就共享 进程需要对资源进行序列化反序列化才可以多进程共享

网络知识
NIO BIO AIO

节点与节点之间调用
服务请求者 服务提供者 之间的调用 在集群中锁定服务提供者
可以使用以下三种
1.负载均衡硬件
2.LVS 属于中间代理 请求打到代理 代理打到服务 影响大
3.名称服务发现 负责收集服务提供者的地址 服务请求者获取到地址后自行负载均衡打到对应Server
4.规则服务器 服务请求者去决定逻辑

nameserver是请求发起方和 请求处理方直连的模式
负载均衡 LVS都成为了必经之路 甚至如果硬件坏了 整体都坏了

服务请求端 请求域名DNS DNS是全球的根服务器 会根据域名响应找到合适的服务器 会快速地选择一台WEB SERVER请求服务端响应

• 客户端调用哪台服务器 可以使用使用DNS来帮助选择 也可以使用负载均衡打到那台服务器是那台
  
  请求qq域名 会找到一台DNS DNS去找到比如com下的服务提供者
  服务器有多台 可以选择负载均衡算法

第二章 网站架构演进过程

上一章在说随着硬件的发展 随着需求的升级 多机多进程 以及 服务提供者 服务请求者 等节点直接的调用 都是刚需

大型网站的定义： 高并发量+海量数据

这一章主要是介绍 引进分布式系统 会带来什么问题 以及分布式系统解决了那些问题

服务调用者 使用服务提供者

可以采用 DNS 或者DNS+负载均衡硬件

session 无法保证会话每一次都打到那台服务器上

有三种措施解决

数据库读写分离

读写分离 主要是增加了一个读 源
搜索引擎 读库 都是在增加一个读源 减少主库读写操作的压力
缓存也相当于一种读源 缓解压力
甚至使用分布式文件系统 代替关系型数据库存储 来降低主库的压力

拆分数据库 垂直拆分 水平拆分

• 垂直拆分 根据业务拆分 把订单业务 和 商品业务 的数据完全分离开
  但对于很多的跨业务的关联关系 或者事物 怎么解决
• 水平拆分 把一个表拆到两个数据库里
  1/ 操作数据的时候需要提前路由找到数据所在的库
  2/分库之后 无法保证主键不重复 A库用户张三id 为1 B库用户李四ID为1
  3/分库之后 要查询多个数据库 如果查询数据量很大 还要分页 处理麻烦

应用拆分

web系统管理交互
服务中心进行公共代码的维护 数据库的链接 业务核心的编写
数据库

第四章 服务框架的设计和实现

分布式系统的定义是 节点之间通过消息互相通信协调完成系列操作
节点之间互相通信 分布式系统依靠消息中间件来进行 消息的发送和接受

WEB层 和 应用服务器之间有 服务框架 负责 分布式集群之间的通信 的服务治理

中间件 负责 支持分布式服务器之间的信息传递
应用服务器和 数据库之间 分布式数据层 让应用层便捷的访问分库分表的数据库节点- 服务框架指的是 在WEB和 应用服务器之间多了一层 服务框架
用于服务治理 远程调用 比如DUBBO SPRINGCLOUD

• 之前是WEB直接调用SERVICE应用服务器 随着服务器增多
  WEB的调用错综复杂 应用功能也有冗余和重复
  应用集中功能向外提供服务 WEB调用应用服务器 先进过服务框架

调用发起
寻址 路由
编码 适配网络协议/序列化
通信 网络传输
协议解析/反序列化
返回结果

• 服务提供者 如何调用具体的实现类来处理请求者的操作
  、服务提供者启动后 服务框架完成服务注册并开始监听 解析请求参数（反序列化）
  请求参数中包含 服务名称 服务版本号 调用服务器的方法名 参数
  、 服务提供者在本地 的 服务注册表中找到对应的机器 采用反射调用方法
  将返回结果序列化 二进制编码返回

寻址路由

基础路由 获得注册表负载均衡的路由

服务架构提供给服务调用者 服务注册查找中心 调用者从服务框架中获取服务提供者的列表 调用者会先去本地查找可用地址 服务注册中心感知到地址变化后会消息通知 服务调用者

服务调用者 获取列表后 自己选择负载均衡的方式

根据接口 方法 参数的路由

服务调用者集群有自己的接口路由规则
和服务提供者地址取交集 再进行负载均衡 锁定服务提供者机器

根据接口路由 如果接口A的方法耗时比较长 线程资源是有限的 如果大部分的线程都去运行接口A的方法 那其他耗时短的接口 比如接口B的请求就阻塞了
所以可以将接口A的方法都路由到一台机器 接口B路由到另一台 这样接口B就可以快速的处理 不用等待

编码 适配协议 序列化

把请求参数 变为服务提供者可以解析 传输的数据
网络通信协议 HTTP
服务调用协议
序列化方式 JSON XMLF

网络传输

NIO \

服务治理

服务治理是 系统采用服务框架后 为服务化保驾护航的功能集合
服务治理 包括 管理服务 查看服务
管理比如告警 上线下线所容扩容
查看比如版本号 统计容量，质量等查看对比的一个功能

第六章 消息中间件

互联网的中间大致分为以下三类

• 远程调用 访问中间件
• 数据库中间
• 消息中间件

保证业务操作和消息中间件一致性的解决方案

介绍背景： 服务调用者的一次请求 可能包含多个业务线的调用
比如登陆 发短信/打电话/发邮件 多个业务线 彼此分隔
登陆是无需关心发短信是否成功的 发邮件是否成功 登陆只关心密码 验证码
登陆无需关注其余依赖他的业务如何操作 是否成功
所以为了 解耦 和 异步操作 登陆的结果发送到中间件
其余的依赖登陆结果的业务 监听中间件 监听登陆的结果 自行操作

简单的消息中间件架构

产生问题1： 怎样保证业务操作和消息中间件发送消息的一致性

这边登陆成功了 那边消息中间件没有收到登陆成功的消息 然后也不生成一条向外发送的消息！导致短信业务无法继续操作

核心问题 确保消息中间件生成了消息 确保消息所描述的状态是业务操作的真实结果

保证消息和业务一致

业务操作成功 消息要入库成功 这就叫做一致性

消息中间件的消息库和业务库进行结合 增加一个新的字段 消息状态 messagestatus
0-待处理 1-消息待发送 2-消息发送成功 3-消息发送失败（失败就删除该消息）

我们的目的是确保业务操作无论失败成功 + 网络延迟 错误 等所有的异常情况都能够让消息中间件有记录 而且和业务的状态保持一致

• 但是从第一步开始如果业务发消息让生成message就出问题 我们无法让中间件有存储DB 也无法同步记录业务的状态
• 消息中间件返回插入DB成功 业务处理成功了返回业务结果时异常了 此时DB消息状态为待处理 没有同步为成功
• 消息中间件返回插入DB成功 业务处理失败了返回业务结果时异常了 此时DB消息状态为待处理 没有同步为失败 并删除消息

好在我们多生成了一个字段 可以用来标识业务的状态 可以反向做操作
轮询访消息那张表 访问这个字段 对于待处理 的去业务中看是否还要再次做补偿任务 并且更新message status字段值

有消息表合同签章表 由业务表合同申请表
类似合同签章表 如果看到合同状态为处理中 我们就去扫库扫表 看合同申请表中那个申请是失败的 帮助重新补偿

这样一定程度的又帮助业务和中间件消息的一致 增加了一层消息中间件回复业务的过程 却正向反向的确保了业务一致性

业务与中间价强依赖 耦合太高

业务在确保DB中消息中间件形成message消息 的情况下才会发起业务
如果消息中间级出问题 业务在有资源完成请求也无法进行

为了把耦合度降低 很粗暴的方式就是由业务掌管所有的流程

消息 发送 调度 以及消息中间级反向的 重发 都在业务里调
中间件和数据库的频繁交互也删除 由业务来
中间件只负责掌管消息

消息表和业务表 不在同一个库中 业务无法在一个事物里同时更改
所以把他们放在同一个库中 放在业务的本地库

消息中间件出问题了 要保障消息入DB
优点1：不用等消息中间件存入DB之后再返回给业务
导致这个返回给业务出问题
优点2：新增了一个功能
让业务写message入库 再通知消息中间件取这个message发送 消息中间件不用访问数据库了 减少了步骤 又一次减少错误发生的可能