微服务架构拆分介绍

最新推荐文章于 2024-05-18 17:00:54 发布
最新推荐文章于 2024-05-18 17:00:54 发布
阅读量1k 收藏 25
点赞数 31
分类专栏： 微服务 文章标签： 架构 微服务 云原生
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_49862903/article/details/138704196
版权

微服务介绍

英文：https://martinfowler.com/articles/microservices.html

中文：https://blog.cuicc.com/blog/2015/07/22/microservices/

微服务拆分

拆分的目的：复杂的问题简单化，不应为了拆分而拆分。

单体架构优势：

  1. 开发简单直接： 单体架构下，开发过程更加简单和直接，因为所有功能模块都在同一个代码库中，开发人员可以更轻松地理解整个系统的结构和功能。
  2. 项目集中式管理： 单体架构有利于集中式管理，使得团队更容易协作，减少沟通成本，并且便于维护和部署。
  3. 有针对性排查问题： 排查问题时只需要关注一个应用，更容易定位和解决问题，提高了故障排除效率。
  4. 节省人力成本： 维护一个工程可以节省维护系统运行的人力成本，因为不需要额外的部署和维护工作，减少了运维成本。

单体架构劣势：

  1. 规模扩大导致的研发成本增加： 随着业务功能的增多和开发团队规模的扩大，单体架构下的研发成本会逐渐增加，可能会抑制研发效率的提升，比如版本控制和代码冲突解决等问题。
  2. 技术瓶颈： 单体架构在技术层面可能会面临数据库连接数的限制，这会成为应用服务器扩容的瓶颈，限制了系统的横向扩展能力。
  3. 对运维的影响： 单体架构对于系统的运维也会产生一定的影响，因为所有的功能模块都在同一个应用中，可能会增加系统维护的复杂性和风险。

微服务优点：

  1. 快速迭代： 微服务架构支持快速迭代和敏捷开发，因为各个微服务可以独立开发、测试、部署和扩展，不会因为整个系统的迭代而受阻。
  2. 可伸缩性： 微服务架构具有良好的可伸缩性，可以根据需要独立地扩展或缩减每个微服务，以满足不同业务需求和流量的变化。
  3. 容错性： 微服务架构下，每个微服务都是独立部署和运行的，如果某个微服务发生故障，不会影响整个系统的稳定性，提高了系统的容错性和可用性。

微服务缺点：

  1. 分布式系统复杂性： 微服务架构引入了分布式系统的复杂性，包括服务发现、负载均衡、分布式事务等问题，需要额外的技术和工具来解决。
  2. 部署和运维成本： 微服务架构下，由于服务数量增多，部署和运维成本也会相应增加，需要更多的自动化工具和流程来管理微服务的生命周期。
  3. 数据一致性： 微服务架构下，由于数据分布在不同的服务中，可能会出现数据一致性的问题，需要通过一致性协议或者异步通信来解决。

拆分时机

微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。

  1. 代码维护困难： 当代码库变得庞大，同时有多个开发者进行频繁提交，并且出现了大量的代码冲突时，这表明单体架构下的代码管理已经难以维护，可以考虑微服务拆分来减少代码库的复杂度，提高团队的开发效率。

  2. 模块耦合严重： 如果模块之间的依赖关系过于复杂，小的功能修改也需要等待大版本上线，并且需要高层级的协调才能进行上线，这表明模块之间的耦合度过高，不利于快速迭代和独立部署，可以通过微服务拆分来解耦模块，实现独立部署和快速上线。

  3. 横向扩展流程复杂： 如果主要业务和次要业务耦合严重，需要对某些业务进行横向扩展而另一些业务不需要扩展，这会导致扩展流程复杂，不利于系统的横向扩展和资源的有效利用，可以通过微服务拆分来将不同的业务功能拆分成独立的服务，实现按需扩展

  4. 业务规模增长： 当业务规模逐渐扩大，需要更快地满足市场需求时，微服务拆分是有必要的。在业务成长期阶段，单体架构可能已经无法满足需求，需要考虑微服务架构。

  5. 团队规模增长： 当团队规模达到一定程度，如百人规模以上，单体架构下的开发效率可能会受到限制，此时考虑微服务拆分可以提高团队的协作效率和开发效率。

  6. 技术储备和人才储备： 微服务架构需要具备相应的技术储备和人才储备，包括领域驱动设计、注册中心、配置中心、日志系统、持续交付、监控系统等方面的知识和经验。

  7. 研发效率下降： 如果单体架构下研发效率大幅下降，代码维护困难，影响了团队的整体生产力，那么这就是进行微服务拆分的一个很好的时机。

