Я читал книгу Мартина Клеппманна Распределенные системы. Он очень красиво объяснил, как идеи и уроки Unix переносятся на крупномасштабные разнородные распределенные системы данных.
Прочитав эту книгу, я понял, что могу связать это с моим первым промышленным проектом. Я начал свою карьеру с небольшого стартапа в 2002 году. Мы были выпускниками инженерных специальностей с опытом работы от 0 до 2 лет. Наш наставник был опытным исследователем в области инструментовки с большим опытом работы с экосистемами Unix.
Наше приложение было очень простым. Он периодически считывает данные (например, температуру, влажность, напряжение, нагрузку и т. Д.) С датчиков. У приложения был приятный интерфейс для отображения текущих показаний и текущих предупреждений. Он выдает предупреждения, если условие предупреждения нарушается. Все данные были записаны на диск. Пользователи могут делать запросы о временном диапазоне для появившихся предупреждений, статистических агрегатов, например. среднее, минимальное, максимальное, стандартное отклонение и т. д. Пользователи могут экспортировать или распечатать все журналы. Это приложение использовалось в холодильных камерах, медицинских исследовательских лабораториях, строительных проектах в Дели / NCR. Мы находились в Дели.
Если вы жили в Дели / NCR примерно в 2002–2004 годах, вполне вероятно, что купленные вами овощи хранились в холодильном хранилище, контролируемом этим приложением, или вы использовали проект инфраструктуры, который контролировался этим приложением во время его строительства. .
Архитектура проекта
Дизайн был основан на шаблонах стиля Unix, таких как множественные процессы, связь клиент-сервер на основе сокетов. Многие вещи в дизайне и реализации были вдохновлены шаблонами, использованными в книге «Сетевое программирование Unix (2-е издание)» Ричарда Стивенса. Резюме о различных модулях:
DAQ: периодически считывайте предварительно настроенные датчики и записывайте данные в циклическую очередь, реализованную в общей памяти.
Монитор: считывать данные из очереди и запускать правила предупреждений, запускать предупреждения с помощью Alert Utils при нарушении условий предупреждения. Клиент пользовательского интерфейса может запрашивать текущие данные с сервера через сокет.
Alert Utils: это были небольшие служебные программы для создания предупреждений, таких как включение гудка, вызов по телефону с предварительно записанным звуком. Да, это был 2002 год и производственная установка, поэтому предупреждения сильно отличались от того, что мы видим сегодня.
Регистратор: сериализует все данные в файлах журнала на диске. Журналы были добавлены только для добавления, поэтому они были отсортированы по отметке времени. Файлы журнала менялись каждый день.
Анализ: поддерживаются только запросы временного диапазона. Это была пакетная обработка заданий по запросу для уже отсортированных данных по метке времени. Результаты могут отображаться на экране или экспортироваться в формате ps / pdf. Создание ps / pdf также производилось с помощью инструментов Unix awk, latex, gnu-plot, ps2pdf.
Системный монитор: каждый серверный процесс выгружал свое сердцебиение на диск в виде файла. Системный монитор использовался для отслеживания этих биений и перезапуска остановленных или зависших процессов.
Многие могут возразить, что это излишество или не лучшая архитектура, и я согласен с этим, но не об этом.
Современная архитектура для проекта
Я больше не работаю над этим проектом и не знаю, используется он до сих пор или нет. Моментом для меня стало осознание того, что я могу легко преобразовать эту архитектуру в современную микросервисную и распределенную архитектуру. С другими проектами мне не повезло.
Каждый процесс в архитектуре может быть отдельным микросервисом или лямбда-функцией. Круговую очередь (реализованную в разделяемой памяти) можно заменить на Kafka. Kafka - это лучшая и распределенная версия того, что нам требовалось (не обязательно реализовано) в то время.
Весь анализ журналов может быть обеспечен Spark с поддержкой гораздо большего количества запросов и функций.
Вместо необработанных сокетов и пользовательского интерфейса ОС можно использовать остаточный API и веб-интерфейс.
Новая архитектура в моей голове:
Опять же, для этого приложения возможна лучшая архитектура, но идея здесь состоит в том, чтобы показать, насколько легко старые шаблоны были заменены новыми аналогичными шаблонами в этом дизайне.
Последние замечания
Архитектура нашего проекта была невелика, но мы использовали множество шаблонов UNIX, вдохновленных книгой «Сетевое программирование Unix». Эти шаблоны были хороши в прошлом. Мы можем относиться к этим шаблонам в современном мире распределенных микросервисов.
