Комментарии 12
на сегодняшний день, микросервисы - некогда и незачем!
как я уже здесь цитировал:
Если вы давно не смотрели на серверное оборудование, то обнаружите, что современные высокопроизводительные серверы — это целые датацентры в коробке! Я просто ткнул Dell и нашел следующие характеристики PowerEdge R960:
240 ядер (4 сокета по 60 ядер в каждом)
16 ТБ ОЗУ в 64 модулях DDR5 DIMM (это как 1000 приличных ноутбуков)
А если нужно хранилище, то вы можете подключить до 24 NVMe дисков — по 4 ТБ каждый, а это почти 100 ТБ высокоскоростного SSD! И если 240 ядер вам покажется маловато, то Intel анонсировала процессоры Xeon с 288... Уже прямо сейчас вы можете подключить два Xeon 6780 к PowerEdge R770 серверу, получив в общей сложности 288 ядер, по цене около USD 32k.
Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.
Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро в секунду) или даже 50 000 звучит более правдоподобно.
А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.
https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f
Ну вы статью то мою прочитали?
Я же написал, что требование по высокой производительности / масштабируемости реализуется множеством способов. И масштабируемость становится доводом за микросервисы только если вы уже исчерпали остальные возможности.
Ок, я добавлю туда вертикальное масштабирование.
Сервер хорош, конечно, но предположу, что покупать такой вот сразу себе мало кто решится - нужно дорасти по нагрузке и с микросервисами проще её наращивать постепенно. Да ещё часто не хочется вовсе владеть никаким железом тк нужно же его обслуживать, резервирование учесть, держать запасные части, а то умрёт рейд-контроллер - что будем делать? Тоже горячая замена есть? Да и географически в разных дата-центрах тоже имеет смысл размещаться, а так с одним большим сервером может всякое произойти, например его могут забрать просто как вещдок и увезти, и для этого даже не нужно доказать вину - достаточно наличия дела.
покупать такой вот сразу себе мало кто решится
а зачем его покупать сразу? сервер может расти за Прибылью.
в общем, парадигма ИЗМЕНИЛАСЬ! еще лет 10 назад каждая первая статья о Масштабировании вполне резонно отмечала, что Вертикальное Масштабирование вас НЕ вывезет...
но!
на сегодняшний день ваш Бизнес сдохнет раньше, чем вы исчерпаете возможности одного Хорошего Сервера.
ЗЫ расчлененка - дополнительная Сложность! зачем себе портить Жизнь, если можно не портить?
Обычно, несколько серверов одновременно. Но их сложнее синхронизировать
Микросервисы по простому это распределенная архитектура, когда отдельно от остального один или несколько экземпляров сервиса и его данные тоже отдельно.
И вот теперь сервис взаимодействует с остальной частью по сети.
Здравствуйте, сетевые задержки
Здравствуйте, сетевые ошибки
Здравствуйте, очереди и повторы
Зато можно отключить сервис, заменить и включить, использовать несколько версий одновременно
Зато можно задать потолок ОЗУ на каждый запрос, чтобы вся система не рухнула при котором запросе
Зато можно вкатить новый сервис без сложного интеграционного тестирования (но это можно и на монолите)
И вот теперь база данных отдельно
Здравствуйте, сложные и долгие изменения в нескольких БД сразу, ака распределенные транзакции.
Здравствуйте, некосистентность данных чтобы хоть как-то это ускорить
могут быть вариации же.
У меня обычно микросервисы не честные, например. Связанны через БД.
У каждой данные в своей схеме, но естественно с fk, чтобы не ходить в чужие схемы внаглую, обычно делаю view в схеме сервиса.
Много головной боли по поводу консистентности снимается. При этом приложения маленькие, логика изолирована, горизонтальное масштабирование возможно.
Ведь главная проблема микросервисов не сетевые задержки, а распределенные транзакции, эвеншал консистанси и косяки с этим связанные. Система усложняется кардинально.
В общем кактусы есть, нету колючек.
Плюс в том, что базовая часть "микро" сервисов превратилась в библиотеки, подключаемые к конкретному проекту и немного кастомизируемая под конкретные задачи. Например профиль, или Api Gateway.
Все как раз наоборот: надо сразу проектировать как набор микросервисов. Их проще писать, отлаживать, версинировать, аутсорсить и тд
На скорость монолита всем чихать так что скорость оборудования это аргумент в пользу МС
Просто пишите код. Часть 1