{"id":13842,"url":"\/distributions\/13842\/click?bit=1&hash=4092fa5bbad74653204c7561dcd5fe57486fea481929ecdbf7bbf16b31cd3087","title":"\u041a\u0430\u0436\u0434\u044b\u0439 \u043f\u0440\u043e\u0434\u0430\u0432\u0435\u0446 \u043d\u0430 \u00ab\u041c\u0430\u0440\u043a\u0435\u0442\u0435\u00bb \u0445\u043e\u0442\u044c \u0440\u0430\u0437 \u043e\u0431 \u044d\u0442\u043e\u043c \u0434\u0443\u043c\u0430\u043b ","buttonText":"\u041e \u0447\u0451\u043c?","imageUuid":"a6164600-1125-55db-8c60-f927d5e7e7d4","isPaidAndBannersEnabled":false}

Какой язык выбрать для создания своих микросервисов?!

В мире IT существует бесконечное множество языков программирования. У каждого из них есть свои плюсы. Одни языки программирования накопили огромную кодовую базу, которая позволяет решить абсолютно любую задачу. Другие обладают уникальными характеристиками — быстродействие, нетребовательность к ресурсам, совместимость со множеством операционных систем и аппаратных платформ.

Исторически в нашей компании накоплен большой опыт разработки на Java. И, опираясь на него, для создания экосистемы цифровой трансформации Digital Q мы сделали выбор в пользу Spring Boot. Продукты, создаваемые на этой базе, имеют большое количество преимуществ:

  • легкость разработки
  • гибкость в используемом окружении
  • множество поддерживаемых технологий и т. д.

Но при всех преимуществах, были и недостатки:

  • повышенное потребление памяти контейнером
  • время старта приложения - десятки секунд

При условии, что в решении могут быть тысячи микросервисов, сильно повышаются требования к аппаратной составляющей проекта.

В качестве эксперимента, для снижения этих требований мы сделали альтернативную версию одного из наших сервисов на языке Golang. Мы постарались воспроизвести основной функционал, поддерживаемый в исходном сервисе: rest api, работу с Kafka, логирование в ELK, заложили возможность работы с разными СУБД и т. д.

И сравнили полученный сервис c исходным в одинаковом окружении, при выполнении одинаковых задач:

· время старта Go – менее 1 секунды против 70 для Spring Boot (сервер был слабенький, но на наглядность это не повлияло);

· оперативная память, используемая в работе контейнера, – 15 Мб против 815 Мб;

· быстродействие REST API и время обработки сообщения Kafka оказалось сравнимым: где-то GO чуть быстрее, где-то Java.

Полученный результат нас очень заинтересовал. Было решено двигаться в сторону внедрения Golang в производство, поддерживать его во всех производственных процессах. На текущий момент с его помощью мы реализуем различные вспомогательные сервисы, необходимые для работы продуктов.

Spring Boot – общепризнанный фреймворк на основе Java с открытым исходным кодом.

Go, или Golang, – компилируемый многопоточный язык программирования с открытым исходным кодом.

0
4 комментария
Дмитрий Кузнецов
Ответить
Развернуть ветку
Сергей Ольков
Автор

Так тоже пробовали, с GraalVM ситуация немного другая. С точки зрения характеристик - приложение стартует моментально, потребляет памяти на треть меньше от оригинала. Но время сборки проекта растет в 10 раз. Далеко не каждый сервис можно безболезненно перевести - самые проблемы возникают. Ключевое - в момент разработки для отладки удобней использовать обычную jdk, а на стенде же работает graalvm. Что потенциально может привести к неповторимым ошибкам.
Для себя решили - что graalVM можно будет использовать точечно, для конкретных сервисов, которые нужно будет масштабировать в десятки экземпляров.

Ответить
Развернуть ветку
Дмитрий Кузнецов

О, спасибо за такой подробный комментарий.

для отладки удобней использовать обычную jdk, а на стенде же работает graalvm

Там вроде анонсировали, что бОльшую часть коммьюнити версии скоро включат в OpenJDK и релизный цикл синхронизируют. Так что стоит приглядывать за проектом.

Ответить
Развернуть ветку
Сергей Ольков
Автор

От graalvm не отвернулись, просто пока поставили на паузу. Возможно через какое то время повторно попробуем.

Ответить
Развернуть ветку
Читать все 4 комментария
null