首页 资讯 社群 我的社区 搜索

再看Spring Could微服务的关键组件

LM123
2019-02-16 17:57:58

Consul是用go开发的开源注册中心服务,内置服务发现与注册、raft一致性协议实现、健康检查、多数据中心等方案。与Eurker相比,consul还能对异构服务如rpc提供支持。

作为微服务系统的核心组件,一旦consul挂掉,所有服务都将停止,因此生产环境中必须要用Consul高可用集群。在Consul集群中有server、client两种角色,集群状态信息都存在server节点,client角色是无状态的,它只是代理转发rpc请求到sever节点,起到缓冲的作用,从而减少server节点数量(server节点越多,达成共识、节点间同步代价越高,一般建议3-5台)。Consul通过集群设计,Raft选举算法,Gossip协议等机制来确保Consul服务的稳定与高可用,如果需要更高的容灾机制,可通过设计双数据中心异地搭建两个Consul数据中心,组成一个异地灾备Consul服务集群。

ConfigServer配置中心是对微服务应用配置管理的服务,如数据库、端口配置等,与Consul一样是一个重要的独立服务组件,所有的微服务应用都要调其服务获取配置信息。随着微服务配置越来越多,如何管好这些配置及它们的更新策略,搭建ConfigServer集群也是保证微服务体系稳定的重要方面。这样的关键组件应该搭建独立的集群、部署在物理机而不是容器里。因为ConfigServer主要是http配置文件访问服务,不涉及节点选举、一致性同步操作,可以按传统方式搭建高可用配置中心。可以单独通过git来管理应用配置文件,ConfigServer通过网关拉取git仓库的配置供服务获取就可以了。

与传统方案通过Nginx做负责均衡方案不同,Spring Could中微服务间调用的负载均衡默认是服务消费端通过Robbin代理实现的客户端负载均衡,同样的服务熔断、限流等机制也是基于Hystrix在消费端实现的,这都需要在消费端进程内部通过代码的方式实现,对消费端存在一定的代码侵入性,这也是后面出现Service Mesh(服务网格)概念的原因之一。

基于Spring Could的微服务体系,通过集成各种开源组件为整个体系服务支持,但在负载均衡、熔断、流控等方面需要对消费端业务进程侵入,于是出现了Service Mesh,其基本思路是通过主机独立的Proxy进行的部署来解耦业务系统流程,Proxy除了负责服务发现和负责均衡外,还负责动态路由、容错限流、监控度量和安全日志等功能。

用户评论