wyz191的专栏

第十章 大数据架构设计1、数据应用的发展历程答：（1）企业部门信息化建设（独立系统，All-in-One架构） 解决部门内的信息化问题，各部门间系统隔离、数据隔离，无法互联互通（2）企业系统互联互通 通过各种数据接口，实现系统间的互联互通，杂乱无章、维护困难（3）面向服务架构（SOA：Service-Oriented Architecture） 在各个子系统间建立企业级的服务总线（ESB：Enterprise Service ...

8.5 如何开展微服务项目建设？答：（1）统一语言建模 沟通中注意专业术语，努力学会用专业术语进行业务探讨（2）事件风暴会议事件即事实，那些在业务领域中已经发生的事件就是事实；运用头脑风暴会议进行领域分析建模；1）梳理当前业务有哪些领域事件，即已经发生并需要保存下来的那些事实。这时，是按照业务流程依次去梳理领域事件的。 DDD有自己的适用范围，它往往应用于系统增删改的业...

8.4 微服务的分解和组合模式有哪些？答：微服务技术团队在转型过程中往往会经历三个阶段：技术架构、业务落地与云端运维。使用微服务架构划分服务和团队是微服务架构实施的重要一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。在微服务设计中，有6种设计模式，分别是：聚合模式、代理模式、链路模式、分支模式、异步模式与数据共享模式。（1）聚合模式聚合模式是微服务设计中最常见的一种设计模式，它根据业务流程处理的需要，以一定的顺序调用

说明：本文来自知乎作者：老刘Spring Cloud 入门总结 - 知乎8.3 微服务之Spring Cloud8.3.1 什么是Spring cloud构建分布式系统不需要复杂和容易出错。Spring Cloud 为最常见的分布式系统模式提供了一种简单且易于接受的编程模型，帮助开发人员构建有弹性的、可靠的、协调的应用程序。Spring Cloud 构建于 Spring Boot 之上，使得开发者很容易入手并快速应用于生产中。官方果然官方，介绍都这么有板有眼的。我所理解的Spring..

8.2 什么是微服务？答：1）是一种架构风格与设计模式2）提倡将大的应用分割成一系列小的服务3）每个服务专注于各自单一的业务功能4）每个服务运行于独立的进程中，有清晰的服务边界5）采用轻量级的通信机制（HTTP/REST）来实现互通、协作微服务最大的特点是“小而专”，小就是将原有的大的应用拆分成一系列小的服务；专就是专注，这里指单一职责，也就是高内聚。 怎样才能保证每次变更都只更新一个微服务呢？ 将因同一个原因而改变的代码放在一个微服务中，而将因不同原因而改变...

8.1 快速变化如何进行快速交付？答： 什么时候软件价值最高呢？是用户刚刚提出需求的时候。此时，市场还没有满足用户需求的产品，如果我们适时推出相应的产品，用户将更有意愿去购买我们的产品。引出快速交付。 如何才能获得快速交付的能力？（1）高效的团队组织 避免“烟囱式的开发团体”将大量的时间耗费在部门间的沟通协调中；应该建立“跨功能团队”或者“特性团队”，每个团队都直接面对终端客户，整个交付过程都由这个团队负责，避免了团队间的沟通协调，交付速度自然就提升了。（2）精简的...

15、分布式数据库15.1 MPP数据库的运行原理大规模并行处理（Massively Parallel Processing,MPP)数据库，是一种较早基于Shared Nothing存储思想设计的一种分布式数据库。在该数据库中，每个节点都有独立的磁盘存储与内存，业务数据根据数据库模型及其应用特点被划分到各个节点上。同时，每个节点都通过专用网络互相连接、彼此协同，并作为整体对外提供数据库服务。MPP架构是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到

14.7 分布式事务解决方案之分布式队列14.7.1 生产者-消费者模型分布式队列在不同的应用场景中使用时，被分为两种模型：生产者-消费者模型与发布者-订阅者模型。在生产者-消费者模型中，消息发送方将消息发送给队列。这时虽然有多个消费者，但只能有一个消费者接收到这个消息。使用生产者-消费者模式能保证幂等吗？答案是不能。当生产者向队列发送消息时，队列需要反馈一个确认消息，保证队列已经收到这个消息。然而，当生产者等待了一个timeout时间还没有收到这个反馈信息时，情况可能有两种：（1.

