软件体系结构之14面试题

1.微服务架构基本理念和原则，为什么会在团队中使用微服务架构，实行微服务架构过程中碰到的问题及其解决方案。

理念和原则：对于微服务架构而言，服务建模、服务拆分和服务集成是基本的设计理念;软件架构的原则：围绕业务领域建模，而不是基于技术架构；高度去中心化，独立部署这几个方面。

为什么会在团队中使用微服务架构？微服务使技术团队与企业需求保持一致，可以调整团队的大小匹配所需的任务。

碰到的问题：各个服务之间数据传送不能完全对接上。解决方案：直接主类上加@enableclientdiscovery @feignclientdiscovery

2.RPC 的概念及其包含的核心组件和主流实现技术，如何实现一个自定义的 RPC 框架。

RPC指的是过程调用，是分布式系统的基础。RPC架构是基本的远程通信架构，主要由网络通信，序列化反序列化，传输协议和服务调用等四个组件构成。

RPC由左右对称的两大部分构成，分别代表了一个远程过程调用的客户端和服务器端组件。远程服务提供者以某种形式提供服务调用相关信息，远程代理对象通过动态代理拦截机制生成远程服务的本地代理，让远程调用就像在本地调用一样。

业界主流的RPC技术有Alibaba Dubbo，Dubbo 是阿里开源的一个极为出名的 RPC 框架，被广泛使用。协议和序列化框架都可以插拔是其鲜明的特色。

3．Dubbo 框架的原理和设计架构，涉及协议、内部基础框架、SPI 扩展性原理等。

Dubbo 框架的原理和设计架构

Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

内部基础框架

dubbo采用的是核心系统+插件的微内核模式。微内核架构也被称为插件式架构，它是一种面向功能进行拆分的架构模式。微内核架构包含两类组件：1.核心系统：只负责加载插件，只包含系统可运行的最少功能。2.插件模块：独立存在的模块，包含特殊的处理逻辑，额外的功能，用于强化和扩展核心系统，提供最多的能力。

SPI 扩展性原理

​ 良好的扩展性对于一个框架而言尤其重要，Dubbo 就依靠 SPI 机制实现了插件化功能，几乎将所有的功能组件做成基于 SPI 实现，并且默认提供了很多可以直接使用的扩展点，实现了面向功能进行拆分的对扩展开放的架构。而 Dubbo SPI 则自己实现了SPI，可以通过名字实例化指定的实现类，并且实现了IOC、AOP 与自适应扩展SPI。

参考文档：https://blog.csdn.net/qq_38249409/article/details/122823277

https://aobing.blog.csdn.net/article/details/108256452

4.Zookeeper 的用途和主要应用场景，基本结构和组件，Leader 选举的过程和实现算法，分布式锁的实现方案。

Zookeeper 的定位是一种分布式协调工具，在分布式系统中应用非常广泛。Zookeeper是一个开源的分布式协调服务框架，主要用来解决分布式集群中应用系统的一致性问题和数据管理问题。

基本结构和组件

 Zookeeper集群是一个基于主从架构的高可用集群，读请求一般为非事务性请求，写请求为事务性请求，follower一般只处理非事务性请求，如果请求一个写则要由follower转发给leader处理。

每个服务器承担如下三种角色的一种：

leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follower以及Observer间的心跳。所有的写操作必须要通过leader完成再由Leader将写操作广播给其他服务器

Follower：一个Zookeeper集群可能同时存在多个Follower，他们会响应Leader的心跳。

Follower可以直接处理并返回客户端的读请求，同时将写请求转发给Leader处理，负责在Leader处理写请求时对请求进行投票

Observer：角色类似于Follower，但无投票权

Leader 选举的过程和实现算法

Leader选举机制是保证分布式数据一致性的关键所在，*选举的三个核心选举原则：*

（1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作；

（2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader；

（3）选出Leader之后，之前的服务器状态由Looking改变为Following，以后的服务器都是Follower。

进行Leader至少需要两台主句，以下以3台为例

一、服务器启动时期的Leader选举

第一台启动时，无法完成Leader选举，第二台启动的时候，两台机器可以互相通信，并试图找Leader，投票则开始

1、每个Server发出一个投票，Server1和Server2都会将自己定为Leader进行投票

