【架构专题】微服务架构

1. 简述什么是微服务？

微服务是一种分布式架构，分布式架构就是把服务做拆分，在我们的传统单体架构中，我们把所有的服务都写在一起，随着业务的扩大我们的代码耦合度会变得越来越高，后期维护起来也很不方便。微服务就是把模块拆分，把我们整个项目拆解分成许多独立的子项目，每个子项目之间独立开发和部署，子项目也有自己独立的功能，这些独立的子项目就形成了微服务，不同的子项目就进而形成一个服务集群。

​ 举例说明：一个商城系统很多模块组成，例如订单模块、用户功能、商品服务、支付模块等，这些模块如果采用单体架构，代码之间的耦合度会非常高，也不便于后期的维护，当一个模块出现问题时整个项目也会受到影响。如果采用微服务，每个模块独立开发，由这些子模块构成整个商城系统，有利于提升我们的开发效率，也便于后期的维护

2. 简述微服务的优缺点 ？

1：微服务的优点：
不同的服务可以使用不同的技术；
隔离性。一个服务不可用不会导致其他服务不可用；
可扩展性。某个服务出现性能瓶颈，只需对此服务进行升级即可；
简化部署。服务的部署是独立的，哪个服务出现问题，只需对此服务进行修改重新部署；

2：微服务的缺点：
网络调用频繁。性能相对函数调用较差。
运维成本增加。系统由多个独立运行的微服务构成，需要设计一个良好的监控系统对各个微服务的运行状态进行监控。

3. 简述分布式和微服务的区别 ？

1、含义不同
微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
分布式架构：分布式系统是若干独立计算机的集合，这些计算机对用户来说就像单个相关系统，即整个系统是由不同的计算机组成，而用户是无感知的，就像访问一台计算机一样。这里强调的是系统由不同物理上分离的计算机（服务器）组成。

2、概念层面不同
微服务架构：微服务是设计层面的东西，一般考虑如何将系统从逻辑上进行拆分，也就是垂直拆分。微服务可以是分布式的，即可以将不同服务部署在不同计算机上，当然如果量小也可以部署在单机上。
分布式架构：分布式是部署层面的东西，即强调物理层面的组成，即系统的各子系统部署在不同计算机上。

3、解决问题不同
微服务架构：微服务解决的是系统复杂度问题： 一般来说是业务问题，即在一个系统中承担职责太多了，需要打散，便于理解和维护，进而提升系统的开发效率和运行效率，微服务一般来说是针对应用层面的。微服务如果用在其它系统，如存储系统感觉怪怪的，就像说Mysql集群是微服务的，总觉得哪里不舒服。
分布式架构：分布式解决的是系统性能问题： 即解决系统部署上单点的问题，尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力。

4、部署方式不同
微服务架构：微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式，它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。
分布式架构：分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。

5、耦合度不同
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

4. 简述微服务的服务怎么划分原则 ？

1：横向拆分：按照不同的业务域进行拆分，例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。
2：纵向拆分：把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。
要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求
总之，微服务的设计一定要 渐进式 的，总的原则是 服务内部高内聚，服务之间低耦合

5. 请列举微服务设计原则 ？

（1）单一职责原则
意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

（2）服务自治原则
意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

（3）轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

（4）接口明确原则
由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

6. 简述微服务之间是如何通讯的？

微服务之间通信方式有以下几种：

1 HTTP/REST API：这是最常见的通信方式，它使用HTTP协议进行通信。每个微服务都可以通过公开API提供数据和操作。这种方式简单易用，适合于独立服务的场景。
2 RPC（Remote Procedure Call）：RPC 是一种远程过程调用协议，它允许不同的进程在网络上相互通信。 RPC 隐藏了底层通信细节，使得远程调用就像本地调用一样自然。目前比较主流的 RPC 框架包括 Dubbo、gRPC 等。
3 消息队列：消息队列是解耦微服务之间通信的一种有效方式。一个微服务将消息发布到队列，其他微服务从队列中订阅消息并处理。这种方式有助于实现异步通信，缓解系统压力。
4 事件驱动架构：事件驱动架构（EDA）确保了微服务之间的松散耦合。一个微服务发送事件，而其他微服务可以订阅该事件并采取相应的行动。这种方式有助于实现实时数据流和反应式编程。

7. 简述微服务通信协议选择的方式以及考虑因素 ？

选择合适的通信协议对于微服务的正常运作非常重要。下面是一些选择协议的指导原则：
考虑应用程序的性能需求。如果你的应用程序需要高速数据传输，那么基于二进制协议的 RPC 或消息队列可能会更好。
考虑代码的可读性和可维护性。如果你希望代码易于阅读和理解，那么 HTTP/REST API 可能更适合。
考虑团队技能。选择一种与团队技能相关的协议可以使开发更加顺畅

