Что нащет микросервисов, ммм?
Mar. 24th, 2018 04:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stdray
Всё изменилось, когда я сменил работу. Попал в ситуацию, где соотношение сервисов к количеству разработчиков было 3-4 к 1. И, конечно, всё это называлось «сервисной» архитектурой, а при продумывание того, как нам делать новую функциональность люди ориентировались на непонятные мне каноны микросервисов и «облачную архитектуру».
Что вообще я знал про микросервисы из статеек в интернете:
- Всегда есть противопоставление некоему «монолиту»
- Есть понимание, что «монолит» - енто некий сервис с API, который крутит внутри себя кучу фоновых процессов
- Выделяем фоновые процессы в самостоятельные сущности, получаем микросервисы
- Разбиваем большое сложное API на логически связанные разделы, уносим в самостоятельные сущности, и вуаля микросервисы
Что я вообще понимал под термином «микросервис»:
- Технически это сайт или служба/демон, который имеет простой и понятный API
- Инкапсулирует в себе некую атомарную часть «бизнес-логики» (кавычки потому, что адепты микросервисов чому-то редко употребляют ентот термин)
Какие я видел плюсы подобного подхода:
- Настоящее разграничение и изолированность (грабли в сервисе А, не долетают до всех от него зависимых, технически невозможно доступиться до условного синглтона)
- Простота архитектуры и реализации (чем проще задача, тем меньше надо инфраструктурных наворотов)
- Масштабируемость по людям (раз уж мы все сегментировали даже технически, то можно нагонять ораву)
- Разнообразность технологий (если потребителям видно только API, то похуй как оно врутри сделано)
- Простота тестирования (меньше логики и внутренних инфраструктурных сложностей – проще писать тесты)
Что на практике:
- Пересечение логических зон ответственности нескольких микросервисов (самое страшное, имхо, тому что не понять, куда впиливать фичу)
- Сложный и плохо формализуемый граф зависимостей (если в условном монолите, написанном на популярном языке, можно легко посмотреть граф, кто от кого зависит и пробежаться по конкретным примерам использования, то в миросервисах енто все крайне затруднено)
- Дисбаланас функционалисти (один сервисы делаю дохуя, другие реально «микро»)
- Дисбаланс нагрузки (следствие предыдущих 2 пунктов, то есть от одного сервиса зависят 100500 других и, значит, его будут нагружать)
- Невероятная сложность тестирования (из-за того, что зависимости стали «физическими», тк реально разные приложения работают, то находить несостыковки можно только интеграционными тестами, а они сами по себе в 1000 раз более долгие чем юнит-тесты, а «моки» на таком уровне – енто сложнее чем вся фича)
- Замедление разработки (если фича требует поддержки от 2 или более сервисов, то надо общаться с людьми, а потом синхронизировать процесс деплоя и тестирования)
- К любой вообще логике добавляется A/B тестирование (как следствие предыдущего пункта, тому что при количестве сервисов более определенного порога, просто невозможно поднимать согласованное окружение на одной машине, а тестироваться полными окружениями в облаке ради 2-3 сервисов невероятно дорого).
- Усложнение формальных процессов, тому что даже автотесты через A/B предполагают хотя бы наличие веток в разных репозитариях с единым названием (или любой подобный механизм согласования)
- Невероятно сложные релизы, тому что заказчик хочет в проде «вон те 2 фичи», которые невероятно сложно отодрать от общего потока разработки
Резюмируя. Сам по себе переход на микросервисную архитектуру не решает ни одну проблему вообще. Максимум, что он дает – это много боли, через которую, можно дойти до достаточно удобной инфраструктуры управления всем ентим зверинцем. Те же самые выстраданные A/B-тесты -- большой профит. Да и то, это реально только в условиях ГОМОГЕННОЙ инфраструктуры, когда для одних и тех же вещей, используется одна и та же технология и общие библиотеки для них. В противном случае, можно весело смотреть, как при появлении нового микросервиса пишется клиент для него на первом ЯП, потом втором и так далее. Это все идиотская трата времени. При гетерогенной инфраструктуре теряется экспертиза, потому что вот эти все разговоры типо «вот тут у на MySql, а вот тут возьмем PostgreSQL, у нас же микросервисы», ведут лишь к снижению уровня требований по работе с каждой конкретной технологией. Кроме того, очень сильно падает уровень вовлеченности. Люди знают, что отвечают за свои 3.5 сервиса и им поебать, чо там происходит в остальных. Я могу допустить, что есть некий уровень сложности, где подобных подход решает, без него никак. Но если подобная дичь творицца лишь потому, что в интернетах зафорсили как «последнее слово техники», то нахуй нахуй.
Проектирование AI
Date: 2018-03-24 04:10 pm (UTC)Re: Проектирование AI
Date: 2018-03-24 04:45 pm (UTC)>С точки зрения проектирования и разработки сверху вниз теория микросервисов работает как дети в школу...
Дискуссионный вопрос. Это работает как дети в школу, если есть некий монололит, который надо побить на микросервисы. Если надо строить с нуля, когда не из чего брать понимание, то как дробить не ясно. Может как в анектоде про чайник и программиста -- надо сначала написать монлит.
>недостатки которые вы написали в основном преодолеваются на стадии проектирования
У меня как раз сложилось мнение, что адепты микросервисной архитектуры сидят на двух стульях. С одной стороны, если понятен некий функционал, то можна начинать пилить. Типо снизу вверх подход. Понаделаем кубиков, потом соберем систему. А с другой стороны надо проектировать. И мой опыт говорит, что проектировать надо и даже больше чем в монолите, чтобы потом не было больно.
>AI и самообучающиеся системы,
Я не большой специалист в ентом, но моя контора (я уже уволился правда, щас дорабатываю) имеет очень серьезные наработки в этой области. И какбы если нет критериев, если нет даже обучающей выборки, то что-то сделать нереально. А индустрия как раз в положении, когда ничего нет. Есть закрытые супер-конторы уровня гугла и фейсбука, которые травят байки, есть 100500 проектов, которые на енто ведуцца, а еще больше просто игнорируют. И как понимать, если код закрыт, да и успех/провал не осязаемы.
Re: Проектирование AI
Date: 2018-03-24 07:10 pm (UTC)...ты конечно прав на все 100% насчет монолита... но монолит ваяют не от хорошей жизни, а чтобы сьекономить на проектировании... я всегда был стороником проектирования сверху вниз и микросервисов, хотя они тогда так не назывались... и только со временем я понял, что это дело вкуса писать сверху или снизу, но когда появился opensource просто перестали писать сверху автоматически... дело в том, что дьявол прячется в мелких деталях и при ошибках проектирования возвращаться осень больно когда идешь сверху и когда идешь снизу, но просто когда идешь снизу - это делаешь чаще... вот и все...
...насчет AI я тоже не большой специалист и я тебе по большому секрету скажу сто всеми фибрами своей души ненавижу всякие генераторы кода и самое главное латать их всякими заплатками... но к сожалению я другого пути не вижу в разработке AI и самообучающих программ, которые будут генерировать код и латать баги и писать микросервисы не приходя в сознание... может есть конечно и другой путь, но это не с архитектурой фон Неймана, а это уже другая тема, в которой ч тоже не великий специалист, как впрочем подозреваю и ты тоже...
Re: Проектирование AI
Date: 2018-03-24 08:12 pm (UTC)генерация - это следствие либо недостаточной выразительности языка, либо "границы технологии" (к примеру, не вижу ничего плохого, в том чтобы генерировать из классов на C# интерфейсы на TypeScript). Но никаких AI тут и рядом не валялось, и не будет.
>но монолит ваяют не от хорошей жизни, а чтобы сьекономить на проектировании...
>я всегда был стороником проектирования сверху вниз и микросервисов
Проектирование же в итоге тоже самое, только в одном случае меньше инфраструктуры (монолит), в другом больше (сервисы). Если опираться на хорошую архитектуру, то одно сделать быстро, а другое не очень (монолит быстрее, тому что не надо поднимать деплой, тестирование, и даже на уровне кода кода, думать "а какие вообще зависимости мне нужны")
Так что да, монолиты ваяют не от хорошей жизни. А микросервисы, в условиях, когда "монолит тащит" - енто "с жиру бесимся" и прочее джоб секьюрити.
Re: Проектирование AI
Date: 2018-03-24 08:54 pm (UTC)(no subject)
Date: 2018-03-24 07:46 pm (UTC)Прелесть микросервисов в том и заключается, что за качество на макро-уровне никто не отвечает.
(no subject)
Date: 2018-03-24 08:19 pm (UTC)ЗЫ: если желания делать продукт нет, писать хороший код нет и тд. И скрещиваешь микросерсивы и ФП, то можно на достойных условиях пинать хуй.
Тока если так
(no subject)
Date: 2018-03-24 08:28 pm (UTC)Какая ситуация для них лучше: мы не можем построить сквозную архитектуру, потому что архитектор - остолоп, а менеджер нанял каких-то тупых козлов, или у нас не хватает ресурсов, нам нужны ещё люди для создания микросервисов. И ещё люди. И ещё люди. Ну и что, что не работает? "К пуговицам претензии есть?"