Влад: другие произведения.

"Служба доставки", концепция

Журнал "Самиздат": [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь]
Peклaмa:
Конкурс фантастических романов "Утро. ХХII век"
Конкурсы романов на Author.Today

Летние конкурсы на ПродаМан
Открой свой Выход в нереальность
[Создай аудиокнигу за 15 минут]
Peклaмa
 Ваша оценка:
  • Аннотация:
    Сервер-клиентская ‘delivery service’ на скриптах (conception)

NB. Предлагаю вашему вниманию некоторые результаты разработки темы "служба доставки"
Для ознакомления и, возможно, обсуждения на предмет.
+ В ближайших планах - детализация общей концепции с последующим изложением некоторых технических решений, прошедших "проверку практикой".

(l) Копилефт (copyleft) 1998-2018 гг.

Автор: Владислав Носов, Владивосток, Россия.
(nickname: nvvLazyTiger)
Ограничения: разрешается свободное использование изложенного при соблюдении условий:

=== Серверная "служба доставки" (данных) ===

(‘Delivery service’ conception)

Предисловие

Для обеспечения долговременного решения стоявших передо мной задач, в конце 90-х была разработана и реализована "служба доставки" данных (далее - "служба"). На платформе ОС Windows. В составе: самодельный монитор/шедулер (далее - "пускач") + обвязка на интерпретируемых скриптах (CMD, AWK, VBS) + комплект вспомогательных утилит (например: BinkD, BlAt, 7z, etc.).

Предназначение

Служба предназначена для регулярного автоматического транзита данных (в т.ч. и с преобразованием) от систем, их предоставляющих (далее - "источники"), к системам, в них нуждающимся (далее - "потребители"). Т.е. служба выступает как посредник между системами, не имеющими штатной возможности (приемлемого качества) взаимодействовать напрямую.

Историческая справка

  1. Постановка задачи: "нужно регулярно копировать/перемещать данные туда-сюда между рабочими местами (персонала) и между ними и общим файловым сервером предприятия".
  2. Формирование концепции службы в самом общем виде, первый работающий макет, выдача технического, задания на разработку технологического пускача.
  3. Сдача в опытную эксплуатацию (на производстве, в режиме 24/7) прототипа службы, около 15-и источников/потребителей на головном предприятии (г. Владивосток).
  4. Расширение обслуживания на весь Приморский край, около 50-и источников/потребителей. Формирование концепции службы в целом завершено. Продолжается формализация и обкатка технческих требований к отдельным подсистемам службы. Расширяется номенклатура обслуживаемых типов интерфейсов взаимодействия (далее - "стыки") с источниками и с потребителями.
  5. Начало постулирования ключевых требований к персоналу, обеспечивающему сопровождение и поддержку службы и требований к партнёрам, обслуживающим источники и потребителей (разграничение ответственности).
  6. Начало обслуживания данных от контрагентов (сторонних организаций, в масштабах края).
  7. Скачкообразный рост количества источников и объёма обслуживаемых данных. Развёртывание экземпляров службы в других городах Дальнего Востока (Благовещенск, Магадан, Петропавловск-Камчатский, Южно-Сахалинск), подключение к службе источников/потребителей в гг. Москва и Санкт-Петербург.
  8. Пик востребованности службы, сотни первичных источников данных по всему Дальнему Востоку, десятки каналов "точка-точка" до головных серверов во Владивостоке, гигабайты данных, обслуживаемых ежедневно.
  9. Служба остаётся востребованной и работает стабильно уже 18 лет. Без существенных замечаний.

=== Концепция службы ===

Основные положения

  1. Разграничение ответственности вовлечённых.
  2. Круглосуточный автоматический режим работы.
  3. Гибкость.
  4. Прозрачность.
  5. Живучесть (устойчивость и надёжность).
  6. Ремонтопригодность.
  7. Самодостаточность (автаркия, в т.ч. и самообслуживание).
  8. Бюджетность (лирическая констатация).

Подробности…

