架构理念

架构学习

系统分解多个系统业务模块好处？（微服务）

• 简单的系统更容易做到高性能，因为在单体应用中，提高了A业务效率有可能会降低其他的业务效率。
• 分解之后更容易看到系统的瓶颈所在，可以对单个业务进行扩展，有针对性的优化比如代码或者增加服务解决，其他服务可以保持不变。
• 分解的业务模块越多，网络的开销也就越大，调用的业务链路也长，排查问题越不方便。

今日心得

1 WHAT 对高性能的理解?

性能是软件的一个重要质量属性。衡量软件性能包括了响应时间、TPS、服务器资源利用率等客观指标，也可以是用户的主观感受。

在说性能的时候，有一个概念与之紧密相关—伸缩性，这是两个有区别的概念。性能更多的是衡量软件系统处理一个请求或执行一个任务需要耗费的时间长短;而伸缩性则更加关注软件系统在不影响用户体验的前提下，能够随着请求数量或执行任务数量的增加(减少)而相应地拥有相适应的处理能力。

软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度;另一方面是多台计算机集群为了高性能带来的复杂度。
2 WHY 为什么需要高性能?追求良好的用户体验;满足业务增长的需要。

3 HOW 如何做好高性能?可以从垂直与水平两个维度来考虑。垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升;水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。

垂直维度可包括以下措施:

增大内存减少I/O操作

更换为固态硬盘(SSD)提升I/O访问速度

使用RAID增加I/O吞吐能力

置换服务器获得更多的处理器或分配更多的虚拟核

升级网络接口或增加网络接口
水平维度可包括以下措施:
功能分解:基于功能将系统分解为更小的子系统
多实例副本:同一组件重复部署到多台不同的服务器
数据分割:在每台机器上都只部署一部分数据

垂直维度方案比较适合业务阶段早期和成本可接受的阶段，该方案是提升性能最简单直接的方式，但是受成本与硬件能力天花板的限制。

高性能 基本都是通过水平增加服务 冗余

高可用 必须要提到cap理论 ，zk的pasox zab协议是其中的了解的。另外还有脑裂的情况产生。zk是通过投票的算法在少数服从多数。

可扩展性

将变化封装到变化层

将不变封装到不稳定层

1.系统需要拆分出变化层和稳定层
2.需要设计变化层和稳定层之间的接口

以上基本就是复杂度的来源，另外成本，安全，规模 也同样是复杂度的来源之一。

架构设计原则

合适优于先进>演化优于一步到位>简单优于复杂

合适也就是适应当前需要是首位的，连当前需求都满足不了谈不到其他。
架构整体发展是要不断演进的，在这个大前提下，尽量追求简单，但也有该复杂的时候，就要复杂，比如生物从单细胞一直演化到如今，复杂是避免不了的，

架构设计三原则;
合适原则最适合;
简单原则不简单;
演化原则需推进;
如若脱离三原则;
老板生气你苦逼。

​

nginx 负载均衡 大约5w ，http 请求大约2w ，kafaka 号称百万，zk读写速度大约2w多

架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性;为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是:

(1)构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。

(2)结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要?是否关键?

“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。

“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。

“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。

(3)按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。

