当前位置： 首页 > news >正文

微服务入门级学习 - 微服务技术栈汇总

news 2025/11/7 13:37:58

本文系统性介绍微服务知识，对微服务理论知识做了一次归纳总结。

下一篇文章会系统介绍消息队列进阶，看看MQ在分布式下的挑战。

微服务概念

什么是微服务？

微服务是一种软件架构风格，它将应用程⁢序构建为一组小型、独立的 服务，每个服务都围绕特定‏的业务功能构建，并通过明؜确定义的 API 进行通信。

为了更好地理解微服务架构的作⁢用，先给大家举个例 子，看看单体架构和‏微服务架构的对比。

单体架构：

img

微服务架构：

img

从图中可以看出，单体架构将所有功能模块集⁢中在一个应用中，而微服务架 构将不同的业务功能拆分为独‏立的服务，每个服务都有自己؜的数据存储和业务逻辑。

微服务有哪些作用？

1）独立部署与运行：既**去中心化治理，**每个微服⁢务都可以独立开发、 测试、部署和扩展，‏彼此之间互不影响，؜大大降低了系统的耦合度。

举个例子，当我们需要修改用户⁢管理功能时，只需要 重新部署用户服务，‏其他服务完全不受影؜响，可以正常运行。

2）按业务功能划分服务：微服务的拆分遵循业务边界，每个服务⁢专注于特定的业务领域，做到高内聚、低耦合。比如用户服务专门负责用户注册、‏登录、权限管理等功能，AI 服务则专؜注于代码生成、模型调用等核心能力。

3）技术选型灵活：不同的微服务可以根据自身特点选择最合适的技⁢术栈，不再受限于统一的技术架构。用户服务 可以用 MySQL 存储用户信息，应用服‏务可以用 Redis 缓存数据，截图服务؜可以用对象存储保存图片，各取所需。

4）弹性扩展：可以根据业务负载情况，针对性地扩展高压力⁢服务，实现资源的精准利用。比如 AI 代码生成请求量激增时，我们只需要扩‏展 AI 服务的实例数量，而不用扩展؜整个应用，既节省成本又提升效率。

5）故障隔离：通过合理的容错设计（熔断、⁢重试、超时等机制），即使某个服务出现故障，也不会影响‏其他服务的正常运行，大大提؜升了系统的整体可用性。

6）数据分离：这是微服务架构的一条铁律。每个服务都拥有自己独立的数据库。例如，“用户服务”有自己的用户数据库，“订单服务”有自己的订单数据库。这彻底避免了服务间因数据库耦合而无法独立部署的问题。

微服务的挑战

注意，微服务架构不是银弹，不⁢是什么时候都适用的 ，它也会带来一些问‏题：

1）分布式复杂性：原本简单的本地方⁢法调用变成了跨网络的服 务调用，需要处理网络延‏迟、服务发现、数据一致؜性等分布式系统特有的问题。

2）运维复杂度提升：从管理一个应用变⁢成管理多个服务，监控、日 志收集、部署发布等运维工‏作的复杂度成倍增长，需要؜更完善的工具和流程支撑。

3）服务治理挑战：需要解决服务注册发⁢现、负载均衡、配置管理、 链路追踪等一系列问题，通‏常需要引入Nacos、网؜关等额外的基础设施组件。

4）数据一致性难题：在分布式环境下，⁢如何保证跨服务的数据一致 性是一个技术难点，往往需‏要采用最终一致性方案，增؜加了业务逻辑的复杂性。

而且很多问题的解决都要从单体考虑到分布式场景，比⁢如单机锁 => 分布式锁、单机限流 => 分布式限流、单机定时任‏务 => 分布式定时任务，会增加؜很多的开发成本和复杂任务。

微服务核心理论

服务拆分原则

微服务架构的核心在于将单体应用拆分为多个独立的服务，每个服务围绕特定的业务能力构建。以下是常用的服务拆分原则：

1. 领域驱动设计（DDD）

DDD 是服务拆分的核心指导思想。通过识别业务领域中的子域，划分限界上下文（Bounded Context），可以有效地将复杂的业务逻辑拆分为多个服务。每个限界上下文代表一个独立的业务模块，内部拥有自己的模型和逻辑，外部通过明确的接口进行交互。