拆分通用原则

  1. 单一服务内部功能高内聚低耦合： 每个微服务应专注于解决特定的业务问题，确保内部功能高度内聚，即相关功能组件应该紧密相关，而与其他组件的耦合应尽量降低。这有助于提高服务的独立性和可维护性。

  2. 闭包原则（CCP）： 当需要对一个微服务进行修改时，所有的变更应该局限在这个微服务的内部，而不影响其他微服务。这样做可以降低系统的耦合性，提高服务的自治性和可维护性。

  3. 服务自治、接口隔离原则： 每个微服务应该具有自治性，能够独立开发、测试、部署和运行。同时，服务之间应该通过标准的接口进行通信，隐藏内部实现细节，降低服务之间的依赖，提高系统的稳定性和可维护性。

  4. 持续演进原则： 微服务架构的设计应该是一个持续演进的过程，根据业务需求和技术发展不断优化微服务的划分和边界，避免服务数量的爆炸性增长，确保服务的合理性和灵活性。

  5. 影响产品日常功能迭代的最小化： 在微服务拆分过程中，应尽量减少对产品日常功能迭代的影响，优先拆分比较独立的边界服务，并逐步减少对现有业务的影响，同时避免服务之间的环形依赖或双向依赖。

  6. 服务接口的可扩展性： 微服务接口的设计应具备良好的可扩展性，尽量避免修改接口签名，而是通过封装类等方式来进行参数的扩展，确保向后兼容性，降低对调用方的影响。

  7. 避免环形依赖与双向依赖： 尽量避免微服务之间存在环形依赖或双向依赖，这会导致系统的耦合度增加，使得服务边界不清晰，降低了系统的可维护性和可扩展性。

  8. 阶段性合并和重新梳理： 随着对业务领域理解的深入和业务逻辑的变化，应定期对微服务的边界进行合并和重新梳理，确保服务边界的清晰和合理性，避免服务边界的混乱。

  9. 自动化驱动： 在微服务架构中，应优先构建自动化工具和环境，简化服务的创建、开发、测试、部署和运维过程，减少手动操作，提高开发和管理效率，降低微服务数量增加所带来的复杂性问题。

拆分策略

功能维度

在功能维度拆分策略中，基于业务复杂度的拆分可以选择领域驱动设计或数据驱动的方法。以下是一些优化介绍：

  1. 基于领域驱动设计的拆分优化：

    • 确保与领域的密切合作：以业务建立统一的语言和概念模型，确保对业务领域的深入理解，从而更好地划分服务边界。
    • 重视核心业务场景：识别和优先处理核心业务场景，将其拆分为独立的微服务，这有助于提高系统的灵活性和可维护性。
    • 聚合和分解的平衡：通过领域模型和业务分析，找到合适的聚合和分解点，避免过度拆分或过度集中，确保微服务的功能单一性和内聚性。

  2. 基于数据驱动的拆分优化：

    • 综合考虑表之间的关系：在确定整体数据结构时，不仅要考虑单个表的结构，还需要考虑表之间的关系和依赖，从而更好地划分服务边界。
    • 强调数据一致性和事务边界：在拆分服务时，要考虑数据一致性和事务的边界，避免将需要在同一个事务中操作的数据拆分到不同的服务中，从而确保系统的数据一致性。
    • 迭代验证和持续优化：拆分服务后，需要不断验证业务流程和服务调用关系，及时发现和解决问题，持续优化服务拆分的结果，以满足业务需求和性能需求。

  3. 已有单体架构中逐步拆分服务：

    拆分步骤： 前后端分离，提取公共基础服务（如登录、权限），不断从老系统抽取服务，垂直划分优先，适当水平切分