经过架构设计流程第 1 步——识别复杂度，确定了系统面临的主要复杂度问题，进而明确了设计方案的目标，就可以开展架构设计流程第 2 步——设计备选方案。架构设计备选方案的工作更多 的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。
1. 几种常见的架构设计误区 
(1)设计最优秀的方案。不要面向“简历”进行架构设计，而是要根据“合适”、“简单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。 
(2)只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。
2. 备选方案设计的注意事项
(1)备选方案不要过于详细。备选阶段解决的是技术选型问题，而不是技术细节。
(2)备选方案的数量以 3~5个为最佳。
(3)备选方案的技术差异要明显。
(4)备选方案不要只局限于已经熟悉的技术。
3. 问题思考 由于文中已经从开源、自研的角度提出了架构设计方案;为此，从架构设计三原则出发，也可考虑第四个备选方案:上云方案，该方案是直接采用商业解决方案，就好比阿里前期采用IOE类似。 如果是创业公司的业务早、中期阶段，可直接考虑采用阿里云/腾讯云，性能、HA、伸缩性都有保证。
此外，在文中备选方案1 - 开源方案中，如果从提供另外一种视角看问题的角度出发，个人会更加倾向于RabbitMQ。首先，RabbitMQ与Kafka都同样具备高可用、稳定性和高性能，但是，通 过一些业界测试比较，RabbitMQ比Kafka更成熟、更可靠;其次，在高性能指标方面，Kafka胜出，kafka设计的初衷是处理日志，更适合IO高吞吐的处理。但是，对于“前浪微博”系统 的QPS要求，RabbitMQ同样可以驾驭。为此，综合来看，会更加倾向于RabiitMQ。
最后，通过本文再结合自己做技术最大的感悟是:做事情永远都要有B方案。

Kafka VS rocketMQ

1、数据可靠性
kafka使用异步刷盘方式，异步Replication
RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication
2、严格的消息顺序
Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序 RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序 3、消费失败重试机制
Kafka消费失败不支持重试
RocketMQ消费失败支持定时重试，每次重试间隔时间顺延
4、定时消息
Kafka不支持定时消息
RocketMQ支持定时消息
5、分布式事务消息
Kafka不支持分布式事务消息
阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
6、消息查询机制
Kafka不支持消息查询
RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息(发送消息时指定一个Message Key，任意字符串，例如指定为订单Id) 7、消息回溯
Kafka理论上可以按照Ofset来回溯消息
RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

高性能数据库集群

1.读写分离

本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力

一般是主从的概念，主负责写入，从负责读取数据。主复制数据到从 。

主从复制延迟

1. 一些业务如果是写之后马上进行读取的操作，建议读写操作都保证分配主上进行避免。

2. 关键业务的读写都在主进行操作，非关键性业务去从库进行读取

3. 进行二次读取，从库读取失败后向主进行读取。

   分配机制

• 程序代码封装

  简单易用，灵活性高，但是如果主宕机发生故障，这个时候需要切换配置。

目前开源的实现方案中，淘宝的TDDL，它是一个通用数据访问层，所有功能封装在jar包中提供给业务代码调

用。其基本原理是一个基于集中式配置的 jdbc datasource实现，具有主备、读写分离、动态数据库配置等功能。

• 中间件封装

360开源自己的数据库中间件Atlas，基于mysql proxy 。

2.“分库分表”

既可以分散访问压力，又可以分散存储压力

高性能缓存

缓存穿透

一般指去缓存中查询数据，发现没有直接去存储系统去查询数据。

存储数据不存在

如果查询存储系统的数据没有找到，则直接设置一个默认值(可以是空值，也可以是具体的值)存到缓存中，这样第二次读取缓存时就会获取到默认。

缓存数据生成耗费大量时间或资源

例如电商的商品分页，我们只能缓存单页数据，一般设置的有效期为1天。

缓存雪崩

指的是当缓存失效后引起系统性能急剧下降的情况。

解决办法 更新锁机制和后台更新机制

更新锁

对缓存更新操作保证只有一个线程能够进行缓存更新，可以采用分布式锁进行处理，未获取到锁的线程要么等待重新读取缓存或者直接返回默认值。

缓存雪崩问题，我们采取了双key策略:要缓存的key过期时间是t，key1没有过期时间。每次缓存读取不到key时就返回key1的内容，然后触发一个事件。这个事件会同时更新key和key1。

后台更新

业务线程发现缓存失效后发送一条消息到消息队列，之后后台线程进行更新缓存，更新前判断缓存是否存在。后台更新还有一个好处就是缓存预热，在系统上线前可以更新一些数据到缓存中。