1. Разграничение ответственности вовлечённых.

  1. Источник отвечает за все проблемы источника;
  2. Служба отвечает за все проблемы службы;
  3. Потребитель отвечает за все проблемы потребителя;
  4. За стык отвечают состыкованные + ответственные за среду передачи;
  5. Возможно добровольное участие сторон в "не их" проблемах;
  6. Ответственность за службу несёт технолог, а админ - за место размещения оной, - если это разные люди, то админ не имеет права непосредственно вмешиваться в работу службы, а технолог, - в работу места размещения. Исключения:
    • критическая аварийная ситуация;
    • предварительно согласованное (с другой стороной) действие.
  7. Любые "заинтересованные" лица (включая начальство) получают доступ к данным, протоколам и т.п. службы только через технолога (т.е. опосредствованно). Исключение — специально обустроенные в составе службы "шары" (места с жёсткой регламентацией доступа);
  8. Ответственность за собственно данные:
    • источник отвечает за корректность отправляемых данных (включая их целостность и непрерывность); Вплоть до поступления от потребителя квитка "принято";
    • если служба видоизменяет поступившее, то она (частично) разделяет вышеуказанную ответственность;
    • оперативные проблемы с данными должны устраняться вовлечёнными сторонами незамедлительно (по возможности);
    • такие же проблемы, но обнаруженные post factum, устраняются с помощью механизма служебных расследований.
NB. Все пересылки через стыки должны (по возможности) квитироваться. При отсутствии приемлемого механизма квитирования, в качестве квитанции рассматривается успешное завершение процесса пересылки, а при служебных расследованиях, - сведения из соответствующих протоколов.

2. Круглосуточный автоматический режим работы.

  1. Служба действует по принципу: данные, - это "горячая картофелина", т.е. поступившие данные должны незамедлительно обрабатываться и отправляться дальше (получателю);
  2. Обслуживаемые данные формируются/предоставляются источниками периодически (по мере готовности/возможности);
  3. Период поступления зависит от особенностей источника и типа данных. Может варьироваться от "один и более раз в час" и до "один раз в месяц";
  4. Допускается приостанавливать получение/обслуживание новых данных в ЧНН (часы наименьшей нагрузки) для самообслуживания службы (см. ниже секцию "7. Самодостаточность");
  5. Устанавливается общий минимальный допустимый интервал времени обслуживания данных. Для некоторых типов данных, требующих длительную обработку, минимальный допустимый интервал обслуживания соответственно увеличивается;
  6. Устанавливается общая максимальная задержка в транспортировке данных от источника до потребителя;
  7. Однако, по возможности, служба должна обслужить все, сформированные и предоставленные источниками данные за последние 24 часа, к началу очередного рабочего дня;
  8. Вмешательство технолога (ответственный за службу) требуется только в случаях:
    • развёртывание службы;
    • добавление/изменение/удаление отдельных задач (или подсистем целиком);
    • ремонт после аварий;
    • свёртывание/перенос службы в другое место.
    NB.Тем не менее, технолог обязан обеспечивать надлежащий присмотр за службой ("ломается всё").

3. Гибкость.

  1. Независимость отдельных задач (обслуживания потоков данных) от других таких задач;
  2. Простота внесения изменений в:
    • конфигурационные файлы;
    • рабочие области подсистем;
    • алгоритмы работы подсистем;
    • общий состав службы.
  3. Низкие требования к месту развёртывания/эксплуатации службы;
  4. Унификация (по возможности) всех компонентов/решений службы (соглашения, структуры, интерфейсы, протоколы и т. п.);
NB. Сторонние потребные компоненты, несоответствующие требованиям унификации, должны, или дорабатываться, или "заворачиваться" в соответствующие скрипты (и применяться только посредством этих скриптов);