在实际应用中，DDD 强调以下概念：

  • 实体（Entity）：具有唯一标识的对象，如用户、订单等。
  • 值对象（Value Object）：没有唯一标识的对象，通常用于描述某些属性，如地址、日期等。
  • 聚合根（Aggregate Root）：聚合内部唯一对外暴露的入口，确保聚合内部的一致性。
  • 领域服务（Domain Service）：封装领域逻辑的服务，通常用于处理复杂的业务规则。

通过 DDD，可以将业务逻辑与技术实现解耦，提高系统的可维护性和扩展性。

2. 单一职责原则（SRP）

每个服务应仅承担一种业务职能，避免多重职责的混合。例如，订单服务应仅处理订单相关的逻辑，而不应涉及支付或库存管理等功能。

3. 数据一致性

相关性强的数据保持在同一服务中，减少跨服务的数据依赖，也就是高内聚、低耦合。比如用户信息和用户权限放在同一个服务中，避免跨服务查询。

4. 基于业务能力拆分

将系统按照业务能力进行拆分，如电商系统可以拆分为用户、商品、订单、支付等服务。每个服务负责特定的业务领域，避免跨领域的复杂依赖，要符合业务的相互隔离才可拆分，另外能否成功拆分，还要看拆分后这个服务有没有依赖其它服务（有没有注入其它服务的Bean,new xx()对象, 这都是依赖了其它服务），来判断能不能拆，好不好拆，如果强依赖或大量依赖其它服务，你可能需要重新考虑微服务拆分方案。

除了业务上的划分，还可以将严重耗费计算力的业务独立出来，便于单独优化和扩展。比如AI代码生成和网页截图都是计算密集型任务，独立部署便于资源优化。

5. 扩展性需求

根据不同模块的扩展需求进行拆分。访问频率高的模块可以独立扩展，不影响其他服务。

服务通信机制

微服务之间的通信方式直接影响系统的性能和可靠性。常见的通信机制包括同步通信和异步通信。

1. 同步通信

参考Dubbo官方文档

  • dubbo 协议： Dubbo 自研的 高性能二进制 RPC 协议，用于在提供者和消费者之间进行远程方法调用。
  • Triple 协议： Dubbo 3.x 推出的 下一代高性能 RPC 通信协议。它基于 HTTP/2，并且 完全兼容 gRPC——所以跨语言支持。序列化格式： Protobuf / JSON / Hessian 。
  • REST 协议： 是基于 HTTP/1.1 的一种 Web 风格接口设计规范，使用 URL + HTTP 方法 表达动作（GET、POST、PUT、DELETE） ，跨语言支持。序列化格式： JSON / XML 。
  • gRPC ： 是由 Google 推出的 跨语言高性能 RPC 框架，基于 HTTP/2 + Protocol Buffers。 跨语言支持 。序列化格式： Protobuf 。

落地使用，在配置文件中修改 name 属性值

dubbo:protocol:name: dubbo / tri / restport: 8080
2. 异步通信 - 消息队列

如 RabbitMQ、RocketMQ、Kafka 等消息中间件，可实现服务间的解耦、削峰填谷和最终一致性。适用于处理高并发、异步任务等场景。

微服务九大核心组件

本小节参考文章：https://blog.csdn.net/cgk_ALEM/article/details/144664124

1. 服务注册与发现

服务注册与发现是微服务架构的基础设施，主要解决服务如何找到彼此的问题。在微服务架构中，服务实例可能会频繁地启动和停止，因此需要一个服务注册与发现机制来动态地管理和发现服务实例。服务注册中心允许服务在启动时注册自己，并在停止时注销，而服务发现机制则允许其他服务动态地查找和调用这些服务。

工作原理：服务启动时向注册中心注册自己的信息；服务消费者从注册中心获取服务提供者的地址列表；注册中心监控服务实例的健康状态，剔除不健康的实例

落地技术：Nacos、Zookeeper 、Eureka和Consul等