缓存热点

缓存热点的解决方案就是复制多份副本，将请求分散到多个缓存服务器上，缓存数据一样，通过缓存的key加编号进行区分，每次读取缓存随机读取副本。但是注意副本的过期时间千万不能一样，那样会导致缓存同时失效。

应用总结

一 数据库自身不是有缓存吗，标准答案是怎么回击他?
1. mysql第一种缓存叫sql语句结果缓存，但条件比较苛刻，程序员不可控，我们的dba线上都关闭这个功能，具体实现可以查一下

2. mysql第二种缓存是innodb bufer pool，缓存的是磁盘上的分页数据，不是sql的查询结果，sql的执行过程省不了。而mc，redis这些实际上都是缓存sql的结果，两种缓存方式，性能差很远

二 分级的缓存策略，客户端可以采用cdn加上localstorge 

三 业务查询的结果序列化后放到redis，下次从redis取出来时报错。原来是结果类虽然实现了Serializable接口，但是没有重写serialVersionUID，导致不能成功反序列化。

四 将查询条件组合成字符串再计算md5，作为缓存的key，优点是简单灵活，缺点是浪费一部分缓存

五 请问如何保证缓存和数据库的一致性，例如用户修改了一项配置，是先更新缓存还是先更新库?如何保证缓存和库都更新一致呢？
先更新库好些，因为更新库成功后即使更新缓存失败，缓存也有过期时间。
如果要保证一致，更新库前先删除缓存，然后更新库，再更新缓存，但即使这样，也可能出现缓存和库不一致，因此要做到绝对一致是很复杂的，需要用到zk这类协调软件，不建议这么设计。

单Reactor单进程的是Redis.

以Java的NIO为例，Selector是线程安全的，但是通过Selector.selectKeys() 返回的键的集合是非线程安全的，对selected keys的处理必须单线程处理或者采取同步措施进行保护.

Nginx采用的是多Reactor多进程，采用多Reactor多线程的实现有Memcache和Netty

​
​
​
​
​
​
​
​

Reactor与Proactor能不能这样打个比方:

1、假如我们去饭店点餐，饭店人很多，如果我们付了钱后站在收银台等着饭端上来我们才离开，这就成了同步阻塞了。
2、如果我们付了钱后给你一个号就可以离开，饭好了老板会叫号，你过来取。这就是Reactor模型。
3、如果我们付了钱后给我一个号就可以坐到坐位上该干啥干啥，饭好了老板会把饭端上来送给你。这就是Proactor模型了。

高性能负载均衡

负载均衡分类：

DNS负载，软负载(LVS,nginx + keeplive)和硬负载(F5,A10)

负载均衡的算法

轮询，不关注服务本身的状态，例如机器配置，负载高等。

加权轮询 一般针对机器性能，还是无法根据服务器的状态差异进行负载

负载最低优先

LVS4层的网络负载设备，可以“连接数”来判断服务器状态，连接数越大表明系统压力越大。

nginx 7层网络负载系统

性能最优类 优先分配给处理速度最快的服务器

Hash类

源地址hash 适用于存在事务和会话的业务。

​
当我们通过浏览器登录网上银行时，会生成一个会话信息，这个会话是临时
的，关闭浏览器后就失效。网上银行后台无须持久化会话信息，只需要在某台服务器上临时保存这个会话就可以了，但需要保证用户在会话存在期间，每次都能访问到同一个服务
器，这种业务场景就可以用源地址Hash来实现。

ID hash

将某个ID标识的业务分配到同一个服务器中进行梳理，这里的ID一般是临时性数据的id 例如session id

网络搜素 “微信红包高并发” 学习下怎么设计的？

CAP理论

ACID是数据库事务完整性的理论，CAP是分布式系统设计理论，BASE是CAP理论中AP方案的􏲀伸。