在实施功能维度拆分策略时，需要根据具体业务情况和团队的实际情况选择合适的方法，并不断进行迭代和优化，以确保微服务架构的设计符合业务需求和系统性能的要求。

非功能维度

考虑到扩展性、复用性、高性能、高可用、安全性、异构性等方面，以下是针对这些目标的主要拆分策略：

  1. 扩展性：

    • 将系统中变与不变的部分区分开来，将不变的部分拆分为共用的服务，而将变化的部分独立出来满足个性化扩展需要。
    • 根据二八原则，将经常变动的部分与基本不变的部分进行拆分，以降低对成熟服务稳定性的影响。

  2. 复用性：

    • 将系统中重复的功能，如鉴权、限流、安全和日志监控等，拆分为独立的服务，形成微服务中的API网关，以提高功能的复用性。

  3. 高性能：

    • 将性能要求高或者性能压力大的模块拆分出来，避免对其他服务产生性能影响。
    • 基于读写分离或根据具体性能瓶颈，对服务进行拆分，以优化性能。例如，将核心的排队功能拆分为独立的服务，或对流量较大的服务进行读写分离。

  4. 高可用：

    • 将可靠性要求高的核心服务与可靠性要求低的非核心服务进行拆分，重点保证核心服务的高可用性。确保服务数量满足“三个火枪手”的原则，以提高系统整体的可用性。

  5. 安全性：

    • 将对信息安全要求高的服务进行拆分，进行区别部署，如设置特定的DMZ区域对服务进行分区部署，以满足信息安全的要求。
    • 采取针对性的安全策略，降低安全风险，并提高信息安全的效率和成本效益。

  6. 异构性：

    • 对于对开发语言种类有要求的业务场景，可以将功能独立出来实现为一个独立服务，使用不同的语言进行实现，以满足异构性的需求。

Spring Cloud技术栈选型

Spring Cloud Alibaba 官网：

Spring AI 抢先体验 | https://sca.aliyun.com

GitHub - alibaba/spring-cloud-alibaba: Spring Cloud Alibaba provides a one-stop solution for application development for the distributed solutions of Alibaba middleware.

针对Spring Cloud存在的痛点，选择Spring Cloud Alibaba作为微服务组件是一个明智的选择。以下是优化介绍：

  1. 稳定性和持续更新：

    • Spring Cloud Alibaba的组件由阿里巴巴经过实际使用和考验，具有较高的稳定性和性能。与此同时，Alibaba积极参与并支持这些组件的维护和更新，确保其与最新技术的兼容性，从而避免了部分组件停止维护和更新所带来的不便。

  2. 简化部署和管理：

    • Spring Cloud Alibaba提供了更简单的环境搭建过程，其集成了完善的可视化界面，使得部署和管理变得更加简单和直观。这减少了二次开发和定制的需求，同时提高了开发和运维的效率。

  3. 简化配置和降低学习成本：

    • 相比于传统的Spring Cloud，Spring Cloud Alibaba简化了配置过程，降低了配置的复杂性。它提供了更易于上手的配置方式，并且明确了各个组件之间的配置差异，使得开发人员更容易理解和合理应用。这降低了学习曲线，提高了开发效率。

  4. 成熟的生态系统和强大的性能：

    • Spring Cloud Alibaba基于Alibaba在大规模分布式系统方面的丰富经验，提供了一整套成熟的微服务组件。这些组件经过了实际的考验，性能强劲，设计合理。借助这些组件，开发人员可以构建高性能、可靠的微服务架构，同时享受到完善的可视化界面带来的便利。

  5. 低学习成本和简化搭建过程：

    • Spring Cloud Alibaba的搭建过程相对简单，并且提供了较低的学习曲线。其文档和社区资源丰富，开发人员可以快速上手，并且通过阿里云提供的云原生服务，可以进一步简化部署和管理的过程，降低了搭建和维护的成本。

Spring Cloud Alibaba官方推荐版本选择:

2.2.x 分支