8. 请简述微服务中各组件的作用 ？

注册中心：记录微服务中每个服务的ip、端口、能干什么事等信息。（我们调用微服务中的某个服务时，可能服务A需要调用服务B，服务B需要调用服务发现，注册中心负责记录服务之间的调用关系，我们调用服务时找注册中心就可以了）。
配置中心：统一管理每个服务的配置信息，如果需要变更某个服务的配置信息，只需找到配置中心即可。
网关服务：形如小区保安，能对用户身份做校验，另一方面可以把用户的请求路由到具体的服务中去。

9. 简述什么是服务注册与发现 ？

服务消费者找到服务提供者的这种机制称为服务发现，又或者服务注册
服务发现组件应具备以下功能：
服务注册表：服务注册表是服务发现组件的核心（其实就是类似于上面的registry表），它用来记录各个微服务的信息，例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册和注销；
服务注册与服务发现：服务注册是指微服务在启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制；
服务检查：服务发现组件使用一定机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表中移除该实例

10. 请列举常用的服务注册发现的组件 ？

我们通常使用以下组件：
（1）ZooKeeper：ZooKeeper 是一个具有高可用性和可扩展性的分布式协调服务。它可以用于服务注册和发现，以及配置管理。
（2）etcd：etcd 是一个分布式键值存储系统，用于服务注册和发现，并提供强一致性保证。
（3）Consul: Consul 是一个分布式服务发现和配置管理系统。它支持多数据中心、健康检查和负载均衡等功能。

11. 简述什么是服务调用 ？

服务调用，即一个服务调用另一个服务，此过程可以分为服务调用者、服务提供者。基本上都会使用注册中心来作为中间件。
地址硬编码即将微服务的IP、端口号、请求url等具体的api地址通过代码的形式写在调用者服务中。
平常的单体应用中，客户端访问应用api即可取得数据；在微服务中，服务调用其它服务的api，就可以获取其数据，这样做的好处在于服务细分化，即将一个服务拆分为很多小服务。

12. 请列举常用的服务调用组件 ？

服务调用是微服务之间通信的另一个重要组件。它包括客户端负载均衡、服务降级、熔断和容错等功能。为了实现服务调用，我们通常使用以下组件：
（1）Ribbon：Ribbon 是一个负载均衡器，它可以帮助我们在集群中平衡负载。它支持多种负载算法和服务发现，可以与Eureka等注册中心集成。
（2）Feign：Feign 是一个声明式的 REST 客户端，它使编写 REST 客户端变得更加简单。我们可以使用注解来定义需要访问的服务接口，并且在运行时自动生成实现代码。
（3）Hystrix：Hystrix 是一种容错和熔断框架，它可以帮助我们处理分布式系统中的故障，并防止故障扩散。Hystrix 通过控制线程池和请求队列来实现熔断机制，从而避免系统崩溃。
（4）Resilience4j：Resilience4j 是一个轻量级的容错库，它提供了诸如熔断、超时、重试和限流等功能。与Hystrix相比，Resilience4j提供了更为灵活和集成化的解决方案。

13. 简述什么服务降级 ？

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。**降级的核心思想就是丢车保帅，优先保证核心业务。**例如，对于教育类App学习主链路是核心服务，其他的各种礼品活动弹窗，老师点评服务等如果出问题后不应该影响主学习链路，这时可以停掉这些非核心服务。常见的实现降级的方式有：

1 系统后门（配置）降级
为每一个可降级服务提供一个业务开关配置，在业务出现故障后通过切换业务开关配置进行手动降级，但主要缺点是如果服务器数量多，需要一台一台去操作，效率比较低，这在故障处理争分夺秒的场景下是比较浪费时间的。
2 独立降级系统
为了解决系统后门降级方式的缺点，将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能，但引入独立系统运维，集成等复杂度会相应提高 Hystrix,sentinel等都有相应功能实现

14. 简述什么熔断机制 ？

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。
这种牺牲局部，保全整体的措施就叫做熔断

15. 简述熔断有哪几种状态 ？

熔断有三种状态：
1.Closed：关闭状态，所有请求都正常访问。
2.Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
3.Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时
实际上服务熔断 和 服务降级 没有任何关系，就像 java 和 javaScript
服务熔断，有点自我恢复的味道

16. 解释服务熔断原理(断路器的原理) ？

统计用户在指定的时间范围（默认10s）之内的请求总数达到指定的数量之后，如果不健康的请求(超时、异常)占总请求数量的百分比（50%）
达到了指定的阈值之后，就会触发熔断。触发熔断，断路器就会打开(open),此时所有请求都不能通过。在5s之后，断路器
会恢复到半开状态(half open)，会允许少量请求通过，如果这些请求都是健康的，那么断路器会回到关闭状态(close).如果
这些请求还是失败的请求,断路器还是恢复到打开的状态(open).