一个电商网站􏲂心模块有会员，订单，商品，支付，􏳃销管理等。
对于会员模块，包括􏲾􏲲，个人设􏳄，个人订单，购物车，收􏳅􏳆等，这些模块保证AP，数据短时间不一致不影响使用。 订单模块的下单付􏳇􏳈􏱾库存操作是整个系统的􏲂心，我觉得CA都需要保证，在极􏰜情况下􏰌􏰍P是可以的。
商品模块的商品上下架和库存管理保证CP, 􏳉索功能因为本身就不是实时性非常高的模块，所以保证AP就可以了。 􏳃销是短时间的数据不一致，结果就是优􏳊信􏰯看不到，但是已有的优􏳊要保证可用，而且优􏳊可以提前􏳋计算，所以可以保证AP 现在大部分的电商网站对于支付这一块是􏳁立的系统，或者使用第三方的支付宝，微信。其实CAP是由第三方来保证的，支付系统是一个对CAP要求极高的系统，C是必须要保证的，AP中A相对 更重要，不能因为分区，导致所有人都不能支付

FMEA 故障模式与影响分析

􏳬􏰡􏰥􏳭􏰆failure mode and effects analysis)

架构设计领域，FMEA的具体分析方法是：

• 给出初始的架构设计图
• 假设架构中某个部件发生故障
• 分析此故障对系统功能造成的影响
• 根据分析结果，判断架构是否需要进行优化

FMEA分析表格

1. 功能点

   注册登录是功能点，redis缓存功能不能作为功能点。

2. 故障模式

   包括故障点和故障模式模式并不需要给出真正的􏰪􏰫原因

   􏰪􏰫模式的描述要􏳱􏲥精确，多使用􏲥化描述，避免使用􏰬化的描述。例如，推荐使用“MySQL响应时间达到3􏲜”，而不是“MySQL响应慢”

3. 故障影响

   ​ 当发生故障模式中的故障时，功能点偶尔不可用，完全不可用，部分用户功能点不可用，功能点响应缓慢，功能点出错等。

4.严重程度

一􏲃分为“致命􏳻/高/中/低/无”五个􏲇档次

严重程度按照这个公式进行评􏰞:严重程度 = 功能点重要程度 × 􏰪􏰫影响范围􏲦 × 功能点受􏲽损程度

• 致命􏳻:超过70%用户无法􏲾􏲲。

• 高:超过30%的用户无法􏲾􏲲。

• 中:所有用户􏲾􏲲时间超过5􏲜。
• 低:10%的用户􏲾􏲲时间超过5􏲜。
• 中:所有用户都无法􏱗改资料。
• 低:20%的用户无法􏱗改头像

5. 故障原因

   比如导致mysql查询响应慢，可能是mysql bug 或者是没有索引。不同的故障原因检查手段不一样，如果是磁盘坏道导致的运维部门去查询，慢查询导致mysql慢，那么就在mysql添加慢查询日志即可。如果mysqlbug 那么升级mysql。

6. 故障概率

   硬件，开源系统，自研系统

7. 风险程度

8. 已有措施

   系统现在是否提供了某些􏱉􏱊来应对，包括:􏳟测􏲪􏴂、容错、自􏱳恢复等。

9. 规避措施

   技术手段+ 管理手段

10. 解决措施

    解决措施位了能够解决问题而做的一些技术手段。

    例如 为了解决拖库导致数据泄露，将数据库中敏感数据进行加密。

    解决非法访问，增加白名单控制

11. 后续规划

高可用存储架构 双机架构

对任何一个高可用存储方案，需要从以下几个方面去分析：

• 数据如何复制？
• 各个节点的职责是什么？
• 如何应对复制延迟？

• 如何应对复制中断？

  常见的双机高可用架构：主备，主从、主备/主从切换和主主
  ​
  主备：一般后台系统资源稍微有浪费。

主从：主负责写，从负责读操作，帮主人干活。缺点主从复制延迟大，容易产生数据不一致。

