Микросервисная архитектура: теория и практика
Представьте, вы создали компанию и заказали для неё сайт. Вы оказались неплохим бизнесменом: продажи растут, клиентов все больше, открываете новые филиалы. Приходится добавлять на сайт все новые и новые функции, чтобы удовлетворить запросы посетителей.
Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP. В результате...
Каждый сервис тратит процессорное время на кодирование-декодирование данных. Это вроде бы мизер в рамках одного сервисе, но когда их становится слишком много...
есть MySQL (база данных сайта), в нём по прежнему хранятся SKU,есть Elasticsearch, в него мы тоже поместили все SKU, когда нам нужны определенные SKU с определенными свойствами, мы эти параметры передаем в Elasticsearch и за 0,5 сек. получаем не сами SKU, а список их id-шников. Эти id мы отдаем в MySQL и говорим: «Выведи их на страницу».
А потом оказывается что то-то где-то не так с синхронизацией баз и одни SKU есть на сайте, но их нет в эластике, другие - наоборот.
Я не спорю, что микросервисы где-то и в чем-то хороши, но это не абсолютно. Честно говоря, я как-то затруднюсь себе представить более-менее крупную 100% монолитную систему. Это вообще как? Одна программа, которая делает все-все-все? Такое вообще бывает?
Зато могу себе представить (ибо сам работаю с такой) достаточно крупную систему, работающую на многопользовательской платформе, где каждый процесс выполняется в отдельном задании (job). Задания полностью изолированы друг от друга - в каждом может быть свое окружение построено. У каждого своя память (в нашей системе каждому заданию выделяется 16Гб памяти). Полное падение одного задания никак не влияет на все остальные. Общаться между собой задания могут любыми доступными средствами - сокеты, пайпы, очереди (не те, которые кафки различные, а системные, где они есть, очереди сообщений, очереди данных...). И каждый процесс в своем задании выполняет свою часть общей работы. Одновременно может крутиться тысячи и более различных заданий.
Хотите распараллелить обработку? Да не вопрос. Пишем классическую батчмашину, где родительское задание запускает сколько нужно обработчиков (каждый в своем отдельном фоновом задании), создает конвейер (ту же "очередь данных" - есть у нас такой тип объекта в системе), а дальше делает выборку нужных для обработки данных, формирует их в пакеты и выкладывает на конвейер. Обработчики оттуда подхватывают и делают что нужно.
Это микросервисы? Если да, то "изобрели" их очень давно. Еще во времена System/36..38 и всяких разных ЕС ЭВМ и БЭСМ. Если нет, то что это? Уж точно не монолит...
Комментарий недоступен
лучше обычные сервисы в монолите
изолированные, стабильные, параллельные
лично у меня сеть падала в разы чаще чем приложение
единственное, где горизонтальное масштабирование потребно это БД