4. Прозрачность.

  1. Все действия службы и события (оной касающиеся) должны детально протоколироваться; В частности, вмешательства технолога в службу должны (по возможности) тоже протоколироваться;
  2. Процессы службы должны вести собственные протоколы:
    • либо в виде "plain text" файлов (процесс типа "ЗАДАЧА");
    • либо в виде выдачи на StdOut (процесс типа "ФУНКЦИЯ") для перехвата пустившими их процессами (типа "ЗАДАЧА").
  3. Протоколы в виде файлов должны создаваться/пополняться в обустроенном "особом" месте ("для протоколов");
  4. Причём каждый протокол должен содержать достаточный набор атрибутов и сведений для выяснения:
    • "КОГДА" (дата/время);
    • "КТО" (какой именно процесс);
    • "КАК" стартовал (в каких условиях и обстоятельствах);
    • "ЧТО" сделано;
    • "ЧЕМ" закончилась работа;
    • "ГДЕ" (и что) взято;
    • "КУДА" (и что) помещено.
  5. Протоколы "ФУНКЦИЙ" включаются "as is" в протоколы вызвавших их "ЗАДАЧ";
  6. Пускач службы должен вести собственный протокол вне указанного "общего" места. В этом протоколе должны регистрироваться все события (в границах ответственности пускача), влияющие на функционирование службы, как и все действия самого пускача в связи. Иными словами, протоколы пускача должны обеспечивать альтернативный вариант учёта/фиксации происходящего в службе;
  7. Если технолог вынужден (по уважительным обстоятельствам) вмешаться в обработку данных и это вмешательство не обеспечено надлежащим автоматическим протоколированием, то [этот] технолог обязан вручную отобразить своё вмешательство надлежащим образом. В соответствующем протоколе процесса или рядом;
  8. Для обеспечения служебных расследований (касаемо деятельности службы) должно быть организовано хранение (на срок не менее срока юридической ответственности):
    • всех протоколов;
    • актуальных (на момент) конфигов, скриптов и т.п.;
    • полученных/отправленных службой данных;
    • + если транзитные данные разделяются на "нужное" и "мусор/брак", то и этот "мусор/брак" должен также попадать на хранение.
NB. Иными словами, хранимое должно обеспечивать восстановление полной картины любого события/обстоятельства (в указанных временных границах).
+ должна быть обеспечена возможность предъявить (при надобности) любые поступившие и отправленные данные. Как [предъявить] и то, что служба рассмотрела как "мусор".
В т.ч. должна быть обеспечена возможность повторить любой цикл обслуживания данных, прошедших через службу (в оговоренном интервале прошлого), т.е. возможность эмуляции post factum имевшего место ранее быть.

5. Живучесть (устойчивость и надёжность).

  1. Ни при каких обстоятельствах служба в целом, как и отдельные подсистемы/задачи в частности, не имеют права "тихо" (внезапно, полностью или частично) прекращать свою работу. Т.е. должны быть предусмотрены и обустроены надлежащие действия при:
    • полном отказе места размещения ("железо", электропитание, etc.);
    • локальном отказе какой-то подсистемы/задачи;
    • проблемах со стыками или у источников/получателей;
    • проблемах с собственно пересылаемыми данными.
  2. Соответственно, контроль ситуации должен включать следующие мероприятия:
    • внешний (автоматический) контроль "живости" службы, например методом "пинг-понг";
    • внутренний контроль "успешности" [завершения] пускаемых процессов;
    • внутренний контроль наступления оговоренных событий в оговоренной время;
    • внутренний контроль текущей достаточности наличного дискового пространства (как и прочих обязательных ресурсов, при целесообразности и по возможности);
    • внешний эпизодический персональный контроль "рисунка" работы службы;
    • регулярное зеркалирование (всей службы) или backup (критически важного).
  3. Служба должна быть оснащена развитой системой оповещения (участников и "сочувствующих") о значимых событиях в службе (и в "окрестностях"):
    • аварийная сигнализация;
    • нарушения в штатном обслуживании данных (брак, неполучение или не отправка данных и т.п.);
    • оперативная отчётность о значимых событиях (касаемо данных);
    • оперативные рабочие результаты/сводки (для заинтересованных);
  4. Служба должна быть обеспечена достаточным дисковым пространством (места размещения) для исключения исчерпания оного пространства при непрерывной долговременной работе без вмешательства технолога;
  5. Служба и технолог должны быть обеспечены средствами удалённого оперативного вмешательства технолога в работу службы;
  6. Обслуживание поступающих данных должно включать обязательные механизмы контроля целостности и корректности этих данных. Причём, таких механизмов может быть сразу несколько. Например:
    • целостность архивов (+соответствие пароля, если используется);
    • отсутствие в поступившем постороннего;
    • отсутствие выпадений в потоках данных;
    • корректность именования файлов/архивов;
    • соответствие поступившего заявленному формату;
    • попадание значений данных в заданные границы.
    NB. Не допускается приём в обслуживание потоков данных совсем без таких механизмов.