本节主要参考：小白不想上班链接：https://www.jianshu.com/p/0f50adfc9992，有部分补充内容14.5. 分布式事务解决方案之可靠消息最终一致性14.5.1 什么是可靠消息最终一致性事务可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方（消息消费者）一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成，如下图：案例：图中订单服务在执行“下单”操作时...

本节内容来自“作者：小白不想上班链接：https://www.jianshu.com/p/0f50adfc9992”，有部分补充内容14.4. 分布式事务解决方案之TCC14.4.1 什么是TCC事务TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的.

本节内容整理自网络，以“小白不想上班”为基础，补充了3PC内容14.3. 分布式事务解决方案之 2PC、3PC前面学习了分布式事务的基础理论，以理论为基础，针对不同的分布式场景业界常见的解决方案有 2PC、3PC、TCC、可靠消息最终一致性、最大努力通知这几种。14.3.1 什么是 2PC2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。举例：张三和李

注：本节内容来自“小白不想上班” https://www.jianshu.com/p/0f50adfc999214.1. 基础概念14.1.1 什么是事务事务可以看作是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。14.1.2 本地事务在计算机系统中，更多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，因此叫数据库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务。数据

13、内存数据库如何保障数据安全？13.1 Redis的主从同步方案应用服务器在存库的时候，将数据存储于Redis集群中；整个Redis集群通过Slot操作，将所有的数据以散列的形式均匀存储到各个节点中。同时，为了保证数据的安全，一方面每一个Redis节点在存储时都以镜像的形式将数据存储在本地磁盘中，另一方面为集群中的每个节点提供一个备用节点。这样，当Redis中的某个主节点失效时，可以自动通过主从切换，切换到从节点上，即能保证数据安全，又能保障系统高可用。13.2 GemFire的节点数据复制

12、缓存穿透、缓存击穿与失效时的雪崩效应（补充）参考自网络，具体出版忘记了12.1 缓存穿透描述：缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会

11、Redis分布式缓存概述答：Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。Redis除了以K-V形式进行存储处外，还可以有Map（将记录以Map的形式存储，每个字段都是一个k-v）、List（将数据串联起来形成链表，常常用来制作队列）、Set（数据集合）、与ZSet（有序集合，即对某个字段进行排序）。Redis的部署有两种方.

10、分布式缓存如何保证数据一致性？答：分布式缓存的设计目的就是在系统查找数据时，不再查找数据库，而是查找缓存，这要求缓存与数据库中的数据一致。然而，在系统实际运行中可能出现这种情况：系统在删除缓存与更新数据库的间隙，另一个进程去查找这个数据，由于数据还未完成更新，还是处于更新前状态，查询完就将更新前数据又载入缓存了，数据就不一致了。因此，解决分布式缓存数据一致性最有效的解决方案，就是在数据库更新和删除数据的前后都分别执行一次该数据在缓存中的删除。然后，为了避免最后一次删除失败，还需要定期比

