架构07-从类库到服务

零、文章目录

架构07-从类库到服务

1、服务发现

（1）服务发现的意义

• 服务发现的核心意义在于解耦程序对服务具体位置的依赖。
• 在分布式应用中，服务发现是必须的，它使得计算机可以通过网络中的不同机器互相协作来复用功能，从而实现软件发展的第二次飞跃。

（2）服务发现的关键过程

• 服务的注册（Service Registration）：
  • 服务启动时，通过调用 API、产生事件消息、在 ZooKeeper/Etcd 的指定位置记录等方式，将自己的坐标信息通知给服务注册中心。
  • 可以由应用程序或容器框架（如 Kubernetes）完成。
• 服务的维护（Service Maintaining）：
  • 服务发现框架通过多种协议（HTTP、TCP等）和方式（长连接、心跳、探针、进程状态等）监控服务的健康状况，自动下线不健康的服务，确保服务列表的正确性。
• 服务的发现（Service Discovery）：
  • 消费者通过 HTTP API 请求或 DNS Lookup 操作，将符号（如 Eureka 中的 ServiceID、Nacos 中的服务名、通用的 FQDN）转换为服务的实际坐标。
• 
• 在真实场景中，服务发现是整个系统中，其他所有服务都直接依赖的最基础的服务，所以我们必须尽最大可能，在技术层面上保证系统的可用性。
• 

（3）服务发现的权衡

• 服务发现需要在一致性和可用性之间进行权衡，主要关注点是一旦出现分区所带来的后果。常见的权衡选择包括：
  • **CP（一致性优先）：**如 Consul，采用 Raft 协议，要求多数派节点写入成功后才完成服务注册或变动，确保集群外部读取到的服务发现结果一致。
  • **AP（可用性优先）：**如 Eureka，采用异步复制，服务注册或变动时不需要等待信息在其他节点复制完成，提高可用性但牺牲了一致性。

（4）服务发现的实现形式

• 在分布式 K/V 存储框架上实现：
  • **代表：**ZooKeeper、Doozerd、Etcd。
  • **特点：**提供分布式环境下读写操作的共识保证，通常是 CP 的，维护较为简单的应用接口，适用于“大厂”自定义实现。
• 以基础设施（DNS 服务器）实现：
  • **代表：**SkyDNS、CoreDNS。
  • **特点：**对应用透明，不受程序技术选型的约束，但需要自行处理客户端负载均衡、远程方法调用等问题。
• 专有服务发现框架：
  • **代表：**Eureka、Consul、Nacos。
  • **特点：**支持 CP 和 AP 的选择，对应用不是透明的，但提供了丰富的功能和便捷的开发体验，适用于特定语言和框架。

（5）服务发现的优势与挑战

• 优势：
  • 提供服务注册、维护和发现的完整解决方案。
  • 支持多种协议和健康检查方式。
  • 集成配置管理、K/V 存储等功能。
• 挑战：
  • 需要在一致性和可用性之间进行权衡。
  • 对应用程序有一定的侵入性，需要考虑技术栈的兼容性。

2、网关路由

（1）网关的基本概念

• **定义：**网关（Gateway）是位于内部区域边缘，与外界进行交互的物理或逻辑设备，如家庭路由器。
• **作用：**在微服务架构中，网关作为服务集群对外的统一入口，承担着将外部流量路由到内部服务节点的任务。

（2）网关的基础职能

• **路由器：**网关的主要职责是将外部访问的流量根据规则路由到内部集群中正确的服务节点。
• **过滤器：**网关还可以提供额外的可选功能，如安全、认证、授权、限流、监控和缓存等。

（3）路由原理与知识点

• 网络层次与协议
  • **四层路由：**基于 TCP 报文中的源地址、目标地址进行路由。
  • **七层路由：**基于 HTTP 的 URL、Header 等信息进行路由。
  • **高级协议：**支持 WebSocket、SOAP 等上层协议，从中提取特征进行路由。