一般用于读和写比例1:10或者更多

主备切换：

1. 主备间状态判断

   ​状态传递的渠道：是相互间互相连接，还是第三方仲裁？

   ​状态检测的内容：例如机器是否掉电、进程是否存在、响应是否缓慢

   2.切换决策

• 切换时机

  什么情况备机升级主？掉电？主进程不存在？还是主超时响应？还是一段时间内重复次数？

• 切换策略

  原来主故障恢复后，继续主还是当备？

• 自动程度

  完全自动还是半自动？

3. 数据冲突解决

   切换时候数据不一致怎么解决？

常见的架构

主备切换架构三种形式：互连式、中介式、模拟式

高可用存储架构：集群和分区

计算高可用架构，主要解决当单点发生􏰪􏰫后，原本发􏴣到􏰪􏰫节点的任务，任务如何分发给非􏰪􏰫节点，根据业务特点选择分发和重试机制即可，不存在数据一致性问题，只需要保证任务计
算完成即可
存储高可用架构，解决的问题是当单点发生􏰪􏰫了，任务如何分发给其他非􏰪􏰫节点，以及如何保􏰫数据的一致性问题。
所以存储的高可用比计算的高可用的设计更为复杂。
计算高可用系统需考虑safety和liveness，而存储高可用􏰘了需考虑safety和liveness，还受CAP􏰙􏰚

​

接􏰓口级故障􏰐􏰑的四种应对方法，分别是􏰉降级、容􏰈断、限流和􏰶排队

1.􏰧购􏱠面最大程度静态化，一􏰟用户开始前会尝试􏱡新􏱠面，查􏱑压力要比下单压力大很多

2.􏰧购􏱠面要求􏱂􏱢后􏰠问，一􏰟人不会􏰧购开始那一刻才进来，错开􏱂􏱢压力

3.活动未开始，不􏰡许点􏱣􏰧购按􏱤。对请求做轻􏰣分析，对于请求过􏱛􏱥或者可疑ua等做􏱎黑，为􏱦误􏰿要求􏱧验证码

4.􏰧购下单接􏰓􏰘用􏰶队+限流，􏰉低压力的同时保证公平性，如􏰧购1000件，只放2000人进来，其他􏰖回􏰶队人数过多。进来的请求全部入􏰳，􏱨定数􏰣的队􏰳􏰻费者􏱩制订单生成速率以及

走到支付流程的速率。支付是下单流程􏰬心功能，􏰉级不应该􏰉级􏱪。队􏰳做􏱫峰，保证支付系统不会压力过大。

## 可扩展架构的基本思想和模式

基本思想：拆

拆分思路

• 面向流程拆分：将整个业务流程拆分几个阶段，每一个阶段为一部分。分层架构
• 面向服务拆分：将系统提供的服务拆分，每个服务做为一部分。soa,微服务
• 面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。微内核

面向流程、面向服务、面向功能，这三个的􏲎名，面向服务和面向功能还可以，面向流程这个容易让人误解。
面向流程，大概指的是数据移动的流程，而不是业务流程。分层架构的本质，就是􏱨定的内􏰬，移动的数据。
规则引􏲵的扩展方式，可以用下􏰶􏲶法。
首先，􏰔定不是分层架构，即不是面向流程的，因为规则引􏲵主要作用在业务层。
其次，也不应该是面向服务的，因为规则引􏲵都是􏲷越多个服务的。
规则引􏲵和􏲸件式架构，解决的都是功能扩展的问题。微内􏰬架构就是一种􏲸件式架构。
所以，规则引􏲵应该是面向功能的扩展方式。

Mvp 逻辑分层架构 ，是自顶向下依赖的。

SOA的全称是Service Oriented Architecture，中文翻􏴒为“面向服务的架构”,一个特点的就是异构系统整合使用esb总线的思想。

微服务

soa和微服务的区别：