// 落地实现： 需要Dubbo stater 、 Nacos stater 依赖
// Main 主类需要打上 @EnableDubbo 
// 标记一个类为 Dubbo 服务提供者，由 Dubbo 自动进行注册与暴露。
@DubboService
public class UserServiceImpl implements UserService {public User getUserById(Long id) { ... }
}// 从注册中心调用上面提供的服务：
// 在另一个服务上，启动类加上@Dubbo,
// 跟原本注入 Bean 语法相似，@Resource注解换成 @DubboReference，搞定！

img

2. API网关

API网关是微服务架构的入口点，它负责处理所有进入系统的请求。作为微服务的前端，API网关提供了一个统一的接口，使得客户端不需要直接与后端的多个服务交互。它不仅简化了客户端的交互，还提供了路由、负载均衡、认证、监控和日志记录等功能。

API网关的核心功能包括：

  • 请求路由：根据请求的URL、HTTP方法或其他属性，将请求路由到相应的服务 。
  • 负载均衡：将请求分发到多个服务实例，以提高系统的可用性和响应速度 。
  • 安全认证：集中管理安全策略，如OAuth、JWT等，确保只有经过认证的请求才能访问后端服务 。
  • 监控日志：收集和记录所有通过它的请求的日志，这对于监控系统性能和排查问题至关重要。

网关还可以分为接入层网关（流量网关）和应用层网关（业务网关）。

  • 接入层网关：如 nginx , 关注网络流量的分发、路由和基础网络层面的功能，负载均衡、流量控制、反向代理都是接入层网关的职责。
  • 应用层网关：如 Spring Cloud Gateway , 更贴近业务逻辑，是业务请求的“业务处理中心”包含了特定业务规则和处理逻辑，负责将流量网关转发来的请求智能地路由到正确的后端微服务，并在过程中执行必要的业务级处理,（如安全校验，日志等，相当于拦截器）。

img

落地技术：Spring Cloud Gateway ， Higress（阿里巴巴的，基于envoy技术），Kong(跨语言通用)

Higress 翻到文末附录1了解更多。

3. 配置中心

在微服务架构中，通常会有成百上千个服务实例，每个服务可能有多个配置文件（如开发、测试、生产环境）。如果采用传统的静态配置方式，修改一个配置可能需要重新部署整个服务，效率低下且风险高。配置中心能够实现配置的动态管理，在不重启服务的情况下更新配置，大大提高了系统的灵活性和可维护性。

核心功能：

  • 配置动态更新：支持配置的实时推送，无需重启应用 。
  • 版本管理：提供配置的版本控制和回滚功能 。
  • 灰度发布：支持配置的灰度发布，先在部分应用实例中验证配置变更是否符合预期，然后再推送到所有应用实例 。
  • 权限管理：提供完善的权限管理机制，适合大型团队协作。

工作原理：服务启动时从配置中心拉取配置；配置中心推送配置变更通知到服务实例；服务实例接收到通知后重新加载配置

落地技术：Nacos 和 Spring Cloud Config

img

4. 负载均衡

我们平时说负载均衡一般都是指服务端负载均衡，但因为分布式spring cloud分布式框架出现，也出现了客户端负载均衡这一概念。

  • 服务端负载均衡：依赖中心化组件（如Nginx）统一分发请求，适用于集中式流量管理，但可能成为单点瓶颈

img

  • 客户端负载均衡：我们在使用spring-cloud分布式框架时，同一个service大概率同时启动多个，当一个请求奔过来时，那么这多个service，Ribbon通过策略决定本次请求使用哪个service的方式就是客户端负载均衡。在spring-cloud分布式框架中客户端负载均衡对开发者是透明的，添加@LoadBalanced注解就可以了。

img

常见的负载均衡策略包括：

  • 轮询：按顺序依次分配请求。
  • 随机：随机选择一个服务实例 。
  • 加权轮询：根据服务实例的权重分配请求，权重越高分配的请求越多。
  • 最少连接：选择当前连接数最少的服务实例。
5. 熔断器