• 性能与可用性
  • **性能考量：**网关的性能主要取决于其网络 I/O 模型。
    • **同步 I/O：**包括阻塞 I/O、非阻塞 I/O、多路复用 I/O 和信号驱动 I/O。
    • **异步 I/O：**数据到达缓冲区后，由操作系统向线程发送信号，是非阻塞的。
  • 可用性考量：
    • **轻量化：**网关应尽可能轻量，避免过度增加职责。
    • **选型成熟性：**选择经过长期考验的产品，如 Nginx Ingress Controller、KONG、Zuul 等。
    • **高可用性：**在网关之前部署负载均衡器或等价路由器（ECMP）。

（4）BFF 概念

• **定义：**Backends for Frontends，网关不必为所有前端提供无差别的服务，而是针对不同的前端，聚合不同的服务，提供不同的接口和网络访问协议支持。
• **应用：**例如，Web 程序使用 RESTful API，桌面程序使用 gRPC 协议。

（5）网关的性能优化

• Zuul 网关：
  • **1.0 版本：**采用阻塞 I/O 模型，适合计算密集型服务。
  • **2.0 版本：**基于 Netty Server 实现异步 I/O 模型，减少线程数，提高性能和降低延迟。

（6）网关的其他应用

• **限流：**防止后端服务过载。
• **容错：**处理失败请求，提高系统稳定性。
• **安全：**提供认证、授权等安全机制。
• **监控：**收集和分析流量数据，监控系统性能。

3、客户端负载均衡

（1）相关概念的区分

• **服务发现：**将服务名称转换为恰当的服务地址，通常根据请求来源的物理位置进行分配。
• **网关路由：**将请求与配置中的特征进行比对，确定请求的目标服务。
• **负载均衡：**在多个服务实例中根据某种策略选择一个服务实例来响应请求。
• **调用容错：**当某个服务实例失败时，根据故障转移策略重试其他服务实例。

（2）具体案例场景

• 假设你在广东访问 Fenix’s Bookstore 购买一本书，调用商品出库服务的过程如下：
  • **服务发现：**将 warehouse 服务名称转换为广州机房的服务地址。
  • **网关路由：**广州机房的服务网关将请求转换为内网地址。
  • **负载均衡：**负载均衡器选择一个具体的 warehouse 服务实例。
  • **调用容错：**如果某个服务实例失败，负载均衡器会重试其他实例。

（3）客户端负载均衡器的工作原理

• **传统集中式负载均衡器：**部署在服务集群前端，将用户请求分流到各个服务。
• **客户端负载均衡器：**部署在每个服务实例前端，与服务实例共存于同一进程内。
  • 优点：
    • 无额外网络开销。
    • 避免“绕场一周”的问题。
    • 天然避免单点问题。
    • 更灵活的均衡策略设置。
  • 缺点：
    • 受限于服务使用的编程语言。
    • 影响服务进程的稳定性和资源消耗。
    • 内部网络安全和信任关系复杂。
    • 需要持续轮询服务注册中心。

（4）代理客户端负载均衡器

• **定义：**将客户端负载均衡器提取到边车代理中实现。
• 优点：
  • 不受限于编程语言。
  • 不影响服务进程的稳定性。
  • 更高效的拓扑感知。
  • 更好的安全性和可观测性。
• 缺点：
  • 数据需要经过操作系统协议栈，但仍然比真正的网络交互高效。

（5）地域与区域

• **Region（地域）：**地理上的大范围区域，不同地域之间没有内网连接。
• **Zone（区域）：**地理上位于同一地域内，但电力和网络独立的物理区域，区域之间有内网连接。
• 应用场景：
  • **高可用：**跨区域部署以应对电力或网络中断。
  • **低延迟：**部署在同一区域以减少网络延时。

原文地址：https://blog.csdn.net/liyou123456789/article/details/144224381

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！