Уничтожит ли Project Loom будущее Java?
Еще один замечательный пост Адама Варски, в котором обсуждаются компромиссы различных моделей параллельного программирования: фьючерсы, зеленые потоки, сопрограммы, ввод-вывод монада, актеры.
Варски проводит аналогию с RPC, чтобы продемонстрировать, что шаблонность асинхронных вызовов (которые проект Loom стремится устранить) не обязательно является плохой вещью:
RPC и любые сетевые вызовы в целом имеют существенно иные характеристики, чем обычный вызов функции. Они непредсказуемы: могут произвольно выйти из строя , независимо от значения входных параметров. Для их завершения может потребоваться произвольное количество времени , в то время как обычная функция завершается, выходит из строя или зацикливается. И даже если сетевой вызов кажется неудачным , он все равно мог бы быть успешным с точки зрения другой системы. […] Тот факт, что обычный вызов функции также синтаксически отличается от вызова RPC, может быть преимуществом для удобства чтения.
Мартин Томпсон дает представление о том, почему волокна ткацкого станка волшебным образом не решат все проблемы с производительностью в наших параллельных приложениях:
Варски предлагает убедительную стратегию выбора модели параллелизма для этой задачи:
При выполнении простого сервиса , небольшого приложения или быстрого скрипта я не хочу иметь дело с какими-либо оболочками, будь то Будущее или ВВОД-вывод . Волокна и их модель “коды, подобные синхронизации, работают как асинхронные”, сделают мою жизнь намного проще.
При написании бизнес-приложения я мог бы захотеть использовать синхронный API, который работает с Волокном s позволяют выразить бизнес-логику, используя хорошо известные конструкции для выражения потока управления в рамках бизнес-процесса. Однако для организации одновременно выполняемых вычислений, обработки ошибок и распределения ресурсов я буду использовать абстракцию, подобную IO .
Наконец, для высокопроизводительной асинхронной системы я, вероятно, воспользуюсь полностью асинхронным подходом, работая с конечными машинами, обратными вызовами или Будущими s.
Я хочу противопоставить приведенное выше рассуждение цитате из этого сообщения в блоге Брэда Фитцпатрика:
Среда выполнения Go относительно сложна внутренне, но она позволяет использовать простые API-интерфейсы и модели программирования для пользователей, которым затем не нужно беспокоиться об управлении памятью, управлении потоками, блокировке, цвете их функций и т. Д.
Действительно, не имея фьючерсов, Go избегает большой сложности, с которой мы сталкиваемся при параллелизме в Java .
Предотвращение отказов в распределенных системах
Джейкоб Габриельсон делится многими неинтуитивными наблюдениями и действенными тактиками повышения надежности.
В Amazon мы избегаем отказов в наших системах, потому что это трудно доказать, а его эффективность трудно проверить. Резервные стратегии вводят рабочий режим, в который система переходит только в самые хаотичные моменты, когда что-то начинает ломаться, и переключение в этот режим только увеличивает хаос.
Предварительно распределить:
Для критически важных приложений на одной машине, которые должны работать в случае сбоев выделения памяти, одним из решений является предварительное выделение всей памяти кучи при запуске и никогда больше не полагаться на malloc, даже в условиях ошибок.
В ” Режимы сбоя и непрерывная устойчивость ” Адриан Кокрофт упоминает аналогичную идею в контексте перехода на другую зону доступности: в критический момент служба плоскости управления также может выйти из строя (или, похоже, не работает из-за проблем в коде или конфигурации, что не было замечено ранее, потому что это обычно не выполняется), поэтому экземпляры/базы данных/сети могут быть предварительно выделены во вторичном регионе в режиме холодного ожидания.
Замените “тянуть” на “толкать”:
Службе IAM необходимо предоставить подписанные, измененные учетные данные для кода, работающего в экземплярах EC2. Чтобы избежать необходимости когда-либо отступать, учетные данные предварительно передаются в каждый экземпляр и остаются действительными в течение многих часов. Это означает, что запросы, связанные с ролью IAM, продолжают работать в маловероятном случае сбоя в механизме отправки.
Преобразуйте откат в отказоустойчивость, которая соответствует шаблону постоянная работа :
Служба должна непрерывно выполнять как резервную, так и не-резервную логику. Он должен не просто запускать запасной вариант, но и рассматривать его как одинаково достоверный источник данных. Например, служба может случайным образом выбирать между резервными и неаварийными ответами (когда она возвращает оба ответа), чтобы убедиться, что они оба работают.
Вы уже отслеживаете повторные попытки в своей системе?
Мы поддерживаем показатели, которые отслеживают общую частоту повторных попыток, и сигналы тревоги, которые предупреждают наши команды о частых повторных попытках.
С чего начать
Кив Макминн о том, как начать новый проект: поговорите с людьми. Клиенты, коллеги, коллеги по отрасли.
Отличный вопрос, который я узнал совсем недавно, когда сидел с коллегой, проводившим собеседование с клиентом, был “Какой вопрос вы хотели бы, чтобы я вам задал?”.
Мой опыт научил меня, что если вы хотите создать правильную вещь, которая окажет богатое и длительное воздействие, эта отправная точка поиска людей, общения с ними и обучения у них имеет основополагающее значение. Для меня это предвестник того, что технические исследования и эксперименты действительно могут начаться.
Что делает инженеров продуктивными?
Из комментария HN Джонатана Тана:
Джефф и Санджай имеют репутацию рок-звезд, потому что они могут применить эту производительность к вещам, которые действительно важны; они способны выделить действительно важные части проблемы, а затем сосредоточить свои усилия на этом, чтобы конечный результат оказался гораздо более эффективным, чем то, что написал SWE3. SWE3 может потратить свое время на написание кучи модульных тестов, которые выявляют ошибки, которых на самом деле все равно бы не произошло, или на переход с одной системы на другую, что на самом деле не является значительным улучшением, или на то, чтобы зайти в архитектурный тупик, который просто придется переписать позже.
Джефф или Санджай потратят свое время на запуск предлагаемого клиентами API, чтобы убедиться, что он соответствует их потребностям, или на измерение производительности подсистем, чтобы они полностью понимали свои строительные блоки, или на мысленное моделирование работы системы перед ее созданием, чтобы они быстро протестировали альтернативы. На самом деле они пишут не больше кода, чем младший разработчик (часто они пишут меньше), но код, который они пишут, дает им больше информации, что позволяет им убедиться, что они пишут правильный код.
…эти разработчики быстро становятся разработчиками 1x (или хуже), если вы не позволяете им самим выбирать архитектуру – причина, по которой они превосходны в первую очередь, заключается в том, что они знают, как определить, будет ли определенная работа бесполезной и избегайте ее в первую очередь.
Как создать PaaS для 1500 инженеров
Гало Наварро подчеркивает самый важный вопрос, который должна задать себе каждая команда по инфраструктуре платформы:
Команде платформы действительно следует избегать конкуренции с AWS, Google или любой другой коммерческой компанией . Не имеет значения, превосходит ли их доморощенная система CI сегодня $commercial_ci_system . Рынок наверстает упущенное быстрее, чем ожидалось, и сделает эту команду ненужной. Каждая команда платформы должна спросить себя: в чем наше отличие? Что мы предлагаем, чем выгодно нашей компании инвестировать в наша команда, вместо того, чтобы бросать этих инженеров на продукт?
Главная ценность, которую мы предоставляем, заключается в соединениях, сочленении, склеивании. В том, как мы объединяем все эти системы. […] Мы фокусируемся на том, что является специфичным для нашей компании, адаптируя готовые решения к нашим потребностям.
Как я научился программировать
Дэн Луку о преимуществах предварительной фазы проектирования проекта с этапами изобретения и внедрения, более сложными, чем этап открытия (см. Фазы Грейди Буча ):
Совместная работа над дизайном учит всех членов команды всем остальным трюкам. Это очень похоже на передачу навыков, которую вы получаете при парном программировании, но применяется к дизайну.
Скорость итерации намного выше на этапе проектирования, когда выбрасывание дизайна просто означает удаление доски. Как только вы начнете кодировать, повторение дизайна может означать отказ от кода; для инфраструктурных проектов это может легко занять человеко-годы или даже десятки человеко-лет работы. […] Я видел команды по проектам аналогичного масштаба, которые настаивают на том, чтобы как можно скорее получить “рабочий” код. В каждом отдельном случае это приводило к огромным задержкам, так как приходилось переписывать огромные куски кода , а в некоторых случаях проект был в корне испорчен таким образом, что команде приходилось начинать все с нуля.
Я понимаю, что в продуктовых проектах, где вы не можете сказать, какую отдачу вы получите от чего-то, вы можете захотеть получить MVP за дверью и повторить, но для чистой инфраструктуры часто можно предсказать, насколько полезным что-то будет на этапе проектирования.
Он также подтверждает важность проектной документации, которая соответствует практике Uber , которой поделился Гергели Орош:
Я заметил удивительно сильную корреляцию между качеством начальной проектной документации и успехом проектов.
Вы можете подписаться на новые инженерные идеи через RSS (например, используя Feedly ) или по электронной почте .
Оригинал: “https://dev.to/leventov/engineering-ideas-6-4oa6”