投票包含myid（是个权值，越大越占优势）和ZXID（事务ID，值越大数据越新，越占优势），用（myid,ZXID）表示，此时Server1投（1,0）,Server2投（2,0）

后各自发给集群中其他机器

2、接受来自各个服务器的投票，集群中的每个服务器收到投票后，首先判断该投票的有效性，如是否为本轮投票，是否来自LOOKING状态的服务器

3、处理投票。针对每一个投票，服务器都需要将别人投的票和自己投的票进行PK，

规则：

优先检查ZXID，大的优先作为Leader

ZXID相同则比较myid，myid较大的作为Leader

注意：但投票的服务器一定要过半数

这里对于Server1，它投的是（1，0），接收到Server2投的票是（2，0），ZXID都为0，myid Server2的大，于是更新自己的投票为（2，0），变为自己也支持Server2，然后重新投票，对于Server2无需更新，只需再次向集群中所有机器发出上一次的投票信息

4、统计投票

每次投票后，服务器会统计投票信息，判断是否有过半机器收到了相同的投票信息，对于Server1、Server2都统计出了集群中已经有两台机器接受了（2，0）的投票信息，便认为选出了Leader

这时就算是第三台Server3出来了也不会改变投票结果了

5、改变服务器状态，一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变为FOLLOWING，如果是leader就变为LEADING

分布式锁的实现方案

核心的原理还是依赖于临时节点和Watcher 机制

1、排他锁（写锁、独占锁）

（1）、获取锁：在需要排他锁时，所有客户端调用接口在/exclusive_lock节点下创建临时节点exclusive_lock/lock

Zookeeper可以保证只有一个客户端能够创建成功，没有成功需要注册/exclusive_节点监听

（2）释放锁，当获取到锁的占用结束会删除他的临时节点，并通知所有监听客户端，可以重新获取锁

2、共享锁（读锁），当一个事务对数据对象加上共享锁只能做读操作，其他事务也只能加共享锁，直到该对象的所有共享锁都被释放

创建：在/shared_lock下面创建一个临时顺序节点

参考：https://blog.csdn.net/weixin_46919419/article/details/112442388

5. 使用过的消息中间件介绍，涉及 JMS 规范，场景，集群等，主流几种 MOM 如 ActiveMQ、Kafka、RocketMQ 的比较，Zero-Copy 等细节问题。

消息中间件的各项需求：

消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统

主流的几种消息传递规范以及这些规范的基本原理：

JMS：基于JVM消息代理的规范，具有两种通信规范：

1. 队列模式（点对点）

每个消息只有一个消费者（接收者）；

发送者和接收者之间没有时间上的依赖性，也就是说发送者发送了消息之后，不 管接收者有没有在运行，都不会影响到消息被发送到队列；

接收者在成功接受消息之后需要向队列应答成功

1. 主题模式

一个消息可以传递给多个订阅者；

发布者与订阅者具有时间约束，针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态；

AMQP：AMQP是一种协议，更准确的说是一种binary wire-level protocol（链接协议）。最早用于解决金融领不同平台之间的消息传递交互问题。

四种交互类型：

1. 单播

