Городить микросервисы имеет смысл в условиях неразберихи и переизбытка разработчиков. Таким образом можно явно распределить ответственность между командами и улучшить диагностируемость системы (мониторинг компонентов, хелсчеки).
Крайне важным при этом становится соблюдение контрактов и поддержка обратной совместимости (с версированием интерфейсов).
Процесс миграции и разделения монолита может занять годы.
Что касается масштабирования, хороший монолит не слишком уступает тут сервис-ориентированной архитектуре. Как правило все упирается в централизованные хранилища и диспетчеры.
Действительно полезное свойство — параллельные композиционные релизы, когда из-за ошибки в одной задаче, не приходится перестраивать весь реализ.
Не стоит рассматривать СОА как способ оптимизации производительности, межкомпонентные задержки и блокировки скорее всего ухудшат общую скорость.
По опыту живого проекта, общий код выделяется в библиотеки которые потом доставляются менеджером зависимостей (например composer для php, или glide для golang). Зависимости актуализируются согласно семантическому версированию.
Что касается контрактов, для REST есть спецификация описания интерфейсов swagger, из неё можно сгенерировать клиентскую библиотеку (методы и структуры) и внедрить её как зависимость.
В общем случае (rabbitmq, protobuf) протокол взаимодействия (методы и структуры) должен быть описан в клиентской библиотеке.
Вывод через USB DisplayLink обладает спецификой из-за ограниченной пропускной способности, на кино или видео игры ее конечно не хватает. Но окно IDE или консоль с логами работают вполне.
Есть проблема с одноименными населенными пунктами, так например адрес 77.106.95.186 принадлежит российскому Северску в Томской области, но определяется как украинский из Донецкой области.
Четвертое решение уже сейчас не будет работать в таком виде на Maria DB (https://mariadb.com/kb/en/derived-table-merge-optimization/), чтобы работало достаточно добавить LIMIT с заведомо большим числом в derived выборку
SELECT article, dealer, price
FROM (
SELECT article, dealer, price
FROM shop
ORDER BY price desc
LIMIT 1000000000000
)
as t
GROUP BY article
ORDER BY NULL;
В качестве окна можно использовать лог веб-сервера, это значительно уменьшит расходы на подсчет т.к. позволяет вообще не обращаться к бд при кэшировании страницы. Что касается таблицы в памяти, можно использовать буфферизированную запись лога (такая возможность есть например в nginx).
Для многих пользователей, которые не перезагружают компьютеры без крайней необходимости, а хранят их в сонном состоянии вместе с запущенными программами, SSD не особо актуален, гораздо полезнее иметь достаточный объем кэширующей оперативной памяти.
Так например в официальных рекомендациях по улучшению производительности Adobe Photoshop применение SSD отнесено к последним мерам.
Безусловно изоляция слоев приложения помогает избежать многих ошибок, но эта же изоляция может затруднять решение задачи.
Например, у нас есть замечательная библиотека для работы с БД, она умеет автоматически собирать синтаксически правильные запросы, но при этом потребялет в качестве оплаты за свои услуги дополнительные ресурсы. Внезапно перед нами встает задача, которая загоняет библиотеку в мемори лимит. Что делать?
Если решение требует нетривиального использования БД, с конструированием сложных вложенных запросов основанных на критериях определяемых в разных местах кода, что делать?
Ручная сборка запросов — это как ассемблерные вставки в коде драйвера устройства, неудобно, опасно, но иначе не взлетит :(
Отдельной головной болью может стать обеспечение транзакционности в рамках всего приложения, а также трассировка кто кого куда вызвал при дебаге.
Городить микросервисы имеет смысл в условиях неразберихи и переизбытка разработчиков. Таким образом можно явно распределить ответственность между командами и улучшить диагностируемость системы (мониторинг компонентов, хелсчеки).
Крайне важным при этом становится соблюдение контрактов и поддержка обратной совместимости (с версированием интерфейсов).
Процесс миграции и разделения монолита может занять годы.
Что касается масштабирования, хороший монолит не слишком уступает тут сервис-ориентированной архитектуре. Как правило все упирается в централизованные хранилища и диспетчеры.
Действительно полезное свойство — параллельные композиционные релизы, когда из-за ошибки в одной задаче, не приходится перестраивать весь реализ.
Не стоит рассматривать СОА как способ оптимизации производительности, межкомпонентные задержки и блокировки скорее всего ухудшат общую скорость.
По опыту живого проекта, общий код выделяется в библиотеки которые потом доставляются менеджером зависимостей (например composer для php, или glide для golang). Зависимости актуализируются согласно семантическому версированию.
Что касается контрактов, для REST есть спецификация описания интерфейсов swagger, из неё можно сгенерировать клиентскую библиотеку (методы и структуры) и внедрить её как зависимость.
В общем случае (rabbitmq, protobuf) протокол взаимодействия (методы и структуры) должен быть описан в клиентской библиотеке.
SELECT article, dealer, price FROM ( SELECT article, dealer, price FROM shop ORDER BY price desc LIMIT 1000000000000 ) as t GROUP BY article ORDER BY NULL;Так например в официальных рекомендациях по улучшению производительности Adobe Photoshop применение SSD отнесено к последним мерам.
Безусловно изоляция слоев приложения помогает избежать многих ошибок, но эта же изоляция может затруднять решение задачи.
Например, у нас есть замечательная библиотека для работы с БД, она умеет автоматически собирать синтаксически правильные запросы, но при этом потребялет в качестве оплаты за свои услуги дополнительные ресурсы. Внезапно перед нами встает задача, которая загоняет библиотеку в мемори лимит. Что делать?
Если решение требует нетривиального использования БД, с конструированием сложных вложенных запросов основанных на критериях определяемых в разных местах кода, что делать?
Ручная сборка запросов — это как ассемблерные вставки в коде драйвера устройства, неудобно, опасно, но иначе не взлетит :(