и с Magpie и X-Trace. Но были приняты определенные конструктивные решения, которые стали ключом к его успеху в нашей среде, такие как использование выборки и ограничение инструментария довольно небольшим количеством общих библиотек.
Идеи Dapper с тех пор попали в открытый исходный код, особенно в Zipkin(7) и Open Tracing (8).
10. «Kafka: Распределенная система обмена сообщениями для обработки каротажных данных» (Kafka: a Distributed Messaging System for Log Processing).
Apache Kafka (9) стал основным элементом инфраструктуры для многих интернет-компаний. Универсальность позволяет ему выполнять множество функций, служа точкой входа на «ландшафт данных» для одних и создавая надежную очередность для других. И это только самые очевидные преимущества.
Kafka – это не только полезное дополнение к вашему набору инструментов, но и красиво разработанная система:
Обработка каротажных данных стала важнейшим компонентом конвейера передачи данных для интернет-компаний-потребителей. Мы представляем Kafka, распределенную систему обмена сообщениями, которую разработали для сбора и доставки больших объемов каротажных данных с низкой задержкой. Наша система включает в себя идеи существующих агрегаторов каротажных данных и систем обмена сообщениями. Она подходит как для автономного, так и для онлайн-использования при передаче сообщений. В Kafka мы приняли довольно много нетрадиционных, но практичных разработческих решений, чтобы сделать эту систему эффективной и масштабируемой. Наши экспериментальные результаты показывают, что Kafka обладает более высокой производительностью по сравнению с двумя популярными системами обмена сообщениями. Мы уже некоторое время используем Kafka в производстве, и он обрабатывает сотни гигабайт новых данных каждый день.
В частности, разделы Kafka выполняют феноменальную работу, заставляя разработчиков приложений принимать четкие решения о компромиссе между производительностью и предсказуемым порядком сообщений.
11. «Wormhole: Надежный паб-саб[46] для поддержки геореплицируемых интернет-сервисов» (Wormhole: Reliable Pub-Sub to Support Geo-Replicated Internet Services).
Во многом похожая на Kafka, система Wormhole от Facebook – это еще один масштабируемый подход к обмену сообщениями:
Wormhole – это система публикация-подписка (pub-sub), разработанная для использования в географически реплицированных центрах обработки данных Facebook. Она применяется для надежного воспроизведения изменений между несколькими сервисами Facebook, включая TAO, Graph Search и Memcache.
В этой статье описывается разработка и внедрение Wormhole, а также операционные проблемы масштабирования системы для поддержки нескольких систем хранения данных, развернутых в Facebook. При производственном развертывании Wormhole передается более 35 Гбайт/сек в устойчивом режиме (50 миллионов сообщений в секунду или 5 триллионов сообщений в день) во всех развертываниях с пакетами до 200 Гбайт/сек во время восстановления после сбоя. В статье демонстрируется, что Wormhole публикует обновления с низкой задержкой для подписчиков, которые могут выходить из строя или потреблять эти обновления с разной скоростью, без ущерба для эффективности.
В частности, обратите внимание на подход к поддержке отстающих потребителей без ущерба для общей пропускной способности системы.
12. «Borg, Omega и Kubernetes» (Borg, Omega, and Kubernetes).
Материалы по каждой из систем оркестровки Google (Borg, Omega и Kubernetes) заслуживают отдельного прочтения, но эта статья представляет собой отличный обзор всех трех систем:
Хотя повсеместный интерес к программным контейнерам вспыхнул относительно недавно, в Google мы занимаемся масштабным управлением контейнерами Linux уже более десяти лет и за это время создали три различные системы управления контейнерами. Каждая система находилась под сильным влиянием предшественников, даже, несмотря на то что они были разработаны по разным причинам. В этой статье описываются уроки, которые мы извлекли из их разработки и эксплуатации.
К счастью, не вся оркестровка происходит под эгидой Google, и статья об альтернативной двухуровневой архитектуре планирования Apache Mesos также довольно увлекательна.
13. «Крупномасштабное управление кластерами в Google с помощью Borg» (Large-Scale Cluster Management at Google with Borg).
Borg управлял большей частью инфраструктуры Google в течение довольно долгого времени (это началось значительно раньше Omega, хотя, что интересно, статья про Omega вышла раньше статьи про Borg на два года).
Система Borg от Google – это диспетчер кластеров, который выполняет сотни тысяч заданий из многих тысяч различных приложений в нескольких кластерах, каждый из которых насчитывает до десятков тысяч машин.
В этой статье рассматривается модель централизованного планирования Borg, которая была одновременно эффективной и действенной, хотя со временем ее становилось все труднее модифицировать и масштабировать. Система Borg вдохновила как Omega, так и Kubernetes в Google (первая оптимистично заменила ее, а вторая, по-видимому, коммерциализировала знания разработчиков или, по крайней мере, не позволила Mesos захватить слишком много внимания).
14. «Omega: Гибкие, масштабируемые планировщики для больших вычислительных кластеров» (Omega: Flexible, Scalable Schedulers for Large Compute Clusters).
Omega, помимо всего прочего, является отличным примером эффекта второй системы (10), при котором попытка заменить сложную существующую систему чем-то гораздо более элегантным оказывается труднее, чем ожидалось.
В частности, Omega является реакцией на реалии расширения устаревшей системы Borg: требования трудно удовлетворить с помощью современных архитектур планировщиков монолитных кластеров. Это ограничивает скорость развертывания новых функций, снижает эффективность и использование и в конечном итоге ограничивает рост кластера. Мы представляем новый подход к удовлетворению этих потребностей с использованием параллелизма, общего состояния и управлением параллелизмом без блокировки.
Возможно, это также пример того, что чем хуже, тем лучше (11) снова берет верх.
15. «Mesos: Платформа для мелкомодульного совместного использования ресурсов в центре обработки данных» (Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center).
В этой статье описывается дизайн Apache Mesos (12), в частности, его отличительный двухуровневый планировщик:
Мы представляем Mesos, платформу для совместного использования коммерческих кластеров между несколькими различными кластерными вычислительными платформами, такими как Hadoop и MPI. Совместное применение улучшает использование кластера и позволяет избежать репликации данных для каждой платформы. Mesos распределяет ресурсы мелкомодульным образом, позволяя инфраструктурам достигать локализации данных, по очереди считывая данные, хранящиеся на каждом устройстве. Для поддержки сложных планировщиков современных инфраструктур Mesos внедряет распределенный двухуровневый механизм планирования, называемый предложением ресурсов. Mesos решает, сколько ресурсов предоставить каждой инфраструктуре, в то время как инфраструктуры решают, какие ресурсы принимать и какие вычисления выполнять.
Наши результаты показывают, что Mesos может достичь почти оптимальной локализации данных при совместном использовании кластера между различными инфраструктурами, может масштабироваться до 50 000 (эмулируемых) узлов и устойчив к сбоям.
Активно используемый Twitter и Apple, Mesos некоторое время был единственным общим планировщиком с открытым исходным кодом, получившим значительное распространение. Сейчас он участвует в увлекательном соревновании в популярности с Kubernetes.
16. «Шаблоны проектирования для распределенных систем на основе контейнеров» (Design Patterns for Container-Based Distributed Systems).
Переход к развертыванию и организации на основе контейнеров привел к появлению совершенно нового набора терминов, включая расширение за счет внешних устройств и адаптеры. В этой статье представлен обзор моделей, которые эволюционировали за последнее десятилетие, поскольку микросервисы и контейнеры становятся все более заметными компонентами инфраструктуры:
В конце 1980-х и начале 1990-х годов объектно-ориентированное программирование произвело революцию в разработке программного обеспечения, популяризировав подход к созданию приложений как наборов модульных компонентов. Сегодня мы наблюдаем аналогичную революцию в разработке распределенных систем с растущей популярностью микросервисных архитектур, построенных из контейнерных программных компонентов. Контейнеры особенно хорошо подходят в качестве основного «объекта» в распределенных системах благодаря стенкам на границе контейнера. По мере развития этого архитектурного стиля мы наблюдаем появление шаблонов проектирования, во многом похожих на то, что мы делали для объектно-ориентированных программ. По той же причине мышление в терминах объектов (или контейнеров) абстрагирует низкоуровневые детали кода, в конечном итоге выявляя шаблоны более высокого уровня, общие для различных приложений и алгоритмов.
Термин расширение за счет внешних устройств, в частности, вероятно, возник в этом посте в блоге Netflix (13), который сам по себе достоин прочтения.
17. «Raft: В поисках понятного алгоритма консенсуса» (Raft: In Search of an Understandable Consensus Algorithm).
Мы часто наблюдаем эффект второй системы, когда итоговая система становится раздутой и сложной по сравнению с простой исходной. Однако в случае с Paxos и Raft роли поменялись местами. В то время как Paxos часто считается недоступным человеческому пониманию, Raft довольно понятен:
Raft – это согласованный алгоритм для управления реплицируемым журналом. Он дает результат, эквивалентный (мульти-) Paxos, и так же эффективен, как Paxos, но его структура отличается. Это делает Raft более понятным, чем Paxos, а также обеспечивает лучшую основу для построения практических систем. Чтобы повысить понятность, Raft разделяет ключевые элементы консенсуса, такие как избрание лидера, репликация журнала и безопасность, и обеспечивает более высокую степень согласованности, чтобы уменьшить количество состояний, которые необходимо учитывать.