消息中的路由键（routing-key） 如果和Binding中的binding key一致，交换器就发到对应的队列中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n9bXdSIH-1655284538883)(file:///C:\Users\DELL\AppData\Local\Temp\ksohtml15172\wps1.jpg)]

1. 广播

每个发到fanout类型交换器的消息都会分到所有绑定队列上去。fanout交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout类型转发消息是最快的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bpzf2WO9-1655284538884)(file:///C:\Users\DELL\AppData\Local\Temp\ksohtml15172\wps2.jpg)]

1. 有选择的广播

topic交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串分成单词，这些单词用点隔开（a.b）。它同样也会识别两个通配符：符号：# 匹配0或者多个单词，*匹配一个单词。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-28RKDR5r-1655284538884)(file:///C:\Users\DELL\AppData\Local\Temp\ksohtml15172\wps3.jpg)]

1. headers（不常用）

本质上来讲出单播外的其他三种交换方式与JMS中的主题模式没有太大差别，仅是在路由机制上做了更详细的划分。

ActiveMQ、Kafka、RocketMQ 的比较:

	ActiveMQ	Kafka	RocketMQ
公司	Apache	Apache	阿里
开发语言	java	Scala&java	java
可用性	一般	高	高
单机吞吐量	差	非常高	高
消息延迟	毫秒级	毫秒以内	毫秒级
消息可靠性	一般	一般	高

优缺点：

ActiveMQ：

优点：单机吞吐量万级，时效性ms级，可用行高。消息可靠性较好，数据丢失的概率较低

缺点：官方社区现在对ActiveMQ的维护越来越少；不适用于高吞吐量的场景

Kafka：

优点：

1. 为大数据而生的消息中间件，吞吐量非常大，到达百万级；
2. 时效性ms级
3. 可用性非常高
4. Kafka是分布式，一个数据多个副本，少数机器宕机不会丢失数据

缺点：

1. Kafka单机超过64个分区或者队列，Load会发生明显的飙高现象，队伍越多，load越高发送消息的反应时间越长。

RocketMQ:

优点：

1. 吞吐量十万级
2. 可用性非常高
3. 分布式架构，消息可以做到0丢失
4. 不会因为消息堆积导致性能下降

缺点：

1. 支持客户端的语言不多，目前仅有java和C++
2. 社区活跃度一般

Zero-Copy 等细节问题

零复制（英语：Zero-copy；也译零拷贝）技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省CPU周期和内存带宽。

传统的的拷贝需要经历四个：jvm切换到内核态缓冲区读取->操作系统将数据拷贝用户缓冲区–>-再次切换到内核态并将用户缓存区数据拷贝进来->将内核态缓冲区写入socket buffer(cpu参与两次)

零拷贝经历两个：用户->内核态缓冲区（cpu不参与）

6. 缓存系统，Memcached 和 Redis 的选型和特性比较，针对 Redis 的业务场景数据结构建模，lazy-expiration 等细节问题。

Memcached 和 Redis 的选型和特性比较

memached是一套分布式的高速缓存系统。

Redis是一个使用ANSI C编写的开源、支持网络、基于内存、分布式的键值对等数据库。

与memcached相比，Redis功能更强大，更受欢迎并且得到更好的支持。Memcached只能做Redis可以做的一小部分。即使Redis的功能重叠，Redis也更好。

两者比较：

memached：

除了重新启动memcached之外，从来没有真正的方法可以回收任何空间，所有密匙都可能过期

Memcached无法将其转储到磁盘的机制

Memcached是一个简单的易失性缓存服务器。它允许您存储键/值对，其中值限制为最大1MB的字符串。

redis：

设置最大大小由您决定。Redis永远不会使用过多的内存，并且会为您提供不再使用的内存。

Redis在默认情况下会进行磁盘I/O转储，并且具有非常可配置的持久性

Redis也可以充当缓存。它也可以存储键/值对。在redis中，它们甚至可以达到512MB。

针对 Redis 的业务场景数据结构建模

Redis一共有5种数据结构

1. String 字符串类型

使用场景：

可以处理业务上面的的一些访问次数之类的，例如：文章的点赞数，阅读量，允许有一点的延迟效果，先保存到redis中，然后在同步到数据库当中

1. Hash （哈希）

使用场景：

使用hash类型，则可以针对某个属性单独修改，没有序列化，也不需要修改整个对象。比如，商品的价格、销量、关注数、评论数等可能经常发生变化的属性，就适合存储在hash类型里面。

1. 链表

使用场景：

timeline：例如微博的时间轴，有人发布微博，用lpush加入时间轴，展示新的列表信息。

1. Set 集合

使用场景：

标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。

1. zset 有序集合

使用场景：

排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行。

lazy-expiration 等细节问题

Memcached不会监控记录是否过期，而是在外部来获取数据的时候，才检查记录的时间戳，因此称为Lazy Expiration

7. 高并发场景的应对思路和技术

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:

SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡。

8. 服务高可用性设计思路和实现方案

可用性就是一个系统处在可工作状态的时间的比例,这通常被描述为任务可行率。相应的，我们的软件系统处于可工作的时间比例，就是服务的可用性。

系统设计层面：

一、分布式计算

一个高并发的系统，需要对系统功能进行分布式部署，核心生产流程进行异构化。特别是现如今微服务热潮，Docker云，更为分布式部署提供了有利条件。一个电商系统，接受用户订单的功能、并完成支付是优先级最高的，其次是对订单的生产，最后是运营人员对用户订单的管理。那么就可以根据优先级把系统设计成：Web_Tomcat 、Order_Produce、Manager_Tomcat三个子系统。如果再进一步，还可以把支付功能从Web_Tomcat中拆出来，做成Pay_Tomcat四个应用。四个应用共同完成一笔订单交易。

二、多机房入口

用户的请求是从机房进去的，应用部署的再多，入口拥挤，用户请求进不去也是无用。特别是现在动不动就某个机房网络拥堵，动不动就光纤被挖断。增加请求入口，把用户请求分散到多个机房，解决请求入口拥堵问题。只有把这个问题解决了，请求才会打到后端应用上。

三、CDN加速

任何一个互联网系统面向的用户都遍布于地球的每个角落，每个角落的请求到机房可用多种路径可选，正所谓条条大路通罗马，这里是条条路径通机房。其中有速度快的路径有慢的路径，如何选择最优路径，把每个角落的请求快速的传递到机房，这就是CDN的功能。

四、HTML页面静态化

这是最长见的一种优化方式，成本也最低，不需要考虑硬件成本。静态页面部署在NGNIX中，收到用户请求，Ngnix不需要访问Webapp即可响应用户，减少应用渲染页面的时间，同时也降低了应用的压力。

五、Cache

这也是常见的一种优化方式，在数据库层之上加一层缓存，减少对数据库的访问压力。缓存中的数据都是存储在内存里的，而数据库中的数据是写在磁盘上的，访问内存肯定是比访问磁盘快的可不止一个数量级。

六、数据库拆分

当数据量达到某个阀值时，数据库拆分就会成为一个紧急的需求。一般从业务上进行垂直拆分，如果业务单一，也可从水平上进行拆分。拆分的原则一般是：避免跨数据库事务和如何选择shardingId。跨数据库事务可以选择在前期调研时把同一事务中的表放在一个数据库中。如果数据冷热不均shardingId可以是UserPin或者订单号Hash打散后的值，如果数据冷热均匀可以按段分库也可以对某一个值取模后的值。

七、多线程

接下来的方式就是在开发层面上的优化了。现在的机器都是多核的，如果还像之前那样编写串行的代码，那多核机器就是个浪费。如何编写多线程应用比较简单这里就不在赘述了，重点讨论下如何管理线程。线程是机器宝贵且有限的资源，线程数量太多，上下文频繁的切换也会带来性能消耗，太少又不能物尽其用。线程可以交给线程池管理，设置好最大和核心线程数，存活时间等重要参数。

八、CAS指令

九、Nginx反向代理

9. Spring Cloud 的核心组件和基本实现原理

关键思路

Spring Cloud 是微服务架构的代表性实现框架，涉及基础框架 Spring Boot、Spring Cloud Netflix Eureka 与服务治理、Spring Cloud Netflix Ribbon 与负载均衡、Spring Cloud Netflix Hystrix 与服务容错、Spring Cloud Netflix Zuul 与 API 网关、Spring Cloud Config 与配置中心等诸多内容。在面试过程中，面试官的主要切入点还是围绕这些框架的原理进行展开，所以还是需要对服务治理、负载均衡、服务容错、分布式配置等基础性概念有足够的认识，然后再与 Spring Cloud 进行整合

五大组件

• Eureka：注册中心

  作用：实现服务治理（服务注册与发现）

  Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。

  由两个组件组成：Eureka服务端和Eureka客户端。

  Eureka服务端用作服务注册中心。支持集群部署。

  Eureka客户端是一个java客户端，用来处理服务注册与发现。

  在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

• 原理

Eureka作为微服务中的注册中心，其服务注册与发现的原理如下：
首先有两个角色，一个服务端和客户端，服务端就是Eureka本身，客户端就是服务提供者和消费者，当服务提供者启动会将自己的信息注册到Eureka去，消费者启动会去注册中心拉取服务列表缓存到本地，消费者就可以远程调用服务提供者。客户端会与注册中心保持心跳来证明自己存活，每隔30s客户端会发送心跳给注册中心，默认情况下，每隔90s注册中心会检查是否有收到心跳，如果没有收到心跳会将客户端从服务列表剔除。
但是由于服务之间的调用常常会受网络延迟的影响导致心跳没有及时的收到，从而误将客户端剔除，所以Eureka会有自我保护机制来应对这种情况。
默认情况下，Eureka的自我保护机制是开启的。
自我保护机制的触发：在15分钟内，Eureka收到的心跳总数低于总数的85%，就会开启。
自我保护机制的退出：当收到心跳数达到阈值之后，会自动退出自我保护机制。

• 面试题

1.Eureka与Zookeeper的区别在哪？

zookeeper保证的是CP，在Zookeeper集群中，当发生网络故障导致master节点和slave节点失联时，剩余的slave节点会进行leader选举，而在选举的过程中，zookeeper集群不可用，不能对外提供注册和查询的服务。
Eureka保证的是AP，在Eureka集群中，某些节点挂掉，只要有一个Eureka节点存在，就可以对外提供注册和查询服务，但是可能注册信息不是最新的(不保证强一致性)。
2 .Eureka与Nacos的区别？

Nacos既支持AP也支持CP，默认使用AP和Eureka一样。

• gateway/Zuul：服务网关

  Zuul：就是微服务网关，主要是负责网络路由的。

  ​ 浏览器所有请求都需要经过网关，网关就会根据请求中的特征将请求转发后端的各个微服务中。网关还可以做统一的降级，限流，认证授权…

  • 面试题

  Zuul和gateway的区别？

  • Zuul1.0是阻塞式的api，不支持长连接，而gateway支持异步。
  • Zuul没有提供限流、负载均衡等支持，而gateway支持。
  • 它们都是web网关，处理http请求，底层都是servlet。

• Ribbon：负载均衡

  • 原理

  先去本地获取从Eureka缓存下来的服务列表，然后使用负载均衡算法选取一个服务，使用HttpClient进行调用。

  • 面试题

  负载均衡算法有哪些？

  随机、轮询、响应时间权重、重试等，还可以实现IRule接口，自定义负载均衡算法。

• Feign：服务调用(微服务间通信)

  ​

  • 原理

  在配置类上，加上@EnableFeginClients，那么该注解是基于@Import注解，注册有关Fegin的解析注册类，这个类是实现ImportBeanDefinitionRegistrar 这个接口，重写registryBeanDefinition 方法。他会扫描所有加了@FeginClient 的接口，然后针对这个注解的接口生成动态代理，然后你针对fegin的动态代理去调用他方法的时候，此时会在底层生成http

  • 面试题

  1.Ribbon和Feign的区别？

  启动类上加的注解不同，Ribbon用的是@RibbonClients；Feign用的是@EnableFeignClients
  服务的指定位置不同，Ribbon是在@RibbonClient上指定服务名称；Feign是在接上的@FeignClient上指定。
  调用方式不同，Ribbon需要自己构建http请求，模拟http请求，然后使用RestTempate进行调用；Feign采用接口的方式调用。

  2.Feign和OpenFeign的区别？
  OpenFeign在feign的基础上支持了SpringMVC的注解，如@RequestMapping等等，OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

• Hystix：熔断器

Hystix是分布式系统的一个延迟和容错的开源库，它可以进行熔断、降级、限流、监控，可以避免分布式系统的级联故障和雪崩效应。

服务熔断：熔断是直接调用降级方法。不调用目标方法，无需等待接口调用超时才返回结果。
服务降级：降级是调用目标方法，由于目标方法调用超时或者异常，才调用降级方法。
使用：服务降级是在消费端和feign一起使用，默认降级的配置不是开启的(feign.hystrix.enabled=false)，服务熔断是在服务端使用，对服务端的controller进行熔断，默认熔断的配置是开启的(spring.cloud.circuit.breaker.enabled=true)。

• 面试题

1、什么是服务雪崩？

服务雪崩就是服务A调用服务B，服务B调用服务C，服务C挂掉了，导致服务B、C超时受影响，导致服务A也超时，对服务造成级联的影响。即下游服务挂掉或者超时，导致上游调用服务大面积受到影响，阻塞、超时，进而导致雪崩效应。

• Config

SpringcloudConfig是微服务中的配置中心，对微服务中多个自服务的配置进行统一的管理，可以对配置的读取、加密、解密等操作。

• 面试题

1、Config和Nacos的区别？

Config大部分集合git使用，配置动态变更需要依赖SpringCloudBus消息总线来通知所有Client变化；并且没有可视化界面。
Nacos采用长连接，一旦配置变更，会迅速通知Client进行变更，速度较快；提供可视化界面。

10.团队建设方面：如团队规模如何规划，团队成员构成方式，绩效相关工作的开展等。

关键思路

从组织管理角度讲，团队建设属于向下管理的范畴。首先，架构师可以从团队组织结构、工作分析、选择人员、培训人员等角度出发展开这一话题，这是比较容易的一个切入点。其次，需要展现架构师自身的领导力和激励能力，这里面可以提到马斯洛需求层次理论、麦格雷戈的 X-Y 理论、赫茨伯格的双因素理论等主流的激励理论，并结合一定的案例展示自己对团队成员成长和管理上的具体措施。最后，可以结合平时与 HRBP 这边的协作简要介绍绩效管理的要点和实践方法

向下管理

向下管理是组织管理最重要的一个方面，作为技术团队的负责人，通常技术管理者会花费大部分时间在向下管理上。这里“向下”的含义不仅仅是指你的直接下属，在大中型团队中，还可能包含你的间接下属，也就是说技术管理者不仅仅需要管理下面的人，也需要指导下面的人去做向下管理，从而提供整个团队的工作效率。管理应该有好的思路和方法论，但期望这些思路和方法论能按照自己想的那样发挥效果，通常只是一种理想。在职权的范围内充分利用人力和客观条件，并以最小的成本办成所需的事情还需要团队负责人的领导力（Leadership）。同时，领导力和激励（Motivation）是两个相辅相成的一因素，对于软件开发这一特定领域而言，领导力最主要的表现或者说最能发挥其作用的切入点是激励。

详情见

https://gitchat.csdn.net/columnTopic/5a584e2ae286423809d4b130?utm_source=so

11.研发过程管理方面：过程资产建设的含义和实践方式，如何应用工具和流程进行研发知识分享和积累，如何开展 Code Review 和重构等。

研发过程体系建设是一个非常大的主题

• 一方面需要对目前主流的研发过程管理方法论有明确的认识
• 另一方面对具体如何应用这些方法论要有裁剪的意识
• 敏捷方法是当下流行的过程方法论，但敏捷中也有很多派系，例如 Scrum 与过程管理、精益与消除浪费、看板方法与流程管理、极限编程与工程实践等。同时，过程管理很大程度上要实施过程改进，那么就需要对传统CMMI中的过程改进以及敏捷中的过程改进都有一定的了解。最后，作为技术管理者通常还需要开展过程资产建设、过程裁剪以及建设符合自身团队的轻量级过程模型。

过程资产建设的含义和实践方式

含义：过程资产：是指一个学习型组织在项目操作过程中所积累的无形资产。

实践方式：对于快速发展的研发团队而言，过程改进的宗旨是提供轻量级的实施方法，针对没有专设过程改进部门的团队现状，可以通过比较低的代价建立合理的开发流程体系，目标是能达到适合当前团队发展的过程能力。

Code Review的开展（小组会议 team review和 Git 统计进行审查）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S2da8q4n-1655284538888)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20220615143426632.png)]

