分布式注册中心Overview

最新推荐文章于 2024-08-21 21:22:05 发布

置顶

小弟季义钦

最新推荐文章于 2024-08-21 21:22:05 发布

阅读量5.4k

点赞数 2

分类专栏：分布式服务架构

本文链接：https://blog.csdn.net/jiyiqinlovexx/article/details/43702035

版权

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

摘要由CSDN通过智能技术生成

一、动机

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

但是在这样一种架构下：

1、减轻配置灾难：

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

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

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

2、服务访问透明：

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

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