Вот мне довелось обновляться — и я ВЫНУЖДЕН в монолите обновлять или всё или ничего.
Стоп-стоп-стоп. Речь совсем о разных вещах.
Во первых:
У меня написано-то, что можно модернизировать систему построенную на базе монолита, без остановки обслуживания клиентов/посетителей/заказчиков.
То есть я говорю с точки зрения конечного пользователя — об уровне эксплуатации или operations, если по ненашему. Вторая часть термина DevOps. Вы же не выключили систему на месяц, пока занимались модернизацией?
Вы же говорите о самом процессе модернизации системы, то есть об разработке или, по ненашему, development. Первая часть термина DevOps.
Во вторых:
Ваш пример — про сильносвязанную систему, изначально разработанную без учета принципов «Чистой архитектуры».
Это позволило вам изначально программировать быстрее (что само по себе и неплохо), но затруднило дальнейшие модификации. То есть таков был изначальный выбор разработчиков. Хороший он или плохой — я не говорю. Заочно тут нечего обсуждать. Выбирать можно только взвешивая все «за-против» видимые только в конкретном случае.
Важно другое — вы говорите не об корневой проблеме монолитов, а о проблеме конкретной разработки, сделанной не по принципам чистой архитектуры.
Но да, монолиты в этом смысле расслабляют разработчика. Не лишают его возможности сделать грамотный SOLID — это вовсе не принципиальное свойство монолитов. А всего-то расслабляют, так как не обязательно делать все «по-правильному, с учетом дальнейших модификаций и расширений».
Так что виноваты не монолиты. А люди.
Но и примеров, когда микросервисы не помогут при серьезных переделках — можно придумать. Например, была у вас система, где микросервисы разговаривают через шифрованную сеть, внутри сети доступ не ограничен, снаружи не попасть. Все вроде зашибись.
Но пришли безопасники и сказали — что для multi-tenancy так нельзя. И будьте добры запилить теперь в каждом микросервисе функционал для аутентификации и авторизации и шифрования для каждого tenant независимо. И вы встряли опять таки с тем же объемом работы, что и был в вашем примере. И для микросервисов он будет даже побольше, чем для монолитов.
P.S.:
Имхо, хороший монолит можно распилить на части и превратить в микросервисы относительно легко. Ибо все входящие в него сервисы изолированы, взаимодействие между ними идет на уровне известных интерфейсов.
Собственно, человечество еще в прошлом веке придумало для этого инструменты, используемые для написания больших программ — всевозможные «private vs public» в помощь принципа SOLID/«чистой архитектуры». Как раз, чтобы не было соблазна лезть в другой модуль напрямую. Как раз чтобы на выходе не получить мешанину сильносвязанного кода. Это нужно не только для микросервисов. С таким кодом и в монолите сложно работать. Например, проблема тестирования части функционала.
P.P.S.:
Довольно подробно pro/contra микросервисов рассказано тут habr.com/company/flant/blog/424531
Ребята как раз специализируются на обслуживание всевозможных систем, в том числе и микросервисных.
Далеко не всегда:
Оправдываются ли ожидания с микросервисами?
Красным — неоправдывающиеся ожидания.
В том числе и усложнение (а не упрощение) разработки.
За деталями — туда. У них довольно развернутая аргументация.
И — они как раз любят и вовсю используют Kubernetes, созданный как раз для микросервисной архитектуры.
Вы уводите рассуждение в сторону от корня проблемы. Это из разряда — 'пусть вор ворует деньги, зато он их в стране потратит, налоги там, бизнес поддержит, поддержим вора'.
Проблемы-то две различные, не путайте их:
1) Если ничего не делать, ничего не вкладывать — то ничего у вас своего и не будет, никакой индустрии. Некопеечные государственные заказы тут один из хороших источников в помощь становления индустрии. Далеко не каждый коммерческий заказ сравним с государственным по финансированию. Ну хотя бы потому, что не так много коммерческих структур имеют такое количество подразделений как ФНС и мало кому из коммерческих структур посему нужна такая разветвленная система в ПО.
2) Воровство/коррупция. Пункт первый для воровства разумеется, очень лакомая питательная среда, бульон. Ну и что же? Вообще ничего не делать раз «разворуют»? Может, все же, делать, но реализовывать и меры для борьбы с воровством.
А еще в статье явно написано что они уперлись в производительность монолита. Т.е. до этого они монолите построили крупнейший в россии интернет-магазин.
Там не так написано.
С одной стороны, мы уперлись в производительность сервера с главной базой, но это не основная причина, так как вопрос производительности можно решить, например с помощью шардирования. С другой стороны, у монолита очень сложная логика, и на определенном этапе роста доставка изменений (релизов) становится очень длительной и непредсказуемой: много неочевидных и сложных зависимостей (все тесно связано), тестировать тоже трудоемко, в общем масса проблем. Решение — перейти на микросервисную архитектуру.
Они уперлись в производительность монолита. Но видели пути решения.
Однако, заодно им захотелось все переписать, ибо им было неудобно.
Монолит отличается от микросервисов в первую очередь тем, что в монолите нельзя отключить определенный кусок когда тебе вздумается. Только целиком.
Нет никакой проблемы поменять кусок в монолите без отключения всей системы.
Серьезные системы обновляют хитрым образом. Например, blue-green deployment или gaceful restart.
Эти же технологии применяются что для монолитов, что для микросервисов.
Без использования blue-green deployment/graceful restart и пр. вы и с микросервисами не можете поменять произвольную часть системы без остановки обслуживания клиентов.
Некоторые части системы — да.
Некоторые — ключевые, нет. Отключение их равносильно отключению сервиса целиком.
А микросервисами можно манипулировать — включил-выключил-поменял без остановки других частей
Система только выглядит рабочей.
Формально — да. Если 90% микросервисов у вас работают — то система рабочая как бы на 90%?
Фактически нет. Не рабочая. Пример ниже.
Пример: Интернет магазин.
Если вы отключите подсистему, отвечающую за формирование списка товаров и навигацию по нему (каталог товаров, витрина) — ваш интернет магазин не функционирует.
И то, что у вас при это успешно работает 90% остального кода — уведомления пользователей, корзина с товаром, личный кабинет, платежная система — не имеет никакого значения.
Ваш сайт мертв пока, вы не восстановите каталог товара.
Да, возможно, в этот момент кто-то уже в корзине и просто оформляет покупку. Однако:
а) Одного покупателя дает только 1000 или даже 10 000 посетителей.
б) Покупателем он становится после длительного прохода по каталогу товаров, выбора товаров.
Так что вы обслуживаете 1 покупателя в корзине/личном кабинете и даете отлуп 10 000 или 100 000 потенциальным, что нужен каталог.
То же самое можно сказать об отключении корзины или механизма оформления покупок, платежной системы — без всего этого ваш интернет-магазин и не магазин вовсе.
Тут товарищ в соседней ветке предлагает делать правильный монолит — 1 приложение и много потоков.
Не обязательно.
Для отказоустойчивости и для горизонтального масштабирования монолит все равно нужно запускать в нескольких инстансах на разных серверах.
Ничем тут от микросервисов не отличается.
Если позволяет выбранная технология — будет у вас один инстанс обрабатывать и 10 000 потоков. Не позволяет — просто будете запуском дополнительных инстансов этот недостаток компенсировать.
И причина, по которой вы запускаете дополнительные инстансы — не важна.
Неважно что это будет необходимость утилизировать все ядра процессора, если выбранный инструмент этого не умеет (если использует только 1 ядро, а на сервере их 16 — в этом случае вы запустите 16 инстансов на одном сервере). Или неважно, что это будет необходимость обеспечить обработку достаточного числа потоков (если один инстанс обрабатывает 1 000, а вам нужно 100 000, то вы просто запустите 100 инстансов)
Важно другое — вам нужно обеспечить корректную совместную работу большого количества инстансов (например, используя: репликации, общие сервера очередей и пр.).
Это важно и для монолита и для микросервисной архитектуры.
Давайте рассмотрим чистый монолит (сам конвертирующий видео файлы, сам же обрабатывающий запросы от пользователей) на примере ситуации, описанной ppl2scripts в habr.com/post/427215/#comment_19272331
Потому что завтра нужно будет отрендерить миллион превьюшек. Хорошо 50 тысяч. Тысячу.
Ситуация с монолитом не отличается от ситуации с микросервисами.
Определимся с вашей политикой использования вычислительных ресурсов. Что для монолита, что для микросервисов это будет одно и то же:
Или по мере освобождения вычислительных ресурсов, выделенных только под длительные операции. Таким образом, под трудоемкие операции выполняются только на определенном выделенном пуле вычислительных ресурсов.
Или по мере освобождения вычислительных ресурсов от других операций. В этом случае, фактически размер доступного пула динамически меняется в зависимости от нагруженности по прочим операциям
Пусть, для простоты, автомасштабированием без лимитов — простой способ получить производительность, но дорогой метод (сервера денег стоят):
В схеме бэкендом+конвертер мы просто запустим конвертер 50 000 раз.
Для бэкендов ничего не изменится.
В схеме с единым бэкендом — мы начинаем конвертацию, тем самым количество бэкендов, доступных для обычных запросов пользователей, сокращается. При обработке очередного запроса от пользователя обнаруживается, что обрабатывать запрос некому, так как свободных бэкендов нет. Просто запустим новый бэкенд. Очевидно, что при сохранении нагрузки придется запустить под быстрые запросы 50 000 дополнительных бэкендов, взамен тех, что длительное время будут заняты конвертацией. Если ваши бэкенды долго инициализируются это имеет смысл сделать заранее, одновременно с запуском конвертации. Или предусмотреть пул «горячих» свободных бэкендов
Рассмотрим ситуацию, когда конвертировать вообще ничего не надо. Но обычные быстрые запросы не успеваем обрабатывать. Просто запустим новый бэкенд. Ничем не отличается от предыдущего пункта в плане автомасштабирования. Только то было «автомасштабирование по причине того, что бэкенды заняты конвертацией». А это «автомасштабирование, так как бэкенды не успевают обработать обычные быстрые запросы». Но не отличается ровно ничем — ответ на недостаток ресурсов для обработки это запуск нового бэкенда
Но почему это произошло?
Если у меня год подряд было 1 000 в день, то вероятность того, что завтра будет 50 000 в день — крайне незначительна. А вероятность того, что будет миллион = 0.
Если такое случится, видимо, теперь мы мега-популярны и мега-посещаемы?
Так что следующий этап:
Инвесторы/владельцы будут только рады доплатить разработчикам за сверхсрочную работу, чтобы они вынесли операцию конвертации в отдельно запускаемый и отдельно масштабируемый модуль.
А пока разработчики оптимизируют систему инвесторы/владельцы будут рады заплатить дополнительные деньги за сервера, которые держат нагрузку по приведенной выше схеме с бэкендом-монолитом.
Платить за это заранее готов далеко не каждый. А вдруг не будет не то что миллиона, а и 50 000 не будет никогда?
Сделать сразу «как у Фейсбука и Гугл» — это ж разница совсем не в 20% по стоимости работ. И по срокам тоже дольше.
Монолиты гораздо эффективнее по производительности, чем микросервисы на огромном числе задач. При меньшей стоимости и большей скорости разработки.
Вот пример примитивнейшей ситуации: habr.com/post/282299
«Кэш внутри приложения» vs «Кэш рядом, в соседнем отдельном процессе».
А ведь в микросервисах, все еще хуже. Там и сетевые задержки. И переходов между процессами/модулями/сервисами куда как больше. И дополнительных сериализаций/десериализаций полным-полно. И пр.
Как было раньше (со старта Авито до 2015 – 2016 годов): мы жили в условиях монолита, с монолитными базами и монолитными приложениями. В определенный момент эти условия стали мешать нам расти. С одной стороны, мы уперлись в производительность сервера с главной базой, но это не основная причина, так как вопрос производительности можно решить, например с помощью шардирования.
Если вы не Гугль, то, вполне возможно, гораздо оптимальнее для вас будет не микросервисы, а всего лишь 2-3-4 крупных сервиса. Главное, чтобы они были способны работать на множестве запущенных инстансов для горизонтального масштабирования.
А возможно оптимальнее будут именно микросервисы.
А возможно у вас такое финансирование, что вы можете на него и продукт свой сделать 5-ю способами, чтобы выбрать лучший, и два Kubernetes'а в придачу. Всяко бывает.
Пользователь загрузил 20-и минутный видео файл в качестве 1024p. Его нужно предобразовать в видео меньшего разрешения: 720p, 480p и 360p. Какой алгоритм будет в монолитном приложении?
Для определенности предположим, что вы делаете клон YouTube, но с посещаемостью на порядки меньше. Вам интересно как бы это выглядело на монолите?
Как бы сделал я:
0) Балансировщик на входе — fabio/Traefik/nginx.
Так как для надежности и горизонтального масштабирования — все это и в случае монолитной архитектуры должно уметь работать на нескольких серверах в нескольких инстансах.
Это что для монолита, что для микросервисов нужно.
1) БД для метаданных видеофайлов, профилей пользователей, сессий, комментариев.
Возможно, одна СУБД, если проект невысокой нагрузки.
Или несколько СУБД различной специализации, например, более часто запрашиваемые сущности такие как сессии — в Tarantol/Redis, комментарии в Mongo (тут пригодится ее умение масштабироваться сравнительно легко, ну а то, что платой за это является у Монги консистентность не строгая, а типа «когда-нибудь потом» — это не важно для комментариев).
Необходимость реляционной СУБД для такой простой задачи под вопросом. Ну, разве что, для строгой консистентности профилей пользователей, если, например, у вас платный доступ. Допустим, возьмем PostgreSQL.
Все экземпляры всех видов СУБД — разумеется реплицируются.
Выделение Tarantool/Mongo/PostgreSQL позволит сделать удобную репликацию master-master для Tarantool/Mongo (Тарантул точно умеет, Монго, надеюсь, не помню точно). Это снимет нагрузку с PostgreSQL, так как он заметно хуже работает на большом количестве экземпляров (а тем более по сети) и позволит обойтись для PostgreSQL более мягким master-slave.
Что для микросервисов, что для монолита — эти СУБД будут.
2) Бэкенд. Вполне себе монолит. Большой и единый.
3) Фронтенд.
Это не монолит и не микросервис. Он запускается все равно не на наших серверах, а у пользователей. С точки зрения сервера — это небольшие статические файлы, раздать их не проблема.
4) Модуль конвертации. Маленькая узкоспециализированная утилита. Даже какой нибудь ffmpeg годится.
С небольшой специально написанной обвязкой, например, подписанной на очередь и запускающий ffmpeg.
Или вообще без обвязки специальной — тот же Nomad из Hashicorp вполне годится, имхо. Его же можно для deploy новых версий бекенда использовать. Его же можно использовать для запуска ffmpeg
Что для монолита, что для микросервисов — все тот же ffmpeg и все та же обвязка.
5) Сервер очередей. Для более гибкого управления множеством инстансов.
Чтобы не лазать в БД на каждый чих, чтобы все экземпляры бэкенда и все экземпляры конвертера были просто подписаны на события.
Это нужно и для монолита и для микросервисной архитектуры.
6) cloud storage работающее по протоколу S3 или OpenStack Swift
Это нужно и для монолита и для микросервисной архитектуры.
7) Кэш. Поскольку у нас есть очередь с подписками и мы сможем легко инвалидировать кэш — то годится и локальный для каждого бэкенда кэш или даже кэш, встроенный в бэкенд (это будет очень быстро).
Инвалидировать локальный внешний кэш можно из бэкенда-монолита, внешняя обвязка для этого не нужна. Все равно кроме бэкенда-монолита в него никто лазать не будет.
Для микросервисов такой вариант тоже имеет смысл — в терминах Kubernetes кэш будет размещен в одном поде с использующими его микросервисами.
Впрочем, не локальный, а общий для всех экземпляров монолита/микросервиса кэш тоже имеет право на жизнь. Но это будет медленнее, чем локальный. Нужно по профилю нагрузки и по имеющейся оперативной памяти на серверах смотреть что выбрать — локальный или общий.
— Имеем множество экземпляров бэкенда-монолита и множество экземпляров конвертера.
Опционально добавляем:
8) Если бюджет позволяет более серьезно относится к диагностике — централизация сбора логов и метрик. Логи нужны всем. Метрики микросервисам важнее.
9) Если нагрузка по закачке на наш сервис новых файлов более серьезна то выделить из монолита один компонент, занимающийся загрузкой файлов. Разумеется, тоже несколько экземпляров.
Для многопоточных бэкендов Erlang или Go (golang) нет необходимости выделять этот компонент сразу. Для NodeJS с ее однопоточностью — принципиально выделить сразу, даже при небольшой нагрузке на upload новых файлов.
Итого имеем балансировщик, СУБД и MQ-сервер и cloud storage и кэш — обязательные как для монолитной так и для микросервисной архитектуры.
Варианты с монолитом:
1) Монолит бэкенда + конвертер.
2) Монолит бэкенда + конвертер + модуль upload
С сохранением все того же масштабирования при нагрузке, что и у микросервисов, причем можно масштабировать отдельно нагрузку и на инстансы бэкенда-монолита и на инстансы конвертера и на инстансы загрузчика.
Конечно модуля upload и конвертер — легковесны и обладают частью признаков микросервисности, но все решение — однако все решение в целом все же не является микросервисной архитектурой, имхо. Максимум — просто сервисной. Без «микро-».
В микросервисной архитектуре, имхо, компонент десятки и сотни и обязательно нужен дополнительный инструментарий для поддержки этого роя микросервисов.
Впрочем, учитывая особо выделяющийся по объемности функционал компонента бэкенда-монолита — все же, полагаю, что это монолитная архитектура. С использованием отдельных помощников бэкенду — MQ, cache, конвертер.
Я вот заглянул к вам в профиль, а там хабы про программированию, хайлоад, и прочим техническим штукам. Как при этом можно не знать о существовании конпки «Home»?
Не у всех она на клавиатуре есть, даже если клавиатура с нумпадом
Это да, но ведь все предыдущие знания не на этой одной клавиатуре без Home получены? Были же и другие клавиатуры
В Госдуму внесен проект закона об ограничении права владения новостным агрегатором для иностранных государств (до 20%): www.interfax.ru/business/634505. У этого законопроекта чуть ли не главная цель — Яндекс. И как вовремя решили продолжить давить на компанию через госаппарат…
<… пожимая плечами… > А в чем проблема у Яндекса создать под новостной агрегатор юр. лицо в РФ? Бухгалтера/юристы Яндекса настолько перегружены работой?
Да, вы правильно поняли. Вести бизнес в России опасно. Пока ты маленький, тебя может и не тронут, но как только становишься средним — жди гостей.
Хотя вы и так всё прекрасно знаете. Кому я только отвечаю…
Ну то есть проблемой вы считаете не создать бизнес?
Создать, обойдя конкурентов, предложив покупателям нужные услуги/товары, создав в глазах покупателей репутацию, решив кучу проблем попутно как сводить концы с концами в плохой месяц и пр.
Но нет, вовсе не поэтому, что нужно напрягаться, у некого мечтателя/ленивца нет хорошего бизнеса? (плюс неудачи могут быть, но это уже объективная причина, единственная объективная, кстати)
Зато он сразу может показать кто в этом виноват?
P.S.:
А у тех, у кого получилось — у тех, как? Живут на этой территории, бизнес на этой территории, но государство другое?
Рекламируют, мол сайты они создают для бизнеса (точнее компания UMI (читай 1с) для них пилит на своём дурнопахнущем куске псевдокода).
Это вы логично заметили:
Да и сам битрикс или юми вы видели изнутри? Думаете он нравится разработчикам? Они получают выплаты от компании за то, что используют этот «кусок».
Разработчики создали, предположим пусть что и говнокод, но виноваты в этом не они. Они просто получают зарплату и морально мучаются тем, с чем работают?
в первом же конфликте с Мэйл.Ру, USM Holding отдал ему под контроль всю свою долю на бумаге к уже имевшемуся контролю фактически, лишь бы сохранить его
Разве не USM Holdings владеет самой Mail.Ru Group?
Так что какая разница.
Поисковик — основной я-бизнес — может умереть очень быстро. См.altavista
В те годы с моделями заработка в интернете было все плохо.
Скажем, на заре того же Яндекса было только ощущение, что вот-вот пойдут большие деньги. Но еще никто не знал как их добыть. Но Яндекс уже пилили.
А потом появилась контекстная реклама. Но altavista уже пролетала как фанера над Парижем.
В августе 1998 года поисковая система была выкуплена корпорацией Compaq за 3,35 миллиона долларов, что являлось крупнейшей сделкой подобного рода на тот момент. При этом адрес поисковой системы оставался прежним — altavista.digital.com. Compaq потратила немало времени и сил на поиск возможностей сделать из AltaVista прибыльный проект, но осуществить это не удалось.
Да, да — все правильно.
В те годы еще люди толком не знали как заработать в интернете (кроме продаж и инвестиций — это то было очевидно).
Хотел бы также привести цифры, которые подготовило одно из наших деловых объединений. За 2014 год следственными органами возбуждено почти 200 тысяч уголовных дел по так называемым экономическим составам.
То есть стараться сделать свою жизнь лучше не стоит, потому что все равно все отберут? Я вас правильно понял?
Ну посмотрите, к примеру, на Роснефть и то, как ей управляет Сечин. Или космическую отрасль и как ей управляет Рогозин. Или Роснано и как ей управляет Чубайс.
И?
Все госуправление должны быть идеальным?
Глобально-то государственное управление показало, что это возможно.
Ваш компьютер, с большой вероятностью, питается от электростанции, созданной государством. И электричество у нас не самое дорогое в мире. А скорее дешевое (пусть и не самое дешевое).
Не нужно обобщать про поколения.
Это всего лишь ваш местячковый термин.
Стоп-стоп-стоп. Речь совсем о разных вещах.
Во первых:
У меня написано-то, что можно модернизировать систему построенную на базе монолита, без остановки обслуживания клиентов/посетителей/заказчиков.
То есть я говорю с точки зрения конечного пользователя — об уровне эксплуатации или operations, если по ненашему. Вторая часть термина DevOps. Вы же не выключили систему на месяц, пока занимались модернизацией?
Вы же говорите о самом процессе модернизации системы, то есть об разработке или, по ненашему, development. Первая часть термина DevOps.
Во вторых:
Ваш пример — про сильносвязанную систему, изначально разработанную без учета принципов «Чистой архитектуры».
Это позволило вам изначально программировать быстрее (что само по себе и неплохо), но затруднило дальнейшие модификации. То есть таков был изначальный выбор разработчиков. Хороший он или плохой — я не говорю. Заочно тут нечего обсуждать. Выбирать можно только взвешивая все «за-против» видимые только в конкретном случае.
Важно другое — вы говорите не об корневой проблеме монолитов, а о проблеме конкретной разработки, сделанной не по принципам чистой архитектуры.
Но да, монолиты в этом смысле расслабляют разработчика. Не лишают его возможности сделать грамотный SOLID — это вовсе не принципиальное свойство монолитов. А всего-то расслабляют, так как не обязательно делать все «по-правильному, с учетом дальнейших модификаций и расширений».
Так что виноваты не монолиты. А люди.
Но и примеров, когда микросервисы не помогут при серьезных переделках — можно придумать. Например, была у вас система, где микросервисы разговаривают через шифрованную сеть, внутри сети доступ не ограничен, снаружи не попасть. Все вроде зашибись.
Но пришли безопасники и сказали — что для multi-tenancy так нельзя. И будьте добры запилить теперь в каждом микросервисе функционал для аутентификации и авторизации и шифрования для каждого tenant независимо. И вы встряли опять таки с тем же объемом работы, что и был в вашем примере. И для микросервисов он будет даже побольше, чем для монолитов.
P.S.:
Имхо, хороший монолит можно распилить на части и превратить в микросервисы относительно легко. Ибо все входящие в него сервисы изолированы, взаимодействие между ними идет на уровне известных интерфейсов.
Собственно, человечество еще в прошлом веке придумало для этого инструменты, используемые для написания больших программ — всевозможные «private vs public» в помощь принципа SOLID/«чистой архитектуры». Как раз, чтобы не было соблазна лезть в другой модуль напрямую. Как раз чтобы на выходе не получить мешанину сильносвязанного кода. Это нужно не только для микросервисов. С таким кодом и в монолите сложно работать. Например, проблема тестирования части функционала.
P.P.S.:
Довольно подробно pro/contra микросервисов рассказано тут
habr.com/company/flant/blog/424531
Ребята как раз специализируются на обслуживание всевозможных систем, в том числе и микросервисных.
Далеко не всегда:
Красным — неоправдывающиеся ожидания.
В том числе и усложнение (а не упрощение) разработки.
За деталями — туда. У них довольно развернутая аргументация.
И — они как раз любят и вовсю используют Kubernetes, созданный как раз для микросервисной архитектуры.
Проблемы-то две различные, не путайте их:
1) Если ничего не делать, ничего не вкладывать — то ничего у вас своего и не будет, никакой индустрии. Некопеечные государственные заказы тут один из хороших источников в помощь становления индустрии. Далеко не каждый коммерческий заказ сравним с государственным по финансированию. Ну хотя бы потому, что не так много коммерческих структур имеют такое количество подразделений как ФНС и мало кому из коммерческих структур посему нужна такая разветвленная система в ПО.
2) Воровство/коррупция. Пункт первый для воровства разумеется, очень лакомая питательная среда, бульон. Ну и что же? Вообще ничего не делать раз «разворуют»? Может, все же, делать, но реализовывать и меры для борьбы с воровством.
Там не так написано.
Они уперлись в производительность монолита.
Но видели пути решения.
Однако, заодно им захотелось все переписать, ибо им было неудобно.
Нет никакой проблемы поменять кусок в монолите без отключения всей системы.
Серьезные системы обновляют хитрым образом. Например, blue-green deployment или gaceful restart.
Эти же технологии применяются что для монолитов, что для микросервисов.
Без использования blue-green deployment/graceful restart и пр. вы и с микросервисами не можете поменять произвольную часть системы без остановки обслуживания клиентов.
Некоторые части системы — да.
Некоторые — ключевые, нет. Отключение их равносильно отключению сервиса целиком.
Система только выглядит рабочей.
Формально — да. Если 90% микросервисов у вас работают — то система рабочая как бы на 90%?
Фактически нет. Не рабочая. Пример ниже.
Пример: Интернет магазин.
Если вы отключите подсистему, отвечающую за формирование списка товаров и навигацию по нему (каталог товаров, витрина) — ваш интернет магазин не функционирует.
И то, что у вас при это успешно работает 90% остального кода — уведомления пользователей, корзина с товаром, личный кабинет, платежная система — не имеет никакого значения.
Ваш сайт мертв пока, вы не восстановите каталог товара.
Да, возможно, в этот момент кто-то уже в корзине и просто оформляет покупку. Однако:
а) Одного покупателя дает только 1000 или даже 10 000 посетителей.
б) Покупателем он становится после длительного прохода по каталогу товаров, выбора товаров.
Так что вы обслуживаете 1 покупателя в корзине/личном кабинете и даете отлуп 10 000 или 100 000 потенциальным, что нужен каталог.
То же самое можно сказать об отключении корзины или механизма оформления покупок, платежной системы — без всего этого ваш интернет-магазин и не магазин вовсе.
Не обязательно.
Для отказоустойчивости и для горизонтального масштабирования монолит все равно нужно запускать в нескольких инстансах на разных серверах.
Ничем тут от микросервисов не отличается.
Если позволяет выбранная технология — будет у вас один инстанс обрабатывать и 10 000 потоков. Не позволяет — просто будете запуском дополнительных инстансов этот недостаток компенсировать.
И причина, по которой вы запускаете дополнительные инстансы — не важна.
Неважно что это будет необходимость утилизировать все ядра процессора, если выбранный инструмент этого не умеет (если использует только 1 ядро, а на сервере их 16 — в этом случае вы запустите 16 инстансов на одном сервере). Или неважно, что это будет необходимость обеспечить обработку достаточного числа потоков (если один инстанс обрабатывает 1 000, а вам нужно 100 000, то вы просто запустите 100 инстансов)
Важно другое — вам нужно обеспечить корректную совместную работу большого количества инстансов (например, используя: репликации, общие сервера очередей и пр.).
Это важно и для монолита и для микросервисной архитектуры.
Давайте рассмотрим чистый монолит (сам конвертирующий видео файлы, сам же обрабатывающий запросы от пользователей) на примере ситуации, описанной ppl2scripts в habr.com/post/427215/#comment_19272331
Ситуация с монолитом не отличается от ситуации с микросервисами.
Определимся с вашей политикой использования вычислительных ресурсов. Что для монолита, что для микросервисов это будет одно и то же:
Пусть, для простоты, автомасштабированием без лимитов — простой способ получить производительность, но дорогой метод (сервера денег стоят):
Но почему это произошло?
Если у меня год подряд было 1 000 в день, то вероятность того, что завтра будет 50 000 в день — крайне незначительна. А вероятность того, что будет миллион = 0.
Если такое случится, видимо, теперь мы мега-популярны и мега-посещаемы?
Так что следующий этап:
Инвесторы/владельцы будут только рады доплатить разработчикам за сверхсрочную работу, чтобы они вынесли операцию конвертации в отдельно запускаемый и отдельно масштабируемый модуль.
А пока разработчики оптимизируют систему инвесторы/владельцы будут рады заплатить дополнительные деньги за сервера, которые держат нагрузку по приведенной выше схеме с бэкендом-монолитом.
Платить за это заранее готов далеко не каждый.
А вдруг не будет не то что миллиона, а и 50 000 не будет никогда?
Сделать сразу «как у Фейсбука и Гугл» — это ж разница совсем не в 20% по стоимости работ. И по срокам тоже дольше.
А скорее всего для начала сгодится компромиссный вариант, описанный тут habr.com/post/427215/#comment_19276749
Монолиты гораздо эффективнее по производительности, чем микросервисы на огромном числе задач. При меньшей стоимости и большей скорости разработки.
Вот пример примитивнейшей ситуации:
habr.com/post/282299
«Кэш внутри приложения» vs «Кэш рядом, в соседнем отдельном процессе».
А ведь в микросервисах, все еще хуже. Там и сетевые задержки. И переходов между процессами/модулями/сервисами куда как больше. И дополнительных сериализаций/десериализаций полным-полно. И пр.
Надо смотреть по конкретной задаче.
Ну вот пример очень даже посещаемого проекта:
habr.com/company/oleg-bunin/blog/418235
Как они пишут производительность можно было решить и с монолитом. А ведь это один из самых посещаемых сайтов в РФ, входит в первую десятку rg.ru/2017/09/28/nazvany-samye-populiarnye-sajty-v-rossii.html
Если вы не Гугль, то, вполне возможно, гораздо оптимальнее для вас будет не микросервисы, а всего лишь 2-3-4 крупных сервиса. Главное, чтобы они были способны работать на множестве запущенных инстансов для горизонтального масштабирования.
А возможно оптимальнее будут именно микросервисы.
А возможно у вас такое финансирование, что вы можете на него и продукт свой сделать 5-ю способами, чтобы выбрать лучший, и два Kubernetes'а в придачу. Всяко бывает.
Надо смотреть по конкретной задаче.
Для определенности предположим, что вы делаете клон YouTube, но с посещаемостью на порядки меньше. Вам интересно как бы это выглядело на монолите?
Как бы сделал я:
0) Балансировщик на входе — fabio/Traefik/nginx.
Так как для надежности и горизонтального масштабирования — все это и в случае монолитной архитектуры должно уметь работать на нескольких серверах в нескольких инстансах.
Это что для монолита, что для микросервисов нужно.
1) БД для метаданных видеофайлов, профилей пользователей, сессий, комментариев.
Возможно, одна СУБД, если проект невысокой нагрузки.
Или несколько СУБД различной специализации, например, более часто запрашиваемые сущности такие как сессии — в Tarantol/Redis, комментарии в Mongo (тут пригодится ее умение масштабироваться сравнительно легко, ну а то, что платой за это является у Монги консистентность не строгая, а типа «когда-нибудь потом» — это не важно для комментариев).
Необходимость реляционной СУБД для такой простой задачи под вопросом. Ну, разве что, для строгой консистентности профилей пользователей, если, например, у вас платный доступ. Допустим, возьмем PostgreSQL.
Все экземпляры всех видов СУБД — разумеется реплицируются.
Выделение Tarantool/Mongo/PostgreSQL позволит сделать удобную репликацию master-master для Tarantool/Mongo (Тарантул точно умеет, Монго, надеюсь, не помню точно). Это снимет нагрузку с PostgreSQL, так как он заметно хуже работает на большом количестве экземпляров (а тем более по сети) и позволит обойтись для PostgreSQL более мягким master-slave.
Что для микросервисов, что для монолита — эти СУБД будут.
2) Бэкенд. Вполне себе монолит. Большой и единый.
3) Фронтенд.
Это не монолит и не микросервис. Он запускается все равно не на наших серверах, а у пользователей. С точки зрения сервера — это небольшие статические файлы, раздать их не проблема.
4) Модуль конвертации. Маленькая узкоспециализированная утилита. Даже какой нибудь ffmpeg годится.
С небольшой специально написанной обвязкой, например, подписанной на очередь и запускающий ffmpeg.
Или вообще без обвязки специальной — тот же Nomad из Hashicorp вполне годится, имхо. Его же можно для deploy новых версий бекенда использовать. Его же можно использовать для запуска ffmpeg
Что для монолита, что для микросервисов — все тот же ffmpeg и все та же обвязка.
5) Сервер очередей. Для более гибкого управления множеством инстансов.
Чтобы не лазать в БД на каждый чих, чтобы все экземпляры бэкенда и все экземпляры конвертера были просто подписаны на события.
Это нужно и для монолита и для микросервисной архитектуры.
6) cloud storage работающее по протоколу S3 или OpenStack Swift
Это нужно и для монолита и для микросервисной архитектуры.
7) Кэш. Поскольку у нас есть очередь с подписками и мы сможем легко инвалидировать кэш — то годится и локальный для каждого бэкенда кэш или даже кэш, встроенный в бэкенд (это будет очень быстро).
Инвалидировать локальный внешний кэш можно из бэкенда-монолита, внешняя обвязка для этого не нужна. Все равно кроме бэкенда-монолита в него никто лазать не будет.
Для микросервисов такой вариант тоже имеет смысл — в терминах Kubernetes кэш будет размещен в одном поде с использующими его микросервисами.
Впрочем, не локальный, а общий для всех экземпляров монолита/микросервиса кэш тоже имеет право на жизнь. Но это будет медленнее, чем локальный. Нужно по профилю нагрузки и по имеющейся оперативной памяти на серверах смотреть что выбрать — локальный или общий.
— Имеем множество экземпляров бэкенда-монолита и множество экземпляров конвертера.
Опционально добавляем:
8) Если бюджет позволяет более серьезно относится к диагностике — централизация сбора логов и метрик. Логи нужны всем. Метрики микросервисам важнее.
9) Если нагрузка по закачке на наш сервис новых файлов более серьезна то выделить из монолита один компонент, занимающийся загрузкой файлов. Разумеется, тоже несколько экземпляров.
Для многопоточных бэкендов Erlang или Go (golang) нет необходимости выделять этот компонент сразу. Для NodeJS с ее однопоточностью — принципиально выделить сразу, даже при небольшой нагрузке на upload новых файлов.
Итого имеем балансировщик, СУБД и MQ-сервер и cloud storage и кэш — обязательные как для монолитной так и для микросервисной архитектуры.
Варианты с монолитом:
1) Монолит бэкенда + конвертер.
2) Монолит бэкенда + конвертер + модуль upload
С сохранением все того же масштабирования при нагрузке, что и у микросервисов, причем можно масштабировать отдельно нагрузку и на инстансы бэкенда-монолита и на инстансы конвертера и на инстансы загрузчика.
Конечно модуля upload и конвертер — легковесны и обладают частью признаков микросервисности, но все решение — однако все решение в целом все же не является микросервисной архитектурой, имхо. Максимум — просто сервисной. Без «микро-».
В микросервисной архитектуре, имхо, компонент десятки и сотни и обязательно нужен дополнительный инструментарий для поддержки этого роя микросервисов.
Впрочем, учитывая особо выделяющийся по объемности функционал компонента бэкенда-монолита — все же, полагаю, что это монолитная архитектура. С использованием отдельных помощников бэкенду — MQ, cache, конвертер.
Ссылки на законы готовы привести?
Как получить доступ к СОРМ-2?
Это да, но ведь все предыдущие знания не на этой одной клавиатуре без Home получены? Были же и другие клавиатуры
<… пожимая плечами… > А в чем проблема у Яндекса создать под новостной агрегатор юр. лицо в РФ? Бухгалтера/юристы Яндекса настолько перегружены работой?
Ну то есть проблемой вы считаете не создать бизнес?
Создать, обойдя конкурентов, предложив покупателям нужные услуги/товары, создав в глазах покупателей репутацию, решив кучу проблем попутно как сводить концы с концами в плохой месяц и пр.
Но нет, вовсе не поэтому, что нужно напрягаться, у некого мечтателя/ленивца нет хорошего бизнеса? (плюс неудачи могут быть, но это уже объективная причина, единственная объективная, кстати)
Зато он сразу может показать кто в этом виноват?
P.S.:
А у тех, у кого получилось — у тех, как? Живут на этой территории, бизнес на этой территории, но государство другое?
А разве это не вы написали сегодня?
habr.com/post/427305/#comment_19269147
Это вы логично заметили:
Разработчики создали, предположим пусть что и говнокод, но виноваты в этом не они. Они просто получают зарплату и морально мучаются тем, с чем работают?
Разве не USM Holdings владеет самой Mail.Ru Group?
Так что какая разница.
Почему только у Запада? Кого я знаю — оборудование из Китая везут.
Глобализация-с.
И даже крутейшие США тоже не способны жить без импорта.
В те годы с моделями заработка в интернете было все плохо.
Скажем, на заре того же Яндекса было только ощущение, что вот-вот пойдут большие деньги. Но еще никто не знал как их добыть. Но Яндекс уже пилили.
А потом появилась контекстная реклама. Но altavista уже пролетала как фанера над Парижем.
Да, да — все правильно.
В те годы еще люди толком не знали как заработать в интернете (кроме продаж и инвестиций — это то было очевидно).
То есть стараться сделать свою жизнь лучше не стоит, потому что все равно все отберут? Я вас правильно понял?
У вас те, кто выжил — те и правы?
Ну тогда нынешнее государство идеальнее предыдущего. Чего ж жалуетесь на него?
Это понятно.
Но почему опять виновато государство?
Почему не ты? Ты же уже вырос, не ребенок уже?
Кто за тебя сделает?
Ну смотря как трактовать.
Это показывает, что частный капитал мало способен на стратегические вещи.
И?
Все госуправление должны быть идеальным?
Глобально-то государственное управление показало, что это возможно.
Ваш компьютер, с большой вероятностью, питается от электростанции, созданной государством. И электричество у нас не самое дорогое в мире. А скорее дешевое (пусть и не самое дешевое).