48 lines
5.2 KiB
Markdown
48 lines
5.2 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
tags:
|
|||
|
|
- maturity/🌱
|
|||
|
|
date: 2024-12-08
|
|||
|
|
---
|
|||
|
|
Централизованный сервис — это компонент [[../../../../_inbox/Информационная система|системы]], выполняющий одну или несколько ключевых функций, таких как аутентификация, управление конфигурацией, обработка данных или логирование. Все или большинство других компонентов системы зависят от работы этого сервиса, что делает его важным элементом архитектуры.
|
|||
|
|
|
|||
|
|
Централизованные сервисы часто встречаются в монолитных приложениях или в [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектуре]], где определённый микросервис выполняет критическую роль.
|
|||
|
|
|
|||
|
|
**Примеры централизованных сервисов**
|
|||
|
|
- **Auth Service** — централизованная аутентификация и авторизация пользователей.
|
|||
|
|
- **Configuration Server** — единый источник конфигурационных данных для системы.
|
|||
|
|
- **Message Broker** — посредник для обмена данными между микросервисами (например, Kafka, RabbitMQ).
|
|||
|
|
- **Logging Service** — агрегатор логов из разных частей системы.
|
|||
|
|
- **Data Store** — единый источник данных, например, основная база данных.
|
|||
|
|
|
|||
|
|
**Преимущества централизованного сервиса**
|
|||
|
|
- **Упрощённая логика**. Все компоненты обращаются к единому сервису, что делает логику работы системы понятной и предсказуемой.
|
|||
|
|
- **Централизованное управление**. Легче внедрять изменения, поскольку обновление логики происходит в одном месте.
|
|||
|
|
- **Консистентность данных**. Использование одного источника данных или логики исключает дублирование и расхождения.
|
|||
|
|
- **Удобство мониторинга**. Проще отслеживать состояние системы, когда ключевые функции реализованы в одном месте.
|
|||
|
|
|
|||
|
|
**Недостатки централизованного сервиса**
|
|||
|
|
- [[Single point of failure|Единственная точка отказа]] (SPOF). При отказе централизованного сервиса вся система может оказаться недоступной.
|
|||
|
|
- [[Bottlneck|Узкое место]]. Высокая нагрузка на сервис может привести к деградации производительности всей системы.
|
|||
|
|
- Риски [[Масштабирование информационной системы|масштабируемости]]. Централизованные сервисы сложнее масштабировать, особенно если они обрабатывают большие объемы данных.
|
|||
|
|
- [[Latency|Задержки]]. В распределённых системах время отклика может увеличиваться из-за необходимости обращения к централизованному компоненту.
|
|||
|
|
|
|||
|
|
**Как минимизировать риски централизованных сервисов?**
|
|||
|
|
- [[highload/Репликация|Репликация]] и кластеризация. Развёртывание нескольких экземпляров сервиса с балансировкой нагрузки между ними.
|
|||
|
|
- **Распределение ответственности**. Разделение функциональности на несколько сервисов, чтобы уменьшить нагрузку на каждый из них.
|
|||
|
|
- [[Кэширование]]
|
|||
|
|
- **Децентрализация**. Внедрение распределённых механизмов, которые уменьшают зависимость от одного сервиса. Пример: использование JWT для авторизации вместо постоянных запросов к Auth Service.
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
|
|||
|
|
**Родитель**:: [[Single point of failure|Single point of failure]]
|
|||
|
|
**Источник**::
|
|||
|
|
**Создана**:: [[2024-12-08]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
|||
|
|
|