9、分布式系统的CAP定理是什么？答：CAP定理指出，在一个分布式系统中，对于一致性、可用性、分区容错这三个特性，不可能同时满足，而是必须有所舍弃。我们设计分布式系统时，必须在三者之间（尤其是一致性和可用性之间）有所取舍和平衡。9.1 概述9.1.1 概念CAP定理(CAP theorem)，又被称作布鲁尔定理(Brewer's theorem)，是分布式系统中的一个基本定理。它指出任何分布式系统(Distributed System)中，最多具有一致性、可用性、分区容错这三个特性中

什么是一致性Hash算法？答：（本部分引自参考：https://kefeng.wang/2018/08/10/consistent-hashing/）一致性hash算法也是取模运算，只不过是对2^32取模。对2^32取余是有依据的；IPV4最大数量就是2^32，所以这样就能保证所有的IP的地址进行取余时不会重复，从而对应hash环上面的正数。分布式系统中对象与节点的映射关系，传统方案是使用对象的哈希值，对节点个数取模，再映射到相应编号的节点，这种方案在节点个数变动时，绝大多数对象的映射关系.

7、如何设计分布式缓存？答： 在写入数据时，对Key值进行散列处理（利用求余算法），在查询数据时，采用同样的算法查询数据。但它不稳定，当增加一个节点时，整个数据就要重新分布；重新分布数据会导致分布式缓存的不可用；这时一种新的算法“一致性Hash算法”被推出以解决这个问题；但是一致性Hash算法在减少节点时，就会将失效的那个节点的数据全部都压到另一个节点上，导致那个节点也失效，进而造成节点一个个失效的“雪崩现象”。 书中讲（目前最有效的解决方案不再是一致性Hash算法，...

6、跨库关联查询的解决方案？答： （1）大变小不要一次性返回所有结果，采用分页方式一次返回有限小的数据，然后对关联的数据进行补填，完善相关信息后，返回数据给前端。 （2）数据补填数据需要返回关联信息时，可通过调用关联数据的微服务接口进行数据补填（待关联数据量要小）。 （3）借助缓存在调用关联数据的微服务接口时，在微服务中增加缓存的设计，补填的时候先查询缓存数据，再读数据库。 （4）一次性调用在补填数据时，如果...

5、亿级流量如何架构设计？答：采用高并发、高可用、高可靠的“三高”设计原则进行设计。（1）三高设计原则系统建设必须做到，即使个别节点宕机、网络不可用，依然能保证整个系统对用户是可用的，可以为用户正常提供服务。1）高并发主旨原则：系统分层、逐级限流。 服务网关层 负载均衡 将所有压力均匀地分布到许多物理节点上 限流措施 只将有效的流量转发给下游；当业务流量超过系统设计能力时，拒绝掉过载部分.

4、流量在5000万以上如何架构设计？答：（1）分布式缓存设计提高系统吞吐量最有效的措施就是降低系统平均响应时间。响应时间：就是从用户发出请求开始到最终获得系统反馈所需要的时间。服务端的耗时主要分为两部分：数据存库前的耗时和存储数据库中的耗时。数据存库前要进行各种逻辑校验与业务操作。校验与操作的效率的决定性因素是那些为了完成校验和业务而进行的查询。所以，提高这部分操作的查询效率，才是性能提升的关键。本地缓存：将应用服务器集群中每个节点本地的内存拿出一部分，将其作为缓存来存储数据。本地

3、流程在1000万以上如何架构设计？答：1000万以上的流量，除了负载均衡、应用集群，更大的性能瓶颈在于数据库。（1）数据库瓶颈与数据库集群基于Oracle RAC的数据库集群，是将数据库的计算分配到多个节点上，从而起到提升系统性能的目的。此外，为了保障数据一致性，需要在集群的每个节点与每个节点之间架设数据同步线。数据库集群不具备无限扩展的能力。这样的数据库架构没有办法满足不断拓展的用户流量需求。（2）数据操作分析用户访问系统的所有操作都可归纳为三种类型：业务操作、随机查询与统计分

2、流量在1000万以内如何架构设计？答：将原有的一台应用服务器变为应用服务器集群，在前面架设反向代理，增加CDN节点与本地缓存。（1）动静分离与前后端分离利用反向代理实现负载均衡与动静分离；（2）Nginx的高可用设计Nginx是当今主流的反向代理方案，能够支持高达50000并发连接数的响应，为站点提供高并发、吞吐量创造了条件。虽然 Nginx具有超强的系统性能，但系统高可用的设计要求Nginx集群是由“一主多备”的多个Nginx节点组成。同时，在它们之上架设了一个Keep..

第7章 分布式架构设计在应对高并发的时候，我们可以采用“目标 – 问题 – 决策”的解决步骤。目标就是要达到的吞吐量，实际上被表述为两个指标：最大用户并发量与最大平均响应时间。最大用户并发量：就是系统上线以后的最大用户峰值，可以通过评估总用户量去评估在线用户量，再通过在线用户量去评估并发用户量。最大平均响应时间：是评判系统是否被压瘫的标准，即用户等待时间超过了用户可以忍耐的最大等待时间，就代表系统已经被压瘫了。一个系统到底能达到多大的吞吐量，遵循的是“木桶效应”，即是由性能最差的那部分组件决

整体感觉这章没有讲太多东西运行架构关注的是系统如何运行，是同步还是异步，是并发还是串行，关注运行中的各个对象如何交互，状态如何转换，关注那些安全必性、可靠性、可伸缩性等质量要求，以及响应时间、吞吐量等性能要求。运行架构关注的不再是全局，而是局部，是系统中那些关键点与难点。1、如何开展对非功能需求的分析与设计？答：采用“属性à场景à决策”的过程，一步一步进行架构设计。（1）属性：就是整个系统应当遵循的质量属性。譬如，整个系统应当达到的安全性、可靠性，应当达到多少秒内的响应时间，以及多大的高

开发架构设计阶段，首先，通过整体归纳出各个模块的技术共性，看都有哪些共性的需求；然后，从全局角度去思考整个软件的顶层架构。在开发架构设计阶段，架构师主要完成以下工作：1、系统规划2、接口定义3、系统分层4、技术选型5、代码规范4.1 系统规划与接口定义规划一个系统首先站在全局的角度把整个系统规划成几个大的模块或子系统，准确定义出它们的功能与范围，把相互之间的边界划分清楚。然后在此基础上，将各个功能落实到这些模块中。从而可以把整个系统设计的工作分配给多个团队，让彼此独立地去工作

数据架构设计就是以数据为核心，来梳理整个业务处理流程。数据架构设计环节首先要进行领域模型的设计，然后将领域模型的设计转换成数据库设计和程序设计。3.1 数据架构的设计过程早期的数据架构设计是以数据库设计为核心的设计过程；先理需求，再设计数据库，后开发；当系统规模小、团队人员小时，这种方式能有效推动项目的上线，不会存在较大的问题；但是当系统规模大、团队成员多时，会给整个项目带来风险。推荐采用面向对象的设计过程来分析设计系统（OOA/OOD）。拿到需求后，先进行用例模型的设计，明确系统要实现哪些

业务需求是所有架构设计的依据。架构设计必然是从需求分析开始的。1、怎么进行逻辑架构的分析？答：解决思路是“粗 – 细 – 粗”。首先从整体、大局、宏观的角度去思考问题，进行逻辑架构分析。（1）粗1）从需求文档的目录章节中分析 通过阅读目录，了解各章节、功能模块的划分，通过功能模块中的功能命名，猜测功能背后的内容；从而对整个系统 有一个整体的、直观的认识2）从需求文档的概述部分分析 通过概述了解客户的建设目标，根据建设目标为每个功能设定优先级（不能让客户设定优先级），实...

1.1 何为软件架构1、在开发软件的时候是否必须要设计架构？答：不是；要不要设计架构视软件的系统规模及复杂度进行考量。2、架构设计与其他的概要设计、详细设计有什么不同？答：架构设计更多的是从宏观角度、从全局角度去思考问题。概要设计、详细设计考量的是具体的细节，更多的是从微观角度考量。3、什么是软件架构？答：软件架构，就是指从宏观角度说明一套软件系统的组成与特性，它要求架构师在进行架构设计时，必须具有大局观，首先从全局角度去思考问题。软件架构包含逻辑架构、数据架构、开发架构、运行架

1、顶级架构师的核心竞争力是什么？答：是对架构设计的认知以及顶级的思维模型。2、顶级架构师与普通架构师的差距是什么？答：是对技术的认知。3、架构师认知的四个阶段是什么？答：（1）愚昧之巅：不知道自己不知道；特点：自大、不愿接受新事物、自我感觉良好；（2）绝望之谷：知道自己不知道；特点：要么在绝望中死亡，要么在绝望中爆发；（3）开悟之坡：知道自己知道；需要长期学习，持续进行项目实践；认知上升到哲学思维的高度，具有透过表象抓本质的“击穿”能力；明白解决问题的本质都一样，那就是“降