分布式注册中心Overview

本文介绍了分布式注册中心的动机,包括配置管理和服务访问透明化的需要。文章详细阐述了总体架构,包括注册中心集群和客户端库,并提供了如何开始使用的步骤。此外,还对比了与TaoBao-Dubbo的区别,强调了其内外复用、跨语言能力和服务获取的可靠性。最后,提到了配置管理和监控界面的友好性。
摘要由CSDN通过智能技术生成

转载请注明出处:jiq•钦's technical Blog 版权所有 author by 季义钦

一、 动机

当前我们已经全面进入到分布式应用时代,后端已经开始全面服务化,根据职责拆分为多个子系统,并且以廉价服务器集群进行支撑。

 

 

但是在这样一种架构下:

 

1、 减轻配置灾难:

服务、网站、FTP服务器、数据库、公共组件等资源的配置信息,以及一些全局的系统配置参数会在多个地方被配置并使用。

随着各类资源的种类和数量增多,加之引用这些资源配置信息的子系统越来越多、配置文件种类的多样化,一方面导致各类资源在多个地方被复用的时候重复配置,维护起来十分困难(配置灾难),另一方面导致在系统升级、迁移时需要修改的配置项太多。

因此我们需要一种集中管理配置信息的方式,满足逻辑清晰、易于升级部署和维护、可靠存储、读写快速方便的要求,最大程度减轻运维压力。特别注意,我认为更重要的是在将配置集中进行管理的同时,制定出适合于每个开发团队或某些系统的配置管理规范,使得配置管理范围更加清晰,比如我们团队目前将配置项划分为:公共硬件,公共软件,服务,网站,数据库,全局参数六大类。


2、 服务访问透明:

目前大多数的做法是:仍旧在需要访问服务的地方配置服务地址信息,对于后端服务子系统通过F5负载均衡器、虚拟IP(需要一个到真实服务IP的转换手段)等方式来做到服务的负载均衡。但是随着服务数量的增多和系统访问量增加,导致:需要配置和管理的服务地址信息也越来越多,系统运维、部署、迁移困难;为现有的服务增加一个备份需要重新配置负载均衡设备;旧的异构语言的软件资产难以直接接入到系统中进行复用;F5等单点负载均衡器可能成为性能瓶颈等等问题。

所以我们需要能够做到:1) 服务提供者位置和数量的变化对所有服务消费者来说完全透明化;2) 一种异构语言的服务能够无缝接入系统提供服务;3) 一些关键性服务能够无缝地增加新的备份,以提高服务的可靠性和请求处理能力;4) 避免单点压力

评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值