微服务面试题
微服务面试题
微服务架构是什么？
一句话解释：微服务架构是一种将应用程序拆分为小而自治的服务的软件架构模式。每个服务专注于执行特定的业务功能，并通过轻量级的通信机制进行交互。它提供了独立开发、可扩展和技术多样性的优势。
在微服务架构中，应用程序被拆分为一组小型、独立的服务，每个服务都专注于执行特定的业务功能。这些服务之间通过轻量级的通信机制进行交互，例如使用 HTTP/REST、消息队列或者事件总线。
每个微服务都有自己的代码库、数据库和部署单元。它们可以使用不同的编程语言和技术栈，根据自己的需求进行独立开发、测试和部署。每个微服务负责处理特定的业务领域，例如用户管理、订单处理或支付服务。
通过将应用程序拆分为多个小而自治的服务，微服务架构提供了一些优势：
独立开发和部署：每个微服务都可以独立开发、测试和部署，使团队能够更快速地迭代和交付功能。
松耦合和可扩展性：微服务之间通过轻量级的通信进行交互，它们之间的耦合度较低。这使得系统更容易扩展，可以根据需要对实例进行扩缩容。
技术多样性：由于每个微服务可以使用不同的技术栈，团队可以选择最适合其需求的技术和工具。
弹性和容错性：由于每个微服务是独立的，一个微服务的故障不会影响整个系统的稳定性，系统可以更好地应对故障和恢复。
虽然有许多优势，但同时也引入了不少复杂性和管理开销。微服务架构需要服务发现、负载均衡、监控和日志等基础设施的支持。同时由于服务个数变多，传统的运维方式效率完全跟不上，因此一般还需要一个开发同学能点点两下就完成部署运维的devops平台(基于Kubenetters)。
微服务有哪些特点？
- 解耦—系统内的服务很大程度上是分离的。因此，整个应用程序可以轻松构建，更改和扩展
- 组件化—微服务被视为可以轻松更换和升级的独立组件
- 业务能力—微服务非常简单，专注于单一功能
- 自治—开发人员和团队可以彼此独立工作，从而提高速度
- 持续交付—通过软件创建，测试和批准的系统自动化，允许频繁发布软件
- 责任—微服务不关注应用程序作为项目。相反，他们将应用程序视为他们负责的产品
- 分散治理—重点是使用正确的工具来做正确的工作。这意味着没有标准化模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题
- 敏捷—微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃
微服务架构有哪些组件或哪些要素？
微服务：微服务是架构的核心组件，它们是独立的、自治的服务单元。每个微服务专注于执行特定的业务功能，并通过轻量级的通信机制与其他微服务进行交互。
服务通信：微服务之间通过通信机制进行交互。常见的通信方式包括使用RESTful API、消息队列、RPC（远程过程调用）等。这些通信机制允许微服务之间进行数据传递、请求处理和事件触发。
服务发现：由于微服务数量较多，需要一种机制来管理和发现这些服务。服务发现机制可以帮助微服务找到彼此的位置和接口。常见的服务发现工具包括Consul、Etcd和ZooKeeper等。
服务治理：服务治理涉及管理和监控微服务的状态、性能和可用性。这包括服务注册、健康检查、负载均衡、故障转移和流量控制等功能。常见的服务治理工具包括Netflix OSS中的Eureka和Hystrix等。
数据管理：微服务架构中的数据管理需要仔细考虑。数据可能分布在不同的微服务中，因此需要确定数据的一致性和复制策略。常见的方法包括使用分布式数据库、事件溯源和CQRS（命令查询责任分离）模式等。
部署和扩展：每个微服务都可以独立进行部署，并可以根据需要进行水平扩展。容器化技术（如Docker）和容器编排工具（如Kubernetes）通常用于简化微服务的部署和管理。
监控和日志：微服务架构需要对每个微服务进行监控和日志记录，以便实时监测系统的性能和健康状况。常见的监控工具包括Prometheus和Grafana等。
安全性：由于微服务架构涉及多个服务之间的通信，因此安全性是一个重要考虑因素。常见的安全措施包括身份验证、授权、数据加密和网络安全等。
这些组件或要素共同构成了微服务架构的基础。然而，具体的实现方式和工具选择可能因组织和项目的需求而有所不同。
微服务架构的优缺点是什么？
微服务架构优点：
独立开发和部署：每个微服务可以独立开发、测试和部署，使团队能够更快速地迭代和交付功能。
松耦合和可扩展性：微服务之间通过轻量级的通信进行交互，它们之间的耦合度较低。这使得系统更容易扩展，可以根据需要增加或减少特定微服务的实例。
技术多样性：由于每个微服务可以使用不同的技术栈，团队可以选择最适合其需求的技术和工具。
弹性和容错性：由于每个微服务是独立的，一个微服务的故障不会影响整个系统的稳定性，系统可以更好地应对故障和恢复。
微服务架构缺点：
复杂性：微服务架构引入了更多的复杂性，包括服务发现、负载均衡、监控和日志等基础设施需求。管理多个微服务和它们之间的通信也需要额外的努力。
分布式系统的挑战：微服务架构中的服务是分布式的，需要处理分布式系统的挑战，如网络延迟、一致性和事务管理等问题。
服务间通信开销：微服务之间的通信需要通过网络进行，可能会引入一定的开销和性能影响。
数据一致性：由于数据可能分布在不同的微服务中，确保数据的一致性变得更加复杂，需要仔细考虑事务管理和数据复制策略。
综上所述，微服务架构提供了灵活性、可扩展性和独立开发部署的优势，但也需要处理额外的复杂性和管理开销。在应用微服务架构时，需要权衡这些优缺点，并根据具体情况做出决策。
单体，SOA 和微服务架构有什么区别？
单体 SOA 和微服务之间的比较–微服务访谈问题
- 单体架构类似于大容器，其中应用程序的所有软件组件组装在一起并紧密封装。
- 一个面向服务的架构是一种相互通信服务的集合。通信可以涉及简单的数据传递，也可以涉及两个或多个协调某些活动的服务。
- 微服务架构是一种架构风格，它将应用程序构建为以业务域为模型的小型自治服务集合。
怎么做弹性扩缩容，原理是什么?
弹性伸缩（Auto Scaling）根据您的业务需求和伸缩策略，为您自动调整计算资源。您可设置定时、周期或监控策略，恰到好处地增加或减少CVM实例，并完成实例配置，保证业务平稳健康运行。在需求高峰期时，弹性伸缩自动增加CVM实例的数量，以保证性能不受影响；当需求较低时，则会减少CVM实例数量以降低成本。弹性伸缩既适合需求稳定的应用程序，同时也适合每天、每周、每月使用量不停波动的应用程序。
说一下中间件原理.
中间件（middleware）是基础软件的一大类，属于可复用软件的范畴。中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件 IDC的定义是：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。
中间件解决的问题是：
在中间件产生以前，应用软件直接使用操作系统、网络协议和数据库等开发，这些都是计算机最底层的东西，越底层越复杂，开发者不得不面临许多很棘手的问题，如操作系统的多样性，繁杂的网络程序设计、管理，复杂多变的网络环境，数据分散处理带来的不一致性问题、性能和效率、安全，等等。这些与用户的业务没有直接关系，但又必须解决，耗费了大量有限的时间和精力。于是，有人提出能不能将应用软件所要面临的共性问题进行提炼、抽象，在操作系统之上再形成一个可复用的部分，供成千上万的应用软件重复使用。这一技术思想最终构成了中间件这类的软件。中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。
在使用微服务架构时，您面临哪些挑战？
开发一些较小的微服务听起来很容易，但开发它们时经常遇到的挑战如下。
- 自动化构建部署：微服务小而分散，但每个服务都需要进行构建部署，经历 Build，Deploy 和 Monitor 的各个阶段。
- 运维监控：微服务架构带来服务数量膨胀的问题，需要对每一个微服务都加入监控报警日志等能力，会对运维监控带来比较大的压力。
- 配置管理：服务多，配置分散，同时还有多套环境（测试、生产），维护微服务的配置就会变得困难。
- 排查问题：一旦出现报错，微服务节点多，链路长，要排查到具体的报错节点会有一定的困难。
SOA 和微服务架构之间的主要区别是什么？
SOA（面向服务的架构）和微服务架构是两种不同的架构风格，它们之间存在以下主要区别：
规模和复杂性：SOA通常用于大型企业级系统，涉及多个业务领域和组织单元。它旨在将整个企业的功能划分为一组服务。微服务架构更加轻量级，适用于相对较小和较简单的应用程序，将应用程序拆分为多个小而自治的服务单元。
服务粒度：在SOA中，服务的粒度可以比较大，一个服务可能提供多个相关的功能。微服务架构更注重服务的细粒度，每个微服务通常只关注一个特定的业务功能。
依赖关系：在SOA中，服务之间的依赖关系通常是松耦合的，可以通过中间件（如ESB）进行通信。微服务架构更加强调服务之间的独立性，每个微服务都有自己的数据库和通信机制，可以通过轻量级的通信协议（如HTTP/REST）进行直接通信。
数据管理：在SOA中，通常存在共享的数据模型和数据访问层，服务可以共享数据。微服务架构更倾向于每个微服务拥有自己的数据存储，每个服务可以独立地管理和维护其数据。
技术栈：SOA并没有明确的技术栈要求，可以使用不同的技术和协议。微服务架构通常使用轻量级的通信协议（如HTTP/REST）和现代的开发工具和框架，如Docker、Kubernetes等。
部署和扩展：SOA通常以集中式的方式进行部署和扩展，服务通过中间件进行管理。微服务架构鼓励独立部署和扩展，每个微服务可以独立地进行部署和水平扩展。
团队自治：微服务架构更加强调团队自治，每个微服务可以由不同的团队开发和维护。SOA通常更加集中化，由中央团队负责整个架构和服务的管理。
总的来说，SOA和微服务架构在规模、服务粒度、依赖关系、数据管理、技术栈、部署和扩展以及团队自治等方面存在差异。微服务架构更加注重服务的细粒度、独立性和自治性，适用于相对较小和较简单的应用程序，而SOA适用于大型企业级系统，更加集中化和综合性。
什么是领域驱动设计？
待完善
为什么需要域驱动设计（DDD）？
待完善
什么是泛在语言（UL）
泛在语言是领域驱动设计中的一个重要概念，它指的是在软件开发过程中，开发团队和领域专家之间共享的一种通用语言。它是一种统一的、共享的术语和概念的集合，用于描述和沟通领域模型和业务需求。通过建立泛在语言，团队成员能够更好地理解和表达领域的需求和业务规则，促进团队协作和软件系统的设计与实现。
什么是凝聚力？
模块内部元素所属的程度被认为是凝聚力。
什么是耦合？
组件之间依赖关系强度的度量被认为是耦合。一个好的设计总是被认为具有高内聚力和低耦合性。
什么是 REST / RESTful 以及它的用途是什么？跟http的区别是什么
REST（Representational State Transfer）是一种软件架构风格，用于设计分布式系统。它通过使用统一的接口和无状态通信来实现资源的访问和操作。RESTful 是符合 REST 原则的应用程序或服务。
REST 的主要原则包括将系统中的信息和功能抽象为资源，并使用统一的操作方式对资源进行操作。这些操作方式使用 HTTP 方法（如 GET、POST、PUT、DELETE）进行 CRUD 操作。RESTful API 通过提供资源之间的链接和关系，使客户端能够动态地发现和访问其他相关资源。
REST 的主要用途是设计和开发分布式系统，尤其是 Web 服务和 API。它提供了一种简单、可扩展和可靠的通信方式，使不同的应用程序能够通过网络进行交互。RESTful API 可以被其他应用程序或客户端使用，以访问和操作系统中的资源。
与 REST 相关的 HTTP 是一种通信协议，用于在网络上传输数据。它定义了一组请求方法和状态码，用于在客户端和服务器之间进行请求和响应的交互。HTTP 是 RESTful API 常用的通信协议，但 REST 并不限于使用 HTTP，它可以在其他协议上实现。
区别在于，REST 是一种架构风格，用于设计分布式系统，而 HTTP 是一种通信协议。REST 提供了设计原则和约束，而 HTTP 是实现这些原则的一种方式。RESTful API 使用 HTTP 方法和状态码来进行资源的访问和操作，但 REST 并不依赖于 HTTP，可以在其他协议上实现。
简而言之，REST 是一种设计分布式系统的架构风格，RESTful 是符合 REST 原则的应用程序或服务。它们的主要用途是设计和开发分布式系统，通过提供统一的接口和无状态通信来实现资源的访问和操作。HTTP 是常用的通信协议，用于实现 RESTful API，但 REST 不限于使用 HTTP。
什么是不同类型的微服务测试？
在使用微服务时，由于有多个微服务协同工作，测试变得非常复杂。因此，测试分为不同的级别。
- 在底层，我们有面向技术的测试，如单元测试和性能测试。这些是完全自动化的。
- 在中间层面，我们进行了诸如压力测试和可用性测试之类的探索性测试。
- 在顶层，我们的进行验收测试。这些验收测试有助于利益相关者理解和验证软件功能。