.NET微服务架构的演变历程中，有哪些关键节点值得探究？

服务架构的演变 单体架构=>分布式架构=>SOA架构=>微服务架构=>Service Mesh=>Cloud Native 单体架构/垂直架构 分布式架构 SOA架构 SOA是一种软件设计理念与架构模式，核心是将系统拆分为一系列的松耦合，可复用，可独立部署的"单个服务"，通过标准化接口让各个服务之间协同工作。 本质上是为了解决单体架构(所有功能都放一起)的紧耦合，难复用问题。 什么是ESB？为什么需要它？ 在没有ESB的系统中，系统与系统之间的通信往往是点对点直连，比如服务A需要调用服务B/C，就必须适配B/C的协议，比如HTTP，TCP，JMS等，并且格式也各不相同(JSON/XML/CSV)， 当某一个服务发生变更，比如参数调整，协议变化，都会导致依赖它的服务也需要同步适配。 所以延伸出了ESB，它作为一个adapter，起到了承上启下的作用，所有服务只需要连接到ESB，由ESB提供统一的协议转换，格式转换，动态路由等功能。 微服务架构 需要注意一点，微服务架构是分布式架构的一种轻量级落地，它们之间是接口与实现类的关系。 微服务为什么又不需要ESB？ 性能瓶颈 所有服务之间的通信都由ESB统一处理，很有可能造成ESB的处理能力不足。 单点故障 原因同上，当ESB发生故障时，所有依赖ESB的服务均会被拖累，尽管可以通过集群化缓解，但风险依旧存在 与微服务理念冲突 微服务理念是“轻量，去中心化”，而ESB则是强调中心化，基础功能大而全。 微服务核心功能 服务发现 为什么需要服务发现？ 服务实例的动态变化 在水平架构中，我们的服务集群往往是通过Nginx/IIS的静态配置来实现节点的增/减。加上节点少，因此，每次修改节点配置都是人工修改。 而微服务架构天然的动态性与不确定性，服务实例通常需要动态扩容/缩容，故障重启，滚动升级等特点，因此服务示例的网络地址是随时变化的，加上微服务化之后，服务实例呈指数级增加，再由人工干预就不明智了。 分布式环境的网络复杂性 服务实例可能步骤在不同的物理机，虚拟机，容器中，将它们整合非常麻烦，需要一个能够屏蔽底层细节，提供统一入口的组件，让调用方无需关心目标服务具体位置 抽象网络地址 水平架构中，我们常常依赖IP+端口的形式来确定服务实例，在微服务架构中，使用Service-Name来提供一个逻辑名称 去除不可用实例 通过心跳访问实例提供的Healthcheck，当某个实例故障时，自动去除，避免访问到不可用节点。 简单来说，服务发现解决的是微服务实例之间的动态通信问题，主要用于内部服务间的调用。 API网关 API 网关是什么，它具备什么功能? 统一路由 根据请求路径将请求转发到后端实例，比如https://gateway.XXXXX.com/你的业务实例前缀/user/{id}; 协议转换 将前端的HTTP请求转换为服务内部的rpc协议 身份认证与鉴权 集中处理JWT，OAuth2等鉴权操作，避免每个微服务都重复校验 流量管理 实现服务的负载均衡，限流等操作，避免微服务收到冲击。 日志与指标分析 作为统一入口，可以统一记录请求量，响应实践，成功率等指标，方便分析。 感觉服务发现与API网关重合了？ 服务发现解决的是微服务实例之间的动态通信问题，主要用于内部服务间的调用。 API 网关是外部客户端访问微服务的统一入口，主要用于客户端与微服务之间的通信。 举个例子： 客户端认证需求 若没有API网关，客户端直接调用微服务，每个微服务都要重复检验用户的JWT。 多协议支持 微服务内部使用gRPC协议，而客户端是HTTP协议，这中间无法转换。 流量保护 服务发现仅能实现简单的负载均衡（如轮询），但 API 网关可通过限流策略（如令牌桶、漏桶算法）防止突发流量压垮后端服务，这是服务发现无法实现的 数据聚合优化 比如客户端需要同时获取 user与order信息，若通过服务发现，需要分别调用user service与order service，产生多次网络请求，而API网关将多个响应结果合并为一个，减少客户端的请求量。 有人可能会问了，我让服务发现与API网关合并就好了，这样不就大而全了？ 合二为一的组件确实存在，如 Kong、Traefik、Istio Gateway 等，它们通过集成服务发现机制到网关中，简化了微服务架构的复杂度。