На вебсайте картинка, где парень читает на [фоне] проезжей части, резанула глаз: на западе обычно такие картинки используются в социальной рекламе с тем, чтобы люди так не делали, и чтобы их не сбила машина.
Тема оптимизации слишком велика для одной статьи, поэтому у автора получилось по верхам.
Добавлю что:
— Кроме памяти, на сервере могут кончиться другие ресурсы, например таблицы процессов, дескрипторов и TCP-соединений, что так же может вызвать ошибку 500
— Команда top не показывает очередь IO сети или дисков. А как показывает практика, IO гораздо чаще вызывает затыки, нежели например CPU. К тому же top не дает полной картины на VM.
— Nginx хорош не только для статики: если его использовать в качестве reverse proxy перед апачем, это позволит апачу заниматься тем, что он умеет лучше всего — быстро выполнять короткие запросы в больших количествах.
— Если добавить поле IS_READ в индекс в примере, то нужно быть готовым к тому, что операция UPDATE, которая апдейтит это поле, будет выполнятся существенно медленнее (примерно в 10 раз в случае MySQL). Вообще тема оптимизаций SQL заслуживает нескольких статей.
Приходилось сталкиваться с таким подходом в одной системе учета персонала. Столкнулись с тем, что при проектировании более-менее сложного отчета результирующий запрос легко выходил на сотни таблиц, так как каждое VIEW с правами было продуктом основной таблицы + нескольких таблиц с правами и группами. В результате оракл загибался, хотя таблицы были не особо большие.
Для отчетов пришлось в итоге отказаться от VIEW, и заменить на обычные таблицы.
Два профессионала не сошлись в естимэйте. Это само по себе не редкость, и случается сплошь и рядом. Но ваш вывод «избегайте евреев» не характеризует вас как профессионала, а в данном конкретном случае скорее наоборот.
Вообще же профессионала, помимо глубоких технических знаний, отличают отсутствие эмоций по поводу легаси кода, устаревшего стека, наличия/отсутствия процессов/тестов/бизнес аналитиков/тестировщиков/документации. Профессионал работает с тем что есть, объясняет клиенту имеющиеся недостатки и проблемы в понятных клиенту терминах, и знает, где у него оканчивается компетенция.
Поэтому соглашусь, что 6 лет это немного. Для мемуаров точно маловато.
У нас в компании есть таки пример идеального микросервиса — конвертор XML в PDF: никаких зависимостей или связей. Многие приложения его успешно используют чтобы отрендерить печатную версию произвольной страницы.
Все остальные более или менее связаны: сервис учета покупок не может без сервиса покупателей, склад не может без покупок и покупателей, учет гарантийного обслуживания не может без всего перечисленного, и т.п.
Ну хорошо, на компоненты побили, все в разных базах, масштабируемо и т.п. Красота. Потом бизнес начинает требовать отчеты, в которых эти все данные надо опять соединить. И тогда надо либо внедрять Data Warehouse, либо самим писать интерфейсы для передачи данных в общую базу, либо писать отчеты, которые смогут тянуть и Join-ить данные из разных БД без лишних тормозов. И то, и другое, и третье дорого, как в плане разработки, так и особенно поддержки.
Поэтому общая цена может оказаться сильно выше.
Проблема в том, что система у нас очень большая, с кучей взаимосвязанных компомнентов, одним словом, сложная.
Микросервисная архитектура позволяет уменьшить сложность конкретных микро-приложений, но при этом возрастает сложность на уровне интерфрейсов между приложениями, так что общая сложность системы в целом не изменяется.
Этот перенос сложности с одного уровня на другой имеет как плюсы (упрощение конкретных приложений-микросервисов), так и минусы (из спойлера).
Поэтому для каждого конкретного компонента надо смотреть отдельно, как лучше его реализовать. А микросервис — это лишь один из инструментов, который может где-то в чем-то помочь.
При переходе на микросервисы надо учитывать общую стоимость владения, а не только затраты на разработку. Разработка микросервисного приложения и правда может оказаться дешевле. Но жизнь продукта разработкой не заканчивается, далее следует саппорт, затраты на который обычно в разы превышают затраты на разработку. По разным оценкам стоимость разработки составляет примерно 10-20%, в то время как саппорт — 60-80% в общих затратах в течение периода эксплуатации.
Так вот в случае микросервисной архитектуры затраты на саппорт минимум удваиваются.
Процитирую свой коммент к другой статье, почему это происходит
В моей компании тоже все на микросервисах, только счастья это не приносит:
если ищу причину какого-то бага, то в большинстве случаев где-то по ходу анализа исходника приложения натыкаешься на вызов очередного endpoint-а, приходится скачивать его исходники тоже, а там опять endpoint куда-то еще, и т.д. О локальном дебаге речь вообще даже не поднимается, так как слишком много приложений-микросервисов придется локально конфигурировать. В итоге баги ищутся, в основном, путем смотрения на код.
микросервисы, как правильно заметил автор, зачастую написаны на разных версиях разных языков, что делает локальный дебаг трудным или невозможным
особенно странно видеть, как зоопарк микросервисов на разных версиях разных языков оперирует с одними и теми же логическими связанными данными. Я, конечно, понимаю, что хотели делать масштабируемо, но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных, от чего БД становятся узким местом. Но отмасштабировать БД, как правило, намного труднее.
иногда базы данных пытаются сделать масштабируемыми путем разбиения на логически независимые базы. Микросервисы тогда зависимы только от своей БД, и чувствуют себя отлично, но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.
при необходимости внесения изменений в микросервис в большой компании зачастую представляет проблему выявить и, тем более, протестировать, все приложения-юзеры, его использующие. Поэтому часто всместо внесения изменений в существующий микросервис, просто создается очередной модифицированный клон, который делает почти то же самое. В итоге подход, призванный снизить избыточность кода, дает ровно обратный эффект.
микросервисы, когда вызывают другие микросервисы по HTTP, работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса, что часто приводит к необходимости все переделывать без микросервисов
если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.
В общем идея микросервисов красиво выглядит на презентациях и в книжках. В реальной жизни лучше сто раз подумать, а надо ли.
В общем это не факт, что на микросервисах удасться сэкономить.
Видимо это уже стало фольклором, так как каждый рассказывающий выдает это за произошедшее в их компании, но по вине коллеги, естественно.
Ну или случалось повсеместно.
Каждая компания сама решает, как ей быть с безопасностью, какие меры принимать, а какие нет. Исключения составляют случаи, когда меры безопасности диктуются законодательно, например при работе с персональными данными, госсекретами, или если речь идет о финансовых системах компаний, акции которых торгуются публично. В этих случаях есть четкие требования, которые надо выполнять, и для этого там и сидят безопасники. Возможно, вам стоит именно к таким компаниям присматриваться для продолжения карьеры. Остальным это зачастую не нужно.
Какое-то время назад работал с Коболом — отличный язык для банков, биллинга и т.п. Легко пишется и читается, так что даже непрограммисту понятно что происходит в коде. Javascript-у у Кобола стоило бы поучиться в этом плане. Хотя засады тоже есть конечно (типа случая с забытой точкой в конце оператора IF, стоившей некой страховой компании миллиардов долларов, согласно легенде). Но куда ж без этого.
Сталкивался и как гражданин, и как свидетель, и внутри такой машины работал. И приходилось от нее защищаться тоже. Поэтому и говорю, что у системы есть определенная логика, и ее можно заставить защищать свои интересы. К сожалению, большинство предпочитают или махнуть на все рукой и обидеться, или учиняют разборки с подневольными исполнителями. Но всегда есть точка где-то выше в иерархии, через которую можно воздействовать, весь вопрос в том, чтобы ее правильно определить и правильно воздействовать.
Мне вот инетересно почему этот правовой дебилизм никто не использует в своих целях. Так как конкретно по этому закону пока не ясно, какие формы он примет, рассмотрю другой пример — о запрете ввоза нелициензированных шифровальных средств.
Все знают, что любой компьютер или смартфон имеет шифровальные функции.
Все знают, что либо комп, либо смартфон имеется практически у каждого, пересекающего границу.
Налицо неисполнение закона таможенными органами. Почему бы какой-нибудь адвокатской конторе не использовать эту возможность засудить государство? Для конторы это возможность бесплатного пиара на федеральном уровне. Для государсва — обратная связь (а то может они не в курсе). Для людей — менее дебильные законы.
Все что для этого надо — при вьезде в РФ задекларировать свой телефон, а после пересечения границы написать жалобу в прокуратуру (чтобы там не забыли проставить входящий номер) о систематическом неисполнении закона, чтобы бюрократическая машина его не потеряла.
Бюрократической машине пофиг на граждан, но ей точно так же пофиг и на служащих, если те нарушают/неисполняют закон. Этим и нужно воспользоваться.
Мы уверены, что из-за давления властей, которым окружен новый закон, некоторых из наших российских серверов недавно были захвачены российскими властями, без каких-либо предупреждений и надлежащих процедур
Что-то я вот это не понял… Они точно не знают, но им кажется? Провайдер, похоже, просто попиариться решил.
Язык пятого поколения: программист должен думать об алгоритмах, а не о языке.
Вроде не так: юзер должен задекларировать условия/ограничения, а язык все сделает типа сам (https://en.wikipedia.org/wiki/Fifth-generation_programming_language).
А что за IDE на видео?
С++ имеет смысл использовать только если доказано, что приложение значительное время проводит вычисляя что-то процессором. Если команда top не показывает, что ваш процесс сервера приложений забирает хотя бы 10-20% процессорного времени, то значит ваш процесс большей частью что-то ждет, и смысла в С++ нет. Скорее всего минимизация количества компонентов (и TCP-коммуникаций между ними) и дала весь прирост скорости.
В лихие 90-е нас, только вчерашних студентов, командировали из нашей региональной налоговки в Москву получать Novell Netware на все наши районные налоговки. Отказаться в голову не пришло. Веселье было, когда нас сгрузили с кубометром нетвари на казанском вокзале: ярко-красные, иностранные, явно фирменные коробки как мёд манили воров и жуликов со всего вокзала, так что наша начальница устала от них от всех своей ксивой отмахиваться. Когда уже в купе загрузились, челнок из соседнего купе на правах соседа заговорщицки нас пытался расколоть: «Парни, где мыло брали?, Мда, были времена…
Добавлю что:
— Кроме памяти, на сервере могут кончиться другие ресурсы, например таблицы процессов, дескрипторов и TCP-соединений, что так же может вызвать ошибку 500
— Команда top не показывает очередь IO сети или дисков. А как показывает практика, IO гораздо чаще вызывает затыки, нежели например CPU. К тому же top не дает полной картины на VM.
— Nginx хорош не только для статики: если его использовать в качестве reverse proxy перед апачем, это позволит апачу заниматься тем, что он умеет лучше всего — быстро выполнять короткие запросы в больших количествах.
— Если добавить поле IS_READ в индекс в примере, то нужно быть готовым к тому, что операция UPDATE, которая апдейтит это поле, будет выполнятся существенно медленнее (примерно в 10 раз в случае MySQL). Вообще тема оптимизаций SQL заслуживает нескольких статей.
— Масштабирование — отдельную книгу можно писать.
Для отчетов пришлось в итоге отказаться от VIEW, и заменить на обычные таблицы.
Вообще же профессионала, помимо глубоких технических знаний, отличают отсутствие эмоций по поводу легаси кода, устаревшего стека, наличия/отсутствия процессов/тестов/бизнес аналитиков/тестировщиков/документации. Профессионал работает с тем что есть, объясняет клиенту имеющиеся недостатки и проблемы в понятных клиенту терминах, и знает, где у него оканчивается компетенция.
Поэтому соглашусь, что 6 лет это немного. Для мемуаров точно маловато.
Все остальные более или менее связаны: сервис учета покупок не может без сервиса покупателей, склад не может без покупок и покупателей, учет гарантийного обслуживания не может без всего перечисленного, и т.п.
Ну хорошо, на компоненты побили, все в разных базах, масштабируемо и т.п. Красота. Потом бизнес начинает требовать отчеты, в которых эти все данные надо опять соединить. И тогда надо либо внедрять Data Warehouse, либо самим писать интерфейсы для передачи данных в общую базу, либо писать отчеты, которые смогут тянуть и Join-ить данные из разных БД без лишних тормозов. И то, и другое, и третье дорого, как в плане разработки, так и особенно поддержки.
Поэтому общая цена может оказаться сильно выше.
Микросервисная архитектура позволяет уменьшить сложность конкретных микро-приложений, но при этом возрастает сложность на уровне интерфрейсов между приложениями, так что общая сложность системы в целом не изменяется.
Этот перенос сложности с одного уровня на другой имеет как плюсы (упрощение конкретных приложений-микросервисов), так и минусы (из спойлера).
Поэтому для каждого конкретного компонента надо смотреть отдельно, как лучше его реализовать. А микросервис — это лишь один из инструментов, который может где-то в чем-то помочь.
Так вот в случае микросервисной архитектуры затраты на саппорт минимум удваиваются.
В общем идея микросервисов красиво выглядит на презентациях и в книжках. В реальной жизни лучше сто раз подумать, а надо ли.
В общем это не факт, что на микросервисах удасться сэкономить.
Поздравляю с открытием мира ITIL и одной из его практик — segregation of duties.
Ну или случалось повсеместно.
Но в остальном как-то маловато для статьи на Хабре.
Все знают, что любой компьютер или смартфон имеет шифровальные функции.
Все знают, что либо комп, либо смартфон имеется практически у каждого, пересекающего границу.
Налицо неисполнение закона таможенными органами. Почему бы какой-нибудь адвокатской конторе не использовать эту возможность засудить государство? Для конторы это возможность бесплатного пиара на федеральном уровне. Для государсва — обратная связь (а то может они не в курсе). Для людей — менее дебильные законы.
Все что для этого надо — при вьезде в РФ задекларировать свой телефон, а после пересечения границы написать жалобу в прокуратуру (чтобы там не забыли проставить входящий номер) о систематическом неисполнении закона, чтобы бюрократическая машина его не потеряла.
Бюрократической машине пофиг на граждан, но ей точно так же пофиг и на служащих, если те нарушают/неисполняют закон. Этим и нужно воспользоваться.
Вроде не так: юзер должен задекларировать условия/ограничения, а язык все сделает типа сам (https://en.wikipedia.org/wiki/Fifth-generation_programming_language).
А что за IDE на видео?