17. 简单描述降级,熔断, 限流区别 ？

降级: 临时关闭不重要的服务, 把资源留给核心功能
熔断: 依赖服务不可用时, 短时间内不再请求, 避免上游服务雪崩
限流: 超出流量限制时, 拒绝服务, 避免程序无法及时处理请求, 导致请求堆积, 服务器崩溃

18. 简述什么是限流 ？

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。根据限流作用范围，可以分为单机限流和分布式限流；根据限流方式，又分为计数器、滑动窗口、漏桶限令牌桶限流。
限流一般都是系统内实现的，大致可以分为两类：
1 基于请求限流
基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量。
2 基于资源限流
基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即：找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列等。

19. 如何保障微服务通信安全 ？

微服务之间通信的安全性是至关重要的。以下是实现微服务通信安全的一些最佳实践：

1 使用HTTPS协议进行通信，确保数据传输的安全。
2 实现身份验证和授权机制，以确保只有经过身份验证的用户才能访问服务。
3 隐藏内部服务细节，避免将敏感信息暴露给外界。
4 实现API网关，限制对内部服务的访问。
5 对于敏感数据，建议进行加密处理，确保不会被窃取或篡改。

20. 简述微服务中的API定义？

API或接口是软件开发的中心。一个应用由一到多个模块构成(对微服务架构来说，这里的模块就是指组件，也即微服务)，每个模块都有接口，这些接口定义了该模块支持的操作。一个设计良好的接口会在暴露有用功能的同时隐藏实现细节。因此，接口实现的细节可以被修改，而接口保持不变，这样就不会对客户端产生影响。也就是，接口一旦公布出去，在后续的维护过程中，必须保证接口的向下兼容。对于无法兼容的能力，则必须新开接口。
对微服务架构来说，服务的API是服务与其客户端之间的契约(contract)。这里的API可能包含向客户端提供的方法或服务发布的事件。方法具备名称、参数和返回类型。事件具有一个类型和一组字段，可发布到消息通道。
对于微服务架构，其挑战在于：服务和它的客户端并不会一起编译。如果使用不兼容的API部署新版本的服务，虽然在编译阶段不会出现错误，但是会出现运行时故障。
无论选择哪种进程间通信机制，使用某种接口定义语言(Interface Define Language, IDL)精确定义服务的API都很重要。在日常的开发中，首先后端开发人员编写接口定义，然后与设计人员、客户端开发人员一起评审该接口定义文档。只有确定API定义后，后端开发人员和前端开发人员才真正启动编程工作。这种预先设计有助于帮助构建满足客户端需求的接口。这种模式也称为"API设计优先模式"。在前后端分离的阶段，这种方式可以大大弱化前端对后端的依赖，实现一定程度的并行开发，提供工作效率。
如何定义API取决于使用的进程间通信机制。如使用消息通信机制，则API由消息通道、消息类型和消息格式组成。在基于Kafka的消息通信中，Protocol Buffers已成为IDL的推荐方式。如使用HTTP，则API由URL、HTTP动词以及请求和响应格式组成。在基于Java Web的开发中，Swagger的yaml已成为IDL的推荐方式。

21. 简述什么是服务网关 ？

网关就是要去别的网络的时候，把报文首先发送到的那台设备。稍微专业一点的术语，网关就是当前主机的默认路由。
网关一般就是一台路由器，有点像“一个小区中的一个邮局”，小区里面的住户互相是知道怎么走，但是要向外地投递东西就不知道了，怎么办？把地址写好送到本小区的邮局就好了。
那么，怎么区分是“本小区”和“外地小区”的呢？根据IP地址 + 掩码。如果是在一个范围内的，就是本小区（局域网内部），如果掩不住的，就是外地的。
例如，你的机器的IP地址是：192.168.0.2/24，网关是192.168.0.1
如果机器访问的IP地址范围是：192.168.0.1~192.168.0.254的，说明是一个小区的邻居，你的机器就直接发送了（和网关没任何关系）。如果你访问的IP地址不是这个范围的，则就投递到192.168.0.1上，让这台设备来转发。

22. 简述什么是API网关 ？

