微服务专题

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. 请简述微服务中各组件的作用 ？

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

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

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

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

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

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

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

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

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

12. 简述什么服务降级 ？

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

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

13. 简述什么熔断机制 ？

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

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

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

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

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

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

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

17. 简述什么是限流 ？

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

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

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

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

19. 简述微服务中的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的推荐方式。

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

网关就是要去别的网络的时候，把报文首先发送到的那台设备。稍微专业一点的术语，网关就是当前主机的默认路由。
网关一般就是一台路由器，有点像“一个小区中的一个邮局”，小区里面的住户互相是知道怎么走，但是要向外地投递东西就不知道了，怎么办？把地址写好送到本小区的邮局就好了。
那么，怎么区分是“本小区”和“外地小区”的呢？根据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上，让这台设备来转发。

21. 简述什么是API网关 ？

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

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

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粒度的日志请求信息和响应信息进行拦截。

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

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

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

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

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

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

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

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

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

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

28. 详细阐述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等形式进行交互，通信的时延会受到较大的影响

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

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

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

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

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

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

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

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

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