Нюансы проектирования распределенных систем
Нет централизованного сервера. Используется любой email-сервер, который укажете
Надежное e2e-шифрование Autocrypt Level 1. Реализация прошла независмый аудит
Open Source, не преследует коммерческих целей, финансируется НКО и пользователями
Аудитория ~1М. Точно не оценить из-за отсутсвия телеметрии
Недостатки: не такой быстрый и отсутсвуют (пока) редактирование сообщений, реакции и треды
Несколько месяцев назад мне захотелось сдуть пыль со своего аккаунта в Steam и поиграть в старые игры про программирование.
While True Learn в очередной раз показалась слишком скучной, я пару дней позалипал в TIS-100, реализуя свой многопоточный процессор, но в конечном итоге осознал, что интереснее не играть в игры про программирование, а самому писать такие игры.
В статье рассказываю, что из этого получилось и на чём я сломался. Под катом —гремучая смесь из ссылок, картинок, теории распределённых систем и способов визуализации Python в 2022 году.
Решения в области дистанционного банковского обслуживания юридических лиц (ДБО ЮЛ) довольно продолжительное время строились на монолитных автоматизированных системах подрядчика. Вначале было Legacy от BSS, потом решение от R-Style SoftLab. В таких монолитах нет ничего плохого, это отличный базис, который не просто поддерживает жизнеспособность системы, но и до определенного момента оставляет простор для развития. Однако есть в них и минусы, и чем больше массив становится, тем острее они ощущаются.
Микросервисная архитектура популярна. Даже если речь идет о создании одного небольшого приложения, как правило его реализуют в виде пачки микросервисов, которые запущены отдельно и как-то реплицируются. Как они между собой будут взаимодействовать?
В этой статье поговорим о том, какие бывают способы общения в микросервисной среде. Расскажу на пальцах, какие обычно предъявляются требования к общению сервисов, почему большинство использует REST API, даже при том, что у него тоже хватает минусов, и при чем тут Kafka.
Рассчитываю на новичков, но если у вас есть интересный опыт в этих вопросах - добро пожаловать в комментарии.
В информационных системах российских распределительных сетей трудностей немало, одна из самых весомых — отсутствие достоверных данных о распределительной сети 0.4-20 кВ, важных для формирования обоснованной инвестиционной программы.
В СИГМЕ комплексные задачки любят. Поэтому отдел решений по автоматизации расчетов технических условий, чья работа напрямую зависит от достоверности данных, взялся за создание универсального инструмента для их выверки. И начали мы с разработки механизма загрузки и выгрузки данных с помощью конструктора на базе стандартов CIM (Common Information Model, electricity).
Команда работала над модулем выверки в рамках СИГМА СУС — решения нашей компании для управления распределительными электрическими сетями. Однако созданный конструктор и наши рекомендации будут полезны не только тем, кто занимается выверкой данных в распределительных электросетевых компаниях, но и тем, кто работает с показателями на других проектах.
Меня зовут Сергей Петренко, вот уже четыре года я работаю над репликацией в Tarantool, и сегодня хочу рассказать про слабые места алгоритма Raft и способы их преодоления. Эта статья — вольный пересказ нашего с Борисом Степаненко доклада на Hydra 2022. Если читатель не знаком с Raft, то предлагаю ознакомиться с моей статьёй о нём.
Узрев повторную статью-мнение-перевод на оригинальный пост фаундера Signal "web3 не будет: расходимся по домам" https://habr.com/ru/post/673836/, не смог устоять от соблазна дать расширенное op-ed опровержение. И в комментарий оно не влезло.
Мое мнение, что Moxie сделал только эмоциональные выводы, хотя и назвал причину правильно: “Все упирается в нежелание людей держать свои сервера. Потому что держать сервера — это сложно, а мы хотим нажимать одну кнопку. “ а если покопаться более фундаментально, то все может предстать в более рациональных абстракциях.
Рациональный анализ приземленный на уровни абстракций “имхо” таков:
Данная статья поможет всем интересующимся лучше узнать про технические особенности платформ: Cosmos, Polkadot, Avalanche.
Эти платформы нацелены на горизонтальное масштабирование с асинхронной гетерогенной сетевой моделью, где предметноспецифичные блокчейны сосуществуют в рамках общей сетевой модели и при необходимости взаимодействуют друг с другом. У каждой платформы есть свои собственные подходы и компромиссы по достижению межцепочной экономической безопасности. Они нацелены на создание блокчейнового междусетья, которое способно вместить не сотни тысяч (как сегодня), а миллионы активных пользователей в день и полноценно реализовать концептуальное видение Web3, принадлежащего и контролируемого пользователями.
Цель этой статьи - помочь разработчикам, исследователям, предпринимателям и всем, кто изучает блокчейн и децентрализованные системы, понять эту смену парадигмы в блокчейн сетях.
Привет! Я Team Lead в Scalable Solutions. Мы с командой давно работаем над нашей платформой и уже дошли до той точки, когда любые технические решения должны быть обоснованы и согласованы с коллегами. Так исторически сложилось, что у нас есть ряд технических решений, которые были приняты в начале, но никогда не проходили этапы обоснования. К такому решению относится Protobuf. Поэтому я решил сравнить популярные бинарные форматы, чтобы выяснить, какие недостатки есть у каждого, и что сегодня наиболее оптимально с точки зрения эксплуатации.
Привет! Меня зовут Александр Кленов, и я работаю в Tarantool. В апреле вышел Tarantool 2.10 Enterprise Edition – обновленная версия платформы in-memory вычислений. В версии 2.10 появилось несколько новых функций, о которых уже немного рассказывали на Хабре.
В этой статье я хочу подробнее остановиться на одной из фичей — сжатии данных в оперативной памяти. Далее я расскажу, как ей пользоваться, что может, а чего не может данный механизм, как его применять и какие существуют особенности.
Эта статья не будет технически глубокой. Мы поговорим о Data Lake и Data Warehouse, важных принципах, которые следует учитывать, и о том, какие сервисы GCP можно использовать для создания такой системы. Мы коснёмся каждого из GCP сервисов и поймём почему они будут полезны при создании Data Lake и Warehouse.
Прежде чем перейти к своей версии Data Lake и Data Warehouse, я хотел бы привести несколько известных архитектур, с которыми вы, возможно, уже знакомы, если интересуетесь этой темой. Архитектура, которую я бы предложил, будет более общей, чем эти: Cloud Storage as a data lake и Architecture: Marketing Data Warehouse.
В своей более общей версии Data Lake и Data Warehouse я расскажу о таких сервисах GCP, как Data Transfer Service, Dataproc, Cloud Storage, Cloud Scheduler, BigQuery, и Cloud SQL.
Микросервисная архитектура предполагает декомпозицию системы на относительно независимые фрагменты с собственными источниками данных, которые могут переиспользоваться в различных процессах и обмениваться данными. Но в таком решении есть и оборотная сторона, связанная с необходимостью включения логики оркестрации или непосредственно в код сервисов (что затрудняет возможность гибкого изменения процесса), либо использовать внешний оркестратор, который будет обеспечивать запуск микросервисов с входными параметрами, получение и передачу результата, а также управление сценарием при возникновении ошибок или определенных ситуаций при выполнении процесса.
Второй вариант может быть реализован в виде исполняемого кода, либо с использованием специальных движков для исполнения сценария бизнес-процесса, который может включать в себя вызов внешних сервисов. Стандартом в области описания бизнес-процессов является визуальная нотация BPMN 2.0 и наибольший интерес представляет соединение графической диаграммы и исполняемых сценариев, которое также называется Executable BPMN 2.0 и среды для его исполнения, среди которых можно назвать jBPM, Flowable, Camunda BPM и Activiti (она интересна еще и тем, что на ней реализуется управление процессами в Open Source системе управления документами Alfresco). В этой статье мы рассмотрим основы BPMN и создадим простой процесс для управления системой полива в зависимости от измеренной влажности (все компоненты системы реализованы как микросервисы).
При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.
Тема задержки доступа и скорости извлечения сетевых ресурсов никогда не перестанет быть актуальной. Максимально близкое расположение источника влияет не только на скорость загрузки и пользовательский опыт, но и на эффективность работы глобальной сети в целом, поскольку позволяет локализовать трафик и сократить загрузку магистральных каналов, предпочитая использовать кэшированные или расположенные локально реплики сетевых ресурсов. Не случайно Google реализует модель сохранения локальных кэшей на оборудовании крупных региональных провайдеров (Google Global Cache) и интеллектуальные алгоритмы в маршрутизации на ближайшую реплики. В этой статье мы обсудим различные подходы к реализации распределенной сети доставки контента (Content Delivery Network, он же CDN), а также акцентируем возможные решения для создания CDN в масштабах отдельно взятой страны или города.
За час до того, как я сел писать эти строки, первый спутник-демонстратор низкоорбитальной навигационной системы Pulsar отделился от разгонного блока.
Идею этой системы я изложил в прошлой статье. Компания Xona планирует вывести около 300 небольших спутников на низкую орбиту. Каждый спутник будет снабжен приемником сигналов глобальных навигационных систем (ГНСС), по их сигналам спутники будут определять свои траектории движения и синхронизироваться. Из-за удаленности от поверхности земли и ориентации антенны, спутники будут оставаться вне досягаемости наземных постановщиков помех.
Каждый спутник системы будет формировать собственный сигнал, который благодаря близости к поверхности планеты, окажется в 100 раз мощнее сигналов ГНСС. В совокупности с криптографической защитой сигнала это обещает устойчивость навигации к помехам и спуфинговым атакам. А за счет простоты спутников и их вывода, простоты комплекса управления, стоимость всей системы можно уместить в несколько сотен млн долларов.
У конференции Hydra в этом году кое-что меняется: кроме двух онлайн-дней, будет ещё и офлайн-день в Петербурге, позволяющий по-настоящему собраться вместе и как следует пообщаться.
И если обычно программа Hydra делилась на два больших блока «concurrency» и «distributed», то в этом году получился ещё и третий: про «внутренности» баз данных.
Но главное остаётся прежним:
— Конференция посвящена разработке параллельных и распределенных систем
— На ней сходятся вместе IT-индустрия и академический мир (тут можно познакомиться и со свежими теоретическими результатами, и с «историями из продакшна»)
— Доклады на английском
О чём именно расскажут в этот раз? Хотя на сайте описания докладов на английском, для хабрачитателей перевели их на русский.
От переводчиков. Эту коротенькую статью Дейкстры, которой уже 57 лет, Лесли Лампорт назвал «работой, которая начала всю область конкурентных и распределенных алгоритмов». Но на Хабре её до сих пор вроде бы не переводили. Поскольку мы скоро проведём конференцию Hydra, которая посвящена именно этой области, решили восполнить этот пробел. Кстати, как думаете, как лучше переводить на русский слово concurrent? Мы выбрали вариант «конкурентный», но консенсуса тут вроде бы нет.
Эдсгер В. Дейкстра
Технический университет Эйндховена, Нидерланды
Ряд преимущественно независимых последовательно-циклических процессов с ограниченными средствами связи друг с другом может быть реализован таким образом, что в любой момент времени один и только один из них находится в «критической секции» своего цикла.