假设你正在开发一个电商网站，那么这里会涉及到很多后端的微服务，比如会员、商品、推荐服务等等。
那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:
每个业务都会需要鉴权、限流、权限校验等逻辑，如果每个业务都各自为战，自己造轮子实现一遍，会很蛋疼，完全可以抽出来，放到一个统一的地方去做。
如果业务量比较简单的话，这种方式前期不会有什么问题，但随着业务越来越复杂，比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作，如果每一个微服务都分配一个域名的话，一方面客户端代码会很难维护，涉及到数百个域名
每上线一个新的服务，都需要运维参与，申请域名、配置Nginx等，当上线、下线服务器时，同样也需要运维参与，另外采用域名这种方式，对于环境的隔离也不太友好，调用者需要自己根据域名自己进行判断。
另外还有一个问题，后端每个微服务可能采用了不同的协议，比如HTTP、AMQP、自定义TCP协议等，但是你不可能要求客户端去适配这么多种协议，这是一项非常有挑战的工作，项目会变的非常复杂且很难维护。
更好的方式是采用API网关（也叫做服务网关），实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。
通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。
网关层通常以集群的形式存在。并在服务网关层前通常会加上Nginx 用来负载均衡。

23. 请列举服务网关基本功能 ？

1 路由功能：路由是微服务网关的核心能力。通过路由功能微服务网关可以将请求转发到目标微服务。在微服务架构中，网关可以结合注册中心的动态服务发现，实现对后端服务的发现，调用方只需要知道网关对外暴露的服务API就可以透明地访问后端微服务。
负载均衡：API网关结合负载均衡技术，利用Eureka或者Consul等服务发现工具，通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡。

2 统一鉴权：一般而言，无论对内网还是外网的接口都需要做用户身份认证，而用户认证在一些规模较大的系统中都会采用统一的单点登录（Single Sign On）系统，如果每个微服务都要对接单点登录系统，那么显然比较浪费资源且开发效率低。API网关是统一管理安全性的绝佳场所，可以将认证的部分抽取到网关层，微服务系统无须关注认证的逻辑，只关注自身业务即可。
协议转换：API网关的一大作用在于构建异构系统，API网关作为单一入口，通过协议转换整合后台基于REST、AMQP、Dubbo等不同风格和实现技术的微服务，面向Web Mobile、开放平台等特定客户端提供统一服务。

3 指标监控：网关可以统计后端服务的请求次数，并且可以实时地更新当前的流量健康状态，可以对URL粒度的服务进行延迟统计，也可以使用Hystrix Dashboard查看后端服务的流量状态及是否有熔断发生。
限流熔断：在某些场景下需要控制客户端的访问次数和访问频率，一些高并发系统有时还会有限流的需求。在网关上可以配置一个阈值，当请求数超过阈值时就直接返回错误而不继续访问后台服务。当出现流量洪峰或者后端服务出现延迟或故障时，网关能够主动进行熔断，保护后端服务，并保持前端用户体验良好。

4 黑白名单：微服务网关可以使用系统黑名单，过滤HTTP请求特征，拦截异常客户端的请求，例如DDoS攻击等侵蚀带宽或资源迫使服务中断等行为，可以在网关层面进行拦截过滤。比较常见的拦截策略是根据IP地址增加黑名单。在存在鉴权管理的路由服务中可以通过设置白名单跳过鉴权管理而直接访问后端服务资源。

5 灰度发布：微服务网关可以根据HTTP请求中的特殊标记和后端服务列表元数据标识进行流量控制，实现在用户无感知的情况下完成灰度发布。

6 流量染色：和灰度发布的原理相似，网关可以根据HTTP请求的Host、Head、Agent等标识对请求进行染色，有了网关的流量染色功能，我们可以对服务后续的调用链路进行跟踪，对服务延迟及服务运行状况进行进一步的链路分析。

7 文档中心：网关结合Swagger，可以将后端的微服务暴露给网关，网关作为统一的入口给接口的使用方提供查看后端服务的API规范，不需要知道每一个后端微服务的Swagger地址，这样网关起到了对后端API聚合的效果。

8 日志审计：微服务网关可以作为统一的日志记录和收集器，对服务URL粒度的日志请求信息和响应信息进行拦截。

24. 简述市面常用微服务框架 ？

Spring Cloud：基于Spring Boot的微服务框架，提供了一系列工具和技术来支持分布式系统的开发。
Kubernetes：一个开源的容器编排工具，可以帮助开发人员快速部署和管理微服务。
Netflix OSS：Netflix开源的一组工具和框架，用于构建和运行分布式系统。
Istio：一个开源的服务网格框架，提供了路由、流量管理、监控等功能，帮助开发人员更好地管理微服务。
Envoy：一个开源的服务网格代理，可以帮助开发人员构建和管理分布式系统。
Linkerd：一个开源的服务网格工具，帮助开发人员更好地管理微服务。

25. 简述微服务中基本概念消费者与提供者 ？

