Привет, на самом деле ты прав. По итогу нашу архитектуру стоит называть сервисной, а не микросервисной. Микросервисами можно назвать только некоторые платформенные сервисы, которые занимаются коровой логикой, например отправкой пушей, аутентификацией и тд. Все продуктовые сервисы уже довольно большие получается, и пока делить их на меньшие системы мы не планиурем, так как изначально частью нашей стратегии было именно изолирование влияния друг на друга различных бизнес процессов.
По поводу стека, ну это ведь тоже везде ситуативно. У нас активно на тот момент развивался PaaS который поддерживал в основном Go (сейчас уже имеется поддержка Ruby, Python, TS) и в направлении принято решение было именно использовать Go как основной ЯП. Поскольку инженеров и команд много проще иметь один язык, чтобы в случае чего можно было как раз привлекать другие команды к иннерсорсу. Поэтому сейчас все активно на гошке пишем. Хотя по мне, после того пути, который прошла моя команда, я считаю что язык это всего лишь инструмент, при желании его в целом можно быстро освоить для решения проблем :)
Да, в целом в начале мы действительно просто пересмотрели взаимодействие сервисов. В этой статье я хотел описать именно базовые вещи, которые помогли нам повысить стабильность и отказоустойчивость систем, перед тем как мы полноценно начали пилить сервисы.
В дальнейших статьях я собираюсь описать то, как именно мы выносили функционал, ну и какую в итоге пользу нам это принесло.
Весь наш путь данной статьей не ограничивается, постараюсь подробнее расписать в будущих статьях.
Привет, на самом деле ты прав. По итогу нашу архитектуру стоит называть сервисной, а не микросервисной. Микросервисами можно назвать только некоторые платформенные сервисы, которые занимаются коровой логикой, например отправкой пушей, аутентификацией и тд. Все продуктовые сервисы уже довольно большие получается, и пока делить их на меньшие системы мы не планиурем, так как изначально частью нашей стратегии было именно изолирование влияния друг на друга различных бизнес процессов.
По поводу стека, ну это ведь тоже везде ситуативно. У нас активно на тот момент развивался PaaS который поддерживал в основном Go (сейчас уже имеется поддержка Ruby, Python, TS) и в направлении принято решение было именно использовать Go как основной ЯП. Поскольку инженеров и команд много проще иметь один язык, чтобы в случае чего можно было как раз привлекать другие команды к иннерсорсу. Поэтому сейчас все активно на гошке пишем. Хотя по мне, после того пути, который прошла моя команда, я считаю что язык это всего лишь инструмент, при желании его в целом можно быстро освоить для решения проблем :)
Да, в целом в начале мы действительно просто пересмотрели взаимодействие сервисов. В этой статье я хотел описать именно базовые вещи, которые помогли нам повысить стабильность и отказоустойчивость систем, перед тем как мы полноценно начали пилить сервисы.
В дальнейших статьях я собираюсь описать то, как именно мы выносили функционал, ну и какую в итоге пользу нам это принесло.
Весь наш путь данной статьей не ограничивается, постараюсь подробнее расписать в будущих статьях.