html网站分页怎么做的,学网站建设需要什么软件有哪些,国外免费的云服务器,在哪里找个人做网站的导语
北极星是腾讯开源的一款服务治理平台#xff0c;用来解决分布式和微服务架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题。在分布式和微服务架构的治理领域#xff0c;目前国内比较流行的还包括 Spring Cloud#xff0c;Apache Dubbo 等。在 Kubernete…导语
北极星是腾讯开源的一款服务治理平台用来解决分布式和微服务架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题。在分布式和微服务架构的治理领域目前国内比较流行的还包括 Spring CloudApache Dubbo 等。在 Kubernetes 的技术领域也有以 Istio 为代表的 ServiceMesh 技术。本篇 Blog 主要分析北极星的优势及其服务注册发现的技术实现。
我是如何看待这些技术
要做好一个服务治理框架核心功能和要素至少包括以下几点 服务注册发现 路由熔断限流 配置中心 可观测性, 日志、度量、链路追踪
从功能实现方面来看不管是 SpringCloudApache DubboIstio 还是北极星基本都实现了这些功能那它们的实现思路有什么不同呢?
SpringCloud
SpringCloud 是完全架构在 SpringBoot 基础上的是 SpringBoot 开发框架很自然的延伸因此继承了 SpringBoot 框架所有的优点可以非常灵活的集成各类服务注册发现、服务治理、可观测组件。例如 SpringCloud 框架自身开发了 Spring-Cloud-Config 和 Spring-Cloud-Sleuth 组件分别提供了配置和部分可观测性的能力在其他能力方面早期版本主要由 Netflix 提供的 Eureka, Ribbon, Hystrix等组件提供了服务注册发现服务治理的能力; 随着 Netflix 很多组件生命周期结束 SpringCloud 又通过自定义的 Abstract LoadBalance/Route 接口及实现 以及集成的 Resilience4J/Sentinel 等熔断限流组件继续为用户提供统一的服务注册发现服务治理等方面的能力。
SpringCloud 在实际使用过程中, 可能会给人一种没有一个统一的服务治理模型的错觉, 这是因为 SpringCloud 保持了自身的胶水框架的特性和思路, 可以集成和融合各类治理组件例如熔断限流就提供了 Hystrix、Resilience4J、Sentinel 等方式。这样的框架特性优势是灵活可以融合各类框架劣势是抽象统一的治理模型比较困难因此 SpringCloud 并没有提供一个统一的服务治理控制面即使是 Spring-Cloud-Admin 的扩展也更多是基于 SpringBoot Actuator 提供可观测的管理并没有提供服务治理的控制面能力。
ServiceMesh-Sidecar 模式
ServiceMesh 解耦了业务逻辑和服务治理逻辑它将服务治理能力下沉到基础设施在服务的消费者和提供者两侧以独立进程的方式部署。这种方式提升了整体架构的灵活性减少对业务的侵入性并很好的解决了多语言支持的复杂性。劣势是一方面服务通过 sidecar 的调用多了一道 iptables/ipvs 的转发降低了一些性能Sidecar 也增加了少量的资源使用另一方面是中小团队很难对框架灵活扩展虽然 Envoy 提供了 WASM 机制其自身也能通过 C 扩展 Filter但是不管哪种方式都需要团队有一定经验的人员来完成中小团队很难提供这样的人员保障。
另外Istio 虽然也能提供基于虚拟机/物理机的部署但是本身还是基于Kubernetes 设计的也对 Kubernetes 部署最友好对于未使用 Kubernetes 的团队有一定的挑战。
PolarisMesh
PolarisMesh 从个人的角度看是融合和兼容了很多技术的解决方案。
一方面它可以看作是 SpringCloud 服务治理实践的一种自顶向下的正向思考过程SpringCloud 是自底向上的一种构建思路它提供了各类服务发现、服务治理、可观测组件的集成和融合但是并没有提供统一的顶层治理模型(或者仅提供了一部分)而 Polaris 是先基于下一代架构基金会所制定的服务治理标准制定和扩展了服务治理的模型然后基于该模型分别构建了服务治理的控制面和数据面(各类语言的 SDK、开发框架、JavaAgent、Kubernetes Controller)。当然基于该模型也能很好的对接到 ServiceMesh 的治理方式, 这样就给未来的发展也留足了空间。
另一方面PolarisMesh 也通过插件机制为框架扩展预留了空间如果当前的开源 Polaris 不满足你的需求可以较灵活的进行扩展。
polaris-go SDK 服务注册发现技术分析源码阅读
本篇 Blog 重点对 Polaris-Go SDK 的服务的注册和发现做下技术分析, 以及源码阅读。主要是服务注册和发现是各类服务治理框架最基础和核心的功能因此先从它开始吧~
公共部分 SDKContext
在客户端 SDK 不论是服务注册的 API, 还是服务发现的 SDK其内部都是封装了 SDKContext 的上下文 SDKContext 内部构成如下图所示 ConfigurationImpl: 主要是客户端 polaris.yaml 配置文件的映射 分为4个部分分别是 GlobalConfig ConsumerConfig ProviderConfig 和 ConfigFileConfig 。
ConnectionManager: gRPC 连接的连接池管理接口。
plugin.Manager: 插件管理接口SDK 内部实现的各类功能- 熔断限流配置健康检查路由负载均衡等都是按照插件的方式实现 插件需要实现 Plugin 接口通过 PluginProxy 包装后交给 plugin.Manager 管理。
EngineSDK 执行的各类动作都交由 Engine 处理 例如服务的注册发现限流路由熔断等都是调用 Engine 内的 API 实现。也就是 SDK 能执行的功能都是由 Engine API 统一实现。
服务注册流程
服务注册的粗略流程如下图所示 : go 客户端 SDK 的整体服务注册流程比较线性, 没有涉及特别复杂的逻辑, 相关 gRPC service 如下:
service PolarisGRPC {// 客户端上报rpc ReportClient(Client) returns (Response) {}// 被调方注册服务实例rpc RegisterInstance(Instance) returns (Response) {}// 被调方反注册服务实例rpc DeregisterInstance(Instance) returns (Response) {}// 统一发现接口rpc Discover(stream DiscoverRequest) returns (stream DiscoverResponse) {}// 被调方上报心跳rpc Heartbeat(Instance) returns (Response) {}// 上报服务契约rpc ReportServiceContract(ServiceContract) returns (Response) {}
}服务发现流程
服务发现流程相对于服务注册流程要复杂很多, 主要原因是北极星的服务发现会涉及本地 Cache 与 远程 Server 端信息的懒加载同步同时加载的服务信息也比较复杂包括实例信息服务信息路由信息限流信息等内容。
服务发现的粗略流程如下图所示 : 可以看到服务发现中的关键点包括: SDK 内部实现了 LocalCache 缓存机制 同时 LocalCache 缓存具备以懒加载方式同步远程 Server 中服务信息的能力。 SDK 与远程服务信息的同步是由插件 Serverconnector 实现 SDK客户端通过专门的 Routine 和 Channel 队列在服务信息第一次远程懒加载完成后 定时拉取远程 Server 中的服务信息并更新本地缓存和插件数据。 获取到服务信息后通过路由和负载均衡机制选取出可用实例参考官网-流量管理。 其他细节包括: 与服务端通信后的异步回调更新机制超时计算重试 缓存实现插件加载机制等 。
go SDK 服务发现的 gRPC 接口如下:
// DiscoverClient 服务发现客户端接口
type DiscoverClient interface {// Send 发送服务发现请求Send(*apiservice.DiscoverRequest) error// Recv 接收服务发现应答Recv() (*apiservice.DiscoverResponse, error)// CloseSend 发送EOFCloseSend() error
}结语
上面的技术分析因为时间有限难免有错误和遗漏欢迎大家指正 也特别感谢社区的帮助。北极星通过对服务治理标准的实现提供了完善的服务发现和治理方案。同时, SDK客户端与 Server 服务端的数据同步与交互也有设计良好的服务治理模型和健壮的通信机制提供了可靠的保障。此外通过插件机制SDK框架 也提供了灵活扩展的能力 。
