Давайте поговорим о положительных и отрицательных сторонах микросервисного подхода.
Первые негативы. Когда вы создаете микросервисы, вы добавляете сложность в свой код. Вы добавляете накладные расходы. Вы затрудняете копирование среды (например, для разработчиков). Вы делаете отладку прерывистых проблем сложнее.
Позвольте мне проиллюстрировать реальный недостаток. Рассмотрим гипотетически случай, когда у вас есть 100 микросервисов, вызываемых при создании страницы, каждая из которых работает правильно в 99,9% случаев. Но в 0,05% случаев они дают неправильные результаты. И в 0,05% случаев возникает медленный запрос на соединение, где, скажем, для соединения требуется тайм-аут TCP / IP, и это занимает 5 секунд. Около 90,5% времени ваш запрос работает отлично. Но примерно в 5% случаев вы получаете неправильные результаты, и примерно в 5% случаев ваша страница работает медленно. И каждый невоспроизводимый сбой имеет свою причину.
Если вы не будете много думать об инструментах для мониторинга, воспроизведения и так далее, это превратится в беспорядок. Особенно, когда один микросервис вызывает другой, который вызывает другого на несколько уровней. И как только у вас возникнут проблемы, со временем будет только хуже.
Хорошо, это звучит как кошмар (и больше чем одна компания создала огромные проблемы для себя, идя этим путем). Успех возможен только тогда, когда вы четко осознаете потенциальные недостатки и последовательно работаете над его устранением.
Так что насчет этого монолитного подхода?
Оказывается, что монолитное приложение так же легко модульно, как и микросервисы. И вызов функции на практике дешевле и надежнее, чем вызов RPC. Таким образом, вы можете разработать то же самое, за исключением того, что оно более надежно, работает быстрее и требует меньше кода.
Хорошо, тогда почему компании переходят на микросервисный подход?
Ответ заключается в том, что при масштабировании существует предел того, что вы можете сделать с монолитным приложением. После стольких пользователей, большого количества запросов и т. Д. Вы достигаете точки, когда базы данных не масштабируются, веб-серверы не могут хранить ваш код в памяти и т. Д. Более того, микросервисные подходы позволяют осуществлять независимое и постепенное обновление вашего приложения. Поэтому микросервисная архитектура - это решение для масштабирования вашего приложения.
Мое личное правило заключается в том, что переход от кода на языке сценариев (например, Python) к оптимизированному C ++, как правило, может повысить на 1-2 порядка как производительность, так и использование памяти. Переход к распределенной архитектуре в другом направлении увеличивает требования к ресурсам, но позволяет масштабировать до бесконечности. Вы можете заставить распределенную архитектуру работать, но сделать это сложнее.
Поэтому я бы сказал, что если вы начинаете личный проект, идите монолитно. Узнайте, как это сделать хорошо. Не распространяйте, потому что (Google | eBay | Amazon | и т. Д.). Если вы попали в крупную распределенную компанию, обратите пристальное внимание на то, как они заставляют ее работать, и не облажайтесь. И если у вас возникнет необходимость сделать переход, будьте очень, очень осторожны, потому что вы делаете что-то сложное, что легко очень и очень неправильно сделать.
Раскрытие, у меня есть почти 20-летний опыт работы в компаниях всех размеров. И да, я видел как монолитную, так и распределенную архитектуры близко и лично. Основываясь на этом опыте, я говорю вам, что распределенная микросервисная архитектура - это действительно то, что вы делаете, потому что вам нужно, а не потому, что это как-то чище и лучше.