我们来看一个问题，在微服务架构中，服务间调用关系错综复杂，一个请求可能需要调用多个微服务接口才能实现。如果某个服务发生故障或响应延迟，可能导致请求阻塞，线程无法释放，最终导致整个系统资源耗尽，这称为“服务雪崩”。

熔断器通过监控服务调用失败率，在达到阈值时自动切断请求，进入熔断状态（类似电路保险丝），从而防止故障蔓延，保护系统稳定性。

熔断器的工作原理可以分为以下三种状态：

  1. 关闭状态：熔断器关闭，所有请求正常通过。在此状态下，会统计请求失败率，当失败率超过阈值时，熔断器跳转到打开状态 。
  2. 打开状态：熔断器打开，所有请求被快速拒绝，直接触发降级逻辑。熔断器保持打开状态一段时间（如10秒）后，自动进入半开状态 。
  3. 半开状态：允许少量探测请求通过，若成功则恢复服务，否则重新进入打开状态 。

落地技术：Resilience4j ， Sentinel**。**

6. 服务链路追踪

在微服务架构中，一次用户请求往往需要经过多个服务协同处理，服务间的调用关系变得非常复杂。如果没有链路追踪，当某个服务出现问题时，排查问题需要逐一检查各个服务的日志，费时费力，效率低下。

服务链路追踪可以帮助我们：

  • 可视化调用链：清晰地展示请求经过的每一个服务节点，以及服务间的调用关系和耗时 。
  • 快速定位问题：通过分析调用链的耗时分布，快速找到性能瓶颈和服务异常点 。
  • 监控系统性能：实时监控各个服务的响应时间、错误率等指标，及时发现潜在问题。

链路追踪的实现原理：

  • 埋点：在代码中插入探针，用于收集追踪数据
  • 数据传递：在服务间传递Span Context
  • 数据收集：将收集到的追踪数据发送到链路追踪系统
  • 数据存储：将追踪数据存储起来
  • 数据展示和分析：提供可视化界面，展示调用链、耗时分布、错误信息等

落地技术：Zipkin、Jaeger和SkyWalking

7. 分布式事务

在微服务架构中，不同的服务之间无法做到使用同一个事务，这就无法保证数据的一致性 。例如，在一个电商系统中，订单服务需要调用库存服务扣减库存，如果订单服务成功而库存服务失败，就会导致数据不一致。

分布式事务用于在分布式系统中保证不同节点之间的数据一致性 。实现分布式事务的方案有很多，包括强一致性方案（如2PC、3PC）和最终一致性方案（如TCC、Saga、本地消息表等）

常用分布式事务的方案：

1） TCC模式

TCC（Try-Confirm-Cancel）采用补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作

  • Try阶段：尝试执行业务，完成所有业务检查（一致性），预留必要的业务资源（准隔离性） 。
  • Confirm阶段：确认执行业务，不再做业务检查。只使用Try阶段预留的业务资源，Confirm操作满足幂等性 。
  • Cancel阶段：若业务执行失败，则取消执行业务并释放Try阶段预留的业务资源 。

适用场景：对一致性要求高、业务逻辑较简单的场景 。

2）Saga模式

Saga模式是把一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块，当Saga事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务，达到事务最终一致性

适用场景：业务流程长、需要保证最终一致性的场景

8. 身份认证与授权

在微服务架构中，身份认证与授权是一个复杂的问题，因为服务数量多，调用关系复杂，需要统一管理用户身份和访问权限，主要挑战包括：

  • 单点登录：用户只需要登录一次，就可以访问所有相互信任的应用系统 。
  • 权限控制：需要控制不同用户对不同服务的访问权限。
  • 令牌管理：需要安全地生成、验证和管理访问令牌 。

主流方案：OAuth2 + JWT

OAuth2是一个授权框架，允许第三方应用程序获得对用户账户的有限访问权限。JWT（JSON Web Token）是一种开放标准（RFC 7519），它定义了一种紧凑的、自包含的方式，用于在各方之间安全地传输信息作为JSON对象.

OAuth2 + JWT的组合是微服务架构中常用的认证授权方案，其工作流程如下:

  1. 用户通过客户端向授权服务器发起认证请求 。
  2. 授权服务器验证用户身份，生成访问令牌（JWT） 。
  3. 客户端使用访问令牌访问资源服务器 。
  4. 资源服务器验证访问令牌，返回相应的资源