1. 服务粒度

   soa的服务粒度要粗一些，可能是一个系统做为一个服务。2⃣微服务会把一个系统拆分成多个服务。

2. 服务通信

   RESTFul 协议，rpc协议，无需esb那么重量级的实现，2⃣而微服务仅仅是消息传递

3. 服务交付

   微服务的架构理念要求“快速交付”，相应地要求􏰘取自动化测试、持续􏳌成、自动化部署􏳋等敏捷开发相关的最􏱾实践。如果没有这些基础能力支撑，微服务规模一􏱊变大(例如，超过20个微服务)，整体就难以达到快速交付的要求。

4. 应用场景

   soa更加适合庞大、复杂的异构的企业级系统

   微服务有哪些坑？

   服务划分过细，服务间关系复杂，单个服务的复杂度下降，但是系统整个复杂度上升，n个服务的复杂度是n*（n-1）/2

​ 服务数量太多，团队效率急剧下降，团队规模要具备，不然适得其反。

​ 调用链太长，性能下降，调用链太长，问题定位困难

​ 没有自动化支撑，无法快速交付，

​ 没有自动化测试，每次测试需要测试大量接口，没有自动化监控，定位故障排查太难，没有 服务治理，微服务数量多后台管理混乱。

微服务最佳实践-方法篇

服务粒度

建议按照团队规模来划分，三个火枪手原则，3个能形成一个稳定的备份，三人能形成讨论，系统复杂度刚好达到每人都能全面了解系统。

基于业务逻辑拆分

比如电商系统，第一种是“商品” “交易” “用户” ，第二种是 商品、订单、支付、买家、卖家。

这个时候要看团队规模了，二种拆分方式都没任何问题。

基于可扩展拆分

将已经成熟和改动不大的服务拆分为稳定服务，变动的服务细化。这样也不会导致后续快速迭代影响到稳定服务。

基于可靠性拆分

系统中业务模块按照优先级排序，将可靠性要求高的核心服务和非核心隔离开，保证核心服务的高可用。

基于性能拆分
​
将性能要求高或者性能压力大的模块进行拆分，避免压力过大影响其他服务。例如 数据库，缓存。

基础设施

​ 服务发现、服务路由、服务容错 ： 这是最基本的微服务基础设施。

​ 接口框架、API网关：接口框架提升内部服务的开放效率，api网关提供与外部服务对接

​ 自动化部署、自动化测试、配置中心，提升测试和运维效率

​ 服务监控、服务跟踪、服务安全，提升运维效率

微服务-基础设施篇

Drools规则引擎了解下？

​
​
​
​
​
​
​

​
​
​
​
​
​
​

​
​
​
​
​

​
​
​
​
​

​
​
​
​

​
​
​
​
​
​
​
​

对于会员模块，包括􏲾􏲲，个人设􏳄，个人订单，购物车，收􏳅􏳆等，这些模块保证AP，数据短时间不一致不影响使用。
订单模块的下单付􏳇􏳈􏱾库存操作是整个系统的􏲂心，我觉得CA都需要保证，在极􏰜情况下􏰌􏰍P是可以的。

商品模块的商品上下架和库存管理保证CP, 􏳉索功能因为本身就不是实时性非常高的模块，所以保证AP就可以了。
􏳃销是短时间的数据不一致，结果就是优􏳊信􏰯看不到，但是已有的优􏳊要保证可用，而且优􏳊可以提前􏳋计算，所以可以保证AP
现在大部分的电商网站对于支付这一块是􏳁立的系统，或者使用第三方的支付宝，微信。其实CAP是由第三方来保证的，支付系统是一个对CAP要求极高的系统，C是必须要保证的，AP中A相对

​
​
​
​
​
​

​
​
​
​

​
​
​
​
​
​
​
​

​
​
​
​
​
​

​
​
​
​

​
​
​
​
​
​
​
​

​
​
​
​