@Gl_Proxy

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

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

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

5d39cf100a34f775117523.png

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

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

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

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

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

Спасибо.
  • Вопрос задан
  • 503 просмотра
Пригласить эксперта
Ответы на вопрос 7
Robur
@Robur
Знаю больше чем это необходимо
без описания задачи, ограничивающих условий, проблем которые перед вами стоят, того что вы понимаете под iis тонкого и толстого клиента и еще пачки деталей ваша схема и вопрос несколько бессмысленны.
Ответ на вопрос заданный в таком виде: да хрен его знает.
Ответ написан
Комментировать
samodum
@samodum
Какой вопрос - такой и ответ
Не хватает Redis и RabbitMQ
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Это нечто хаотичное и похожее на вентилятор, лежащий на столе.
Это соединение сущностей связями без понимания процесса из телефонного разговора/чата.

Просто ничего непонятно! Для чего пользователю с тонким клиентом путешествовать к толстому и обратно через 4-х кратную балансировку?!
Ответ написан
@cema93
WordPress разработчик
Я предлагаю такую схему:
клиент -> балансировщик приложений -> приложение(сколько угодно, в зависимости от необходимочти) -> балансировщик базы(при необходимости) -> база данных(инстансов базы тоже может быть много).

В реальной жизни использую:
клиент -> балансировщик приложений -> приложение(добавляю, убираю в зависимости от нагрузки) -> база банных.
Ответ написан
Комментировать
@grinat
Ну если домен один, то да, иначе не сделать. Если поддомены, то можно два балансировщики, типа как у амазона cloud front и elb
Ответ написан
Комментировать
Подскажите, в каком месте у вас php?
Ответ написан
Комментировать
@Alexandre
Тот кто придумал эту архитектуру имел ввиду микросервисы, но можно только догадываться.
Каждый микросервис имеет свою зону ответственности: (склад, оплата, бухучет, карта, апи)
Без реального описания задачи/проекта нельзя что-либо советовать
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы