思考架构怎么写 架构思想

总结

之前说过语言是基石头，语言通过系统设计思想形成系统，进而发展了语言，同时也发展了系统自身。系统为何有这么大的魅力，这个的关键就是系统的设计思想，系统设计思想分为架构思想和代码设计思想，一个是宏观的系统结构，一个是微观的实际开发，这里重几篇来讲解架构思想。有了架构思想对系统的理解设计如虎添翼。
当时是自己想到了这么个方向查了半天网上说的乱七八糟，后来终于发现了一本专门讲架构的书籍凤凰架构，因此就此根据此书讲解。

凤凰架构

下面的内容总结来说就是对于建设一个系统的架构会经历如下的演变，但是每次的演变都是包含上一次的内容，没有独立存在的架构体系，只是做了逻辑上分类，没有绝对的分类，他们之间还是相互依赖关系，不同的架构只是适合不同的场景，架构之间相互转换和依赖,没有被淘汰的架构，只有不适合的架构

单体系统到分布式系统的演进过程

单体架构

单体架构下，会做代码的逻辑分层，分为控制层，服务层，数据访问层，会做代码的分模块，这样做应用结构也是灵活的，称它为单体式应为即时分了模块还是一起运行在同一个进程，只是做开发的时候逻辑分开，一般网站开发使用这种开发方式就足够了。
具体落地实现：现在的一切单体应用

SOA,面向服务开发的分布式

SOA时代，开始拆分不同的模块到独立的进程进行运行,也可以放到不同的主机上运行，通过负载均衡路由之类的功能寻找服务，不同模块之间的交互使用中间件交流。这样做，不同的模块物理上可以单独维护了，主动停止一个服务，更新一个服务都不使得别的服务被迫停止，当然问题也存在就是逻辑上无法避免不影响其他系统，此外还存在服务治理等问题，随着服务的增多，服务之间的关系越难以管理。,所以对小型分布式架构来说是足够了
在这种思想下也催生了一些优秀的分布式架构的落地实现：比如主从复制，集群部署，负载均衡，注册中心等概念产品

微服务时代的分布式

• 微服务时代，重新思考了SOA时代服务治理存在的问题和分布式架构的服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理，等等，这些问题。重新提出了综合的解决方案，以增强服务的管理，服务之间的交互，服务扩展问题。
  具体落地实现：springcloud ,dubbo等服务治理框架
• 微服务时代的另一个重要的发展就是虚拟化技术软件，使用虚拟化技术，
• 首要目标是让软件分发部署过程从传统的发布安装包、靠人工部署转变为直接发布已经部署好的、包含整套运行环境的虚拟化镜像。
• 其次使用虚拟化技术来屏蔽底层的分布式系统，提供一个基于分布式系统的大型虚拟系统 ，也为分布式系统架构提供了解决方案，比下面的微服务网格

微服务服务网格

微服务通过软件设计的形式完成了分布式系统的架构设计，但是这很多是内容是为了服务治理而产生的，比如注册中心，路由注册等待，这部分代码虽然通过良好的封装在使用过程中已经体会不到它们的沉重了，但是他们还是真是存在的，部署打包一样也会抱进去，为解决微服务的治理和业务代码的解耦，出现了K8s，k8s是一种容器化编排技术可以兼容和接管部分微服务的功能，使得代码轻量，此外增强了服务括缩容技术，弹性部署更加容易，为了进一步解决精细化的服务治理，譬如熔断、流控、观测问题，在k8s基础上提出了服务网格的概念，网格服务就是把和微服务相关的代码独立处理，使得业务代码更加精简
落地实现：k8s,服务网格

应用开发技术，特别是分布式技术的关键问题

采用分布式技术，或者单体技术，无论采用什么方案，都要解决如下的问题来保证系统高可用

🍻分布式系统的业务架构设计考虑的技术点

做分布式系统，针对业务需要考虑的一些技术

🧊分布式共识算法

负载均衡下的算法——hash一致性算法

• 使用hash环把数据分布到0~2^32的环上，在环上分布式节点，实现数据节点的负载均衡

针对事务处理方法的一致性算法强一致性算法

• Paxos算法