详情见

https://gitchat.csdn.net/columnTopic/5a584e1be286423809d4b12f?utm_source=so

12.主流方法论方面：对 Scrum、XP、CMMI、PMP、IPD 等研发过程及其改进模型的认识以及应用情况。

关键思路

主流技术管理方法论包括很多分类，每个分类的关注点有所不同，例如 Scrum 和 XP 属于敏捷方法论，CMMI 是一种过程改进模型，PMP 关注于项目管理，而 IPD 则适合与大型团队的产品研发过程。一般在架构师面试中，这些方法论都不会问的太深，主要还是考察基本的概念，如果在基本概念的基础上能够辅助一些具体的案例那基本上就不会有什么问题。

Scrum：迭代式增量软件开发过程

XP：极限编程，强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用

敏捷方法之极限编程(XP)和 Scrum区别

区别之一： 迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。

区别之三: 在迭代中，User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。

区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量

Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。

CMMI：软件能力成熟度模型集成

CMMI 关注人、工具和方法，从无序的初始级开始，建立项目记录、建立稳定一致的过程、以事实为依据达到能够不断创新和改进的持续优化级，将企业过程成熟能力分为五个等级。我们在实施 CMMI 过程改进的关键在于将标准开发过程制度化。

PMP：项目管理专业人士资格认证

