Size: a a a

Архитектура ИТ-решений

2020 March 04

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Yury Batsyuro
У вас тут уже горизонтальное масштабирование есличо.
Это два разных коммуниста. Обработать 2000 звонков в секунду это одно, обработать звонок не более чем за 0.1 секунду - другое.
Если система обрабатывает за 0.2, она плохая, независимо от того, что её можно отмасштабировать на 50000 тпс, понимаете разницу?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Yury Batsyuro
stateless-микросервисы по мне так это полубеременность. Для stateless есть serverless-архитектура с её лямдами. Но реально это перекладывание нагрузки с сервиса на БД, будь то Redis, Mongo, MSSQL. Не важно, всё равно у процесса стейт есть, и его надо где-то держать. Моя позиция, что выталкивание стейта в Redis не даёт права называть архитектуру stateless. Ну а прелесть сервиса (микро, милли, нано, гига, любого) как раз в том, что он позволяет содержать кэш в оперативке и работать этому кэшу со скоростью оперативки. Конечность этого кэша и позволяет долго жить на одних и тех же ресурсах, не прибегая к горизонтальному масштабированию.
А, ну это да. Просто есть разные сервисы под разные задачи. В некоторых локальный кэш и вполне себе stateless.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Горизонтальное масштабирование решает проблемы количества, а не качества.
Это та самая тупая ошибка про "9 женщин не родят за месяц"
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Это два разных коммуниста. Обработать 2000 звонков в секунду это одно, обработать звонок не более чем за 0.1 секунду - другое.
Если система обрабатывает за 0.2, она плохая, независимо от того, что её можно отмасштабировать на 50000 тпс, понимаете разницу?
Это определяется не тем, применяете вы микросервисы, или нет, а тем, как вы их сцепляете между собой. Это не обязательно делается через шину. Это может быть HTTP, TCP, UDP...
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Yury Batsyuro
Это определяется не тем, применяете вы микросервисы, или нет, а тем, как вы их сцепляете между собой. Это не обязательно делается через шину. Это может быть HTTP, TCP, UDP...
Сеть всегда медленнее памяти. Микросервисы это сеть.

Перерисовать граф взаимодействия, как вы предлагаете, это мёртвому припарки в случае, если требуемое время работы сравнимо со временем обращения к сокету.

Мы просто обсуждаем разные классы систем.

Но да, именно перерисовку графа я и обозначил изначально как "асинхронный конвейер" в качестве второго популярного направления оптимизации
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Горизонтальное масштабирование решает проблемы количества, а не качества.
Это та самая тупая ошибка про "9 женщин не родят за месяц"
Опять же, выделить в задаче подзадачу реального времени и реализовать её с требованием к оптимизации — микросервисы в большинстве своём именно про это, когда вы весь технологический стек определяете из потребности конкретного кейса, вплоть до хардварной реализации.
источник

S

Stanislav in Архитектура ИТ-решений
Alexey Pryanishnikov
Сеть всегда медленнее памяти. Микросервисы это сеть.

Перерисовать граф взаимодействия, как вы предлагаете, это мёртвому припарки в случае, если требуемое время работы сравнимо со временем обращения к сокету.

Мы просто обсуждаем разные классы систем.

Но да, именно перерисовку графа я и обозначил изначально как "асинхронный конвейер" в качестве второго популярного направления оптимизации
микросервисы это не только сеть
обмен сообщениями может быть и через память
hft тому пример
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Почему архитектура — это абстракция, а микросервис — это обязательно конкретная программа? Это и устройство, и человек на конвейере.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Stanislav
микросервисы это не только сеть
обмен сообщениями может быть и через память
hft тому пример
Ну да, в HFT шину выкидывают первой :)
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Stanislav
микросервисы это не только сеть
обмен сообщениями может быть и через память
hft тому пример
Да, я встречал реализации такого рода, давно, еще когда слово "микросервис" не было популярно в нашем буллшит-бинго )
Но сейчас микросервис это однозначно минимум отдельный процесс ОС, иначе мы скатимся к тому, что любой ООП код это микросервисная архитектура, что уже совсем будет безголовым сектантством
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Да, я встречал реализации такого рода, давно, еще когда слово "микросервис" не было популярно в нашем буллшит-бинго )
Но сейчас микросервис это однозначно минимум отдельный процесс ОС, иначе мы скатимся к тому, что любой ООП код это микросервисная архитектура, что уже совсем будет безголовым сектантством
Отдельный процесс, но процессы можно вязать не только по сети, но и по пайпам, шаред мемори и прочим stdio.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Шареную между процессами память ещё вспомните )
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Шареную между процессами память ещё вспомните )
А её кто-то забывал?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
А, вспомнили )
источник

S

Stanislav in Архитектура ИТ-решений
Alexey Pryanishnikov
Шареную между процессами память ещё вспомните )
конечно )
источник

S

Stanislav in Архитектура ИТ-решений
вот классный доклад
https://www.youtube.com/watch?v=QV-ue1YMdds
источник

S

Stanislav in Архитектура ИТ-решений
все живо до сих пор )
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
А, вспомнили )
А у вас когда MSSQL на том же компе стоит, вы с ним как, по-вашему, коммуницируете?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
свят-свят, какой ещё к чёрту ms)
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
свят-свят, какой ещё к чёрту ms)
ТотСамый
источник