Vs Сервисный интерфейс

Question

Я не знаю, существует ли этот вопрос в Переполнении стека.

Переполнение стека вот ситуация:

1. Я пишу внутреннее приложение (на Java)

2. У меня есть API отдыха (предположим, что поиск некоторых элементов в базе данных)

3. API поиска вызывает несколько различных сервисов для достижения конечного результата.

Теперь, поскольку этот API используется для различных сервисов, эти интерфейсы сервисов уже определены, какие методы они предоставляют, какие параметры принимать и т. Д. И т. Д. Итак, теперь для выполнения этой задачи требуется много времени (вся задача поиска Собираюсь в разные службы).

Моя путаница заключается в том, что, если я изменю здесь некоторые вызовы службы или изменим Дизайн / данные (какая служба содержит данные), то я могу быстрее получить результаты. Мой алгоритм поиска в этом случае станет лучше, но Дизайн НЕ будет очень хорошим и чистым, как сейчас .

Итак, будем ли мы заниматься проектированием раньше или нам следует подумать о сложности алгоритма, который мы собираемся реализовать? Что важнее в приложениях с высокой нагрузкой. Хорошо ли идти на компромисс с частью дизайна приложения, чтобы быстрее получать результаты?

Каковы наилучшие практики для этих типов сценариев?

Answer 1

Короткий ответ: если ваша операция поиска слишком важна для вашей системы, вы можете принять решение о разработке ваших служб, учитывая эффективность API поиска. Но если есть другие операции, отличные от API поиска, и новый дизайн повлияет на производительность этих операций, то вам следует подумать перед перепроектированием.

Вы должны придерживаться некоторых ограничений для определения границ микроуслуг. Пожалуйста, прочитайте Границы микросервиса: пять характеристик, которыми следует руководствоваться при разработке .

Кроме того, вам следует разрабатывать службы не только для простоты операций, но и таким образом, чтобы в случае сбоя одной из служб вся система могла обслуживать ее и могла быть изменена, масштабирована и развернута независимо. Пожалуйста, отметьте Вертикальная нарезка на микроуслугах