Personal experience of .IO team of deploying microservices architecture into their products

1. Размышления о
микросервисах
основано на опыте .IO

2. В тексте будет использована следующая аббревиатура:
● МС - микросервис

3. Базы данных - MySQL
Каждый МС - использует связку MySQL + Vertica, где в MySQL лежат рабочие
предаггрегированные данные
В итоге в MySQL лежит не много данных (десятки миллионов), так как данных
не много, то MySQL с ними быстро работает и проблем не возникает
В основе всех таблиц MySQL лежит InnoDB движок
Часть MySQL баз заточена чисто под запись, часть - чисто под чтение, тем
самым достигается максимальная производительность узлов, в зависимости от
назначения узла

4. Базы данных - MySQL
Для backup используют Percona XtraBackup (online non-blocking, tightly
compressed, highly secured backups)
На каждой ноде свое backup-расписание в зависимости от важности данных и
роли ноды
Или полностью или почти полностью отказались от JOIN таблиц в MySQL
Каждый день на Amazon отгружают порядка 70 Gb бэкапов хорошо сжатых raw
data

5. Базы данных - Vertica
Условно каждая Vertica база разбита на 2-е части: delta-таблицы, в которые пишется
raw data и рабочие таблицы с аггрегированными данными
Аггрегация происходит через процессоры данных (отдельные МС) с помощью
предаггрегации в MySQL

6. Культура разработки МС
У каждого, даже самого мелкого МС, есть свой dev-сервер
Разработка ведется в облаке, не используется localhost как временное
окружение для разработчиков ради экономии времени на дополнительный
тестинг + развертывание проекта ((300 дней в году * 15 минут в день) / 9 часов
за рабочий день ~ 8.3 - экономится за год более 8 рабочих дней каждого
разработчика)
Перед разработчиками не стоит задача не допустить ошибку (ошибки
допускают все и всегда), основная задача - построить максимально
отказоустойчивую архитектуру, когда при обнаружени проблемы она бы
устранялась за несколько минут

7. Культура разработки МС
Новые технологии внедряются только после длительных рисерчей и, всегда, на
небольшой процент малоактивных клиентов
Обязательно должен быть удобный трекинг ошибок для каждого микросервиса,
pupergrep или типо этого
У каждого МС может быть несколько разработчиков, но финально
отвественный за его работу - только 1-н человек
Разработчики сами админят свои МС, есть только 1% случаев когда наличие сис.
админов в команде давало бы существенное преимущество

8. Культура разработки МС
Разработчики сами решают что включать в МС, а что нет. Основная идея
заключается в том, что лучше предварительно включить более широкий
функционал и, при необходимости, вынести его со временем в отдельный МС
Каждый web-клиент - это тоже отдельный микросервис
99% МС должны работать асинхронно (или частично асинхронно) за редким
исключением (как пример исключения - сервисы авторизации, геолокации -
ответ нужен сразу)
МС должны быть максимально лояльным к работе внешних сервисов - если
какой-то МС выпадает из цепочки система не должна падать

9. Преимущества МС
МС - масштабируемы, монолитные приложения - нет
Масштабируемость противоречит производительности, но дает возможность
расти приложению
При использовании МС - нельзя убить всю систему, только отдельныюу ее
часть
Все приватные МС можно полностью закрыть фаерволом и завайтлистить
только те ноды, которые работают в рамках системы - таким образом бОльшая
часть системы защищена от внешнего воздействия

10. Преимущества МС
Монолит - большой кусок говна, когда каках много, в них очень тяжело
разбираться и вносить в них правки. Когда приложение разбито на МС - имеем
много мелких каках, которые не тесно связаны друг с другом. Меняя что-то в
монолите есть большой шанс что это изменения поломают какой-то другой
функционал (можно даже не знать что он есть), а так как каждый МС
изолирован в разработке и своих ресурсах, то, внося в него изменения, поломать
можно только его.
МС - может быть сколь-угодно мал, вплоть до 1-го файла в несколько строк,
главное что бы у него была четкая цель и он ее хорошо выполнял

11. Особенности архитектуры .IO
В .IO не используют текущие популярные системы очередей (gearman,
rabbitmq, zeromq, etc). Основная мотивация - исключить потери данных. Даже
те системы, которые умеют делать Durable очереди, например, из-за перебоев
работы сети могут фейлить обработку некоторые сообщений. Архитектурное
решение - файловые очереди - после аггрегации некоторых данных они
записываются в файлик с уникальным именем и передаются на обработку через
nginx на нужную ноду, если передача зафейлилась, файл ложится в папку .
/failed и, при следующей отгрузке, пытается отправить его еще раз. Точно так
же и с ответом от ноды. Таким образом фалик с даными лил передан или нет,
или обработан или нет - все данные целостны.