6. Ремонтопригодность.

  1. Все обслуживаемые данные (в обязательном порядке) буферизируются (обеспечивается их полноценное временное хранение);
  2. Частые типовые аварии должны (по возможности) устраняться службой автоматически (самостоятельно);
  3. Редкие типовые аварии должны устраняться минимальным вмешательством технолога;
  4. Протоколирование работы подсистем должно включать (по возможности) понятное описание "когда/почему" и что именно "упало";
  5. Если указанное в предыдущей позиции невозможно, протокол должен ясно указывать на последнюю (перед аварией) запущенную команду (со всеми фактическими параметрами);
  6. Если "обломки" (от аварии) не могут помочь при локализации/устранении проблемы, они должны "убираться автоматически";
  7. Технолог должен быть обеспечен возможностью легко приостанавливать (на какое-то время) те или иные задачи службы без вмешательства в рабочие конфиги оной;
  8. Технолог должен быть обеспечен (по возможности) средствами запуска ("на бис") тех или иных подсистем без вмешательства в упомянутые конфиги;
  9. По возможности, желательно развернуть отдельное (пространственно) полнофункциональное зеркало службы с целями:
    • быстрое восстановление работы службы на зеркале при критическом отказе штатного места размещения (например отказ винта);
    • доступ к нужным сведениям при служебных расследованиях, не трогая саму работающую службу.

7. Самодостаточность (автаркия, в т.ч. и самообслуживание).

  1. Всё, потребное для работы службы должно находиться в границах оной;
  2. Допускается (при обоснованной необходимости) использовать возможности/ресурсы места размещения (рассматриваемой службы);
  3. Использование внешних (по отношению к месту размещения) средств допускается только в плоскости средств организации/обеспечения стыков службы;
  4. Не допускается бесконтрольный рост "продуктов жизнедеятельности" службы (протоколы, сохранённые копии транзитных данных и т.п.);
  5. Соответственно, такие "продукты" должны регулярно автоматически обслуживаться, т.е. архивироваться и сдвигаться в архивы (сначала в текущие, затем - на долговременное хранение).

8. Бюджетность (лирическая констатация).

  1. Потребные/использованные в службе утилиты/решения, - это, или "самоделки", или Freeware (очевидная натяжка);
  2. В начале пути у меня был в распоряжении "No name" Desktop IBM AT под WinNT4. Сейчас... производственные экземпляры службы работают на серьёзном промышленном "железе" под W2k8 (требования времени;), но всё работало (бы без нареканий;) и в условиях попроще - почти все, имевшие место быть, критические отказы службы - из-за "железа" + грубые ошибки уполномоченного персонала, увы...
  3. Некоторые следствия "бюджетности":
    • нет GUI - серверным процессам он ненужен, технолог использует FAR;
    • нет некоторых, сравнительно важных механизмов (например, отсутствует надлежащий автоматический контроль версий). Соответственно, такие механизмы эмулируются (технологом вручную);
    • нет смысла обустраивать автоматическое восстановление (recovery) для редких типовых аварий.
  4. В целом, предложенная концепция, - это в первую очередь "решение для бедных" (минимально возможный потребный объём начальных вложений и последующих расходов на эксплуатацию отдельного экземпляра службы).
.

 Ваша оценка:

Популярное на LitNet.com М.Зайцева "Трое"(Постапокалипсис) Д.Хант "Дракон и феникс"(Любовное фэнтези) Р.Цуканов "Серый кукловод. Часть 1"(Киберпанк) А.Емельянов "Мир Карика 10. Один за всех"(ЛитРПГ) Д.Сугралинов "Дисгардиум 3. Чумной мор"(ЛитРПГ) А.Емельянов "Последняя петля 5. Наследие Аури"(ЛитРПГ) Р.Цуканов "Серый кукловод. Часть 2"(Антиутопия) А.Робский "Охотник: Новый мир"(Боевое фэнтези) Д.Максим "Новые маги. Друид"(Киберпанк) К.Федоров "Имперское наследство. Вольный стрелок"(Боевая фантастика)
Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
И.Мартин "Время.Ветер.Вода" А.Кейн, И.Саган "Дотянуться до престола" Э.Бланк "Атрионка.Сердце хамелеона" Д.Гельфер "Серые будни богов.Синтетические миры"

Как попасть в этoт список
Сайт - "Художники" .. || .. Доска об'явлений "Книги"