Elena Grahovac len

Меня зовут Эдгар (ZergsLaw), я работаю в компании, которая занимается  финтех-разработкой для b2b и b2c. Когда только устроился в компанию, то попал в команду большого финтех-проекта и получил «в нагрузку» небольшой микросервис. Мне поручили его изучить и подготовить план рефакторинга, чтобы в дальнейшем выделить отдельную команду поддержки для сервиса.



«Мой» сервис — это proxy между определенными модулями большого проекта. На первый взгляд изучить его можно за один вечер и браться за дела поважнее. Но приступив к работе я понял, что ошибся. Сервис был написан полгода назад за пару недель с задачей протестировать MVP. Всё это время он отказывался работать: терял события и данные, или переписывал их. Проект перекидывали из команды в команду, потому что никто не хотел им заниматься, даже его создатели. Теперь стало ясно почему под него искали отдельного программиста.

«Мой» сервис — это пример плохой архитектуры и изначально неправильного проектирования. Все мы понимаем, что так делать нельзя. Но почему нельзя, к каким последствиям это приводит и как попытаться все исправить, я и расскажу.

Мы обещали 5-6 причин перейти на Go, так и получилось! На GolangConf — конференции полностью посвященной Go — 7 октября будет 5 докладов с пометкой «Переход на Go» для тех, кто только собирается или начинает использовать этот язык в своих проектах.

Но это только начало. С первого раза нам удалось собрать очень сильную и разнообразную программу, отвечающую потребностям трех категорий участников: профессиональных Go-разработчиков; тех, кто только переходит на Go; инженеров-инфраструктуры и пользователей инструментов, написанных на Go.



В программе конференции 21 доклад, сессия блиц-докладов и митапы. В любое время гости конференции смогут выбрать из 3–4 разных тем и найти для себя что-нибудь интересное. Думаю даже, что более актуальной будет проблема выбора и невозможность разорваться между потоками (хорошо, что потом все будет на видео). Одновременно в разных залах будут обсуждаться темы, актуальные самым разным специалистам.

Так повелось, что разработчики, еще только начинающие знакомиться с Go, часто сталкиваются с проблемой выбора рабочей директории для Go-проектов. Вот и в чате конференции GolangConf тоже задавался этот вопрос. Новые гоферы часто пугают друг друга словами GOPATH и GOROOT. Однако, в руководствах по быстрому старту с текущей версией Go (1.13) упоминания эти двух «страшных» слов вообще нет.

От автора. Уже пятый декабрь подряд в блоге GopherAcademy самые разные представители Go-сообщества делятся своим опытом в рамках специальной предрождественской серии постов. В этом году я тоже решила предложить свою статью, написанную по мотивам первой части нашего с Игорем Должиковым мастер-класса по микросервисам. На Хабре небольшую часть этого руководства мы уже рассматривали ранее.

Если вы когда-либо пробовали Go, вы знаете, что писать сервисы на Go очень просто. Нам нужно буквально несколько строк кода для того, чтобы можно было запустить http-сервис. Но что нужно добавить, если мы хотим приготовить такое приложение в продакшн? Давайте рассмотрим это на примере сервиса, который готов к запуску в Kubernetes.

Все шаги из этой статьи можно найти в одном теге, или вы можете следить за примерами статьи коммит за коммитом.

В июне на конференции РИТ++ мы с коллегой Игорем Должиковым делились опытом автоматизации процесса разработки сервисов на Go — от первого коммита и до релиза в продакшн-окружение Kubernetes (да-да, видео начинается с 07:16, и нам тоже это не нравится). С момента публикации мастер-класса время от времени я получаю вопросы по тем или иным темам, затронутым в нем. Пожалуй, самые горячие вопросы достойны отдельного рассмотрения, и сегодня я хотела бы поговорить о процессе сборки приложения. Затрагиваемые темы актуальны не только при подготовке сервисов, но и вообще для любых приложений, написанных на Go.

Всё, что описано в этой статье, актуально для текущей версии Go — 1.9.