Это правильная веб архитектура для сервиса?

Question

[Gl_Proxy]

Ребят, подскажите, пожалуйста

Примерно нарисовал архитектуру текущего веб приложения для документоборота



1. От клиента запрос на балансировщик
2. От балансировщика на web iis "тонкого клиента"
3.4. Затем через балансировщик web iis "толстого клиента"
5. От него идет к базе
6.7.8.9.10 Весь путь обратно

Те, кто ее делают, уверяют, что это совершенно нормальная схема

Я не занимаюсь веб архитектурой, но по моему опыты в IT, это "странная" реализация

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

Или, возможно, это совершенно нормально.

Спасибо.

Comments

[Rustam Bainazarov]

Хочу сказать, что нарисованная в Paint логическая схема сделала мой день.

Не смогу подсказать по существу, к сожалению.

[Gl_Proxy]

Рустам Байназаров,

Другой схемы, у меня для вас нет, как говорится)

Paint это творческий процесс, не то что эта бездушная проектировка

[Maksim B]

Напишите пожалуйста что конкретно вас тут смущает в текущий реализации и что поддразумивается под тонким и толстым клиентом.

[Иван Шумов]

Максим Б, вот подпишусь

[chupasaurus]

Вношу нормальную терминологию в тред.
Вместо "тонкого клиента" - фронтенд-приложение (может быть ASP.NET, а может и обычные html+js, IIS не поперхнётся).
Вместо "толстого клиента" - бэкенд.
Gl_Proxy IIS и web в одном словосочетании - почти что тавтология.

Answer 1

[Robur]

без описания задачи, ограничивающих условий, проблем которые перед вами стоят, того что вы понимаете под iis тонкого и толстого клиента и еще пачки деталей ваша схема и вопрос несколько бессмысленны.
Ответ на вопрос заданный в таком виде: да хрен его знает.

Answer 2

[Developer]

Не хватает Redis и RabbitMQ

Answer 3

[xmoonlight]

Это нечто хаотичное и похожее на вентилятор, лежащий на столе.
Это соединение сущностей связями без понимания процесса из телефонного разговора/чата.

Просто ничего непонятно! Для чего пользователю с тонким клиентом путешествовать к толстому и обратно через 4-х кратную балансировку?!

Comments

[Gl_Proxy]

Подробности сказал все - какие знаю.

Это схема прохождения траффика.

Если вопрос сократить, то это нормально для веб архтиектуры, что запросы перебрасываются через балансировщик на сервера для другого типа клиентов? А затем уже к базе и идут обратно.

Я понимаю, что это не нормально, вопрос, как им объяснить, если они утверждают, что это нормально.

[xmoonlight]

Gl_Proxy, Скажите, что балансировщик должен использоваться однократно вне зависимости от типа клиента от запроса клиента к целевой системе. (или мы всё не так понимаем....)

Answer 4

[Сёмка Гавриленко]

Я предлагаю такую схему:
клиент -> балансировщик приложений -> приложение(сколько угодно, в зависимости от необходимочти) -> балансировщик базы(при необходимости) -> база данных(инстансов базы тоже может быть много).

В реальной жизни использую:
клиент -> балансировщик приложений -> приложение(добавляю, убираю в зависимости от нагрузки) -> база банных.

Answer 5

[grinat]

Ну если домен один, то да, иначе не сделать. Если поддомены, то можно два балансировщики, типа как у амазона cloud front и elb

Answer 6

[Станислав Бодро́в]

Подскажите, в каком месте у вас php?

Answer 7

[Alexandre]

Тот кто придумал эту архитектуру имел ввиду микросервисы, но можно только догадываться.
Каждый микросервис имеет свою зону ответственности: (склад, оплата, бухучет, карта, апи)
Без реального описания задачи/проекта нельзя что-либо советовать