9. 日志聚合

在微服务架构中，日志分散在不同的服务器上，每个服务实例都会产生大量的日志文件。如果没有集中的日志管理系统，排查问题需要登录到每台服务器查看日志，效率低下。日志聚合系统可以将所有服务的日志收集起来，集中存储和管理，提供统一的查询和分析界面。

主流方案： ELK/EFK Stack和Lok

微服务开发框架

微服务开发框架是构建微服务应用的基础，它提供了服务注册⁢发现、配置管理、负载均衡、熔断降级等 微服务治理能力的统一抽象。没有框架的‏话，开发者需要自己处理这些复杂的分布؜式问题，开发效率会大大降低。

目前主流的 Java 微服务开发框架包括：

  • Spring Cloud：基于 Spring Boot 的微服务框架，生态完善，社区活跃
  • Spring Cloud Alibaba：阿里基于 Spring Cloud 的扩展，集成了阿里云的微服务组件
  • Dubbo：阿里开源的高性能 RPC 框架，专注于服务调用

注意：Spring Cloud Alibaba 并不是一个 Stater , 它本身只是一个依赖管理平台 , 在项目中可以引用BOMspring-cloud-alibaba-dependencies, BOM 只负责锁定各个组件版本，具体组件按需引入。

功能Maven 依赖说明
Nacos 注册中心spring-cloud-starter-alibaba-nacos-discovery服务注册与发现， 相当于 Eureka
Nacos 配置中心spring-cloud-starter-alibaba-nacos-config动态配置管理
Sentinelspring-cloud-starter-alibaba-sentinel流量控制与熔断
RocketMQspring-cloud-starter-alibaba-rocketmq消息队列
Seataspring-cloud-starter-alibaba-seata分布式事务
Dubbospring-cloud-starter-dubbo高性能 RPC 通信
SchedulerX、OSS、SMS 等对应的 spring-cloud-starter-alibaba-*云服务扩展

Spring Cloud概述

Spring Cloud 是由 Pivotal 团队（现为 VMware 的一部分）在 2014 年发起的微服务框架项目。它并非一个全新的框架，而是基于 Spring Boot 的编程模型，通过整合一系列成熟的第三方组件来提供微服务开发所需的常见模式解决方案。

Spring Cloud 的设计理念是利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以通过 Spring Boot 的开发风格做到一键启动和部署

主要组件：

组件名称功能描述开源公司/组织
Spring Cloud Config集中式配置管理工具，支持外部存储（如Git）Netflix
Spring Cloud Netflix集成Netflix OSS套件（Eureka, Hystrix, Zuul等）Netflix
Spring Cloud Gateway基于Spring 5+的反应式API网关Spring社区
Spring Cloud Sleuth分布式链路追踪，集成Zipkin、HTrace等Spring社区
Spring Cloud OpenFeign声明式REST客户端，整合了Ribbon负载均衡Netflix
Spring Cloud Bus事件、消息总线，用于在集群中传播状态变化Spring社区

说明：

OpenFeign 比较重要，它的定位是简化微服务之间的调用，让 HTTP 调用变得像调用本地方法一样简单的工具。

简单来说，你只需要创建一个 Java 接口，然后在上面添加一些注解，OpenFeign 就能帮你自动生成实现这个接口的代理类。当你调用接口方法时，它会自动帮你构建和发送 HTTP 请求，并将响应结果反序列化成 Java 对象。

Spring Cloud Alibaba概述

Spring Cloud Alibaba 是阿里巴巴基于 Spring Cloud 规范实现的微服务解决方案，它结合了阿里巴巴自身的微服务实践和开源中间件产品。该项目于 2018 年开源，并在 2019 年 7 月正式从 Spring Cloud Incubator 毕业成为 Spring Cloud 的官方子项目，它是 Spring 社区第一个也是唯一一个国产开源项目。Spring Cloud Alibaba 的诞生旨在为 Java 开发者提供一套一站式微服务解决方案，方便通过 Spring Cloud 编程模型轻松使用阿里巴巴的分布式应用解决方案。

