企业官网建设流程全解析

中国移动官方网站,小兽wordpress官网,qnap如何搭wordpress,卖芒果的网络营销策划前言 上一篇内容#xff0c;我们详细讨论了envoy做服务发现#xff0c;并且详细讨论了静态配置与使用dns做服务发现#xff0c;并且通过consul的详细配置阐述了dns做服务发现的工作原理#xff0c;但是也遗留了一个问题#xff0c;一旦想要修改endpoint的配置 clusters:-…前言上一篇内容我们详细讨论了envoy做服务发现并且详细讨论了静态配置与使用dns做服务发现并且通过consul的详细配置阐述了dns做服务发现的工作原理但是也遗留了一个问题一旦想要修改endpoint的配置clusters: - name: app_service connect_timeout: 1s type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: app_service endpoints: - lb_endpoints: - endpoint: address: socket_address: address: backend-service port_value: 10000比如我想改address: backend-serviceenvoy并不会自动感知还是需要重启envoy xDS简介xDS 不是一个单一的模块而是一组与 Envoy 服务发现相关、解耦的 API 接口集合CDS (Cluster Discovery Service) 集群发现。获取上游集群的定义即 Envoy 可以将流量路由到的一组逻辑上相似的上游主机EDS (Endpoint Discovery Service) 端点发现。这是最核心的服务发现模块。它为每个集群提供具体的、健康的网络端点如 IP:Port列表。Envoy 支持通过 EDS 进行增量更新从而实现高效、实时的服务实例变更LDS (Listener Discovery Service) 监听器发现。获取 Envoy 应该监听的网络地址、端口和过滤器链配置RDS (Route Discovery Service) 路由发现。获取虚拟主机和路由规则配置用于将流量定向到正确的集群SDS (Secret Discovery Service) 密钥发现。安全地获取 TLS 证书和私钥ADS (Aggregated Discovery Service) 聚合发现服务。一个特殊的 gRPC 端点它将所有 xDS API 聚合到单个流中。这确保了配置更新的一致性和顺序性避免配置不一致导致的流量中断是不是看得脑袋嗡嗡的没关系我们从最核心的入手那就是EDSenvoy EDS所谓EDS服务就是在envoy之外有一个配置中心之前直接配置在envoy的静态配置搬迁到配置中心来新增和维护新规则都在配置中心维护一旦配置有变更配置中心会主动推送到envoy让其及时变更流量转发配置创建eds服务端手搓一个最简单的eds_server用来演示eds服务该脚本启动18000端口接收gRPC请求并且响应EDS只要envoy来连接18000就会下发endpoint到envoy修改envoy配置再修改一下envoy的配置... clusters: - name: backend_cluster type: EDS connect_timeout: 0.25s lb_policy: ROUND_ROBIN eds_cluster_config: eds_config: api_config_source: api_type: GRPC grpc_services: - envoy_grpc: cluster_name: eds_server - name: eds_server connect_timeout: 1s type: STATIC http2_protocol_options: {} load_assignment: cluster_name: eds_server endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 10.22.12.178 port_value: 18000 ...type: EDS说明了使用EDS作为服务发现而EDS的相关信息在cluster_name: eds_server这里定义eds_server是静态的配置访问10.22.12.178:10000就能够获取获取eds配置验证配置完之后首先启动eds_server▶ go run eds.go 2025/12/23 18:15:36 EDS server listening on :18000修改envoy配置之后重启检查eds_server的输出▶ go run eds.go 2025/12/23 18:15:36 EDS server listening on :18000 2025/12/23 18:17:33 EDS stream connected 2025/12/23 18:17:33 Sending EDS response version1766484936064308385, nonce1766485053421230413 2025/12/23 18:17:33 DiscoveryRequest resources[backend_cluster] version nonce 2025/12/23 18:17:33 DiscoveryRequest resources[backend_cluster] version1766484936064308385 nonce1766485053421230413成功了启动的envoy之后envoy与eds_server建立连接并且eds_server推送相关配置给envoy再访问一下试试curl 10.22.12.178:30785/test[2025-12-23T10:20:44.892Z] GET /test HTTP/1.0 200 40 1 c40a5dd3-29b7-4d1b-b73d-e93b31b5f6e3 curl/7.81.0 - 10.244.0.111:10000 backend_cluster - [2025-12-23T10:20:46.003Z] GET /test HTTP/1.0 200 40 1 1656452c-4571-469b-b2b7-3d43bd703c6d curl/7.81.0 - 10.244.0.114:10000 backend_cluster -EDS小结手搓了一个能够响应eds的服务并且将envoy指向该服务envoy也能够获取后端endpoint的地址成功转发的请求演示中的脚本是将配置写死在代码中的s.endpoints []*endpointpb.LbEndpoint{ newEndpoint(10.244.0.111, 10000), newEndpoint(10.244.0.114, 10000), }只需要将这部分改造一下。如果在k8s里面那就watch k8s的endpoint动态获取就行。如果是在k8s集群之外可以封装一个web 容器在页面上管理后端endpoint也行。总之后端服务的配置完全由eds接管不管ip:port怎 么变化只需要在eds服务中配置就会推送至envoy完成endpoint服务发现envoy RDS现在已经拥有了EDS服务能够动态获取endpoint但是http的路由配置依然是直接在配置文件里面的... static_resources: listeners: - name: ingress_listener address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http http_protocol_options: accept_http_10: true common_http_protocol_options: idle_timeout: 300s codec_type: AUTO route_config: name: local_route virtual_hosts: - name: app domains: [*] routes: - match: { prefix: / } route: cluster: backend_cluster ...比如想要修改match: { prefix: / }envoy并不会感知还是需要重启。所以引入RDS服务与EDS服务类似自动发现HTTP路由配置创建rds服务端手搓一个简单的rds_serverrds服务该脚本启动18001端口接收gRPC请求并且响应RDS只要envoy来连接18001就会下发http route到envoy修改envoy配置static_resources: listeners: - name: ingress_listener address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http http_protocol_options: accept_http_10: true codec_type: AUTO rds: route_config_name: local_route config_source: api_config_source: api_type: GRPC grpc_services: - envoy_grpc: cluster_name: rds_server ... clusters: ... - name: rds_server connect_timeout: 1s type: STATIC http2_protocol_options: {} load_assignment: cluster_name: rds_server endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 10.22.12.178 port_value: 18001验证配置完之后首先启动rds_server▶ go run rds.go 2025/12/24 17:02:34 RDS server listening on :18001修改envoy配置之后重启检查rds_server的输出▶ go run rds.go 2025/12/24 17:02:34 RDS server listening on :18001 2025/12/24 17:02:55 RDS stream connected 2025/12/24 17:02:55 Sending RDS response version1766566954686151045, nonce1766566975846610006 2025/12/24 17:02:55 DiscoveryRequest resources[local_route] version1766561174225337826 nonce 2025/12/24 17:02:55 DiscoveryRequest resources[local_route] version1766566954686151045 nonce1766566975846610006成功了启动的envoy之后envoy与rds_server建立连接并且rds_server推送相关配置给envoy再访问一下试试curl 10.22.12.178:30785/test[2025-12-24T09:03:16.252Z] GET /test HTTP/1.0 200 40 1 bea0ccf1-0621-4be1-919f-3dbb24e93ff5 curl/7.81.0 - 10.244.0.114:10000 backend_cluster - [2025-12-24T09:03:16.916Z] GET /test HTTP/1.0 200 40 1 f22c01e4-8120-4cb1-837e-a6c0b27f7410 curl/7.81.0 - 10.244.0.111:10000 backend_cluster -RDS小结演示中的脚本是将配置写死在代码中的Match: routepb.RouteMatch{ PathSpecifier: routepb.RouteMatch_Prefix{ Prefix: /test, }, },只需要将这部分改造一下。如果在k8s里面那就watch k8s的ingress动态获取就行。如果是在k8s集群之外可以封装一个web 容器在页面上管理后端http router也行envoy ADS目前我们完成了EDS、RDS可以自动发现对应的endpoint、http router资源但是他们都是gRPC协议能不能整合在一起呢并且xDS还有其他的资源什么CDS、LDS等等每个种类都监听一次接口管理难度也太冗余了。于是ADS就应运而生了它是一个聚合发现服务一个特殊的 gRPC 端点将所有 xDS API 聚合在一起创建ads服务端ads服务该脚本启动18000端口接收gRPC请求并且响应聚合请求ADS再根据不同的查询类型EDS、RDS等响应不同的资源并且下发到envoy修改envoy的配置这里修改较为复杂直接给出配置文件即可node: id: envoy-1 cluster: demo-proxy dynamic_resources: ads_config: api_type: GRPC grpc_services: - envoy_grpc: cluster_name: ads_server static_resources: listeners: - name: ingress_listener address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http http_protocol_options: accept_http_10: true codec_type: AUTO rds: route_config_name: local_route config_source: ads: {} http_filters: - name: envoy.filters.http.router typed_config: type: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router access_log: - name: envoy.access_loggers.stdout typed_config: type: type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog log_format: text_format: [%START_TIME%] \%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\ %RESPONSE_CODE% %BYTES_SENT% %DURATION% %REQ(X-REQUEST-ID)% \%REQ(USER-AGENT)%\ \%REQ(X-FORWARDED-FOR)%\ %UPSTREAM_HOST% %UPSTREAM_CLUSTER% %RESPONSE_FLAGS%\n clusters: - name: ads_server connect_timeout: 1s type: STATIC http2_protocol_options: {} load_assignment: cluster_name: ads_server endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 10.22.12.178 port_value: 18000 - name: backend_cluster type: EDS connect_timeout: 0.25s lb_policy: ROUND_ROBIN eds_cluster_config: eds_config: ads: {}验证首先启动ADS服务再修改envoy配置最后重启envoy服务。验证部分同EDS、ADS这里就不赘述ADS小结至此通过ADS聚合服务可以接受不同类型的xDS请求在文中我们实现了EDS与RDS当然如果有需求可以持续的把LDS、CDS等全部加上小结“修改配置之后如何自动生效”本文通过这一切入点详细探讨了envoy的另外一种服务发现策略xDS并且手搓了诸如EDS、RDS等服务成功响应了envoy的需求完成了配置生效。并且最终使用ADS将EDS与RDS聚合在一起形成了一个统一且管理型强的服务入口后记有位老哥说了这不就是istio嘛没错istio的数据面就是使用envoy所谓服务治理也是从解决最基本的问题而诞生的本系列从“记录后端真实pod ip”为切入口通过常见的场景需求不断的解决需求发现问题解决问题最终将这些功能全部聚合一起就是服务治理的基本框架而问题的提出、解决问题的过程以及需求的满足不光是服务治理也是所有软件诞生的基本思想联系我联系我做深入的交流至此本文结束在下才疏学浅有撒汤漏水的请各位不吝赐教…