Для тех, кто никогда не является техническим специалистом, могу вкраце рассказать, как работают микросервисы. Да, их могут быть сотни и тысячи, и каждый может участвовать в формировании данных для приложения (Feed в Twitter например), но они не вызываются приложением напрямую. Все вызовы происходят на стороне сервера, и так как микросервисы запущены в одном датацентре (в худшем случае - в соседних датацентрах, соединенных магистральными каналами, которые заведомо быстрее, чем подключение клиента), и - самое главное - могут выполняться параллельно, ответ на запрос клиента все равно выдается в приемлемые сроки. Преимуществ у такой архитектуры для высоконагруженных сервисов несколько: - масштабируемость (можно точечно добавить реплики сервисов, нагрузка на которые выше) - отказоустойчивость (если один из микросервисов недоступен, приложение все равно будет работать, хоть и без части функций или медленнее; чем "меньше" сервис, тем менее заметен отказ) - простота (более модульный код легче поддерживать, тестировать, выпускать и т.д.) У приложения с 100 млн. пользователей, построенного как-то иначе, практически нет шансов работать как-то иначе. Кстати, Маск заявил, что планирует отключить 80% "ненужных" микросервисов, что вполне в духе его заявляний о необходимости экономить на инфраструктуре. К чему это приведет - будет очень интересно посмотреть.
Да тот же Яндекс так же и работает. Там на каждый запрос идут десятки запросов к сервисам за разными данными (результаты поиска, геоданные, реклама, всевозможные колдунщики, подсказки и т.п.). Если что-то отвалится или не ответит за отведённое время, то этого просто не будет на странице.
Для тех, кто никогда не является техническим специалистом, могу вкраце рассказать, как работают микросервисы. Да, их могут быть сотни и тысячи, и каждый может участвовать в формировании данных для приложения (Feed в Twitter например), но они не вызываются приложением напрямую. Все вызовы происходят на стороне сервера, и так как микросервисы запущены в одном датацентре (в худшем случае - в соседних датацентрах, соединенных магистральными каналами, которые заведомо быстрее, чем подключение клиента), и - самое главное - могут выполняться параллельно, ответ на запрос клиента все равно выдается в приемлемые сроки.
Преимуществ у такой архитектуры для высоконагруженных сервисов несколько:
- масштабируемость (можно точечно добавить реплики сервисов, нагрузка на которые выше)
- отказоустойчивость (если один из микросервисов недоступен, приложение все равно будет работать, хоть и без части функций или медленнее; чем "меньше" сервис, тем менее заметен отказ)
- простота (более модульный код легче поддерживать, тестировать, выпускать и т.д.)
У приложения с 100 млн. пользователей, построенного как-то иначе, практически нет шансов работать как-то иначе. Кстати, Маск заявил, что планирует отключить 80% "ненужных" микросервисов, что вполне в духе его заявляний о необходимости экономить на инфраструктуре. К чему это приведет - будет очень интересно посмотреть.
Да тот же Яндекс так же и работает. Там на каждый запрос идут десятки запросов к сервисам за разными данными (результаты поиска, геоданные, реклама, всевозможные колдунщики, подсказки и т.п.). Если что-то отвалится или не ответит за отведённое время, то этого просто не будет на странице.