img

组件名称功能描述对应阿里巴巴产品
Nacos动态服务发现、配置管理和服务管理平台Nacos
Sentinel流量控制、熔断降级、系统负载保护Sentinel
RocketMQ开源分布式消息系统，提供低延时消息发布与订阅RocketMQ
Dubbo高性能Java RPC框架（集成）Apache Dubbo
Seata高性能微服务分布式事务解决方案Seata
Alibaba Cloud OSS阿里云对象存储服务阿里云OSS
Alibaba Cloud SMS覆盖全球的短信服务阿里云短信服务

Spring Cloud 和 Spring Cloud Alibaba 通信协议对比：

协议类型Spring Cloud 支持Spring Cloud Alibaba 支持
HTTP/HTTPS✅ (主要)✅ (主要)
Dubbo 协议❌✅ (核心)
gRPC⚠️ (需自行集成)✅ (深度集成)
REST✅ (基于HTTP)✅ (基于HTTP)
消息队列✅ (通过 Stream)✅ (通过 Stream)
WebSocket✅ (网关支持)✅ (网关支持)

Dubbo概述

Apache Dubbo（最初称为 Dubbo）是阿里巴巴于2008年开始研发并在2011年开源的一款高性能 Java RPC 框架，后来捐给了 Apache 基金会, 成为 Apache 顶级项目。

Dubbo 支持的通信协议：Dubbo协议、HTTP协议、gRPC协议、REST协议

附录1 ： 云原生概念与 Higress 网关

Higress：阿里巴巴开源的一款**云原生 AI 网关 ，基于 envoy 构建，**旨在为云原生应用和 AI 场景提供高性能、高集成、易扩展的流量治理服务。

envoy：是CNCF（云原生计算基金会）的项目，云原生时代网络通信的基础设施。在微服务中，eveoy的设计理念是网络应该是透明的。当网络和应用程序出现问题时，应该很容易确定问题的根源 ，比如在每个微服务旁边都部署一个 Envoy 代理（Sidecar），所有进出该服务的流量都被强制经过这个 Sidecar。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

作用是无缝为服务提供流量管理、安全和可观测性，业务代码无需任何改动。

下面是 Higress 与 ⁢Spring Cl oud Gatew‏ay 网关的详细对比：

对比项Spring Cloud GatewayHigress
性能中等 (基于 Spring WebFlux)高 (基于 Envoy C++)
内存占用较高 (JVM)较低 (C++)
配置方式**（落地语法）**代码 + 配置文件控制台 + 配置文件
插件生⁢态Spring 生态Envoy + 自定义插件
可观测性依赖 Spri‏ng Actuator内置丰富的监控指؜标
云原生支持原生云原生设计
学习成本低 (熟悉 Spring)中等
AI 支持需要自定义开⁢发⭐原生 AI 功能支持

假如你需要在网关中写一些业务逻辑，Higr⁢ess 可能就不适合了，而 Spring Cloud Gat‏eway 是可以在代码中引入并؜且自定义 Java 业务逻辑的。各有适用场景，在技术选型要考虑到这些点。

AI 网关的概念：参考Higress官方，可以得知我们的后端应用可以集成多个大模型服务（deepseek,glm,Qwen等），后端应用对任意一个集成进来的AI大模型发出/响应请求，AI 网关会对其进行拦截，对本次请求赋予通用能力，比如内容审核，Token计算，日志等。

AI 网关还有插件功能，赋予了更多通用能力，参考 Higress 插件文档——AI提示词，可以得知，在大模型请求前后，我们还能插入一些通用的提示词，类似于系统提示词概念。

img

云原生 AI 网关的云原生是什么呢？

云原生：关键在于 “Native”（原生） 这个词，它意味着应用从设计之初就为云环境而生，充分考虑云的弹性、分布式、自动化等特性。

云原生应用: 本质上是更适合在云上部署的应用。应用从设计之初就为云而生，充分利用云平台的弹性伸缩、分布式部署和自动化运维能力，从而实现快速迭代、高可用性和资源高效利用。云原生应用的特点是启动快、性能高、内存占用少、能够弹性伸缩。