适配 Spring Boot 为 2.4，Spring Cloud Hoxton 版本及以下的 Spring Cloud Alibaba 版本按从新到旧排列如下表（最新版本用*标记）：

Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot Version
2.2.10-RC2*Spring Cloud Hoxton.SR122.3.12.RELEASE
2.2.10-RC1Spring Cloud Hoxton.SR122.3.12.RELEASE
2.2.9.RELEASESpring Cloud Hoxton.SR122.3.12.RELEASE
2.2.8.RELEASESpring Cloud Hoxton.SR122.3.12.RELEASE
2.2.7.RELEASESpring Cloud Hoxton.SR122.3.12.RELEASE
2.2.6.RELEASESpring Cloud Hoxton.SR92.3.2.RELEASE
2.2.1.RELEASESpring Cloud Hoxton.SR32.2.5.RELEASE
2.2.0.RELEASESpring Cloud Hoxton.RELEASE2.2.X.RELEASE
2.1.4.RELEASESpring Cloud Greenwich.SR62.1.13.RELEASE
2.1.2.RELEASESpring Cloud Greenwich2.1.X.RELEASE
2.0.4.RELEASE(停止维护，建议升级)Spring Cloud Finchley2.0.X.RELEASE
1.5.1.RELEASE(停止维护，建议升级)Spring Cloud Edgware1.5.X.RELEASE

组件版本关系

每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本如下表所示：

Spring Cloud Alibaba VersionSentinel VersionNacos VersionRocketMQ VersionDubbo VersionSeata Version
2.2.10-RC21.8.62.2.04.9.4~1.6.1
2.2.10-RC11.8.62.2.04.9.4~1.6.1
2.2.9.RELEASE1.8.52.1.04.9.4~1.5.2
2.2.8.RELEASE1.8.42.1.04.9.3~1.5.1
2.2.7.RELEASE1.8.12.0.34.6.12.7.131.3.0
2.2.6.RELEASE1.8.11.4.24.4.02.7.81.3.0
2.2.3.RELEASE or 2.1.3.RELEASE or 2.0.3.RELEASE1.8.01.3.34.4.02.7.81.3.0
2.2.1.RELEASE or 2.1.2.RELEASE or 2.0.2.RELEASE1.7.11.2.14.4.02.7.61.2.0
2.2.0.RELEASE1.7.11.1.44.4.02.7.4.11.0.0
2.1.1.RELEASE or 2.0.1.RELEASE or 1.5.1.RELEASE1.7.01.1.44.4.02.7.30.9.0
2.1.0.RELEASE or 2.0.0.RELEASE or 1.5.0.RELEASE1.6.31.1.14.4.02.7.30.7.1

2021.x 分支

适配 Spring Boot 2.4，Spring Cloud 2021.x 版本及以上的 Spring Cloud Alibaba 版本按从新到旧排列如下表（最新版本用*标记）：

Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot Version
2021.0.6.0*Spring Cloud 2021.0.52.6.13
2021.0.5.0Spring Cloud 2021.0.52.6.13
2021.0.4.0Spring Cloud 2021.0.42.6.11
2021.0.1.0Spring Cloud 2021.0.12.6.3
2021.1Spring Cloud 2020.0.12.4.2

组件版本关系

每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本如下表所示：

Spring Cloud Alibaba VersionSentinel VersionNacos VersionRocketMQ VersionDubbo VersionSeata Version
2021.0.6.01.8.62.2.04.9.4~1.6.1
2021.0.5.01.8.62.2.04.9.4~1.6.1
2021.0.4.01.8.52.0.44.9.4~1.5.2
2021.0.1.01.8.31.4.24.9.2~1.4.2
2021.1 or 2.2.5.RELEASE or 2.1.4.RELEASE or 2.0.4.RELEASE1.8.01.4.14.4.02.7.81.3.0

2022.x 版本及依赖关系