IPD：一套产品开发模式

详情见

https://gitchat.csdn.net/columnTopic/5a584e1be286423809d4b12f?utm_source=so

13.项目和产品管理方面：项目生命周期管理，项目和产品的规划和演进过程把控，结合主流方法论进行实施过程中的裁剪等。

关键思路

项目管理同样范围很广，针对架构师工作而言，常见的项目管理维度包括需求管理、计划管理、质量管理、风险管理、交付管理等。这些维度一方面可以是考察项目管理的核心理念，另一方面也会与技术因素进行结合。有些维度比较通用，但有些维度还是要体现出架构师自身一定的理解和实践能力，例如交付管理就需要结合具体的工具、框架以及设计合理的工作流程。

项目管理

项目管理包含一整套知识体系，如业界具有代表性的 PMBOK（Project Management Body Of Knowledge，项目管理知识体系）就是对项目管理所需的知识、技能和工具进行了概括性描述。PMBOK 中包含项目整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和干系人管理等十大知识领域。以上这十大知识领域之间的关系可以见下图。

PMBOK 面向通用的、全行业的项目管理过程，对于软件开发而言，由于一般不涉及到材料的消耗，不需要对成本和采购做专门的管理；人力资源、沟通管理和干系人管理涉及到技术管理者的组织管理和软能力，我们会在下一篇中做这方面的阐述；整合管理的思想贯穿项目管理所有内容，产品和技术之间的融合、系统的集成等都是其具体体现。所以本篇中的项目管理主要针对的是与软件开发和技术管理者日常工作密切相关的知识领域，包括需求管理、计划管理、质量管理和风险管理。

