Рубрика «проектирование систем» - 3

Цикл статей: построение NAS, либо домашнего мини-сервера - 1

Как видно из новостей, облака и крупные компании — это удобно и надёжно, но далеко не всегда:

Так что, кормить облачные сервисы хорошо, но в некоторых случаях "своя рубашка ближе к телу".

Изначально, одной из моих целей являлось исследование построения собственной системы, в частности NAS с возможностью работы "домашним сервером".

Постепенно возникла идея, что в свете недавних событий, информация такого плана интересна, и неплохо бы аккумулировать её в одном месте, структурировать и дополнить.
В итоге, должно сформироваться что-то вроде общедоступных best practices для энтузиастов, начиная от выбора и сборки железа и заканчивая программным обеспечением.

Данная статья является оглавлением к статьям по построению NAS.

Читать полностью »

Проектирование программной платформы защищённого NAS - 1

Допустим, аппаратная часть NAS собрана и на неё установлена ОС, например, как показано здесь. И сейчас у вас есть работающий сервер с Debian, который загружается, подключен в сеть, и вы имеете к нему полный физический доступ.

Теперь надо спроектировать среду, позволяющую легко и безопасно добавлять, удалять прикладные сервисы, а также управлять их работой.

Читать полностью »

Очевидно, что лучше предотвратить болезнь, чем впоследствии ее лечить.

С построением видеосистем все обстоит точно также. Вместо того чтобы искать причины и решать проблемы с отображением/записью/архивированием в процессе использования, лучше чуть дольше и внимательнее подумать на этапе проектирования, чтобы избежать неприятностей в будущем.

Наша техподдержка работает активно, очень активно. Она консультирует, помогает настроить и, конечно, решает проблемы в видеосистемах. Часто эти проблемы видны в среде ПО, но с Macroscop они не связаны. Видеосистема многокомпонентна, если что-то в ней ломается или просто не работает должным образом, пользователь не увидит, что какая-то часть испортилась. Он увидит, что в realtime-видео появились рывки, а в архиве – “дырки”. Значит ли это, что проблема в ПО? Часто причина совсем в другом.

Улучшаем работу системы видеонаблюдения и предотвращаем сбои - 1
Читать полностью »

История про хранилище изображений. Или как велосипед спас от костыля - 1

На днях мы порелизили новую фичу — Дорожные события в навигаторе. Теперь пользователи мобильных приложений могут не только посмотреть на дорожные пробки и места расположения скоростных камер, но и участвовать в обмене информацией на дорогах: указать места ДТП, дорожных работ, перекрытий, а также просто пообщаться. Помимо указанных мест сориентироваться в ситуации помогут добавленные фотографии.

В статье расскажу, как мы разработали сервис, способный хранить миллионы фотографий и обслуживать тысячи запросов в секунду.
Читать полностью »

I Вступление

Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.

За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воотчую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.
Читать полностью »

Я присоединился к Uber два года назад в качестве мобильного разработчика, имеющего некоторый опыт разработки бекенда. Здесь я занимался разработкой функционала платежей в приложении — и по ходу дела переписал само приложение. После чего я перешёл в менеджмент разработчиков и возглавил саму команду. Благодаря этому я смог гораздо ближе познакомиться с бэкендом, поскольку моя команда несёт ответственность за многие системы нашего бэкенда, позволяющие осуществлять платежи.

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

В данном посте я собираюсь рассказать про несколько концепций, которые мне потребовалось изучить и применить на практике при построении крупномасштабной высокодоступной распределённой системы платежей, которая сегодня работает в Uber. Это система с нагрузкой до нескольких тысяч запросов в секунду, в которой критическая функциональность платежей должна работать корректно даже в тех случаях, когда перестают работать отдельные части системы.

Полный ли это список? Скорее всего, нет. Однако, если бы лично я сам узнал про эти концепции раньше, это сделало бы мою жизнь гораздо проще.

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.
Читать полностью »

Дорогой Хабр, мы решили поделиться заметками и нашим базовым рецептом о приготовлении проектов в Sparx Enterprise Architect. Причем под проектом мы подразумеваем создание какой-либо информационной системы. Впереди вас ждет рассказ о том, как у нас все организовано – примеры диаграмм, структура проекта в Enterprise Architect, немного о требованиях, проектировании и постановках на разработку.

Готовим проект в Sparx Enterprise Architect. Наш рецепт - 1

Источник
Читать полностью »

Введение

В прошлой статье Проекционное моделирование я дал определения и тезисы проекционного моделирования. Начиная с этой, я начну подробный рассказ, почему же все-таки это сделано так, а не иначе и как это работает.

Дуальность

Часто можно слышать: этот объект одновременно обладает и свойствами такими-то и свойствами такими-то. Например, такое часто можно услышать про квантовую частицу. Якобы она обладает одновременно и свойствами волны, и свойствами частицы. В моей модели нет дуальностей. Как только появляется дуальность, это значит, что у нас есть либо две разные точки зрения на описание 4-Д объекта, или два разных метода.
Читать полностью »

Как мы расписание общественного транспорта в 2ГИС добавляли - 1

2ГИС помогает ориентироваться в городе. Открываешь приложение, вводишь в поиск название улицы или организации, находишь, радуешься. После того, как нужная организация найдена, возникает резонный вопрос: как же туда добраться? И если автомобильным сценариям мы в последнее время уделяли значительное внимание, то поиск проезда на общественном транспорте оказался немного подзабыт. Я расскажу про то, как создавался поиск проезда, поделюсь тонкостями сбора и обработки информации.
Читать полностью »

Перевод книги Кристиана Посты (Christian Posta) Microservices for Java Developers. A Hands-On Introduction to Frameworks & Containers. Продолжение. Предыдущая публикация.

ГЛАВА 1. Микросервисы для Java программистов
(Продолжение)

Проектирование с учетом обязательств

В среде микросервисов с автономными командами и сервисами очень важно иметь в виду взаимоотношения между поставщиком и потребителем сервиса. Как автономная команда обслуживающая сервис, Вы не можете предъявлять какие-либо требования к другим командам и сервисам потому, что Вы не владеете ими, они автономны по определению. Всё, что Вы можете сделать — это выбрать, будете ли Вы принимать или не принимать их обязательства функциональности или поведения. А как поставщик сервиса для других, всё, что Вы можете сделать — это пообещать им определенное поведение. Они вольны в выборе — доверять Вам или нет. Модель теории обязательств впервые предложена Марком Берджессом (Mark Burgess) в 2004 году и описана в его книге «В поисках определенности» (In Search of Certainty, O’Reilly, 2015). Это исследование автономных систем включая человеческие и компьютерные, оказывающие услуги друг другу.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js