把一个传统应用改造成云原生应用，需要做微服务拆分，让其具备弹性伸缩能力、分布式部署能力，需要引用CICD、无服务器技术，让其实现自动化运维能力。

云原生应用程序开发： 云原生开发 ≠ 在云上写代码， 而是为云而生的开发方式， 利用云计算环境的弹性、可扩展性和自动化特性的现代软件开发方法， CNCF（云原生计算基金会）提出了四个关键特征，它们决定了“云原生”与传统开发的本质区别 。四个关键特征：

  • 容器化： 每个服务独立打包运行 ，落地技术是 Docker 。
  • 微服务化： 系统拆分为小型可独立部署服务 ，落地技术是Spring Cloud ,Dubbo
  • 动态编排： 自动调度、扩容、恢复服务 ，落地技术是 Kubernetes
  • 声明式管理： 用配置描述“期望状态” ，落地技术是 YAML 配置， GitOps 。

云原生开发是一整套现代开发方式，具体落地实践是：

  • 持续集成（CI）：简单说就是 代码一改，提交代码后，自动跑测试，快速发现 bug ，落地技术 GitHub Actions 或大厂自研
  • 持续交付（CD） ： 测试通过后，自动部署到测试环境或生产环境 ， 落地技术 Argo CD 或大厂自研
  • DevOps 文化 : 开发 + 运维不再分家， 自动构建、部署、监控、告警 , 落地技术 Docker、Kubernetes 、 Prometheus
  • 无服务器（Serverless） ： “Serverless” 并不是真的没有服务器 ，服务器的管理被云平台完全隐藏，开发者只需要写业务逻辑代码，开发者可以发布一个函数，公开被大家调用，区别于传统理解的一定要开发一个应用服务被调用。

以上就是原生应用程序开发的概念。

无服务器使用场景示例：

比如你写了一个 Node.js 函数：

exports.handler = async (event) => {const name = event.query.name || "World";return { message: `Hello, ${name}!` };
};

上传到 AWS Lambda 或阿里云函数计算。

然后配置触发器：

  • HTTP 请求触发；
  • 或者文件上传触发。

完成！你不用建服务器，不用开 Nginx，不用部署。每次有人访问，平台自动运行你的函数，按调用量计费。

本文参考

鱼总 https://www.codefather.cn/course/1948291549923344386/section/1960544845213282305

http://www.dtcms.com/a/578776.html

相关文章：

  • 温岭自适应网站建设深圳龙岗区景点
  • 公司网站建设及推广网站dns设置
  • 功能网站建设多少钱Wordpress内存占用高
  • 30岁做网站运营网站开发私单哪里接
  • 广东省建网站公司怎么做网站滑动图片部分
  • 公司网站用个人备案可以织梦网站图标更换
  • C++笔记——STL deque
  • 什么样的国家自然科学基金能够中标？
  • 算法322. 零钱兑换
  • 8818网站建设江门关键词优化排名
  • 网站可以个人备案吗弄美团网站的一般一个做赚多少钱
  • 自己做的网站和ie不兼容衡阳县住房和城乡建设局网站
  • 外贸推广网站建设公司装修设计
  • 免费网页设计作业素材搜索引擎优化应注意什么
  • seo站点山东省建设业协会网站
  • 化妆品网站建设描述wordpress数据爬虫
  • 如何修改网站后台密码免费软件下载平台
  • 【八股】更新
  • 数据统计网站精准客户截流软件
  • Facebook 私域运营体系构建指南：从引流到转化的系统化方法
  • 成都门户网站壹六八信息科技网站建设
  • 餐厅网站源码wordpress 阿里云虚拟主机
  • 对话式深度学习基础入门-机器学习 vs 深度学习
  • 沧州市网站企业推广方式有哪些
  • 网站开发的方法有哪些手机做直播官方网站
  • 10.29 JS学习13
  • 网站建设中英文表述手机小说网站源码
  • 建行官网网站综合网站有哪些
  • 360云盘做服务器建设网站开源软件开发平台
  • 免费的网站模版下载360指数官网