详情见

https://gitchat.csdn.net/columnTopic/5a584e1be286423809d4b12f?utm_source=so

14.个人总结方面：对组织级别的贡献，主导某件事情的过程和体会，个人管理风格、优势劣势分析等。

关键思路

从组织管理角度讲，个人总结属于个人管理的范畴，这也是架构师经常忽略的一个管理维度。个人管理首先体现在个人风格的建设上，可以从 DISC 模型出发探讨如何进行个人分析。更常见的问法是考察架构师处理事情的方式方法，对如何安排事情的优先级、如何进行时间管理、如何开展沟通管理等方面可做进一步展开。

自我管理也是一种管理，而且执行起来可能比上面几个管理都要困难。自我管理的内容也非常多，本篇重点讨论处理事情的方式方法。

作为技术管理者，最重要的工作并不是冲到一线做各种技术研发，而是要处理技术以及一些非技术相关的各项事宜。所以处理事情是自我管理中除了个人风格外的又一个重要主题。处理事情需要做到对时间的合理利用以及对事情的管理和跟踪。

时间“四象限”模型是美国的管理学家科维提出的一个时间管理的理论，把工作按照重要和紧急两个不同的程度进行了划分从而形成四个“象限”，见下图。

对技术管理者而言，每个象限的典型事情如下：

