Оптимальный размер микросервиса
Друзья, мне кажется, здесь аудитория достаточно зрелая, чтобы обсудить этот вопрос на интересном мне уровне абстракции. Допустим, мы разрабатываем какую-то очень сложную, но достаточно естественно декомпозируемую систему. Например, банковское приложение крупного банка или агрегатор такси, что-то такое. На одном краю спектра находится монолит, когда код системы представляет собой чудовище, а чтобы ее зарелизить, нужно сначала заморозить на полгода и эти полгода тестировать. На другом краю спектра находится death by a thousand microservices, когда существенный процент кода и работы с ним это обслуживание, собственно, микросервисов, а не какие-то более содержательные манипуляции с данными, а существенный процент сложности системы находится уже даже не в коде, а в графе взаимодействия этих самых микросервисов (и хорошо еще, если этот граф вообще наблюдаемый как какая-то визуализируемая или текстовая сущность, а не существует только имплицитно).
Собственно, вопрос, где находится золотая середина. Мой вариант ответа -- хороший микросервис разрабатывает команда, в которой каждый знает каждого и каждый senior понимает, что происходит в любой части кода. При этом дробить сильнее уже вредно, т.е. правильный размер команды микросервиса это 5-7 человек (так что сервис даже не совсем "микро").
Но я знаю, что очень часто систему дробят гораздо мельче, вплоть до того, что один программист разрабатывает и поддерживает несколько "микросервисов". Например, вместо одного бэкенда профиля пользователя мы устраиваем микросервис, который занимается аватарками, отдельно микросервис, который занимается самоописанием пользователя и т.п. Мне такой способ организации кажется абсурдным. Я не видел внятного обоснования, зачем так делать (хотя знаю цинично-реалистичное: job security архитектора, если такая роль в проекте отдельно выделена). Это я чего-то не понимаю, или все-таки они?
▲ 2 ▼ anonymous 25-03-2024
На каком языке будет написан твой монолит? Микросервисы хороши по крайней мере тем, что n-1 можно наговнякать
на петонена чем попало, а единственный тяжелый написать на плюсах.(имхо, Linux kernel именно поэтому и считается типа охренеть каким рокетсаенсом: внутри код про алгоритмы и структуры данных, написанный на языке программирования без нормальной поддержки хотя бы ассоциативных словарей, я уж молчу о кастомных структурах)
ответить▲ 1 ▼ anonymous 25-03-2024
Ну, на том на каком захочется на самом деле. Но вообще же даже на си можно писать как на питоне, если написать свои хешмапы и прочие структуры(Вспомним 10-е правило Гринспена: Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp).
ответить