服务提供者：提供接口给其他微服务调用。
服务消费者：调用其他微服务的接口。
一个微服务既可以是消费者，也可以是提供者，例如服务A调用服务B，服务B又调用服务C，因此B即使消费者又是提供者。对于一个微服务具体是消费者还是提供者，是相对的。

26. 请列举目前的主流服务网关有哪些 ？

1、Nginx
2、Zuul
3、SpringCloud Gateway
4、Kong
5、Traefik
6、OpenResty

27. 简述SpringCloud Alibaba的整体架构 ？

SpringCloud Alibaba
Spring Cloud Alibaba 是Spring Cloud的一个子项目，致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba 默认提供了如下核心功能：

服务限流降级：
默认支持 WebServlet、OpenFeign、RestTemplate、Spring Cloud Gateway, RocketMQ限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级Metrics 监控。
服务注册与发现：
基于Spring Cloud 服务注册与发现标准，借助Nacos进行实现，默认还集成了 Ribbon 的支持。
分布式配置管理：
基于Nacos支持分布式系统中的外部化配置，配置更改时自动刷新。
消息驱动能力：
基于Spring Cloud Stream 为微服务应用构建消息驱动能力。
分布式事务：
使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。。
分布式任务调度：
提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker上执行。

28. 解释设计微服务的最佳实践是什么？

1 为每个微服务分开数据存储
2 将代码保持在类似的成熟度等级上
3 为每个微服务进行单独的构建
4 部署到容器中
5 将服务器视为无状态的

29. 详细阐述微服务特点和重要特性 ？

1 解耦（Decoupling） - 系统内的服务很大程度上是分离的。因此整个应用可以被轻松构建、修改和扩展
2 组件化（Componentization） - 微服务被视为可以被轻松替换和升级的独立组件
3 业务能力（Business Capabilities） - 微服务非常简单，专注于单一功能
4 自治（Autonomy） - 开发人员和团队可以相互独立工作，从而提高效率
5 持续交付（ContinousDelivery） - 允许频繁发版，通过系统自动化完成对软件的创建、测试和审核，
6 责任（Responsibility） - 微服务不把程序作为项目去关注。相反，他们将程序视为自己负责的产品
7 分散治理（Decentralized Governance） - 重点是用正确的工具去做正确的事。这意味着没有任何标准化模式或着技术模式。开发人员可以自由8 8 选择最合适的工具来解决自己的问题
9 敏捷性（Agility） - 微服务支持敏捷开发。任何新功能都可以快速开发并被再次丢弃

30. 简述使用微服务架构时，你面临的挑战是什么？

开发较小的微服务听起来很容易，但在开发时会经常遇到一些挑战。
1 自动化组件：难以自动化，因为有许多较小的组件。对于每个组件，都必须采取构建、发布和监控的步骤。
2 可感知性：将大量组件维持在一起会带来难以部署、维护、监控和识别的问题。它需要在所有组件周围具有很好的感知能力。
3 配置管理：有时在各种环境中维护组件的配置会很困难。
4 调试：很难找到与产生的错误相关的每一项服务。维护一个集中式的日志和控制面板对调试问题至关重要。

31. 详细阐述SOA 和微服务架构之间的主要区别 ？

SOA架构
SOA是面向服务的架构，它是一种设计方法，设计通常是自上而下的，服务之间松散耦合，ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展。
SOA架构有以下优点:
1 系统集成：在系统的角度，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
2 系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
3 业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
同样的，SOA架构与单体应用相比，其实还是存在中心化的一个问题，说简单点就是依旧是共用一套数据库，这里并不是说这样不好。这样的SOA架构更多的是面向于企业服务，服务的拆分粒度很大，更多的是为了复用。
于是在这个基础上，微服务产生了。

微服务
其实微服务就是去中心化的SOA扩展，每个微服务有自己独立的数据库，它强调服务彻底点组件化，一个组件就是一个服务，服务的切分粒度更小。服务之间通过轻量化的协议进行通信，可以根据服务本身独立化部署。
所以微服务有以下特点:
1.服务拆分粒度更小，每个微服务都需要满足单一职责原则，微服务本身是内聚的，因此微服务通常比较小。比如示例中每个微服务按业务逻辑划分，每个微服务仅负责自己归属于自己业务领域的功能。
2.去中性化，进一步拆分了服务间的耦合度。
3.灵活组合，在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的。
4.技术异构，在一个大型系统中，不同的功能具有不同的特点，并且不同的团队可能具备不同的技术能力。因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。有利于系统的演进。
但是这样的设计也会带来一些其他的问题

