Выбор правильного старта для написания микросервисов?

Question

[LuciusS]

Господа и дамы, значится решили мы пилить новый проект, будет высоконагруженная система, типа социальной сети определённой тематики. Из технологий основное Spring + Kafka на Java. Собственно, мне нужно предложить оптимальную последовательность разработки сервисов, или хоть какую-то, но у меня что-то брейнлаг. Я всю дорого работал в в уже действующих проектах, и как-то так вышло что от моего мнения многое зависит. Что посоветуете? У кого может есть какой-то совет, кто стартовал проект с нуля, именно вебапликуха на приложениях.

P.S. Про сервер кафки и написание тестового взаимодейтвия сервисов понятно, вот как правильно писать архитектуру дальше? Как лучше распределить нагрузку между членами команды, и т.п. Понимаю что вопрос в общем и в целом, но может кто-то поделится своим опытом.

Comments

[alfss]

Позвольте спросить несколько вещей
1. Вас наняли и это оплачиваемая работа?
2. Как раньше происходил процесс?
3. На каком основании вы выбрали данный стек?
4. У вас есть примерное описание бизнес логики?
5. У вас есть видение архитектуры системы крупными блоками?
6. У вас есть опыт разработки фронтенд и бекенд ?
7. У вас есть сроки?
8. У вас есть команда? Какой ее размер и какие специальности?
9. Вы знаете примернын потребности в железе?

[Сергей Горностаев]

Слишком общий вопрос.

Answer 1

[Robur]

https://microservices.io/ - много полезных мыслей про микросервисы.

По опыту - даже при огромном желании запилить микросервисы, они действительно должны быть нужны чтобы получились. И хорошо ложиться на доменную модель.
Иначе у вас получится несколько обычных сервисов, которые вы назовете "микро".

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

Если вам не надо отвечать за продукт, а надо сделать именно архитектуру - то идете к тому кто отвечает, и составляете с ним хоть какой-то роадмап на пару лет. На его основе уже будете думать что от чего будет зависеть, в каком порядке делать, и вообще какие функциональные блоки вам нужны.
Пока продукт не описан - архитектуры не получится, разве что какие-то совсем базовые штуки. Даже выбор БД или протокола общения между сервисами зависит от бизнес - требований

Как лучше распределить нагрузку между членами команды, и т.п.

это уже про управление командой.

Если на вас взвалили вообще все от проекта до архитектуры и управления командой, то удачи. Если не завалите все полностью - будет крутой опыт.

Answer 2

[Кирилл Горелов]

Очень размыт вопрос.
Порекомендую тогда почитать.
Распределенные системы Брендан Бёрнс
и
Масштабирование приложений Ли Атчисон
Читаются легко и быстро. В среднем 250 стр.

И можешь конечно же в идеале еще дополнить
site reability engineering Бетси Бейер(есть на русском)

Вопросы отпадут сами