Комментарии 8
Эххх, про очереди забыли написать. Зато есть повод написать часть вторую)
Простите, а что ,кроме экстремумов в виде монолита одним экзешником и микросервисов, ничего нет? То есть обычный тонкий клиент-сервер вариант с "рациональной масштабируемостью" плюс " простота E2E тестирования, простота развертки", принципиально не может быть правильным решением?
Я ожидал почитать полезный материал, но уже на первых абзацах потерял желание продолжать, так как путаница в деталях - хороший признак поверхностных знаний.
монолит – это иерархическая архитектура, т.е. каждый слой приложения отвечает за свою часть функционала, например: работа с базой, логирование, интерфейс
Тут вы явно хотели указать на n-tier, но вот только это - совсем не признак монолита (даже наоборот), да и приводить логирование как пример слоя в вертикали - крайне спорный аспект, ведь культурные обычаи предков нас учат писать логи на всех уровнях. Я так понимаю вам повезло не разбирать в сортах монолитов. Своё название они берут как раз от имплементации без всякого разделения.
Файловый обмен
Недостатки:
Скорость
Ненадежность
Отсутствие возможности получить информацию о валидности файла со стороны вызывающей системы
Мне всегда казалось что, чтоб быстро и надёжно передать много данных, то используют файлы... Может быть использования других протоколов с дополнительной разметкой уменьшает количество исходных данных? Или если добавить больше итерации и делить данные на кусочки, то пойдёт быстрее? Ну а то, что можно проверить целостность хешем или подписью - не должно быть открытием. Я ни в коем случае не призываю обмениваться файлами, как протоком связи между сервисами, но у каждого инструмента свои цели. Хотите сделать импорт/экспорт большого количества данных, файл - отличный вариант, особенно если нет сети. Я уж не говорю о медиаконтенте.
Короче, не осилил я статью, так что даже оценивать и не буду.
Спасибо за конструктивную критику! На самом деле данная статья скорее предназначена для аналитиков, чтобы структурировать понимание о том, а что и как, собственно, можно интегрировать, поэтому на какие-то инсайты в плане архитектуры она не претендует. Очень жаль, что Вы потеряли интерес к статье на первых строках, т.к интересно было бы посмотреть на данный вопрос с Вашей точки зрения, и в дальнейшем, в продолжении статьи принять ее во внимание)
Спасибо за прекрасный комментарий, отличное резюме всей этой статьи
Спасибо статью. В целом для общего понимания картины очень подходит.
Для общего понимания, для аналитиков - толковая статья)
а на душнил-разработчиков в комментариях не обращайте внимания - их итак в нашей жизни хватает)
Архитектура приложений и интеграции: гайд по основным понятиям простыми словами