微服务的缺点
1 复杂度高
微服务间通过REST、RPC等形式交互，相对于Monolithic模式下的API形式，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂。
2 对于微服务间的事务性操作，因为不同的微服务采用了不同的数据库，将无法利用数据库本身的事务机制保证一致性，需要引入二阶段提交等技术。同时，在微服务间存在少部分共用功能但又无法提取成微服务时，各个微服务对于这部分功能通常需要重复开发，或至少要做代码复制，以避免微服务间的耦合，增加了开发成本。
3 运维复杂
在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。
4 影响性能
相对于SOA和单体应用架构，微服务的间通过REST、RPC等形式进行交互，通信的时延会受到较大的影响

32. 简述领域驱动设计（DDD）？

DDD 全称是 Domain-Driven Design，是一套应对复杂软件系统分析和设计的面向对象建模方法论。
它是一种处理高度复杂领域的设计思想，不是一种架构，而是一种架构设计方法论，是一种设计模式。说白了就是把一个复杂的软件应用系统的其中各个部分进行一个很好的拆解和封装，以达到高内聚低耦合的这样一个效果。
虽然在开发速度上有一定优势，如果只追求开发速度，面向数据模型编程在短期之内可以搞定需求，但一味追求速度，如果你系统的业务变化快速，从长远来看随着时间的增长，系统堆了杂七杂八以后，MVC的短板就会日益明显。
比如MVC开发模式一些常见的问题有：
新需求的开发会越来越难。
代码维护越来越难，一个类代码太多，这怎么看对吧，就是一堆屎山。
技术创新越来越难，代码没时间重构，越拖越烂。
测试越来越难，没办法单元测试，一个小需求又要回归测试，太累。
而DDD开发模式的出现就是为了解决这些问题，从一个软件系统的长期价值来看，就需要用DDD开发模式，虽然一开始从设计到开发需要成本，但是随着时间的增长，N年以后代码依然很整洁，利于扩展和维护，高度自治，高度内聚，边界领域划分的很清楚

33. 为什么需要域驱动设计（DDD）？

“即使我们的软件中没有bug，也不能表示我们设计的软件模型本身就是好的”。使用DDD，能够让我们的软件设计更加合理，但不止于此。
对于一个业务复杂的系统而言，使用DDD有如下好处：

开发者和熟悉业务的人一起工作，加强团队间不同角色的合作；
能够帮助业务人员和开发人员梳理清楚复杂的业务规则；
开发出来的软件是能够准确表达业务规则的，设计就是代码，代码就是设计；

34. 简述什么时候需要使用DDD？

使用DDD是有一些成本的，你的团队成员需要去了解DDD的一些基础知识，最好还需要有人做过DDD方面的实践，有一定的经验。
做任何事情都需要衡量成本和收益，技术方案的选型也不例外。DDD有一定的成本，但也能带给我们显而易见的收益。
一般来说，DDD适用于“业务复杂”的且“需要维护和扩展”的系统。
首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。
从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。
另一方面来说，即使现在这个软件并不复杂，但后续会进行开发和扩展，在可以预见的将来，它会变得复杂，那也可以考虑使用DDD。而一些初创公司，它们或许只需要一个简单的产品来快速测试市场反馈，后续并不会继续开发和维护，而是考虑重新购买或者从头开发的话，那也没有必要浪费成本去使用DDD。
所以再次总结我们什么时候需要使用DDD呢？业务复杂且需要长期维护的时候。

35. 简述什么是通用语言（UL）？

如果你必须定义通用语言（UL），那么它是特定域的开发人员和用户使用的通用语言，通过该语言可以轻松解释领域。
通用语言必须非常清晰，以便将所有团队成员处于同一水平线上，并以机器可以理解的方式进行翻译。

36. 简述REST/RESTful ？它的用途是什么？

Representational State Transfer（REST）/ RESTful （表述性状态转移）是一种帮助计算机系统通过 Internet 进行通信的架构风格。这使得微服务更容易理解和实现。
微服务可以用 RESTful API 来实现，当然也可以不用，但是用 RESTful API 去构建松散耦合的微服务总是更容易些

37. 简述关于 Rest 和微服务的要点？

REST
虽然你可以通过多种方式实现微服务，但 REST over HTTP 是实现微服务的一种方式。 REST 还用于其他应用程序，如 Web 应用、API 设计和 MV C应用以提供业务数据。

微服务
微服务是一种体系结构，其中系统的所有组件都被放入单独的组件中，这些组件可以单独构建、部署和扩展。微服务的某些原则和最佳实践有助于构建弹性应用程序。
简而言之，你可以认为 REST 是构建微服务的媒介。

38. 简述什么是不同类型的微服务测试？

在使用微服务时，由于有多个微服务协同工作，测试变得非常复杂。因此，测试分为不同的级别。
1 在底层，我们有面向技术的测试 —— 单元测试和性能测试。这些是完全自动化的。
2 在中间层，我们有探测性测试，如压力测试和可用性测试。
3 在顶级，我们有很少的验收测试。这些验收测试有助于利益相关者理解和验证软件功能。