适配 Spring Boot 3.0，Spring Cloud 2022.x 版本及以上的 Spring Cloud Alibaba 版本按从新到旧排列如下表（最新版本用*标记）： (注意，该分支 Spring Cloud Alibaba 版本命名方式进行了调整，未来将对应 Spring Cloud 版本，前三位为 Spring Cloud 版本，最后一位为扩展版本，比如适配 Spring Cloud 2022.0.0 版本对应的 Spring Cloud Alibaba 第一个版本为：2022.0.0.0，第个二版本为：2022.0.0.1，依此类推)

Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot Version
2022.0.0.0*Spring Cloud 2022.0.03.0.2
2022.0.0.0-RC2Spring Cloud 2022.0.03.0.2
2022.0.0.0-RC1Spring Cloud 2022.0.03.0.0

组件版本关系

每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本如下表所示：

Spring Cloud Alibaba VersionSentinel VersionNacos VersionRocketMQ VersionSeata Version
2022.0.0.01.8.62.2.14.9.41.7.0
2022.0.0.0-RC21.8.62.2.14.9.41.7.0-native-rc2
2022.0.0.0-RC11.8.62.2.1-RC4.9.41.6.1

2023.x 分支

适配 Spring Boot 3.2，Spring Cloud 2023.x 版本及以上的 Spring Cloud Alibaba 版本按从新到旧排列如下表（最新版本用*标记）：

Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot Version
2023.0.1.0*Spring Cloud 2023.0.13.2.4
2023.0.0.0-RC1Spring Cloud 2023.0.03.2.0

组件版本关系

每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本如下表所示：