• 既重要又紧急：如用户投诉、线上服务问题、广告运营紧急需求等；
• 重要但不紧急：如建立人际关系、人员培训、制订工作流程等；
• 紧急但不重要：如面试安排、部门会议等；
• 既不紧急也不重要：如邮件处理、写博客等。

将事务按时间“四象限”模型整理，再按适当的优先顺序去安排实施，不仅可以有条有理地处理各项事务，还能节约大量的时间。显然，既重要又紧急的事情不得不先做，既不紧急也不重要的应该后做。关键是如何比较紧急性和重要性，在多数场景下，重要性实际上是优先于紧急性的，即我们平时应该把多数时间放在重要但不紧急的事情上，而不要被太多紧急但不重要的事情占据自己有限的精力，因为不重要的事并不能产生什么大的价值，虽然紧急，但不做也没什么损失，所以还是要先管重要的事情。

技术管理者作为整个技术团队的统一入口和出口，在对每件事情所持有的态度上应该有基本的原则，对重要且紧急的事情应该立刻去做，对重要但不紧急的事情可以有计划的做，对不重要但紧急的事情应该学会委托他人去做，而对不重要不紧急的事情就尽量别做。

以上通过时间管理的理念对做不做事情做了分析，即时间管理的关键是保持一份每天需要完成的待办事项清单，然而跟踪这些待办事项同样重要。正如你向上级汇报一样，需要时刻关注工作完成情况。一般需要维护日常任务清单，这份清单可以通过一些电子化工具在你的工作电脑或手机移动端进行提醒。

详情见

https://gitchat.csdn.net/columnTopic/5a584e3ee286423809d4b13c?utm_source=so