39. 简述什么是幂等性（Idempotence）？

幂等性是能够以同样的方式做两次，而最终结果将保持不变，就好像它只做了一次的特性。
用法：在远程服务或数据源中使用幂等性，以便当它多次接收指令时，只处理一次

40. 简述什么是DDD有界上下文？

有界上下文是领域驱动设计中的中心模式。 它们可以将大型应用程序或组织分解为独立的概念模块，通过这种方式来解决复杂性问题。 每个概念模块表示各自独立的上下文（因此有界），并且可以独立改进。 理想情况下，每个有界上下文都应该能够为其中的概念自由选择它自己的名称，并对其自己的持久性存储具有独占访问权限。

至少，各 Web 应用程序应努力成为自己的有界上下文，为其业务模型提供自己的持久性存储，而不是与其他应用程序共享数据库。 有界上下文之间的通信通过编程接口进行，而不是通过共享数据库进行，这样可以引发业务逻辑和事件来响应发生的更改。 有界上下文会紧密映射到微服务，后者在理想情况下也作为其自己的单独有界上下文实现。

41. 简述 PACT 在微服务架构中的用途是什么？

PACT 是一个开源工具，允许测试服务提供者和消费者之间的交互，与契约隔离，从而提高微服务集成的可靠性。
在微服务中的用法：
用于在微服务中实现消费者驱动的契约。
测试微服务的消费者和生产者之间的消费者驱动的契约。

42. 简述契约测试（contract test）是什么？

根据 Martin Flower 的说法，契约测试是在外部服务边界进行的测试，用于验证其是否符合消费者服务预期的契约。
此外，契约测试不会深入测试服务的行为。相反，它测试服务调用的输入和输出包含所需的属性和响应延迟，吞吐量在允许的限制范围内。

43. 简述什么是端到端微服务测试？

端到端测试验证了工作流中的每个流程都正常运行。这可确保系统作为一个整体协同工作并满足所有要求。
通俗地说，你可以说端到端测试是一种测试，在特定时期后测试所有东西

44. 简述容器在微服务中的用途是什么？

容器是管理基于微服务的程序以便单独开发和部署它们的好方法。你可以将微服务封装在容器镜像及其依赖项中，然后可以用它来滚动开发按需实例的微服务而无需任何额外的工作

45. 解释微服务架构中的DRY是什么？

DRY 代表不要重复自己。它基本上促进了重用代码的概念。这导致开发和共享库，
这反过来导致紧密耦合。

46. 简述消费者驱动的契约（CDC）是什么？

这基本上是用于开发微服务的模式，以便它们可以被外部系统使用。当我们处理微服务时，有一个特定的生产者者构建它，并且有一个或多个使用微服务的消费者。
通常，生产者程序在 XML 文档中指定接口。但在消费者驱动的契约中，每个服务的消费者都传达了生产者期望的接口。

47. 简述微服务架构中的语义监控是什么？

语义监控，也称为 综合监控， 将自动化测试与监控应用程序相结合，以检测业务因素失败。

48. 简述微服务中的反应性扩展是什么？

Reactive Extensions 也称为Rx。这是一种设计方法，我们通过调用多个服务来收集结果，然后编译组合响应。这些调用可以是同步或异步，阻塞或非阻塞。 Rx 是分布式系统中非常流行的工具，与传统流程相反

49. Web, RESTful API在微服务中的作用是什么?

微服务架构基于一个概念，其中所有服务应该能够彼此交互以构建业务功能。因此，要实现这一点，每个微服务必须具有接口。这使得 Web API 成为微服务的一个非常重要的推动者。RESTful API 基于 Web 的开放网络原则，为构建微服务架构的各个组件之间的接口提供了最合理的模型

50. 简述什么是微服务中服务配置统一管理 ？

在微服务架构中，微服务的统一配置管理一般有以下需求：
集中管理配置：一个使用微服务架构的应用系统可能会包括成千上万个微服务，因此集中管理配置是非常有必要的。
不同环境不同配置：例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的。
运行期间可动态调整：例如，可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不重启微服务。
配置修改后自动更新：如配置内容发生变化，微服务能够自动更新配置。
综上所述，对于微服务架构而言，一个通用的配置管理机制必不可少，常见做法是使用配置服务器管理配置

51. 简述服务链路追踪以及实现机制 ？