Spring Cloud Alibaba VersionSentinel VersionNacos VersionRocketMQ VersionSeata Version
2023.0.1.01.8.62.3.25.1.42.0.0
2023.0.0.0-RC11.8.62.3.05.1.42.0.0
二月春风留
关注
  • 31
    点赞
  • 踩
  • 25
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
从单体架构到微服务架构的拆分
大道至简，悟在天成。
04-14 858
单体架构、分布式架构和微服务架构是三种不同的软件架构模式，它们各有特点和适用场景。
四种常用的微服务架构拆分方式
xupeiyan的博客
03-08 635
微服务架构并无标准架构，不然什么架构师大会也不会各个系统架构百花齐放了。虽然没有固定的套路，却有一些经验，今天就来做一个总结。 基于角色拆分 这种拆分方式常见于基础设施以及其PaaS层的架构，比如服务治理、k8s、kafka。所谓基础组件的PaaS层是说，基础设施本身主要作为基础设施使用，是IaaS层。但是基础设施本身需要维护功能，需要增删改查等运维操作。业界基于开源做的二次开发也着重在做这方面的工作。 下面以kafka做说明。因为要上升到PaaS层，下图基于美团对kafka的二次开发封装，产品名叫m
微服务架构服务可靠性分析
张彦峰的博客
02-07 164万+
微服务架构服务可靠性分析：服务访问失败的原因和应对策略+服务容错+服务隔离+服务限流+服务降级
微服务架构拆分设计
Zhuxiaoyu_91的博客
12-08 897
微服务架构拆分设计
微服务架构服务拆分原则
weixin_47640583的博客
03-20 1370
微服务架构的目标是将一个大型的、复杂的系统分解为一系列小型的、易于管理和维护的服务。每个服务都是一个独立的单元，可以独立部署、扩展和升级，从而降低了系统的耦合度和风险。4.使用服务注册和发现机制：服务注册和发现机制可以自动地将服务注册到一个中心化的注册表中，并且可以在服务之间进行自动的发现和路由，从而降低服务之间的耦合度。：API Gateway可以将外部请求路由到相应的服务，同时还可以提供身份验证、限流等功能，从而保护服务的安全性和可用性。：根据系统的业务功能，将系统划分为一系列独立的服务。
微服务架构数据一致性分析
热门推荐
张彦峰的博客
02-07 165万+
微服务架构数据一致性分析：分布式事物+CAP&BASE+可靠事件模式+补偿模式+Sagas模式+TCC模式+最大努力通知模式+人工干预模式
微服务架构组件介绍
专注Java（全栈）应用开发，求知若渴，虚心若愚，而知也无涯
01-07 962
微服务架构是一个非常常见的需求。
微服务架构介绍
Dily_Su的博客
06-22 1459
​ model1模式: jsp + java​ model2模式: MVC 模式​ 资源调度、负载均衡、动态服务创建…服务治理​ 微小、单一职责​ 微服务就是将一个单体架构的应用按业务划分为一个个独立运行的程序即服务，他们之间通过HTTP协议进行通信（也可通过消息队列，如kafaka、RabbitMq等），可以采用不同的编程语言，使用不同的存储技术，自动化部署，减少人为控制，降低出错概率。服务数量较多，管理越来越复杂，因此采用集中化管
微服务架构服务拆分粒度
02-27
总的来说，细粒度拆分的优点有： • 服务都能够独立部署 • 扩容和缩容方便，有利于提高资源利用率 • 拆得越细，耦合相对会减小 • 拆得越细，容错相对会更好，一个服务出问题不影响其他服务 • 扩展性更好 细...
微服务架构如何实现网站服务垂直化拆分
02-25
阿里云产品专家银时为大家带来《微服务架构如何实现网站服务垂直化拆分》精彩演讲。主要从服务化的缘起、微服务架构的形成，以及在大规模的服务化过程中所面临的一些挑战以及解决方案，跟大家分享整个微服务。以下...
微服务架构x_docker微服务架构实战
12-02
微服务架构设计 从分析单体服务利弊到微服务的演变。核心内容包括，服务的拆分重组，模块化，注册，分布式，配置，单点登录，通知消息，容器技术等。
分布式——微服务架构
02-24
微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有...
架构篇37：微内核架构详解
星猿科技的博客
05-17 686
微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，本片我们介绍常见的微内核架构及其实现。
第8章 系统质量属性与架构评估
最新发布
辣香牛肉面的博客
05-18 880
向所有人介绍ATAM评估过程及其相关信息，说明评估中使用的分析技术及评估的预期结果，解答成员问题。
Zabbix实现7x24小时架构监控
Lzcsfg的博客
05-17 1282
Zabbix 是C语言编写的企业级开源免费的分布式监控解决方案，可监控网络的众多参数以及服务器、虚拟机、应用程序、数据库、网站、云等的健康状况和完整性。Zabbix 使用灵活的报警通知机制，允许用户为几乎任何事件配置电子邮件的警报。这允许对服务器问题做出快速反应。Zabbix 可通过存储的数据提供出色的报告和数据可视化功能。官网地址：https://www.zabbix.com/常用的监控软件：Cacti、Nagios、Ganglia、Open-Falcon、zabbix、prometheus。
Linux综合架构开场与环境部署
2302_78067597的博客
05-17 763
什么是综合架构：网站通用的结构综合架构是个参考，公司都有自己特别的结构与需求。
避免超卖！深入解析高并发分布式锁架构
逆流的小鱼
05-18 987
并发控制是一切分布式系统设计的基石，确保数据一致性、系统稳定性和最终的用户体验。要理解为什么需要并发控制，就必须先探讨并发对系统可能造成的问题。
SOA和微服务有什么区别
那些疯狂到以为自己能够改变世界的人，才能真正改变世界！
05-17 262
SOA（面向服务的架构）和微服务是两种常见的架构风格，它们之间存在一些关键的区别。
拆分微服务要拆分数据库吗
05-27
在将ERP系统拆分为微服务时，是否需要拆分数据库取决于ERP系统的特定情况和架构设计。一般来说，如果ERP系统的不同模块之间共享同一数据库，那么在将系统拆分为微服务时，也需要考虑是否需要拆分数据库。 在微服务架构中，每个微服务都应该拥有自己的独立数据存储，这样可以避免不同微服务之间的数据耦合和冲突。如果将ERP系统中的不同模块拆分为独立的微服务，但是仍然共享同一数据库，那么这些微服务之间的数据仍然会存在耦合和冲突的风险。 因此，如果ERP系统中的不同模块之间共享数据库，可以考虑将数据库拆分为独立的数据库实例，以便每个微服务都可以拥有自己的独立数据存储。这样可以确保每个微服务都能够独立地处理自己的数据，同时避免不同微服务之间的数据冲突和耦合。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值