2. «Советы по проектированию компьютерных систем» (Hints for Computer System Design).
Батлер Лэмпсон (3) является лауреатом премии ACM Turing Award (среди прочих наград) и работал в Xerox PARC. В этой отличной статье кратко излагаются многие из его идей, касающихся проектирования систем.
По его словам, изучение конструкции и ввода в работу ряда компьютеров привело к созданию некоторых общих советов по проектированию системы. Они описаны здесь и проиллюстрированы множеством примеров, начиная от аппаратных средств, таких как Alto и Dorado, и заканчивая прикладными программами, например Bravo и Star.
В статье говорится, что автор не ставит своей целью открыть какие-либо новые горизонты, но все же – это феноменальный обзор.
3. «Большой ком грязи» (Big Ball of Mud).
В качестве реакции на многочисленные публикации о грандиозных шаблонах проектирования в этой статье наиболее часто встречающийся архитектурный шаблон назван «Большим комом грязи». Автор исследует, почему первоначально элегантные и лаконичные проекты редко остаются в первозданном состоянии, при переходе системы от концепции к эксплуатации.
Выдержка из аннотации:
В то время как большое внимание было сосредоточено на высокоуровневых шаблонах архитектуры программного обеспечения, редко обсуждается то, что фактически является стандартной архитектурой программного обеспечения де-факто. В этой статье рассматривается наиболее часто применяемая архитектура программного обеспечения: БОЛЬШОЙ КОМ ГРЯЗИ. Это случайно, даже небрежно структурированная система. Ее организация. Если ее можно так назвать, продиктована скорее соображениями выгоды, чем проектным решением. Тем не менее, то, что она так популярна, все равно не значит, что надо пренебрегать архитектурой.
Хотя юмор, безусловно, наполняет эту статью, также верно и то, что программные решения в области программного обеспечения на удивление плохи. Очень немногие системы проходят стадию проектирования, и лишь некоторые из них напоминают первоначальный проект (а документация редко обновляется с учетом последующих решений), что делает этот вопрос важным для рассмотрения.
4. «Файловая система Google» (The Google File System).
Выдержка из аннотации:
Файловая система успешно удовлетворяет наши потребности в хранении данных. Она широко используется в Google в качестве платформы хранения для генерации и обработки данных, используемых нашим сервисом, а также для исследований и разработок, требующих больших наборов данных. Крупнейший на сегодняшний день кластер предоставляет хранилище в сотни терабайт на тысячах дисков на более чем тысяче компьютеров, и к нему одновременно обращаются сотни клиентов.
В этой статье мы представляем расширения интерфейса файловой системы, предназначенные для поддержки распределенных приложений, обсуждаем многие аспекты нашего проектного решения и сообщаем об измерениях, полученных как в результате микротестов, так и реального использования. Google сделала нечто довольно выдающееся в определении технических тем в Кремниевой долине и, по крайней мере, по мнению некоторых людей, во всей технологической индустрии. Компания занимается этим уже более десяти лет, и только недавно к ней присоединились в меньшей степени Facebook и Twitter, поскольку достигли значительных масштабов. Google определила эти темы в основном с помощью заслуживающих внимания технических документов.
Статья о файловой системе Google (англ. Google File System, GFS) является одним из первых элементов этой стратегии, а также примечательна как документ, который в значительной степени вдохновил файловую систему Hadoop (англ. Hadoop File System, HFS).
5. «О разработке и развертывании сервисов, организованных на основе глобальной компьютерной сети» (On Designing and Deploying Internet-Scale Services).
Мы не всегда помним о том, что Microsoft является одним из крупнейших игроков в области интернет-технологий – хотя Azure все чаще делает это сравнение очевидным и непосредственным – и, конечно, это название не обязательно приходило на ум в 2007 году. В своей превосходной статье Джеймс Гамильтон дает советы по созданию работоспособных систем в чрезвычайно больших масштабах. Он ясно показывает, что отказ рассматривать Microsoft в качестве крупного интернет-игрока был нашей общей ошибкой.
Выдержка из аннотации:
Соотношение между системой и администратором обычно используется в качестве приблизительного показателя для понимания административных затрат в крупномасштабных службах. Для небольших и менее автоматизированных сервисов это соотношение может составлять всего 2:1, в то время как для ведущих в отрасли высокоавтоматизированных сервисов мы наблюдали соотношение до 2500:1. В службах Microsoft Autopilot [1] часто упоминается как волшебная сила, стоящая за успехом команды Windows Live Search в достижении высокого соотношения между системой и администратором. Хотя автоматическое администрирование существенно, наиболее важным фактором является сам сервис. Эффективен ли он для автоматизации? Является ли он тем, что мы в общем смысле называем удобным в эксплуатации? Такие службы требуют незначительного вмешательства человека. Они обнаруживают и устраняют все, кроме самых малозаметных сбоев, без административного вмешательства. В этой статье обобщены лучшие практики, накопленные за многие годы работы в области масштабирования некоторых из крупнейших сервисов MSN и Windows Live.
Это настоящий контрольный список того, как проектировать и оценивать крупномасштабные системы (почти так же, как «12-факторное приложение» (4) хочет служить контрольным списком для работоспособных приложений).
6. «CAP двенадцать лет спустя: Как изменились “правила”» (CAP Twelve Years Later: How the ‘Rules’ Have Changed).
Эрик Брюер выдвинул теорему CAP (5) в начале 1990-х годов, а 12 лет спустя написал эту превосходную статью-обзор CAP, в которой утверждается, что распределенные системы должны выбирать между доступностью или согласованностью при разделении. Вот подоплека статьи, по словам Брюера:
За десятилетие, прошедшее с момента ее появления, разработчики и исследователи использовали теорему CAP (а иногда и злоупотребляли ей) в качестве причины для изучения широкого спектра новых распределенных систем. Переход на NoSQL также заставил применять ее в качестве аргумента против традиционных баз данных.
CAP интересна тем, что не существует оригинальной статьи о CAP, но эта статья хорошо подходит на данную роль. Эти идеи подробно изложены в статье «Урожай и урожайность»(6).
7. «Урожай, урожайность и масштабируемые толерантные системы» (Harvest, Yield, and Scalable Tolerant Systems).
Эта статья основана на концепциях «CAP двенадцать лет спустя», вводя понятия урожая и урожайности, чтобы добавить больше нюансов в дискуссию о соотношении процессором приложения и основным процессором.
Затраты на согласование непротиворечивости и управления состоянием с высокой доступностью значительно возрастают из-за беспрецедентных требований к масштабированию и надежности современных интернет-приложений. Мы предлагаем две стратегии повышения общей доступности с использованием простых механизмов, масштабируемых для больших приложений, чье поведение на выходе допускает постепенное ухудшение. Мы характеризуем это ухудшение с точки зрения урожайности и производительности и сопоставляем его непосредственно с инженерными механизмами, которые повышают доступность за счет улучшения изоляции сбоев, а в некоторых случаях также упрощают программирование. Собирая примеры соответствующих методов в статьях и иллюстрируя удивительный диапазон применений, которые могут улучшиться благодаря этим подходам, мы надеемся стимулировать более широкую исследовательскую программу в этой области.
Концепции урожая и урожайности особенно интересны, потому что обе самоочевидны и очень редко используются явно. Вместо этого распределенные системы продолжают сбоить в основном неопределенными способами. Надеюсь, продолжая перечитывать эту статью, мы также начнем внедрять ее конструктивные решения в системы, которые впоследствии создадим!
8. «Map Reduce: Упрощенная обработка данных в больших кластерах» (Map Reduce: Simplified Data Processing on Large Clusters).
Статья Map Reduce – отличный пример идеи, которая оказалась настолько успешной, что теперь кажется очевидной. Идея применения концепций функционального программирования в большом масштабе стала громким призывом, спровоцировав переход от хранилища данных к новой парадигме анализа данных:
Map Reduce – это программная модель и связанная с ней реализация для обработки и генерации больших наборов данных. Пользователи задают функцию сопоставления, которая обрабатывает пару ключ/значение для создания набора промежуточных пар ключ/значение, и функцию сокращения, объединяющую все промежуточные значения, связанные с одним и тем же промежуточным ключом. Многие реальные задачи можно выразить в этой модели, как показано в статье.
Подобно тому, как статья о файловой системе Google послужила источником вдохновения для файловой системы Hadoop, эта статья сама по себе стала основным источником вдохновения для Hadoop.
9. «Dapper, Крупномасштабная инфраструктура отслеживания распределенных систем» (Dapper, a Large-Scale Distributed Systems Tracing Infrastructure).
В статье о Dapper представлен эффективный подход к отслеживанию запросов во многих службах, который становится все более актуальным по мере того, как все больше компаний преобразуют основные монолитные приложения в десятки или сотни микросервисов.
Выдержка из аннотации:
Здесь мы представляем дизайн Dapper, производственной инфраструктуры отслеживания распределенных систем Google, и описываем, как были достигнуты наши цели проектирования по снижению накладных расходов, прозрачности на уровне приложений и повсеместному развертыванию в очень крупномасштабной системе. Dapper имеет концептуальное сходство с другими системами отслеживания, в частност