Что нащет микросервисов, ммм?
Mar. 24th, 2018 04:44 pm
Всё изменилось, когда я сменил работу. Попал в ситуацию, где соотношение сервисов к количеству разработчиков было 3-4 к 1. И, конечно, всё это называлось «сервисной» архитектурой, а при продумывание того, как нам делать новую функциональность люди ориентировались на непонятные мне каноны микросервисов и «облачную архитектуру».
Что вообще я знал про микросервисы из статеек в интернете:
- Всегда есть противопоставление некоему «монолиту»
- Есть понимание, что «монолит» - енто некий сервис с API, который крутит внутри себя кучу фоновых процессов
- Выделяем фоновые процессы в самостоятельные сущности, получаем микросервисы
- Разбиваем большое сложное API на логически связанные разделы, уносим в самостоятельные сущности, и вуаля микросервисы
Что я вообще понимал под термином «микросервис»:
- Технически это сайт или служба/демон, который имеет простой и понятный API
- Инкапсулирует в себе некую атомарную часть «бизнес-логики» (кавычки потому, что адепты микросервисов чому-то редко употребляют ентот термин)
Какие я видел плюсы подобного подхода:
- Настоящее разграничение и изолированность (грабли в сервисе А, не долетают до всех от него зависимых, технически невозможно доступиться до условного синглтона)
- Простота архитектуры и реализации (чем проще задача, тем меньше надо инфраструктурных наворотов)
- Масштабируемость по людям (раз уж мы все сегментировали даже технически, то можно нагонять ораву)
- Разнообразность технологий (если потребителям видно только API, то похуй как оно врутри сделано)
- Простота тестирования (меньше логики и внутренних инфраструктурных сложностей – проще писать тесты)
Что на практике:
- Пересечение логических зон ответственности нескольких микросервисов (самое страшное, имхо, тому что не понять, куда впиливать фичу)
- Сложный и плохо формализуемый граф зависимостей (если в условном монолите, написанном на популярном языке, можно легко посмотреть граф, кто от кого зависит и пробежаться по конкретным примерам использования, то в миросервисах енто все крайне затруднено)
- Дисбаланас функционалисти (один сервисы делаю дохуя, другие реально «микро»)
- Дисбаланс нагрузки (следствие предыдущих 2 пунктов, то есть от одного сервиса зависят 100500 других и, значит, его будут нагружать)
- Невероятная сложность тестирования (из-за того, что зависимости стали «физическими», тк реально разные приложения работают, то находить несостыковки можно только интеграционными тестами, а они сами по себе в 1000 раз более долгие чем юнит-тесты, а «моки» на таком уровне – енто сложнее чем вся фича)
- Замедление разработки (если фича требует поддержки от 2 или более сервисов, то надо общаться с людьми, а потом синхронизировать процесс деплоя и тестирования)
- К любой вообще логике добавляется A/B тестирование (как следствие предыдущего пункта, тому что при количестве сервисов более определенного порога, просто невозможно поднимать согласованное окружение на одной машине, а тестироваться полными окружениями в облаке ради 2-3 сервисов невероятно дорого).
- Усложнение формальных процессов, тому что даже автотесты через A/B предполагают хотя бы наличие веток в разных репозитариях с единым названием (или любой подобный механизм согласования)
- Невероятно сложные релизы, тому что заказчик хочет в проде «вон те 2 фичи», которые невероятно сложно отодрать от общего потока разработки
Резюмируя. Сам по себе переход на микросервисную архитектуру не решает ни одну проблему вообще. Максимум, что он дает – это много боли, через которую, можно дойти до достаточно удобной инфраструктуры управления всем ентим зверинцем. Те же самые выстраданные A/B-тесты -- большой профит. Да и то, это реально только в условиях ГОМОГЕННОЙ инфраструктуры, когда для одних и тех же вещей, используется одна и та же технология и общие библиотеки для них. В противном случае, можно весело смотреть, как при появлении нового микросервиса пишется клиент для него на первом ЯП, потом втором и так далее. Это все идиотская трата времени. При гетерогенной инфраструктуре теряется экспертиза, потому что вот эти все разговоры типо «вот тут у на MySql, а вот тут возьмем PostgreSQL, у нас же микросервисы», ведут лишь к снижению уровня требований по работе с каждой конкретной технологией. Кроме того, очень сильно падает уровень вовлеченности. Люди знают, что отвечают за свои 3.5 сервиса и им поебать, чо там происходит в остальных. Я могу допустить, что есть некий уровень сложности, где подобных подход решает, без него никак. Но если подобная дичь творицца лишь потому, что в интернетах зафорсили как «последнее слово техники», то нахуй нахуй.