• 一种基于消息传递的，高度容错性一致算法，平衡cap理论的CA。

• Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner):

• Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。
• Acceptor: 参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。
• Learner: 不参与决策，从Proposers/Acceptors学习最新达成一致的提案(Value)。

• Multi-Paxos算法把Proposer改为了一个，避免了活锁的问题。

• ZAB算法

• 在Paxos的基础上改进的，使用了Multi-Paxos算法一级raft类似是算法
• 参考连接
• 
  

• raft算法

• raft算法动画演示
• Raft将系统中的角色分为领导者(Leader)、跟从者(Follower)和候选人(Candidate):

• Leader: 接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。
• Follower: 接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。
• Candidate: Leader选举过程中的临时角色。

最终一致性算法

• Gossip算法
• Gossip 的过程十分简单，它可以看作是以下两个步骤的简单循环：

• 如果有某一项信息需要在整个网络中所有节点中传播，那从信息源开始，选择一个固定的传播周期（譬如 1 秒），随机选择它相连接的 k 个节点（称为 Fan-Out）来传播消息。
• 每一个节点收到消息后，如果这个消息是它之前没有收到过的，将在下一个周期内，选择除了发送消息给它的那个节点外的其他相邻 k 个节点发送相同的消息，直到最终网络中所有节点都收到了消息，尽管这个过程需要一定时间，但是理论上最终网络的所有节点都会拥有相同的消息。

🧊远程访问

• HTTP
• RPC

🧊分布式缓存

分布式缓存就是使用redis做数据缓存，把查询的热点数据放到redis提高查询效率，具体参考redis缓存数据库中间件介绍

分布式缓存更新策略

• 先查询再更新
• 先修改再更新

分布式分片集群的平衡策略

• 哈希一致性算法

分布式系统缓存可能遇到的问题

• 缓存穿透（查询不存在的或者非法数据）

• 过滤器
• 设计严格查询判断

• 缓存击穿（缓存失效，过期时间到了

• 使用setnx锁阻塞等待拿到锁的数据更新缓存

• 缓存雪崩（大规模缓存失效，过期时间到了）

• 设计间隔过期时间

🧊分布式锁

锁是什么：锁是为了解决并发情况下的对公共资源操作问题，读写问题。

锁的类型

• 本地锁

• 本地锁可以参考java的锁，比如sychornized系统锁，lock的aqs锁，cas锁等等锁

• 分布式锁

• 分布式锁就是解决分布式系统下的数据安全问题所产生的锁，在本质上采用了AQS的思想使用数据库中间件对数据设计的特性来设计aqs中的state作为独占锁，也就是把state从代码里拿到了数据库中间件中。
• 分布式锁的的分布式系统指定的是分布式在不同服务器或者线程的相同服务，和分布式的数据集群两个方面。
• 分布式锁的解决思路就是把不同线程相同业务里的锁state拿到公共的数据集群中做统一分配，解决不同系统或者进程之间锁信息state不呢共享的问题

应用场景

• 库存销耗问题

分布式锁总结：

• 基于mysql的分布式锁，简单但是不推荐
• 基于redis的分布式锁，复杂但是效率高可以考虑，但是是cas自旋的，才外主从部署存在安全问题
• 基于zookeeper的分布式锁，复杂，效率中，但是阻塞式，由于设计思想导致他安全系极高

🧊分布式事务处理

事务是一系列操作的集合，满足ACID原则，原子，隔离，一致，持久。它强调的是一系列操作是一个不可分割的整体，不可以在执行过程中被穿插，执行前的周围的环境，也就是操作涉及的环境不能在执行过程中发生变化只能再执行后发生变化。为了实现这个过程会在做公共资源操作的时候用到锁，也就是包含对高并发下锁的使用，但是锁仅仅为了满足事务的隔离性，还有许多其他的性质需要其他的技术来解决。事务是一个概念，满足ACID原则，但是实现起来是灵活的,而锁只是事务在实现过程中用到的众多技术之一，事务包含锁，但是由于隔离级别不同对并发数据安全的保证程度也不同，并不是事务包含锁就绝对保证锁的数据安全了。具体情况要结合事务的实现具体分析

