正文
谈谈你对微服务的理解，微服务有哪些优缺点？
首先，微服务是对传统单体架构的一种优化。当一个单体架构随着业务的增加而变得臃肿时，微服务通过将业务拆分成小的独立单元来进行优化。
微服务的优点有以下几点：
- 业务清晰：拆分微服务后，每个服务只负责一个独立的业务，没有与其他业务耦合，使新员工能够快速理解和上手。
- 性能优化：单体架构的部署启动通常是一个挑战，而微服务的拆分使得单个服务可以独立部署，大大提升了部署的灵活性，也能够为每个业务单独分配服务器资源。
- 技术更新：单体架构的技术升级往往困难且高风险，而微服务的拆分使得单个微服务的技术更新更加迅速。
- 代码复用：微服务的拆分使得某些服务的业务可以被其他服务调用，实现了代码复用的效果。
然而，微服务也有一些缺点：
- 系统运维复杂度提升：并发问题、分布式事务、网络问题等都会影响服务之间的调用，增加了系统运维的复杂度。
- 测试难度增加：一旦出现问题，很难确定是哪个中间服务出现了问题，增加了测试的难度。
- 运维难度提升：单体架构只需要查看单独的服务器资源监控即可，而微服务的拆分导致服务器数量增加，监控和管理变得更加困难。
SpringCloud和SpringCloudAlibaba都有哪些组件？都解决了什么问题？
SpringCloud和SpringCloud Alibaba是两个不同的微服务框架，它们都有一些不同的组件，用于解决不同的问题。
SpringCloud Netflix是SpringCloud的一部分，它包括以下组件：
- Zuul网关：用于路由请求和负载均衡。
- Hystrix熔断器：用于保护和控制微服务之间的通信，防止故障传播。
- Feign：用于声明式的HTTP客户端，简化微服务之间的调用。
- Ribbon：用于客户端负载均衡，将请求分发给不同的微服务实例。
- Eureka注册中心：用于服务的注册和发现。
- Config：用于集中管理和分发微服务的配置信息。
SpringCloud Alibaba是由阿里巴巴开发的一套基于SpringCloud的微服务框架，它包括以下组件：
- Gateway：用于网关服务，实现请求的转发和路由。
- Sentinel：用于熔断和限流，保护微服务免受高负载和异常情况的影响。
- Feign：用于声明式的HTTP客户端，简化微服务之间的调用。
- Ribbon：用于客户端负载均衡，将请求分发给不同的微服务实例。
- Dubbo：用于基于TCP的远程调用，提供更高效的通信。
- Nacos：用于配置管理和服务注册中心，提供了更灵活的配置和服务发现功能。
- Seata：用于分布式事务的管理，确保多个微服务之间的事务一致性。
分布式事务如何处理？怎么保证事务一致性？
需要注意的是，在面试中，确实分布式事务不等同于Seata，Seata只是分布式事务的一种实现工具，而分布式事务的处理方法可以有多种选择，具体要根据实际需求和场景来确定。
分布式事务是在分布式系统中保证多个节点之间操作的一致性的机制。在分布式环境下，由于每个节点可能使用不同的存储介质或位于不同的数据库实例中，因此需要特殊的处理机制来保证事务的一致性。
为了保证分布式事务的一致性，可以采用以下几种方法：
- http接口回调：类似于配置支付宝支付回调一样，尽最大努力通知，
- mq：可以使用消息队列来解决分布式事务的一致性问题。当产生业务需求时，将相关操作放入消息队列中，并使用事务消息机制来保证消息的可靠性传递。每个节点在接收到消息后执行相应的操作，并将结果发送回消息队列。通过消息队列，可以实现分布式事务的异步处理。
- redis：当需要产生事务时，可以选择在redis中设置初始值，每完成一个就减一，直到0位置提交事物，或者当事务过期进行回滚。
- Seata是一个开源的分布式事务解决方案，它提供了事务协调器（Transaction Coordinator）和事务参与者（Transaction Participant）来实现分布式事务的管理。Seata支持两阶段提交、三阶段提交和Saga模式，并提供了高可用和容错的特性，可以有效地解决分布式事务的一致性问题。
- 两阶段提交（2PC）：在两阶段提交中，一个事务协调器（Transaction Coordinator）负责协调多个参与者（Participants）。在第一阶段，协调器询问各参与者是否可以提交事务，参与者将自己的决策（提交或回滚）返回给协调器。在第二阶段，协调器根据参与者的决策来决定是否提交或回滚事务。但是，2PC存在阻塞和单点故障等问题。
- 三阶段提交（3PC）：三阶段提交在两阶段提交的基础上增加了一个准备阶段（Preparation Phase）。在准备阶段，协调器会发送预提交请求给参与者，参与者会在准备阶段进行事务的准备工作。如果所有参与者都准备就绪，协调器会发送提交请求；否则，协调器会发送回滚请求。三阶段提交相对于两阶段提交，减少了阻塞的时间。
- Saga模式：Saga模式是一种基于补偿的分布式事务处理模式。在Saga模式中，每个参与者负责自己的事务操作，并记录相应的补偿操作。如果某个参与者的事务失败，Saga会根据事务记录执行相应的补偿操作，以保证整个事务的一致性。
怎样拆分微服务以实现高内聚和低耦合？
- 避免业务之间的代码耦合，可通过使用RESTful接口进行调用。这样，每个微服务都专注于自己的业务领域，不会直接依赖其他服务的具体实现细节。通过定义清晰的接口和协议，不同的微服务之间可以进行灵活的交互。
- 不得直接修改其他服务的底层表数据。微服务之间应该通过接口来进行数据交互，而不是直接操作其他服务的底层数据。这样可以保证每个微服务的数据独立性和一致性，并且减少对其他服务的依赖。
- 应该逐个业务拆解，如果时间充裕可以直接全面拆分，但是需要注意风险。将整个系统按照业务功能进行拆分，每个微服务都承担一个特定的业务功能。这样可以将复杂的系统分解为更小、更易于管理和维护的部分。但是，在全面拆分之前，需要进行充分的规划和评估，以确保拆分后的微服务能够满足系统的需求，并且不会引入过多的复杂性和风险。
为了实现高内聚和低耦合，可以采用以下设计原则和方法：
- 使用服务间调用和异步事件驱动等方式解决低耦合的需求。通过定义清晰的接口和消息传递机制，不同的微服务可以通过消息、事件或者远程调用来进行通信，从而实现松耦合的架构。
- 将自身的业务全部集中在一个服务中，避免业务逻辑的扩散和分散。每个微服务应该专注于自己的业务领域，不涉及其他微服务的业务逻辑。这样可以保持高内聚，每个微服务都有清晰的职责和功能。
- 使用HTTP调用和消息队列（MQ）消费等方法解决业务与业务之间的联系。通过定义合适的接口和消息格式，不同的微服务可以通过HTTP调用或者消息队列来进行数据交换和通信。这样可以实现微服务之间的解耦和灵活性。
DDD领域驱动设计
DDD革命性在于：领域模型准确反映了业务语言，而传统微服务数据对象除了简单setter/getter方法外，没有任何业务方法，即失血模型，那么DDD领域模型就是充血模型（业务方法定义在实体对象中）。
DDD只是一种方法论，没有一个稳定的技术框架。DDD要求领域是跟技术无关、跟存储无关、跟通信无关
4层典型DDD分层结构，
- 展现层：controller层。无业务逻辑
- 应用服务层：此层可以包含查询逻辑，但核心业务逻辑必须下沉到领域层。
- 领域服务层：业务在这里组装。仓储（资源库）接口在此层定义。
- 基础设施层：仓储（资源库）实现层+PO持久化层。
展现层负责处理用户界面和用户输入输出。应用服务层协调展现层和领域服务层之间的交互，并执行业务流程。领域服务层包含业务逻辑的核心部分，负责处理领域实体和领域服务之间的交互。基础设施层提供技术实现，如数据库访问、网络通信等。
中台和微服务有什么关系
中台最初是由阿里提出的"小前台，大中台"的战略思想，它并不是一种具体的技术方式，而是一种企业战略和组织架构的理念。中台可以分为数据中台、业务中台和技术中台三个方面。数据中台是将企业内部的数据资源进行整合和开放，实现数据的共享和流转；业务中台是将企业内部的业务能力和流程进行整合和优化，提供给各个业务线使用；技术中台是将企业的技术能力进行整合和开放，提供给各个业务线使用。中台的目标是通过复用和共享现有资源，实现快速的业务更新迭代和快速选型。
微服务是一种架构风格，将一个应用程序拆分为多个小型、独立部署的服务，每个服务都能够独立运行和扩展。微服务提供了较好的技术支撑，能够实现高内聚和低耦合，使系统更加灵活和可维护。中台的落地需要微服务的支撑，通过微服务的方式来构建中台，可以将中台拆分为多个小型服务，每个服务负责特定的业务功能或技术能力。这样可以实现中台的快速发展和创新。
中台和微服务是相辅相成的。中台提供了资源和能力的整合和共享，为企业的业务线提供支持和服务；微服务提供了技术支撑，实现了业务功能的独立和灵活。通过结合中台和微服务，企业可以实现业务的快速发展和系统架构的灵活性。
你的项目中是怎么保证微服务敏捷开发的？
在我们的项目中，我们采用敏捷开发方法来保证微服务的快速开发和迭代。敏捷开发的核心思想是通过设立单个任务目标，进行业务更新的快速迭代，并且可以随时进行上线。为了支持敏捷开发，我们采取了以下几个措施：
- 代码分支管理：我们使用版本控制工具（如Git）来管理代码，每个任务都在自己的分支上进行开发。这样，不同的任务可以并行开发，互不干扰。同时，我们可以随时将某个分支合并到主分支上进行上线。
- 站立会议：每天早上，我们进行短暂的站立会议，通常持续5-10分钟。在会议中，每个团队成员都分享自己的任务进度和遇到的问题。这样可以快速跟进每个任务的进度，及时解决问题，并保持团队的协同性。
- 进度面板：我们使用项目管理工具（如Jira）来跟踪任务的进度。通过在进度面板上创建任务、设置优先级和状态，我们可以清晰地了解每个任务的状态和进度。这有助于团队成员之间的沟通和协作，以及项目整体的可视化管理。
- 开发环境支持：为了支持敏捷开发，我们建立了多个环境，包括测试环境、预发布环境和生产环境。在测试环境中，我们可以进行功能测试和集成测试，确保代码的质量和稳定性。预发布环境用于模拟生产环境，进行最后的验证和性能测试。而生产环境是最终部署和运行的环境。
通过以上措施，我们能够实现快速、高效的微服务开发和部署。敏捷开发方法使我们能够快速响应业务需求的变化，通过快速迭代来持续提供高质量的软件。同时，站立会议和进度面板等工具帮助我们保持团队的协作和可视化管理。各个环境的支持则确保我们能够进行充分的测试和验证，最终将稳定的代码部署到生产环境中。
微服务的链路追踪、持续集成、AB发布要怎么做？
链路追踪
链路追踪是一种监控和分析系统中各个组件之间请求路径和性能的技术。通常，我们可以使用ELK（Elasticsearch、Logstash、Kibana）等工具来实现链路追踪。具体步骤如下：
- 在每个微服务中，添加代码来生成一个唯一的业务id，并将该id传递给所有相关的服务。
- 将每个服务的日志发送到集中式日志系统，如Elasticsearch。
- 使用Kibana等工具来查询和分析链路日志，可以根据业务id关联和追踪整个请求路径，以及查看各个环节的性能指标。
持续集成
持续集成是一种软件开发实践，通过频繁地将代码集成到主干分支，并进行自动化的构建、测试和部署，以确保代码质量和快速交付。实现持续集成可以使用以下方法：
- 使用版本控制系统（如Git）管理代码，并建立主干分支和开发分支。
- 使用构建工具（如Maven、Gradle）来自动化构建过程，包括编译、打包等。
- 使用自动化测试工具（如JUnit）编写测试用例，并在构建过程中执行测试。
- 使用持续集成工具（如Jenkins）设置流水线，定义构建、测试和部署的步骤，并触发自动化流程。
AB发布
AB发布是一种逐步推出新功能或更新的发布策略，它可以在生产环境中逐渐引入新功能，以降低风险和影响。具体步骤如下：
- 在预发布环境中部署新功能或更新，只对少部分用户或流量进行测试。
- 监控和收集预发布环境的性能和稳定性数据，确保新功能正常运行。
- 根据收集的数据和测试结果，决定是否继续推出新功能。
- 如果新功能通过了测试并且运行稳定，可以通过全量发布的方式将其应用于整个生产环境，或者根据需要进行灰度发布或金丝雀发布，逐渐扩大用户范围。
总结
微服务的应用级别确实相对简单，但在实际开发中仍有一些技术难点需要解决。对于微服务组件的使用，确实不存在太大差距，但在设计和开发过程中需要积累经验。学习微服务的上手时间相对较短，可能只需一周到一个月的时间。然而，设计经验和技术难点是需要个人长期积累的，不能急于求成。
因此，在使用和开发微服务时，更应该关注方案思考，展示自己对该领域的理解和见解。这样能够体现出你对问题的思考深度和解决方案的创新性。希望这次面试种子题目的解答能够帮助你应对面试官的问题！
