История развития отношения к IT в России:
прошлое: программисты с другой планеты
настоящее: программистам очень хорошо платят
будущее: программистам очень хорошо платят потому, что они с другой планеты
Мне было проще — я с детства твердо знал, что буду программистом. А людям, которым нужны деньги и которые готовы кардинально изменить свою жизнь, надо идти в бизнес.
собственно, экспертиза… для этого и придумали виртуализацию и облака. Если сервер поломался и экспертизы не хватает — грохнуть и пересоздать, дело пяти минут.
вы не используете виртуализацию? Если на этих серверах крутятся только ваши приложения, которые не зависят от ОС… почему бы и не обновить? Я думаю, здесь скорее проблемы лицензионные или с каким-либо другим софтом от того же производителя типа мониторинга или аудита.
Докер — это один инструмент. Инструмент весьма простой в понимании и использовании. Не знаю, насколько сложнее тот набор технологий, который обеспечивает вам те же преимущества… Но он наверняка сложнее.
Для новых систем, имхо, альтернативы просто нет. Для существующих, которые уже настроены и работают… не знаю.
Давайте я попробую объяснить. Т.е. у вас ситуация, когда:
приложение — это одна папка (или один архив), и зависимости оно таскает с собой, включая JRE
все ваши приложения запускаются одинаково
все ваши приложения используют java process watcher (вроде tanuki wrapper), который умеет перезапускать упавший процесс java
все ваши приложения пишут логи одинаково (или путь для логов настраивается в конфиге)
stdout тоже перехватывается и пишется в лог (важно при крешах jvm)
ваши приложения хранятся в центральном репозитории как версионированные артифакты (нексус например)
Если чего-то из вышеперечисленного у вас нет, то докер может это дать. И дополнительно к этому:
Умное кеширование — образы докера строятся из слоев, т.е. при деплое новой версии приложения не нужно вместе с ним выкачивать лишних 100+ метров jvm. Это экономит место как в центральном репозитории, так и на хосте. Не говоря уже про скорость деплоя.
Безопасность — при взломе приложения хакер получит доступ только к контейнеру, а не к ФС хоста и других приложений
Управление запущенными контейнерами — вывести список запущенных приложений, остановить/запустить/перезапустить приложение.
Лимиты по памяти и cpu — докер позволяет админам выставлять их унифицированно для всех контейнеров, средствами ОС же придется городить что-то своё.
И дополнительно:
построенную инфраструктуру деплоймента можно использовать для не-java (или не ваших) приложений, докер унифицирует.
докер гарантирует, что запущенное приложение не использует никаких библиотек и утилит с хоста — это важно для воспроизводимости деплоя
если приложению понадобятся библиотеки и утилиты, которые сложно носить с собой (требуется конфигурация с правами рута, установка через apt или вообще перекомпиляция под систему) — докер решает эту проблему.
Только сейчас могу сформулировать, чем же мне не нравится async/await. Да тем, что он провоцирует программистов писать последовательный код! Асинхронный, но все операции выполняются по очереди, лишая смысла основную идею — параллельные программы.
С другой стороны, код на промисах "по умолчанию" полностью параллельный, и последовательность операций определяется неявно, через вычислительные зависимости, выраженные в then
пример: сложное приложение, делающее множество Ajax вызовов, на промисах будет по возможности делать эти вызовы параллельно. На async/await… для этого придется прикладывать усилия.
Необязательно из-за этого связываться с распределенными транзакциями. Есть варианты попроще:
Рефералы как-нибудь переживут, если из-за сбоя системы им недоначислят несколько посещений. Выбирая между временем разработки системы распределенных транзакций и небольшими потерями для нескольких клиентов раз в n месяцев… возможны варианты варианты.
Использовать persistent queue. В случае с реферралами не так нужна атомарность и не нужна возможность отката транзакции — так что можно вместе с обновлением аккаунта послать в очередь сообщение о том, что надо обновить рефералов.
А вообще с деньгами надо аккуратнее обращаться. Понимать немного бухгалтерию, двойную запись, проводки. И строить архитектуру по аналогии с тем, как работают с финансами в реальном мире. Все-таки жизнь — она распределенная, асинхронная и транзакций там не предусмотрено :-)
Микросервисы можно мигрировать по одному, микросервисы можно вообще не трогать, пока они работают. И даже когда придет необходимость дописывать микросервис, одновременно релизить всех его клиентов необязательно — можно задеплоить и старую, и новую версию.
В плане утилизации ресурсов на каждый модуль/микросервис — это забота админа и нагрузочного тестирования. Да, это требует соответствующего мониторинга.
Современное приложение должно стартовать 2-3 секунды, не больше. Иначе теряется flow при разработке. Поддерживает ли osgi параллельный старт разных модулей?
Мониторинг и агрегация мониторинга — это отдельная работа, которая в случае микросервисов делается долго, но один раз. Изменения конфига налету через JMX — имхо, плохая идея, т.к. теряется воспроизводимость релиза. В случае редеплоя мы можем эти настройки и не применить и получим неожидаемое поведение. Что касается точек управления — микросервис должен быть задеплоен один раз и просто работать, не требуя каких-либо подкручиваний. При правильной декомпозиции, объем конфигов перед релизами должен уменьшаться.
Да, монолит как один здоровенный кусок лапши, индустрия, к счастью, уже оставила позади. Пожалуй, в настоящее время монолитом можно назвать EE/OSGI приложения, которые не рискуют деплоить отдельными модулями, а только целиком.
Мне не пришлось поработать над большим (большой=нет ни одного человека, который знает детали функционирования всех модулей) монолитным проектом — будет интересно, если вы прокомментируете его недостатки, как я их вижу :-)
прибитые гвоздями технологии. Старая джава, старые версии библиотек, которые достаточно сложно заменить на более новые.
недостаточный уровень изоляции. Всё приложение работает на одном общем пуле ресурсов, и ошибка в одном модуле может уронить/испортить всё приложение
Большое время старта приложения
Большой объем конфигурации, сложное управление зависимостями между модулями
Основная идея микросервисов — это декомпозиция. То, что сервисом можно пользоваться, не изучая его исходники и зависимости.
И я совсем забыл про главное преимущество микросервисной архитектуры — устойчивость. Кластер из микросервисов может переживать аппаратные и программные сбои любого характера, более "мягко" реагирует на перегрузку, может терять функциональность частично, позволяет деплоймент без даунтайма, разнообразные разноцветные тестирования и т.п.
Банки любят такую архитектуру, т.к. она гарантирует отсутствие потерь данных и имеет солидное теоретическое обоснование. Но — очереди хранят данные, их нужно конфигурировать (в частности, роутинг между топиками), они могут переполняться, в них быть данные устаревшего формата/мусор(queue poisoning), их содержимое частенько сложно просмотреть, в системах на очередях требуются дополнительные усилия для того, чтобы связать запрос с ответом.
Да, это еще и неполный список! Но современная инфраструктура — это очень обширная тема, которую обсуждаяемая статья немножко затрагивает. Точно не формат комментариев.
Конечно не бесплатно, просто нужно выбирать решения, которые дают больше плюсов, чем минусов :-) По пунктам, местами гиперболированно:
пусть нам нужно отправлять письма. В случае библиотеки мы имеем конфигурацию e-mail сервера в 10 местах и много работы при смене e-mail провайдера, в случае микросервиса — конфигурация одна, код интеграции с email — один
service discovery. В рамках системы должен быть единый механизм поиска сервиса по имени и авторизации. В этом плане есть различие между внутенними сервисами (микросервисы) и внешними сервисами(почта/база/JMS/...) Т.к. первые контролируются вами, что означает унифицированный интерфейс, обратную совместимость, отсутствие хитрых параметров конфигурации и необходимости мигрировать на альтернативные реализации.
Тестирование — это отдельный большой разговор. Вкратце, моё мнение — микросервисы должны тестироваться изолированно на соответствие своему контракту API. Плюс какие-то базовые приемочные тесты всей системы. К сожалению, полные приемочные тесты часто становятся узким местом — из-за быстродействия, объема и ограниченного кол-ва людей, которые с ними работают.
Да, тот же Фаулер много про это пишет. Выделение микросервиса — это большая ответственность, т.к. нужно стремиться к тому, чтобы любая доработка системы затрагивала минимальное количество микросервисов. А это требует глубоких знаний системы, которые как правило появляются уже после её написания.
Кто-нибудь вообще использует docker networking в продакшне? Я честно не вижу в нем никакого смысла — порты можно настроить в конфиге приложения, service discovery лучше использовать собственный, а не доверять докеру.
Да, в принципе, всё совпадает с моим опытом использования микросервисов. Вот только статья совершенно не раскрывает вопрос "зачем тогда вообще с этим связываться".
Мой ответ — повторное использование уже сделанной работы. Рассматривайте микросервисы как библиотеки 2.0 со следующими преимуществами:
интегрировать микросервис проще, чем библиотеку. Никаких конфликтов, никаких зависимостей, никакой головной боли с конфигурированием. Есть сетевое API по известному протоколу.
библиотека позволяет повторно использовать алгоритмы. Микросервис позволяет повторно использовать еще и данные без многих недостатков интеграционной СУБД (см. Фаулера Integration database antipattern)
микросервисы, в отличие от библиотеки, позволяют скрыть свои зависимости от клиентов. Это позволяет писать как более гибкие, так и более устойчивые приложения. Например, микросервис отправки писем единственный хранит настройки email-сервера и может предпринимать дополнительные усилия по доставке писем.
как обобщение предыдущего пункта, микросервисы изолируют проблемы конфигурирования кода. Те же адреса SMTP, баз данных, JMS… Большой монолит частенько имеет весьма обширную конфигурацию.
гораздо богаче возможности по версионированию. Система может одновременно использовать несколько разных версий одного и того же микросервиса, если не все клиенты не готовы делать миграцию. Не разных версий API, а именно разных версий бинарника с несовместимыми API.
Про цену микросервисов хорошо написано выше. Да, нужно будет сильно вложиться в инфраструктуру. Да, проектирование интерфейсов микросервисов — это очень сложная и ответственная задача, так что лучше начать с монолита. Но я считаю, что в большинстве случаев оно того стоит.
История развития отношения к IT в России:
прошлое: программисты с другой планеты
настоящее: программистам очень хорошо платят
будущее: программистам очень хорошо платят потому, что они с другой планеты
Мне было проще — я с детства твердо знал, что буду программистом. А людям, которым нужны деньги и которые готовы кардинально изменить свою жизнь, надо идти в бизнес.
Я считал, что вы при таком уровне развития инфраструктуры деплоите приложения в кластер — т.е. поменять сервер на проде проблемой не является.
собственно, экспертиза… для этого и придумали виртуализацию и облака. Если сервер поломался и экспертизы не хватает — грохнуть и пересоздать, дело пяти минут.
А зря — есть проблемы у докера с storage driver-ами. Правда, всплывают они при деплойменте, а не при работе контейнера, потому и миримся с ними.
вы не используете виртуализацию? Если на этих серверах крутятся только ваши приложения, которые не зависят от ОС… почему бы и не обновить? Я думаю, здесь скорее проблемы лицензионные или с каким-либо другим софтом от того же производителя типа мониторинга или аудита.
Докер — это один инструмент. Инструмент весьма простой в понимании и использовании. Не знаю, насколько сложнее тот набор технологий, который обеспечивает вам те же преимущества… Но он наверняка сложнее.
Для новых систем, имхо, альтернативы просто нет. Для существующих, которые уже настроены и работают… не знаю.
Давайте я попробую объяснить. Т.е. у вас ситуация, когда:
Если чего-то из вышеперечисленного у вас нет, то докер может это дать. И дополнительно к этому:
И дополнительно:
Прежде всего докер — это когда ВСЁ деплоится одинаково. Естественно, чем больше приложений и чем больше зоопарк, тем больше выигрыш от докера.
т.е. get() асинхронный, но поток выполнения блокируется при вызове любого метода на результате?
это же лочит браузер?
Только сейчас могу сформулировать, чем же мне не нравится async/await. Да тем, что он провоцирует программистов писать последовательный код! Асинхронный, но все операции выполняются по очереди, лишая смысла основную идею — параллельные программы.
С другой стороны, код на промисах "по умолчанию" полностью параллельный, и последовательность операций определяется неявно, через вычислительные зависимости, выраженные в
thenпример: сложное приложение, делающее множество Ajax вызовов, на промисах будет по возможности делать эти вызовы параллельно. На async/await… для этого придется прикладывать усилия.
Необязательно из-за этого связываться с распределенными транзакциями. Есть варианты попроще:
А вообще с деньгами надо аккуратнее обращаться. Понимать немного бухгалтерию, двойную запись, проводки. И строить архитектуру по аналогии с тем, как работают с финансами в реальном мире. Все-таки жизнь — она распределенная, асинхронная и транзакций там не предусмотрено :-)
А в чем преимущество ZeroMQ перед обычным синхронным RPC в такой схеме? И как же гарантия доставки, особенно при падении брокера?
Микросервисы можно мигрировать по одному, микросервисы можно вообще не трогать, пока они работают. И даже когда придет необходимость дописывать микросервис, одновременно релизить всех его клиентов необязательно — можно задеплоить и старую, и новую версию.
В плане утилизации ресурсов на каждый модуль/микросервис — это забота админа и нагрузочного тестирования. Да, это требует соответствующего мониторинга.
Современное приложение должно стартовать 2-3 секунды, не больше. Иначе теряется flow при разработке. Поддерживает ли osgi параллельный старт разных модулей?
Мониторинг и агрегация мониторинга — это отдельная работа, которая в случае микросервисов делается долго, но один раз. Изменения конфига налету через JMX — имхо, плохая идея, т.к. теряется воспроизводимость релиза. В случае редеплоя мы можем эти настройки и не применить и получим неожидаемое поведение. Что касается точек управления — микросервис должен быть задеплоен один раз и просто работать, не требуя каких-либо подкручиваний. При правильной декомпозиции, объем конфигов перед релизами должен уменьшаться.
Да, монолит как один здоровенный кусок лапши, индустрия, к счастью, уже оставила позади. Пожалуй, в настоящее время монолитом можно назвать EE/OSGI приложения, которые не рискуют деплоить отдельными модулями, а только целиком.
Мне не пришлось поработать над большим (большой=нет ни одного человека, который знает детали функционирования всех модулей) монолитным проектом — будет интересно, если вы прокомментируете его недостатки, как я их вижу :-)
Основная идея микросервисов — это декомпозиция. То, что сервисом можно пользоваться, не изучая его исходники и зависимости.
И я совсем забыл про главное преимущество микросервисной архитектуры — устойчивость. Кластер из микросервисов может переживать аппаратные и программные сбои любого характера, более "мягко" реагирует на перегрузку, может терять функциональность частично, позволяет деплоймент без даунтайма, разнообразные разноцветные тестирования и т.п.
Банки любят такую архитектуру, т.к. она гарантирует отсутствие потерь данных и имеет солидное теоретическое обоснование. Но — очереди хранят данные, их нужно конфигурировать (в частности, роутинг между топиками), они могут переполняться, в них быть данные устаревшего формата/мусор(queue poisoning), их содержимое частенько сложно просмотреть, в системах на очередях требуются дополнительные усилия для того, чтобы связать запрос с ответом.
Да, это еще и неполный список! Но современная инфраструктура — это очень обширная тема, которую обсуждаяемая статья немножко затрагивает. Точно не формат комментариев.
Конечно не бесплатно, просто нужно выбирать решения, которые дают больше плюсов, чем минусов :-) По пунктам, местами гиперболированно:
Да, тот же Фаулер много про это пишет. Выделение микросервиса — это большая ответственность, т.к. нужно стремиться к тому, чтобы любая доработка системы затрагивала минимальное количество микросервисов. А это требует глубоких знаний системы, которые как правило появляются уже после её написания.
Кто-нибудь вообще использует docker networking в продакшне? Я честно не вижу в нем никакого смысла — порты можно настроить в конфиге приложения, service discovery лучше использовать собственный, а не доверять докеру.
Да, в принципе, всё совпадает с моим опытом использования микросервисов. Вот только статья совершенно не раскрывает вопрос "зачем тогда вообще с этим связываться".
Мой ответ — повторное использование уже сделанной работы. Рассматривайте микросервисы как библиотеки 2.0 со следующими преимуществами:
Про цену микросервисов хорошо написано выше. Да, нужно будет сильно вложиться в инфраструктуру. Да, проектирование интерфейсов микросервисов — это очень сложная и ответственная задача, так что лучше начать с монолита. Но я считаю, что в большинстве случаев оно того стоит.