• 事务时解决ACID原则下的四个问题的
• 事务包含解决资源访问隔离性问题，也就是包含锁
• 一般不通过数据库的锁来解决并发问题，影响性能，最好在代码层面上解决

事务类型

• 架构上分

• 本地事务

• 一个事务是在一个客户端程序的一个线程内依次执行的一系列操作，并反应到数据库层面

• 分布式事务

• 分布式事务时一个事务的内容分布在不同的客户端不同的线程来执行的，并反应到数据库层面

• 事务结构上分为

• 链式事务
• 扁平事务
• 嵌套事务

分布式事务的解决方案 分布式事务在ACID的原则上有出现了CAP理论（可用性，一致性，分区容错性），只能满足两个

• 解决方案

• 使用两阶段提交

• 先使用事务协调器接管事务把所有请求彩排一遍，如果都没有问题就回滚，有问题也会滚
• 如果彩排有问题回滚之后就执行事务失败
• 如果彩排没有问题就重新执行一遍所有的事务内容完成提交

分布式理论

CAP 理论：

• 一致性 (Consistency): 一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据。所有节点访问同一份最新的数据。
• 可用性 (Availability): 对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使出现节点失效。
• 分区容错性 (Partition tolerance): 能容忍网络分区，在网络断开的情况下，被分隔的节点仍能正常对外提供服务。

Base理论

• Basically Available（基本可用）分布式系统在出现不可预知故障的时候，允许损失部分可用性
• Soft state（软状态）软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventually consistent（最终一致性）最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

分布式事务的一些博客说明，可以详细了解使用
seate官网

分布式事务总结

XA两阶段提交思想

• 优化XA

• TCC
• AT
• Saga

🧊分布式ID

分布式ID意思是保证在分布式系统中生成唯一的ID。

• 分布式ID不仅保证每个重复的业务处理数据时候生成的Id是唯一的。
• 对于分库分表的情况下，在号段技术的加持下也可以有效生成对应范围内的数据

分布式id应用的关键(分布式可用（分表之后依然可以高效，有序，唯一）——唯一算法+号段)

• 唯一（任何相同的业务不会产生相同的ID，雪花算法，自增算法，uuid）
• 高效性（号段方法）
• 有序（不同的id相对有序，号段，加雪花，或者自增）
• 其他都在下图展示了。

🧊多级分流

• 客户端缓存
• 域名解析
• 传输链路
• 内容分发网络
• 负载均衡算法（7种）

• 轮询法(Round Robin)
• 加权轮询法(Weight Round Robin) fair(第三方)按后端服务器的响应时间来分配请求，响应时间短的优先分配。
• 平滑加权轮询法(Smooth Weight Round Robin)
• 随机法(Random)
• 加权随机法(Weight Random)
• 源地址哈希法(Hash) ，哈希一致性算法
• 最小连接数法(Least Connections)
• 
  

• 服务端缓存

🧊架构安全

• 认证
• 授权
• 凭证
• 保密
• 传输
• 验证

---

🦪分布式系统设计的核心组件

和具体业务无关，只要使用了分布式架构就需要使用的核心组件

🦑注册中心——从调用类库到服务调用

• 服务的注册发现（注册中心）Nanco eruka zookeeper
• 路由网关 zuul gateway
• 客户端负载均衡 fegin region

🦑流量治理

• 服务容错 Hystrix
• 流量控制

🦑可靠通信

• 零信任网络
• 流量控制

🦑可观测

• 事件日志
• 链路追踪
• 聚合度量

🥕分布式系统部署设施

🥬虚拟化容器化集群化

• linux
• docker
• k8s

应用开发技术特别是分布式架构的解决方案

解决方案目前来看是十分灵活的，没有绝对的方案，只有唯一的思想。

🧉编码融合的框架方案

springcloud,dubbo等，从编码层面上解决分布式架构的问题，灵活，部署扩展比较麻烦还是要依赖虚拟容器技术。

🧉虚拟化技术

K8S ,服务网格，从应用程序运行环境的底层硬件操作系统来解决微服务问题，这个特性决定了它既可以解决编码层面的部署问题，单体分布式架构狗可以，也可以解决分布式服务问题，应该是很有前途的工作。