Блог | От монолита к микросервисам
Если вы инженер / разработчик программного обеспечения, просто подумайте, что вы делаете, когда модуль в программном обеспечении должен быть изменен?
Ответ - изменение модуля .
Но десятилетия назад, когда модульность не стояла на переднем крае, все было немного иначе.
Были времена, когда программное обеспечение было тем, что мы называли монолитами. Отдельные зависимые приложения, которые должны были быть написаны на C или C # или других процедурных языках, которые всякий раз, когда им нужно было дать обновление, должны были быть полностью удалены и переустановлены на серверах. Это когда у нас были простои сервисов. Раньше эти приложения были очень быстрыми, но все же время простоя во время обновления было большой проблемой.
Следовательно, преобразователь пришел в виде балансировщиков нагрузки .
Вместо использования 1 сервера или 2 серверов было увеличено количество серверов. Это помогло двумя способами:
Не все время трафик службы был одинаковым. Таким образом, всякий раз, когда трафик был высоким, нагрузка между серверами балансировалась, а в периоды низкого трафика работал один сервер. Это снизило потери ресурсов, обеспечило резервное копирование и справилось с интенсивным трафиком в часы пик.
Затем, и главное преимущество заключалось в том, что теперь всякий раз, когда требовалось обновление программного обеспечения, вместо того, чтобы удалять приложение целиком, оно удалялось с половины серверов. Итак, предположим, что приложение работает на 4 серверах, во время низкого трафика 2 сервера будут отключены, а 2 будут работать. Затем приложение было обновлено на 2 неработающих серверах, а затем процесс повторился для 2 других серверов. Таким образом, у пользователя никогда не было простоев.
Но это также не решило проблему полностью, так как все приложение все еще заменялось, что все еще не было идеальной ситуацией.
Затем, с появлением модульности в практике программирования, Oracle представила J2EE или Java Platform Enterprise Edition. Это помогло, поскольку предоставило выбор услуг, баз данных, упрощенную архитектуру и интеграцию с существующими информационными системами. Это привело к монополии оракула в этой области, против которой возникла идея микросервисов.
То, что мы сегодня увидели в приложениях, - это использование микросервисов в лучшем виде.
Вместо изменения всего приложения теперь изменяется только модуль, который нужно обновить, а остальная часть приложения всегда запущена и работает. Это можно сделать, поскольку архитектура микросервисов делает приложения слабо связанными, организованными вокруг бизнес-возможностей и легко обслуживаемыми, предоставляя набор сервисов, обладающих этими свойствами, в архитектурном методе.
И, наконец, у нас есть наша нынешняя форма приложений, модульная, поддерживаемая и легко обновляемая, благодаря долгой истории монолитных приложений .