链路追踪是分布式系统下的一个概念，它的目的就是要解决上面所提出的问题，也就是将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，比如，各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。
微服务这种架构下的几个痛点：
1、排查问题难度大，周期长
2、特定场景难复现
3、系统性能瓶颈分析较难
在微服务架构下，当有用户反馈某个页面很慢时，虽然我们知道这个请求可能的调用链是 A -----> C -----> B -----> D，但服务这么多，而且每个服务都有好几台机器，怎么知道问题具体出在哪个服务？哪台机器呢？
分布式调用链就是为了解决以上几个问题而生，它主要的作用如下：
1、自动采取数据
2、分析数据，产生完整调用链：有了请求的完整调用链，问题有很大概率可复现
3、数据可视化：每个组件的性能可视化，能帮助我们很好地定位系统的瓶颈，及时找出问题所在
通过分布式追踪系统，我们能很好地定位请求的每条具体请求链路，从而轻易地实现请求链路追踪，进而定位和分析每个模块的性能瓶颈。

52. 阐述Zookeeper、Eureka、Consul、Nacos对比区别 ？

Zookeeper 是⼀款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长⼀段时间里，它是国人在提起 RPC 服务注册中心时心里想到的唯⼀选择。
Eureka 借着微服务概念的流行，与 SpringCloud 生态的深度结合，也获取了大量的用户。
Consul 在设计上把很多分布式服务治理上要用到的功能都包含在内，可以支持服务注册、健康检查、配置管理、Service Mesh 等。
Nacos 携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户⼀个新的选择。

数据模型
Zookeeper 没有针对服务发现设计数据模型，它的数据是以⼀种更加抽象的树形 K-V 组织的，因此理论上可以存储任何语义的数据。
Eureka 和 Consul 都是做到了实例级别的数据扩展，这可以满足大部分的场景，不过无法满足大规模和多环境的服务数据存储。
Nacos 是⼀种服务-集群-实例的三层模型。基本可以满足服务在所有场景下的数据存储和管理。

数据⼀致性
从协议层面上看，⼀致性的选型目前就两种：⼀种是基于 Leader 的非对等部署的单点写⼀致性，⼀种是对等部署的多写⼀致性。

Zookeeper 是CP，采用自定义的 ZAB 协议保证数据的强⼀致。Zookeeper 在 Dubbo 体系下表现出的行为，其实采用 Eureka 的 Renew 机制更加合适，因为 Dubbo 服务往 Zookeeper 注册的就是临时节点，需要定时发心跳到 Zookeeper 来续约节点，并允许服务下线时，将 Zookeeper 上相应的节点摘除。
Eureka 是AP，节点都是对等的，通过相互注册提高可用性，通过renew机制进行数据的最终修复。
Consul 是CP，基于Raft协议保证数据的强一致性。
Nacos 同时支持 CP 和 AP ，⼀个是基于简化的 Raft 的 CP ⼀致性，⼀个是基于自研协议 Distro 的 AP ⼀致性。

负载均衡
Zookeeper 不支持。
Eureka 本身不支持，通过Ribbon做负载均衡。Ribbon是客户端负载均衡，主要通过 IRule、ServerListFilter 等接口实现，Ribbon采用的是两步负载均衡，第⼀步是先过滤掉不会采用的服务提供者实例，第二步是在过滤后的服务提供者实例里，实施负载均衡策略。
Consul 本身不支持，通过Fabio做负载均衡。
Nacos 本身具备负载均衡能力，可以提供服务端负载均衡与客户端负载均衡。

健康检查
服务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测，这两种探测方式因为其协议的通用性可以支持绝大多数的健康检查场景。Zookeeper 和 Eureka 都实现了⼀种 TTL(Time To Live)机制，就是如果客户端在⼀定时间内没有向注册中心发送心跳，则会将这个客户端摘除。

Zookeeper 使用TCP的KeepAlive保持客户端和服务端的连接。
Eureka 通过客户端心跳来确定客户端是否启动。
Consul 通过check方法实现健康检查，check方法有五种：Script + Interval、HTTP + Interval、TCP+ Interval、Docker + interval、TTL。
Nacos 既支持客户端的健康检查（KeepAlive、Client Beet），也支持服务端的健康检查（MYSQL命令等）。

性能与容量
影响读写性能的因素很多：⼀致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计等等。并非性能越高就越好，因为追求性能往往需要其他方面做出牺牲。

Zookeeper 在写性能可以达到上万的 TPS，容量从存储节点数来说可以达到百万级别。不过 Paxos 协议限制了 Zookeeper 集群的规模（3、5个节点）。当大量实例上下线时，Zookeeper 的表现并不稳定，同时在推送机制上的缺陷，会引起客户端的资源占用上升，从而性能急剧下降。
Eureka 在服务实例规模在 5000 左右的时候，就已经出现服务不可用的问题，甚至在压测的过程中，如果并发的线程数过高，就会造成 Eureka crash。
Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上。