Деление на сущности - декомпозиция, это артефакт мышления и часть процесса познания, метод, которым мы пользуемся естественным образом при создании мысленной проекции (модели) реальности.
Очевидно, что этот процесс, будучи моделированием реальности, а не самой реальностью, может и будет иметь неточности, которые можно назвать "избыточной декомпозицией" и "недостаточной декомпозицией".
Формальным критерием правильного процесса декомпозиции, на мой скромный взгляд, будет являться критерий получения новой информации, а именно:
Если декомпозиция даёт нам качественно новую информацию (полезную в прикладном смысле), то такая декомпозиция оправдана.
Если декомпозиция даёт информацию, которая является эквивалентной по своей семантике уже имеющимся сведениям, то такая декомпозиция не представляет интереса, так как это избыточное усложнение модели.
Когда в процессе декомпозиции и извлечения информации возникает достаточно оснований для оптимизации, происходит значительное уменьшение сложности модели, ее "универсализация", в том смысле, что общие свойства наблюдаемого представляются значительно более простой конструкцией.
Итог и основная мысль, которую я хотел передать этим сообщением заключается в том, что путь познания до формирования красивого и минималистичного представления о реальности или отдельных аспектов реальности зачастую предполагает тернистый путь поиска и извлечения информации через анализ зависимостей, которые возникают при декомпозиции.
Я внимательно прочитал статью и все комментарии, и мне хотелось бы добавить мнение о том, что физика хороша избирательно, а в общее восприятие (пользовательский опыт) как раз во многом делают вклад именно малозаметные детали.
Допустим, игра изобилует открытыми пространствами, полями, лесами, много растительности - здесь очевидным образом напрашивается реалистичная модель взаимодействия с окружающей средой, чтобы на траве оставался след, чтобы деревья можно было физически реалистично повредить, или сделать эти повреждения частью игровой механики, ведь это очень увлекательно! Представьте себе какую-то баталию пусть даже сетевую, где нагромождение срубленных деревьев является элементом защиты, условной "стеной". Или распространение огня по сухой траве, как это было отчасти реализовано в одной из частей FarCry.
Вторым ярким примером можно привести шутеры, где визуальные эффекты попадания тем усиливаются, чем больше взаимодействия происходит с окружающими объектами. Например, попадания пуль в стену могут приводить к частичному разрушению стены, попадание из более серьезного оружия - полностью разрушать объект (здание). Если взять за основу тот же PUBG, по своей сути обычная стрелялка в виде "охоты на противника", то насколько бы преобразился игровой процесс, если бы из пулемета можно было бы "прошить стену" насквозь или "срубать деревья", разрушать объекты, в которых прячутся игроки.
Моя ключевая мысль заключается в том, что физика ради физики имеет масло смысла до тех пор, пока она не становится ключевым элементом игровой механики, соответственно, такой элемент добавляет большое количество степеней свободы (для фантазии игрока), что и воспринимается как качественный игровой опыт, по аналогии с переходом от коридорных шутеров к открытым мирам (но мирам не пустым, а наполненным приключениями).
Совершенно верно, причем неравенство N != NP порождает ловушку для пытливых умов. Этой проблемой (классом задач) можно заниматься бесконечно из любопытства, можно перегорать в поисках ответов, не находя их долгое время, и от того, эти "крепкие орешки" будут становиться все более интересными - вершинами, покорение которых, на мой взгляд, должно быть в основе как минимум популяризации математики и математического мышления.
Так в моем личном опыте было с простыми числами, и вот уже много лет, буквально в любой задаче, при определенной глубине проработки, упираешься в простые числа, с улыбкой понимая, и думая про себя "ну вот мы снова встретились)", а затем стоит выбор - попытаться снова проработать интереснейшую задачу оценки распределения, залипнув надолго и скорее всего безрезультатно, или же умерить свой пыл и реализовать необходимый и достаточный с практической точки зрения аппарат решения задачи.
В этом прелесть всей математики - она позволяет моделировать, но все модели, какими бы целостными и завершенными, самодостаточными они ни казались, фундаментально имеют слабую основу, уходящую корнями в осознание невозможности точного решения.
Математика словно кино, в последней сцене которого есть намеки на продолжение)
Разумеется, это так, все совершенно верно, и в допустимых в прикладном значении рамках мы (человечество) активно используем эвристические методы, методы нечеткой логики, для решения задач там, где это возможно.
В некотором смысле нами движет любопытство, приводящее к гипотезам вида - "а что, если бы мы проанализировали изменение отдельно взятых параметров, то смогли бы гипотетически и приблизительно предположить, что миры с иными конфигурациями не могут содержать жизнь". Но в этом одновременно и вся ирония - из-за самой природы объекта, над которым мы мыслим, такие исследования лишены какого-либо смысла, кроме смысла заниматься самим процессом. Это похоже не игру ради игры, ради процесса, и я не отрицаю, что это интересно и захватывающе, так как и сам периодически "залипаю" в подобных процессах, но не ради победы, финала, детерминированного ответа.
Моя основная мысль здесь скорее в том, что мы можем заранее понять, можем ли мы решить задачу точно, или же наше решение будет где-то на грани софистики.
Позволю себе еще один пример: допустим мы хотим испечь вкусный кекс, но мы не знаем точный рецепт, мы просто понимаем приблизительные ингредиенты и приблизительные их пропорции, не имея модели, определяющие вкусовые качества и свойства конечного продукта. В таком случае успех с точки зрения ощущений при употреблении в пищу конечного продукта будет носить случайный характер, а наше мастерство в кулинарном деле - пропорционально кол-ву экспериментов - то есть тому, насколько мы смогли удачно редуцировать фазовое пространство (комбинаторное множество) всех возможных вариантов кексов из всех допустимых ингредиентов.
Существуют ли формы жизни в иных мирах? Вопрос эквивалентный задаче выпечки вкусного кекса без заранее определенного рецепта. В таком случае, условные "островки жизни" - это такие же "островки вкусных кексов", где вроде бы не слишком много соли, не слишком много сахара, не слишком много воды и т.д. Вроде бы должно быть вкусно, а как будет - так будет, но сам процесс исследования и выпекания увлекателен для нашего разума, хотя и является математической рутиной, - по сути проблемой, необходимость решения которой породила теорию автоматического управления.
Если рассуждать о классах задач, то все задачи анализа возможных конфигураций системы с большим количеством параметров неразрешимы из-за численной оценки комбинаций, превышающих разумные значения.
Приведу пример:
Число́ Ше́ннона — оценочное минимальное количество неповторяющихся шахматных партий, вычисленное в 1950 году американским математиком Клодом Шенноном. Составляет приблизительно 10^120.
Для сравнения — количество атомов в наблюдаемой Вселенной составляет по разным оценкам от 10^79 до 10^81, то есть в 10^40 раз меньше числа Шеннона.
Исследование бесконечных множеств, например, множество простых чисел, или пример с оценкой последовательности, известной как Гипотеза Коллатца (проблема 3x+1).
Это говорит о принципиальной невозможности анализа без какой-то радикальной редукции комбинаторного множества этого класса задач. При этом стоит отметить, что редукцию (и это следует из контекста рассуждений в статье выше) мы будем производить исходя из оценки свойств исследуемых конфигураций миров на "допустимых диапазонах" в рамках измерений.
Простыми словами, мы увидим, что при такой-то конфигурации, с нашей точки зрения, жизнь в исследуемой мире невозможна, потому что структура атома (любого), допустим, будет нестабильна (это показано на рисунке "островком стабильности"). Но при этом мы допускаем фатальную ошибку, исключая любые иные формы взаимодействия более высоких порядков (комбинации значений в измерениях), а их между прочим N! (факториальная зависимость).
Простейший пример:
Допустим, мы собираем гоночный автомобиль, и при оценке параметров массы автомобиля, исходим из того, что высокий вес авто мешает ускорению из-за инерции, и отсекаем все решения, которые по нашей оценке слишком тяжелые, делая болид в 1100 кг веса, но есть класс авто, которые весят в 2+ раза больше, и при этом позволяют реализовать очень интенсивное ускорение за счет оптимизации других параметров.
Так и в нашем случае эго-центризма, - тот факт, что мы субъективно интерпретируем этот мир таким, оценивая его конфигурацию через набор констант, и делая предположения о его структуре - фактически, реализуя факторный анализ, - говорит нам о том, что мы не знаем модель мира, но когда модель зависимостей всех параметров всех порядков неизвестна достоверно, мы не можем сделать редукцию никак, кроме как через набор аксиом. О проблеме интерпретации еще будет пара слов ниже.
Может оказаться так, что конфигурация пространства-времени зависима от уникального сочетания совокупности отдельно взятых параметров, и все они связаны в единую модель, но не являются независимыми сами по себе, поэтому редукция потенциального множества конфигураций (фазового пространства) на заданной метрике, пусть для упрощения [ a, b, c, d, ... ], на основании того, что параметр "а" может быть, по нашему представлению, в диапазоне от 0.73 до 0.87, может быть принципиально ошибочным - мы банально выбросим те варианты более сложных конфигураций, которые могут оказаться допустимыми по критерию интерпретации динамических процессов внутри такого мира, которые мы субъективно могли бы оценить как "жизнь".
Вы совершенно правы, относительно сложности задачи, но, на мой взгляд, стоит отметить, что существует задача еще более высокого уровня, которая не связана с исследованием гипотетических конфигураций иных миров, а присутствует здесь и сейчас в фактической реальности - феномен интерпретатора.
Рассматривать проблему (задачу) феномена интерпретатора можно с различных позиций, как материальной, так и сугубо математической, отчасти эту проблему можно рассмотреть с позиции антропного принципа, но ни один современный подход за всю историю человечества (насколько я могу судить по той информации, что изучал многие годы) не продвинулся сколь-либо значимо в этом направлении.
Хотел бы задать вопрос экспертам в теме: существует ли корреляция между увеличением антител (к спайк-белку) SARS-CoV-2 и уменьшением других, имеющихся антител в организме, т.е. своего рода усиление "ответа" к SARS-CoV-2, но ослабление по одному или множеству иных форм антител?
Не увеличивается ли вероятность заболеваний другими формами болезней?
Или вопрос в общем виде - имеет ли место быть взаимоисключающий принцип в работе иммунитета в меру ограничения по ресурсам?
При всем уважении, но большая часть описанных в статье проблем не имеют отношения к конкретной используемой СУБД, а очевидно являются проблемами архитектуры, точнее отсутствия управления рисками на этапе проектирования валидации потоков данных и консистентности глобального состояния для совокупности клиентов.
Я бы все-таки отметил, что, когда речь идет о процессе обновления (то есть о состоянии системы в динамике), то речь именно о предметной области обновления (это отдельный домен в DDD) при сохранении функциональной корректности.
Микросервисная архитектура в этом может быть полезна по своему дизайну и свойствам, но процесс маршрутизации трафика между версиями функционала с сохранением работоспособности — предмет обсуждения вне области свойств микросервисной архитектуры, на мой взгляд.
Тоже самое касается консистентности данных в глобальном состоянии (то, что вы называете БД). Вне зависимости от количества версий и репликаций, вне зависимости от контекста, вопрос консистентности глобального состояния — это отдельный домен, отдельная предметная область, по простой причине — она декларирует общее требование (консистентность или более узкое понятие — совместимость, что на самом деле вообще не обязательно для микросервисов), что прямо противоположно свойству атомарной декомпозиции системы.
К чему это я — нет я не оспариваю истинность ваших утверждений (я вообще никогда ни с кем не спорю, так как в этом просто нету смысла), но я пытаюсь отметить (для понимания читателей), что многие ошибки, парадоксы и противоречия (противоречие единого состояния и декомпозиции) возникают там, где нету четкой границы между предметными областями (там, где мы плохо провели границы или не провели их вовсе). Иными словами там, где выделено недостаточно независимых слоев абстракций в представлении системы. Словно система как единое целое представлена недостаточно точно, и эта «неточность» формирует излишние свободы для holy war'ов.
Фактически все статьи вида «что такое <тут любая сущность>?» порождают каскад обсуждений вида дифференциального сравнения свойств двух подмножеств одного семантического множества — именно поэтому спор (дифференциальное сравнение) смысла не имеет, так как несет в себе функцию поиска отличий, вместо процесса классификации (формального определения границы между классами — то есть решение задачи непротиворечивого представления системы в виде набора предметных областей с полным покрытием).
Я снова отмечу в тексте, так как считаю это важным, что речь о микросервисной архитектуре. То есть свойства самих микросервисов, их динамика, их консистентность, связность, состояния, структурная совместимость и эволюция не имеют никакого отношения к архитектуре, а характеризуют лишь сами микросервисы. На уровне же архитектуры возникают свойства более высокого порядка, производные, или так называемая "эмерджентность".
Свойства отдельных глюонов не определяют свойства атома в целом, но глюоны являются частью переносчиков взаимодействия. Макроскопические объекты обладают свойствами, которые не присущи свойствам микроскопических составляющих. В конечном счете восприятие цвета вообще не определено на уровне отдельных фотонов. Все это проявления эмерджентности.
Это вообще слабая сторона в формализации систем (в их полноте представления и непротиворечивости модели).
P.S.
Если не совсем понятно то, о чем я пишу, то я попробую объяснить простыми словами:
Допустим, мы рассуждаем о системе «Самолет» — в прямом смысле о летающей машине с крыльями в общепринятом представлении.
Если мы поставим вопрос о том, что такое «самолет», то фактически вопрос будет слишком абстрактным, но тем не менее, этот термин (класс систем) обладает определенными характеристиками (свойствами).
Например, самолет можно охарактеризовать тем, что это летательный аппарат (то есть предназначенный для полета, формально мы это можем доказать от противного), следовательно он обладает необходимой аэродинамикой, которая представлена его формой (вне зависимости от самой формы), а также самолет характеризуется силовой установкой, приводящей его в движение (тип установки не имеет значения). Сам пример условный, я лишь хочу продемонстрировать ход рассуждений.
— Есть ли у самолета шасси?
— Да есть.
— А что если мы шасси во время полета внутри фюзеляжа поменяем на другие?
— Ну, они должны быть совместимы, иначе посадка будет непредсказуемой.
— Хорошо, они совместимы.
— А что если мы будем менять их поочередно, а не одновременно? А что если бы была возможность заменить один из двигателей на ходу? Или вообще изменить геометрию самолета?
Дело в том, что все это не важно, так как динамические процессы не являются ответом на вопрос, что такое самолет, они не меняют его принципиальных свойств, не меняют глобально класс (подмножество семантическое). Но зато путем замены, мы можем легко перейти в другой класс исследуемых систем, где появятся новые свойства, которые мы совершенно некорректно экстраполируем на исходный объект исследования!
Иными словами свойства шасси, их состав, их характеристики, даже их динамика или их замена в динамике не имеют отношения к классу систем — самолет. Хотя бы потому, что есть самолеты с посадкой на воду…
Понимаете о чем я? Все о том же — о границах предметной области. Если бы статья начиналась с формализации аксиом, на базе которых строятся дальнейшие рассуждения, то комментарии сводились бы к согласию или выявлению (формальному) ошибок в доказательной базе тех свойств, о которых рассуждает автор, приводя модель системы.
Может быть слишком замороченным кажется, но, поверьте, огромное количество времени люди тратят именно на рефакторинг ментальной модели чего-либо в частности и мировоззрения в целом. Мы словно перепрограммируем сами себя снова и снова, пытаясь найти консистентную ассоциативную модель, которая всегда не получается, так как расширение границ познания создает парадоксы вида — «блин, этот факт все меняет...»
Такова наша природа) Простите за «многабукф», мне бывает интересно порассуждать)
Вы, вероятно, не совсем правильно меня поняли. Я описывал своего рода часто встречающееся заблуждение. Я апеллировал к аудитории, представляющей мнение, схожее с мнением автора статьи, который пишет буквально следующее:
И наступает время деплоя. И тут, вам придётся аккуратно последовательно отключать все ваши микросервисы и накатывать новые версии. Процесс долгий, многое может пойти не так.
Иными словами, сама формулировка об остановке противоречит, как Вы правильно указали, свойствам микросервисной архитектуры.
Просто большинство разработчиков, на мой взгляд, среди тех, с кем мне доводилось иметь возможность обсуждать данный вопрос, делают акцент на понятии «микросервисная», в то время как основная смысловая нагрузка содержится в понятии «архитектура».
Иными словами, для большинства — микросервисная архитектура означает микросервисы и их свойства, нежели специфическую архитектуру, свойства которой обусловлены особенностями композиции микросервисов.
Если еще проще сказать, то микросервисная архитектура не про микросервисы, а про топологию, консистентность, актуальность глобального состояния и асинхронную природу внешней среды (в некотором смысле — про энтропию).
А если пытаться выразиться в контексте проекций Футамуры — то микросервисная архитектура — это специализация топологии энтропией ^_^
Вы, вероятно, не совсем правильно истолковали смысл, который я хотел Вам передать. Позвольте, я попробую еще раз объяснить суть парадокса синхронизации:
Допустим, у нас есть одна точка, в которой мы фиксируем событие (любое). Пусть это будет лампочка и ее включение. Когда лампочка включается, мы отмечаем время включения, допустим 12:00:00. Пока все хорошо.
Но как только мы имеем дело более, чем с одним наблюдением, у нас принципиально возникает возможность сравнения (относительности). То есть мы можем соотнести результаты разных измерений между собой. И в этом кроется нюанс.
Соотношение состояний — задача простая. Лампочки обе включены или обе выключены. Сравнить легко.
Но сравнение во времени оказывается крайне нетривиальной задачей. Давайте порассуждаем на этот счет.
Что такое время? Давайте дадим времени некоторое определение через понятие относительности: время — это некий процесс изменения состояний, который мы способны интерпретировать. То есть, понятие времени в статической форме не существует, так как для определения времени необходима система координат и точка отсчета, относительно которой можно фиксировать какое-либо изменение.
Пускай в рамках задачи такой системой будут часы, на которых хорошо видно дискретное изменение состояния (стрелки или цифры меняются с некоторым дискретным шагом).
Так как измерений мы делаем два, то у нас должно быть и два измерительных прибора.
Когда два прибора (часы) находятся рядом, мы можем наблюдать их состояния как эквивалентные по показателям, стрелки отображают одно и то же время.
Когда мы разносим часы на некоторое расстояние, недоступное для нашего прямого наблюдения и интерпретации, принципиально возникает парадокс неопределенности состояния — собственно, так как мы не можем наблюдать состояние других часов, мы видим лишь те, которые мы непосредственно наблюдаем.
Возникает задача сравнения результатов измерения лампочки с привязкой ко времени. Мы неизбежно должны будем из различных частей пространства-времени консолидировать результаты в едином месте для их интерпретации. Именно момент необходимости консолидации (по сути передачи данных на расстояние) оказывается нетривиальным с точки зрения истинных свойств пространства-времени, так как мы ведем расчеты исходя из положения константного значения скорости света.
Но это не обязательно так.
Совершенно эквивалентными будут результаты, если свойства пространства-времени оказываются такими, что условное разнесение в пространстве точно также формирует смещение по времени таким образом, что сигнал, отправленный с Марса на Землю, достигает пункта назначения мгновенно, словно не преодолевая пространство вовсе.
Ровно как и при линейном распространении с константной скоростью.
Иными словами, как только мы перемещаем вторые часы, нам остается лишь «верить» в то, что они показывают точно такое же время, как и наши. В то время как на самом деле, сам факт разнесения в пространстве может обладать свойством искажения пространственно-временного континуума таким образом, что возникает задержка во времени, то есть, вторые часы могут в действительности менять свое состояние совсем не так как первые, допустим идти либо быстрее, либо медленнее, и все решения при подобных допущениях будут эквивалентны, если принимать распространение сигнала не константно (то есть, если относительная скорость распространения будет больше или меньше скорости света).
С проекциями Футамуры не все так просто, на мой взгляд… Поясню:
0. Специализацией называется процедура конкретизации, допустим, 2^х образует множество решений в зависимости от х, но конкретизируя (специализируя) 2^x числом 3 в качестве значения х, мы получаем вид функции 2^3, как форму абстрагированной записи решения = 8, то есть специализация — это редукция когерентной суперпозиции состояний допустимых решений (редукция множества решений путем коллапса этого множества на детерминированном значении).
Простыми словами, мы детерминируем потенциальную суперпозицию системы, «схлопываем» множество виртуальных возможных состояний до конкретного одного.
Поэтому,
1. Первая проекция Футамуры, скажем, на некотором коде высокого уровня по отношению к интерпретатору этого кода (специализация интерпретатора кодом) сформирует редукцию потенциального множества состояний интерпретатора до конкретного состояния — до программы, которая конвертирует конкретный высокоуровневый код в конкретный низкоуровневый, фактически жестко реализуя match'инг из двух множеств.
Иными словами, реализуя конструкцию вида:
IF <тако-то конкретный код> THEN <такой-то выходной>, где информация о выходном была взята специализатором из допустимых возможных состояний интерпретатора.
Первую проекцию называют «компиляцией».
2. Вторая проекция Футамуры предполагает специализацию специализатора кодом самого интерпретатора. Это предполагает следующее:
Код специализатора имеет два аргумента (два входа): что специализировать и чем специализировать. Эти аргументы заранее не определены и могут быть чем угодно, то есть специализатор в отличие от интерпретатора имеет два потенциальных и заранее неопределенных, но связанных множества (по определению специализации).
В таком случае получается, что когда мы специализируем специализатор кодом интерпретатора (правилами интерпретации), мы производим такую редукцию, что, в потенциальном множестве состояний специализатора мы оставляем лишь то множество состояний, которое соотносится один-к-одному с допустимыми состояниями интерпретатора…
Иными словами специализация специализатора интерпретатором порождает не компилятор, а интерпретатор иного рода, по сути индексатор, хеш-функцию. То есть такую программу, которая редуцирована на потенциальном множестве состояний интерпретатора с заранее неопределенным аргументом и создана с целью принимать в качестве аргумента высокоуровневый код и соотносить его с допустимым конкретным значением из (специализированного) потенциального множества низкоуровневых решений.
Фактически специализация — это индексирование. Таким образом, специализация специализатора на интерпретаторе порождает индексатор состояний интерпретатора.
Иными словами, мы делаем редукцию множества состояний специализатора, оставляя из него только то подмножество состояний, которое соотносится к множеству состояний специализатора, которое определено множеством соотносимых друг к другу один-к-одному множеств двух аргументов.
То есть мы получаем на выходе такую программу (редукцию специализатора), которая индексирует все решения, которые могут быть представлены двумерным индексом вида «правила преобразования кода» и «сам код» в качестве «координат», на пересечении которых находится состояние решения проекции конкретного высокоуровневого кода в конкретный низкоуровневый код.
Простыми словами, мы получаем программу представляющую собой уравнение вида F(правила, код) -> низкоуровневый код, таким образом, что:
— подставляя в нее лишь правила, мы получаем подмножество всех допустимых состояний интерпретатора (то есть все возможные виды компиляции всех возможных аргументов — видов компилируемого кода),
— подставляя только код — подмножество всех возможных интерпретаторов с множеством всех возможных интерпретаций, относительно высокоуровневого кода,
— но, подставляя правила и низкоуровневый код — мы можем получить допустимое подмножество исходного высокоуровневого кода в качестве решения (то есть мы вырождаем дизассемблер)
На мой взгляд, смысл микросервисной архитектуры некорректно понимают даже многие из тех, кто ее якобы использует.
Сначала я опишу то, что часто считают проблемами микросервисной архитектуры:
1. Микросервисная архитектура не предполагает единство протокола взаимодействия, так как подобное обобщение является распространением глобальной декларации, а любая декларация формирует зависимость, в итоге это утверждение уже само по себе нивелирует смысл декомпозиции.
Простыми словами, как только вы придумываете «правило», у вас возникает проблема с «соблюдением этого правила». Иными словами вы неизбежно попадаете в проблему парадокса консистентности, считая это свойством микросервисной архитектуры, но это не так — это лишь свойство противоречивого суждения: мы разделим все на независимые части и создадим для них зависимость…
2. Микросервисы сложно обновлять, так как всю систему нужно «остановить». Это тоже является следствием некорректного формирования зависимостей между функциональными сущностями (собственно, микросервисами). Все это имеет одну и ту же природу — большинство разработчиков не понимает сути декомпозиции.
Д е к о м п о з и ц и я — это не просто разделение «слова на буквы». Это принципиальное выделение в отдельные доменные области (Д) (е) (к) (о) (м) (п) (о) (з) (и) (ц) (и) (я), которые можно представить как вершины графа, и которые имеют возможность (а не обязанность) взаимодействуя формировать динамические конфигурации, топология которых будет представлена множеством из N*(N-1)/2 связей (без учета рекурсии), а конфигуративное множество иметь факториальную зависимость.
Таким образом, декомпозиция — это мощнейший инструмент превращения системы из состояния с малым количеством степеней свободы (и высоким кол-вом ограничений — об этом ниже) в систему с высоким количеством степеней свободы — то есть, таким образом, мы получаем доступ к потенциальному множество (фазовому пространству) доступных конфигураций, можем их исследовать (через редукцию, иначе это NP-полная задача) и выбирать оптимальную топологию (кластеризацию, как статическую, так и динамическую).
Иными словами, сложность обновления — это не свойство микросервисной архитектуры, это свойство топологии связей частей целого, выбранное таким образом, что консистентное мгновенное состояние системы оказывается зависимо от неконсистентности (разнесенном во времени и/или пространстве запуске) микросервисов.
Если сказать проще — вы ожидаете единство глобального состояния системы при принципиальном выборе декомпозиции сущностей композитно образующих это состояние.
Вы словно пытаетесь собрать воедино бревна, которые сплавляете по реке, вместо консолидированной перевозки их в грузовике, сравнивая одно с микросервисами, другое с монолитом (условно одним рантаймом), считая минусом тот факт, что по реке бревна приходят в заранее плохо предсказуемом порядке (либо приходят не все или не приходят вовсе).
3. Энтропия. Фактически все минусы возникают в неосознанном и неумелом контроле энтропии в системе. Ее «утечка» происходит, либо в меру нелинейного роста сложности топологии при неосозанном подходе к декомпозиции (так как степень свободы в топологии растет в общем случае квадратично N^2, а конфигуративное множество — факториально, следовательно редукцию делать все сложнее), либо в меру вытеснения в мета-конфигурации (вытеснение конфигурирования частей системы в рантайм — фактически это так называемая проблема интерпретации в контексте нейросетей), создает ощущение «минусов», либо очевидные с практической точки зрения ограничения. Но все эти минусы и ограничения — это следствия малой степени осознания процесса управления сложностью (контроль энтропии).
4. Накладные расходы. Дело в том, что любая сериализация данных, будь то трансфер по шине между кешами, преобразование в форматы для передачи, образование пакетов, межпроцессные взаимодействия и т.д. сопряжены с накладными расходами на абстрагирование, но эти накладные расходы должны быть осознаны с точки зрения принципиального снятия ограничения на масштабирование и параллелизм. В случае, когда не возникает осознания в том, зачем создавать абстракцию (сериализовать данные), очевидным образом следует, что на практике не возникали естественные причины, которые побудили бы к необходимости решать проблему вертикального масштабирования и неконтролируемого роста сложности, только и всего.
Так в чем же сакральный смысл микросервисов?
Сутью микросервисов является намеренное и осознанное абстрагирование функциональной сущности от «канального уровня» передачи сообщений.
Система формируется таким образом, что в ней принципиально заранее нету договоренностей между отправителями и адресатами (подписчиками в общем случае). Ее конфигурационная неопределенность (высокая степень энтропии в топологии), закладывается как часть дизайна. Эта же неопределенность формирует принципиальную неконсистентность глобального состояния.
Да, вы можете намеренно внедрить в систему консистентность глобального состояния путем внедрения кворума на синхронизацию, тем же блокчейном (как классом взаимозависимости в данных), или создать систему с высокой степенью синхронизации по времени, но сам факт консолидации состояний при декомпозированном дизайне обладает стоимостью на сериализацию + синхронизацию (выборы, кворум). Вы должны четко понимать, зачем вам это нужно, почему вы это делаете, готовы ли вы заплатить стоимость такого latency, не станет ли сам факт синхронизации бутылочным горлышком системы. Вы должны четко понимать, какие свойства для вашей системы целевые, иначе это басня Крылова «Мартышка и очки».
Так как микросервисы абстрагированы от «канального уровня» у них есть лишь одна точка входа — канал передачи сообщений. Его реализация вносит вклад в свойства обмена сообщениями, но не имеет принципиального значения для архитектуры. Как правило, этот канал либо пассивный, либо активный (активный фильтр), который представляет собой очередь, — своего рода «конвейер», либо с одной «лентой», либо со множеством параллельных «лент», либо даже множеством множеств таких конфигураций, которые между собой зеркалируют сообщения (допустим, при объединении в один логический контур совокупности имплементаций шин на разных технологиях).
При таком подходе выбор топологии связей между сущностями не предполагает единой декларации протоколов, правил взаимодействия, а предполагает декларацию понятия «шины», внутри которой происходит трансфер сообщений с той сигнатурой, которую определили между собой конечные функциональные сущности. Иными словами формируется множество протоколов между «черными коробками», образуя конечную конфигурацию связей функциональных сущностей, которые в свою очередь (микросервисы) могут асинхронно (если вы намеренно не внесли консистентность, как я писал выше) влиять на глобальное состояние.
Микросервисы выбирают не только и не столько потому, что они снимают ряд ограничений на масштабирование, сколько потому, что асинхронная природа разнесенных во времени рантаймов коррелирует с высокой степенью энтропии воздействующих на систему в реальном времени событий.
Иными словами, микросервисная архитектура позволяет создавать масштабируемые системы (любого масштаба), которые пытаются «скальпировать» реальность с минимальным latency, но лишь при условии, что создатели осознают высокую стоимость сериализации на передачу сигналов, а также зависимость между стоимостью сериализации и степенью параллелизма, которые и формируют сходимость системы к некоторому минимальному latency в процессе проекции асинхронных потоков в глобальное состояние (в global state — с точки зрения понятия statefull, что упрощенно можно представить как некий консолидированный map-reduce по всем данным, или «отчет»), которое в свою очередь будет консистентно на момент времени t-1, но в настоящий момент времени будет оставаться принципиально неактуальным по аналогии с вашим намерением прокрутить скролл на странице с самим фактом прокручивания и наблюдением результата в меру latency на «сериализацию» данных через органы восприятия.
Все мы интерпретируем «прошлое», считая его актуальным настоящим. Это лишь вопрос масштабов времени. Для коммерческих систем реального времени необходимость реагировать быстро эквивалентна инстинкту самосохранения.
С «мгновенностью» синхронизации спутанных фотонов не совсем корректное утверждение (глобальное заблуждение), так как возникает парадокс самой проверки:
Представьте, что у вас две «спутанные лампочки», которые загораются одновременно для простоты метафоры.
Вы берете одну и другую и разносите их в разные части пространства, скажем, одна на Земле, другая на Марсе.
Вы включаете одну лампочку и фиксируете время, когда она зажглась (будем считать, что зажигается она мгновенно), тоже самое фиксируют относительно другой лампочки.
Но вот в чем вопрос — а как сверить результаты? Для этого у вас должны быть высокоточные синхронизированные (насколько это возможно) часы. Допустим, у вас есть часы идеально синхронизированные, по которым ведется логирование событий.
Но когда вы перемещаетесь в пространстве для того, чтобы «отнести как можно подальше» лампочку, возникает эффект искажения пространства-времени из-за факта перемещения.
В итоге тот факт, что явление «зажигания лампочки» происходит в «один момент времени», в действительности может сам по себе включать необходимую задержку на синхронизацию состояний в самих часах.
Я хочу сказать, что сама пространственно-временная конфигурация эксперимента от его начала до его завершения со сверкой логов и часов может включать в себя необходимый объем энтропии (необходимое время и энергию), который мы по ошибке не замечаем, предполагая, что пространство-время линейно и интерпретируем результат как «мгновенную передачу состояния», но это не обязательно так, это лишь гипотеза о мгновенности, либо явная ошибка в интерпретации пространственно-временной конфигурации.
P.S.
Это в принципе фундаментальная проблема суперпозиции.
Если гипотетически допустить, что это объект искусственного происхождения, то что, если его траектория прохождения в солнечной системе не случайна?
Раскрывая мысль, я хотел бы задаться вопросом, можно ли каким-либо образом проверить, куда этот объект направляется (если допустить, что он движется без существенной коррекции траектории, вне зависимости от природы этой коррекции, газ ли это или давление солнечного ветра) с точки зрения его возможных пересечений с другими звездными системами в будущем?
Подскажите, был ли опыт создания кастомных стоек (стеллажей), совершенно неформатных. У меня возникла задача построения лабораторного стенда с оборудованием (совокупность микро-серверов, кастомные платы, наборы дисков), для чего требуется что-то вроде гибкого конструктора. Все что нашел — это довольно габаритные и грубые конструкционные профили.
Может быть кто-то сталкивался с изящным решением данной задачи?
Интересное наблюдение. Корпус действительно хорош. Видимо у данной модели диска не очень удачная конструкция двигателя, а его шумо-вибро-изоляция (скажем, если приклеить на диск какой-то шумо-вибро-поглощающий материал прямо на корпус, может потенциально привести к перегреву).
Как говорится, буду иметь в виду при выборе дисков!
Я полагаю, что доводить предупреждения до абсурда как минимум не разумно.
Предупреждения должны быть исключительно об опасности здоровью и жизни на объектах, представляющих такую опасность, например, на трансформаторных щитках, где явно написано — Осторожно! Высокое напряжение! Опасно для жизни! Либо на опасных участках дороги, где совсем неочевидно, что покрытие может быть скользким, а поворот слишком крутым и т.д.
В таких сообщениях есть смысл, так как любое наивное касание элементов под напряжением с высокой долей вероятности именно убьет. Не каждый человек обязан знать электрику, особенности схем, фазы, что можно трогать, а что нет, и тем более предсказывать будущее в ограниченном наборе информации.
Критерием для подобных предупреждений является «НЕЗНАНИЕ» человека в полной форме, то есть человек может даже не догадываться о том, что какой-то силовой кабель или дверка трансформаторного щитка из-за неисправности под напряжением, а безобидный закрытый поворот может увести его в кювет даже на малой скорости из-за, скажем, песка на дороге.
В случае же с тем, что люди имеют какие-то недостатки со здоровьем, о которых они знают или НЕ знают, касаются субъектов, а не относятся к объектам.
То есть, как в примере выше, если у человека гастрит явный или только в начальной стадии, о которой он не подозревает, и ему запрещено или дискомфортно употреблять в пищу сильно острое, кислое, жареное, но он это упорно делает, испытывая дискомфорт, боль, то это говорит в первую очередь о том, что субъект по отношению к своему здоровью невнимателен, и он не может перекладывать свою ответственность на других, мол, меня не предупредили, что пить водку нельзя при язвенной болезни желудочно-кишечного тракта!
Чем эпилепсия принципиально отличается, если человек о ней знает, но продолжает смотреть на быстрые контрастные сцены?
Но даже если не знает, что говорит о том, что он никогда не сталкивался прежде, ни с гастритом, ни с эпилепсией, то мы можем полагать, что у любого человека, не обладающего явным знанием есть ненулевая вероятность любой болезни, начиная от эпилепсии, защемлением нервов в позвоночнике, риском развития сколиоза, уменьшению кровообращения в сидячем положении, риском развития кариеса, если в игре есть сцены с изображением пищи, что провоцирует игрока принести «покушать бутер», не говоря уже о том, что при низкой частоте модуляции подсветки будут сильно напрягаться глаза, что приведет к ухудшению зрения.
Неужели было бы разумным к каждому объекту выдавать сборник томов противопоказаний?
Я полагаю — нет. Более того, есть достаточно формальный критерий адекватности предупреждений, где они действительно необходимы, и где они мягко говоря избыточны, либо дискриминируют права на безопасность других групп граждан, которые могут нанести вред своему здоровью, «так как не было написано, что нельзя!»
Было бы хорошо, чтобы все правила, включая законодательную базу, имели под собой не просто частный случай условно субъективной оценки, а хотя бы более-менее целостную логическую систему суждений, но, к сожалению, это где-то в идеальном мире, в реальности же люди будут занимать позицию субъективно правильных выводов, но в своем очень узком scope, относительно общей картины.
Однажды столкнулся с такой ситуацией — в какой-то момент времени, я решил установить диск серии Seagate Constellation ES.3, который сам по себе достаточно шумный при работе (работа механизмов управления головками) на мягкую резиновую «подушку», а также соединения в корзине использовал через резиновые «шайбочки».
Мне хотелось проверить, насколько такое вибропоглощающее крепление сможет снизить шум.
Я был впечатлен, но шум практически полностью исчез, включая шум работы головок диска. Как оказалось, любой слышимый шум в основном создается поверхностями корпуса, при передачи ему вибраций, даже малейший, по крайней мере, в моем случае, так как корпус был выполнен из цельных листов металла.
Тоже самое касается всех вентиляторов, они почти перестают издавать шум, как только они ставятся через прорезиненные крепления (из мягкой резины) или силиконовые прокладки.
То, что раньше казалось мне шумом работы HDD — оказалось по сути шумом всяческих резонансов корпуса.
То, что раньше казалось мне шумом работы вентиляторов, оказалось все тем же шумом от корпусных конструкций. В действительности же шум воздушного потока в чистом виде достаточно тихий, даже на высоких оборотах вентиляторов.
В итоге даже системный блок ножками ставлю на прорезиненные подкладки, так как малейшая вибрация может передаваться на поверхность, на котором он стоит (в моем случае на пол, на паркетную доску).
P.S. Я также пробовал звукопоглощающие материалы ставить на стенки, но они лишь немного приглушают общий шум системы.
Попробуйте, возможно, такой совет кажется банальным, но он может дать неожиданный эффект! По крайней мере для меня это был настоящий Wow-эффект, так как я не ожидал, что незначительные вибрации могут вносить свой вклад в общий шум системы на ~80% (субъективная оценка).
Этап эволюции вещества (энергии)
Деление на сущности - декомпозиция, это артефакт мышления и часть процесса познания, метод, которым мы пользуемся естественным образом при создании мысленной проекции (модели) реальности.
Очевидно, что этот процесс, будучи моделированием реальности, а не самой реальностью, может и будет иметь неточности, которые можно назвать "избыточной декомпозицией" и "недостаточной декомпозицией".
Формальным критерием правильного процесса декомпозиции, на мой скромный взгляд, будет являться критерий получения новой информации, а именно:
Если декомпозиция даёт нам качественно новую информацию (полезную в прикладном смысле), то такая декомпозиция оправдана.
Если декомпозиция даёт информацию, которая является эквивалентной по своей семантике уже имеющимся сведениям, то такая декомпозиция не представляет интереса, так как это избыточное усложнение модели.
Когда в процессе декомпозиции и извлечения информации возникает достаточно оснований для оптимизации, происходит значительное уменьшение сложности модели, ее "универсализация", в том смысле, что общие свойства наблюдаемого представляются значительно более простой конструкцией.
Итог и основная мысль, которую я хотел передать этим сообщением заключается в том, что путь познания до формирования красивого и минималистичного представления о реальности или отдельных аспектов реальности зачастую предполагает тернистый путь поиска и извлечения информации через анализ зависимостей, которые возникают при декомпозиции.
Я внимательно прочитал статью и все комментарии, и мне хотелось бы добавить мнение о том, что физика хороша избирательно, а в общее восприятие (пользовательский опыт) как раз во многом делают вклад именно малозаметные детали.
Допустим, игра изобилует открытыми пространствами, полями, лесами, много растительности - здесь очевидным образом напрашивается реалистичная модель взаимодействия с окружающей средой, чтобы на траве оставался след, чтобы деревья можно было физически реалистично повредить, или сделать эти повреждения частью игровой механики, ведь это очень увлекательно! Представьте себе какую-то баталию пусть даже сетевую, где нагромождение срубленных деревьев является элементом защиты, условной "стеной". Или распространение огня по сухой траве, как это было отчасти реализовано в одной из частей FarCry.
Вторым ярким примером можно привести шутеры, где визуальные эффекты попадания тем усиливаются, чем больше взаимодействия происходит с окружающими объектами. Например, попадания пуль в стену могут приводить к частичному разрушению стены, попадание из более серьезного оружия - полностью разрушать объект (здание). Если взять за основу тот же PUBG, по своей сути обычная стрелялка в виде "охоты на противника", то насколько бы преобразился игровой процесс, если бы из пулемета можно было бы "прошить стену" насквозь или "срубать деревья", разрушать объекты, в которых прячутся игроки.
Моя ключевая мысль заключается в том, что физика ради физики имеет масло смысла до тех пор, пока она не становится ключевым элементом игровой механики, соответственно, такой элемент добавляет большое количество степеней свободы (для фантазии игрока), что и воспринимается как качественный игровой опыт, по аналогии с переходом от коридорных шутеров к открытым мирам (но мирам не пустым, а наполненным приключениями).
Совершенно верно, причем неравенство N != NP порождает ловушку для пытливых умов. Этой проблемой (классом задач) можно заниматься бесконечно из любопытства, можно перегорать в поисках ответов, не находя их долгое время, и от того, эти "крепкие орешки" будут становиться все более интересными - вершинами, покорение которых, на мой взгляд, должно быть в основе как минимум популяризации математики и математического мышления.
Так в моем личном опыте было с простыми числами, и вот уже много лет, буквально в любой задаче, при определенной глубине проработки, упираешься в простые числа, с улыбкой понимая, и думая про себя "ну вот мы снова встретились)", а затем стоит выбор - попытаться снова проработать интереснейшую задачу оценки распределения, залипнув надолго и скорее всего безрезультатно, или же умерить свой пыл и реализовать необходимый и достаточный с практической точки зрения аппарат решения задачи.
В этом прелесть всей математики - она позволяет моделировать, но все модели, какими бы целостными и завершенными, самодостаточными они ни казались, фундаментально имеют слабую основу, уходящую корнями в осознание невозможности точного решения.
Математика словно кино, в последней сцене которого есть намеки на продолжение)
Разумеется, это так, все совершенно верно, и в допустимых в прикладном значении рамках мы (человечество) активно используем эвристические методы, методы нечеткой логики, для решения задач там, где это возможно.
В некотором смысле нами движет любопытство, приводящее к гипотезам вида - "а что, если бы мы проанализировали изменение отдельно взятых параметров, то смогли бы гипотетически и приблизительно предположить, что миры с иными конфигурациями не могут содержать жизнь". Но в этом одновременно и вся ирония - из-за самой природы объекта, над которым мы мыслим, такие исследования лишены какого-либо смысла, кроме смысла заниматься самим процессом. Это похоже не игру ради игры, ради процесса, и я не отрицаю, что это интересно и захватывающе, так как и сам периодически "залипаю" в подобных процессах, но не ради победы, финала, детерминированного ответа.
Моя основная мысль здесь скорее в том, что мы можем заранее понять, можем ли мы решить задачу точно, или же наше решение будет где-то на грани софистики.
Позволю себе еще один пример: допустим мы хотим испечь вкусный кекс, но мы не знаем точный рецепт, мы просто понимаем приблизительные ингредиенты и приблизительные их пропорции, не имея модели, определяющие вкусовые качества и свойства конечного продукта. В таком случае успех с точки зрения ощущений при употреблении в пищу конечного продукта будет носить случайный характер, а наше мастерство в кулинарном деле - пропорционально кол-ву экспериментов - то есть тому, насколько мы смогли удачно редуцировать фазовое пространство (комбинаторное множество) всех возможных вариантов кексов из всех допустимых ингредиентов.
Существуют ли формы жизни в иных мирах? Вопрос эквивалентный задаче выпечки вкусного кекса без заранее определенного рецепта. В таком случае, условные "островки жизни" - это такие же "островки вкусных кексов", где вроде бы не слишком много соли, не слишком много сахара, не слишком много воды и т.д. Вроде бы должно быть вкусно, а как будет - так будет, но сам процесс исследования и выпекания увлекателен для нашего разума, хотя и является математической рутиной, - по сути проблемой, необходимость решения которой породила теорию автоматического управления.
Если рассуждать о классах задач, то все задачи анализа возможных конфигураций системы с большим количеством параметров неразрешимы из-за численной оценки комбинаций, превышающих разумные значения.
Приведу пример:
Число́ Ше́ннона — оценочное минимальное количество неповторяющихся шахматных партий, вычисленное в 1950 году американским математиком Клодом Шенноном. Составляет приблизительно 10^120.
Для сравнения — количество атомов в наблюдаемой Вселенной составляет по разным оценкам от 10^79 до 10^81, то есть в 10^40 раз меньше числа Шеннона.
Исследование бесконечных множеств, например, множество простых чисел, или пример с оценкой последовательности, известной как Гипотеза Коллатца (проблема 3x+1).
Исследование конфигураций, описываемых странным аттрактором.
Это говорит о принципиальной невозможности анализа без какой-то радикальной редукции комбинаторного множества этого класса задач. При этом стоит отметить, что редукцию (и это следует из контекста рассуждений в статье выше) мы будем производить исходя из оценки свойств исследуемых конфигураций миров на "допустимых диапазонах" в рамках измерений.
Простыми словами, мы увидим, что при такой-то конфигурации, с нашей точки зрения, жизнь в исследуемой мире невозможна, потому что структура атома (любого), допустим, будет нестабильна (это показано на рисунке "островком стабильности"). Но при этом мы допускаем фатальную ошибку, исключая любые иные формы взаимодействия более высоких порядков (комбинации значений в измерениях), а их между прочим N! (факториальная зависимость).
Простейший пример:
Допустим, мы собираем гоночный автомобиль, и при оценке параметров массы автомобиля, исходим из того, что высокий вес авто мешает ускорению из-за инерции, и отсекаем все решения, которые по нашей оценке слишком тяжелые, делая болид в 1100 кг веса, но есть класс авто, которые весят в 2+ раза больше, и при этом позволяют реализовать очень интенсивное ускорение за счет оптимизации других параметров.
Так и в нашем случае эго-центризма, - тот факт, что мы субъективно интерпретируем этот мир таким, оценивая его конфигурацию через набор констант, и делая предположения о его структуре - фактически, реализуя факторный анализ, - говорит нам о том, что мы не знаем модель мира, но когда модель зависимостей всех параметров всех порядков неизвестна достоверно, мы не можем сделать редукцию никак, кроме как через набор аксиом. О проблеме интерпретации еще будет пара слов ниже.
Может оказаться так, что конфигурация пространства-времени зависима от уникального сочетания совокупности отдельно взятых параметров, и все они связаны в единую модель, но не являются независимыми сами по себе, поэтому редукция потенциального множества конфигураций (фазового пространства) на заданной метрике, пусть для упрощения [ a, b, c, d, ... ], на основании того, что параметр "а" может быть, по нашему представлению, в диапазоне от 0.73 до 0.87, может быть принципиально ошибочным - мы банально выбросим те варианты более сложных конфигураций, которые могут оказаться допустимыми по критерию интерпретации динамических процессов внутри такого мира, которые мы субъективно могли бы оценить как "жизнь".
Вы совершенно правы, относительно сложности задачи, но, на мой взгляд, стоит отметить, что существует задача еще более высокого уровня, которая не связана с исследованием гипотетических конфигураций иных миров, а присутствует здесь и сейчас в фактической реальности - феномен интерпретатора.
Рассматривать проблему (задачу) феномена интерпретатора можно с различных позиций, как материальной, так и сугубо математической, отчасти эту проблему можно рассмотреть с позиции антропного принципа, но ни один современный подход за всю историю человечества (насколько я могу судить по той информации, что изучал многие годы) не продвинулся сколь-либо значимо в этом направлении.
Здравствуйте!
Хотел бы задать вопрос экспертам в теме: существует ли корреляция между увеличением антител (к спайк-белку) SARS-CoV-2 и уменьшением других, имеющихся антител в организме, т.е. своего рода усиление "ответа" к SARS-CoV-2, но ослабление по одному или множеству иных форм антител?
Не увеличивается ли вероятность заболеваний другими формами болезней?
Или вопрос в общем виде - имеет ли место быть взаимоисключающий принцип в работе иммунитета в меру ограничения по ресурсам?
При всем уважении, но большая часть описанных в статье проблем не имеют отношения к конкретной используемой СУБД, а очевидно являются проблемами архитектуры, точнее отсутствия управления рисками на этапе проектирования валидации потоков данных и консистентности глобального состояния для совокупности клиентов.
Вы адекватный человек, потому как любить общаться с теми, кто Вам не нравится, если не логический парадокс, то близко к этому.
Микросервисная архитектура в этом может быть полезна по своему дизайну и свойствам, но процесс маршрутизации трафика между версиями функционала с сохранением работоспособности — предмет обсуждения вне области свойств микросервисной архитектуры, на мой взгляд.
Тоже самое касается консистентности данных в глобальном состоянии (то, что вы называете БД). Вне зависимости от количества версий и репликаций, вне зависимости от контекста, вопрос консистентности глобального состояния — это отдельный домен, отдельная предметная область, по простой причине — она декларирует общее требование (консистентность или более узкое понятие — совместимость, что на самом деле вообще не обязательно для микросервисов), что прямо противоположно свойству атомарной декомпозиции системы.
К чему это я — нет я не оспариваю истинность ваших утверждений (я вообще никогда ни с кем не спорю, так как в этом просто нету смысла), но я пытаюсь отметить (для понимания читателей), что многие ошибки, парадоксы и противоречия (противоречие единого состояния и декомпозиции) возникают там, где нету четкой границы между предметными областями (там, где мы плохо провели границы или не провели их вовсе). Иными словами там, где выделено недостаточно независимых слоев абстракций в представлении системы. Словно система как единое целое представлена недостаточно точно, и эта «неточность» формирует излишние свободы для holy war'ов.
Фактически все статьи вида «что такое <тут любая сущность>?» порождают каскад обсуждений вида дифференциального сравнения свойств двух подмножеств одного семантического множества — именно поэтому спор (дифференциальное сравнение) смысла не имеет, так как несет в себе функцию поиска отличий, вместо процесса классификации (формального определения границы между классами — то есть решение задачи непротиворечивого представления системы в виде набора предметных областей с полным покрытием).
Я снова отмечу в тексте, так как считаю это важным, что речь о микросервисной архитектуре. То есть свойства самих микросервисов, их динамика, их консистентность, связность, состояния, структурная совместимость и эволюция не имеют никакого отношения к архитектуре, а характеризуют лишь сами микросервисы. На уровне же архитектуры возникают свойства более высокого порядка, производные, или так называемая "эмерджентность".
Свойства отдельных глюонов не определяют свойства атома в целом, но глюоны являются частью переносчиков взаимодействия. Макроскопические объекты обладают свойствами, которые не присущи свойствам микроскопических составляющих. В конечном счете восприятие цвета вообще не определено на уровне отдельных фотонов. Все это проявления эмерджентности.
Это вообще слабая сторона в формализации систем (в их полноте представления и непротиворечивости модели).
P.S.
Если не совсем понятно то, о чем я пишу, то я попробую объяснить простыми словами:
Допустим, мы рассуждаем о системе «Самолет» — в прямом смысле о летающей машине с крыльями в общепринятом представлении.
Если мы поставим вопрос о том, что такое «самолет», то фактически вопрос будет слишком абстрактным, но тем не менее, этот термин (класс систем) обладает определенными характеристиками (свойствами).
Например, самолет можно охарактеризовать тем, что это летательный аппарат (то есть предназначенный для полета, формально мы это можем доказать от противного), следовательно он обладает необходимой аэродинамикой, которая представлена его формой (вне зависимости от самой формы), а также самолет характеризуется силовой установкой, приводящей его в движение (тип установки не имеет значения). Сам пример условный, я лишь хочу продемонстрировать ход рассуждений.
— Есть ли у самолета шасси?
— Да есть.
— А что если мы шасси во время полета внутри фюзеляжа поменяем на другие?
— Ну, они должны быть совместимы, иначе посадка будет непредсказуемой.
— Хорошо, они совместимы.
— А что если мы будем менять их поочередно, а не одновременно? А что если бы была возможность заменить один из двигателей на ходу? Или вообще изменить геометрию самолета?
Дело в том, что все это не важно, так как динамические процессы не являются ответом на вопрос, что такое самолет, они не меняют его принципиальных свойств, не меняют глобально класс (подмножество семантическое). Но зато путем замены, мы можем легко перейти в другой класс исследуемых систем, где появятся новые свойства, которые мы совершенно некорректно экстраполируем на исходный объект исследования!
Иными словами свойства шасси, их состав, их характеристики, даже их динамика или их замена в динамике не имеют отношения к классу систем — самолет. Хотя бы потому, что есть самолеты с посадкой на воду…
Понимаете о чем я? Все о том же — о границах предметной области. Если бы статья начиналась с формализации аксиом, на базе которых строятся дальнейшие рассуждения, то комментарии сводились бы к согласию или выявлению (формальному) ошибок в доказательной базе тех свойств, о которых рассуждает автор, приводя модель системы.
Может быть слишком замороченным кажется, но, поверьте, огромное количество времени люди тратят именно на рефакторинг ментальной модели чего-либо в частности и мировоззрения в целом. Мы словно перепрограммируем сами себя снова и снова, пытаясь найти консистентную ассоциативную модель, которая всегда не получается, так как расширение границ познания создает парадоксы вида — «блин, этот факт все меняет...»
Такова наша природа) Простите за «многабукф», мне бывает интересно порассуждать)
Иными словами, сама формулировка об остановке противоречит, как Вы правильно указали, свойствам микросервисной архитектуры.
Просто большинство разработчиков, на мой взгляд, среди тех, с кем мне доводилось иметь возможность обсуждать данный вопрос, делают акцент на понятии «микросервисная», в то время как основная смысловая нагрузка содержится в понятии «архитектура».
Иными словами, для большинства — микросервисная архитектура означает микросервисы и их свойства, нежели специфическую архитектуру, свойства которой обусловлены особенностями композиции микросервисов.
Если еще проще сказать, то микросервисная архитектура не про микросервисы, а про топологию, консистентность, актуальность глобального состояния и асинхронную природу внешней среды (в некотором смысле — про энтропию).
А если пытаться выразиться в контексте проекций Футамуры — то микросервисная архитектура — это специализация топологии энтропией ^_^
Допустим, у нас есть одна точка, в которой мы фиксируем событие (любое). Пусть это будет лампочка и ее включение. Когда лампочка включается, мы отмечаем время включения, допустим 12:00:00. Пока все хорошо.
Но как только мы имеем дело более, чем с одним наблюдением, у нас принципиально возникает возможность сравнения (относительности). То есть мы можем соотнести результаты разных измерений между собой. И в этом кроется нюанс.
Соотношение состояний — задача простая. Лампочки обе включены или обе выключены. Сравнить легко.
Но сравнение во времени оказывается крайне нетривиальной задачей. Давайте порассуждаем на этот счет.
Что такое время? Давайте дадим времени некоторое определение через понятие относительности: время — это некий процесс изменения состояний, который мы способны интерпретировать. То есть, понятие времени в статической форме не существует, так как для определения времени необходима система координат и точка отсчета, относительно которой можно фиксировать какое-либо изменение.
Пускай в рамках задачи такой системой будут часы, на которых хорошо видно дискретное изменение состояния (стрелки или цифры меняются с некоторым дискретным шагом).
Так как измерений мы делаем два, то у нас должно быть и два измерительных прибора.
Когда два прибора (часы) находятся рядом, мы можем наблюдать их состояния как эквивалентные по показателям, стрелки отображают одно и то же время.
Когда мы разносим часы на некоторое расстояние, недоступное для нашего прямого наблюдения и интерпретации, принципиально возникает парадокс неопределенности состояния — собственно, так как мы не можем наблюдать состояние других часов, мы видим лишь те, которые мы непосредственно наблюдаем.
Возникает задача сравнения результатов измерения лампочки с привязкой ко времени. Мы неизбежно должны будем из различных частей пространства-времени консолидировать результаты в едином месте для их интерпретации. Именно момент необходимости консолидации (по сути передачи данных на расстояние) оказывается нетривиальным с точки зрения истинных свойств пространства-времени, так как мы ведем расчеты исходя из положения константного значения скорости света.
Но это не обязательно так.
Совершенно эквивалентными будут результаты, если свойства пространства-времени оказываются такими, что условное разнесение в пространстве точно также формирует смещение по времени таким образом, что сигнал, отправленный с Марса на Землю, достигает пункта назначения мгновенно, словно не преодолевая пространство вовсе.
Ровно как и при линейном распространении с константной скоростью.
Иными словами, как только мы перемещаем вторые часы, нам остается лишь «верить» в то, что они показывают точно такое же время, как и наши. В то время как на самом деле, сам факт разнесения в пространстве может обладать свойством искажения пространственно-временного континуума таким образом, что возникает задержка во времени, то есть, вторые часы могут в действительности менять свое состояние совсем не так как первые, допустим идти либо быстрее, либо медленнее, и все решения при подобных допущениях будут эквивалентны, если принимать распространение сигнала не константно (то есть, если относительная скорость распространения будет больше или меньше скорости света).
0. Специализацией называется процедура конкретизации, допустим, 2^х образует множество решений в зависимости от х, но конкретизируя (специализируя) 2^x числом 3 в качестве значения х, мы получаем вид функции 2^3, как форму абстрагированной записи решения = 8, то есть специализация — это редукция когерентной суперпозиции состояний допустимых решений (редукция множества решений путем коллапса этого множества на детерминированном значении).
Простыми словами, мы детерминируем потенциальную суперпозицию системы, «схлопываем» множество виртуальных возможных состояний до конкретного одного.
Поэтому,
1. Первая проекция Футамуры, скажем, на некотором коде высокого уровня по отношению к интерпретатору этого кода (специализация интерпретатора кодом) сформирует редукцию потенциального множества состояний интерпретатора до конкретного состояния — до программы, которая конвертирует конкретный высокоуровневый код в конкретный низкоуровневый, фактически жестко реализуя match'инг из двух множеств.
Иными словами, реализуя конструкцию вида:
IF <тако-то конкретный код> THEN <такой-то выходной>, где информация о выходном была взята специализатором из допустимых возможных состояний интерпретатора.
Первую проекцию называют «компиляцией».
2. Вторая проекция Футамуры предполагает специализацию специализатора кодом самого интерпретатора. Это предполагает следующее:
Код специализатора имеет два аргумента (два входа): что специализировать и чем специализировать. Эти аргументы заранее не определены и могут быть чем угодно, то есть специализатор в отличие от интерпретатора имеет два потенциальных и заранее неопределенных, но связанных множества (по определению специализации).
В таком случае получается, что когда мы специализируем специализатор кодом интерпретатора (правилами интерпретации), мы производим такую редукцию, что, в потенциальном множестве состояний специализатора мы оставляем лишь то множество состояний, которое соотносится один-к-одному с допустимыми состояниями интерпретатора…
Иными словами специализация специализатора интерпретатором порождает не компилятор, а интерпретатор иного рода, по сути индексатор, хеш-функцию. То есть такую программу, которая редуцирована на потенциальном множестве состояний интерпретатора с заранее неопределенным аргументом и создана с целью принимать в качестве аргумента высокоуровневый код и соотносить его с допустимым конкретным значением из (специализированного) потенциального множества низкоуровневых решений.
Фактически специализация — это индексирование. Таким образом, специализация специализатора на интерпретаторе порождает индексатор состояний интерпретатора.
Ладно, едем дальше…
3. Третья проекция Футамуры: специализация специализатора специализатором.
Иными словами, мы делаем редукцию множества состояний специализатора, оставляя из него только то подмножество состояний, которое соотносится к множеству состояний специализатора, которое определено множеством соотносимых друг к другу один-к-одному множеств двух аргументов.
То есть мы получаем на выходе такую программу (редукцию специализатора), которая индексирует все решения, которые могут быть представлены двумерным индексом вида «правила преобразования кода» и «сам код» в качестве «координат», на пересечении которых находится состояние решения проекции конкретного высокоуровневого кода в конкретный низкоуровневый код.
Простыми словами, мы получаем программу представляющую собой уравнение вида F(правила, код) -> низкоуровневый код, таким образом, что:
— подставляя в нее лишь правила, мы получаем подмножество всех допустимых состояний интерпретатора (то есть все возможные виды компиляции всех возможных аргументов — видов компилируемого кода),
— подставляя только код — подмножество всех возможных интерпретаторов с множеством всех возможных интерпретаций, относительно высокоуровневого кода,
— но, подставляя правила и низкоуровневый код — мы можем получить допустимое подмножество исходного высокоуровневого кода в качестве решения (то есть мы вырождаем дизассемблер)
Сначала я опишу то, что часто считают проблемами микросервисной архитектуры:
1. Микросервисная архитектура не предполагает единство протокола взаимодействия, так как подобное обобщение является распространением глобальной декларации, а любая декларация формирует зависимость, в итоге это утверждение уже само по себе нивелирует смысл декомпозиции.
Простыми словами, как только вы придумываете «правило», у вас возникает проблема с «соблюдением этого правила». Иными словами вы неизбежно попадаете в проблему парадокса консистентности, считая это свойством микросервисной архитектуры, но это не так — это лишь свойство противоречивого суждения: мы разделим все на независимые части и создадим для них зависимость…
2. Микросервисы сложно обновлять, так как всю систему нужно «остановить». Это тоже является следствием некорректного формирования зависимостей между функциональными сущностями (собственно, микросервисами). Все это имеет одну и ту же природу — большинство разработчиков не понимает сути декомпозиции.
Д е к о м п о з и ц и я — это не просто разделение «слова на буквы». Это принципиальное выделение в отдельные доменные области (Д) (е) (к) (о) (м) (п) (о) (з) (и) (ц) (и) (я), которые можно представить как вершины графа, и которые имеют возможность (а не обязанность) взаимодействуя формировать динамические конфигурации, топология которых будет представлена множеством из N*(N-1)/2 связей (без учета рекурсии), а конфигуративное множество иметь факториальную зависимость.
Таким образом, декомпозиция — это мощнейший инструмент превращения системы из состояния с малым количеством степеней свободы (и высоким кол-вом ограничений — об этом ниже) в систему с высоким количеством степеней свободы — то есть, таким образом, мы получаем доступ к потенциальному множество (фазовому пространству) доступных конфигураций, можем их исследовать (через редукцию, иначе это NP-полная задача) и выбирать оптимальную топологию (кластеризацию, как статическую, так и динамическую).
Иными словами, сложность обновления — это не свойство микросервисной архитектуры, это свойство топологии связей частей целого, выбранное таким образом, что консистентное мгновенное состояние системы оказывается зависимо от неконсистентности (разнесенном во времени и/или пространстве запуске) микросервисов.
Если сказать проще — вы ожидаете единство глобального состояния системы при принципиальном выборе декомпозиции сущностей композитно образующих это состояние.
Вы словно пытаетесь собрать воедино бревна, которые сплавляете по реке, вместо консолидированной перевозки их в грузовике, сравнивая одно с микросервисами, другое с монолитом (условно одним рантаймом), считая минусом тот факт, что по реке бревна приходят в заранее плохо предсказуемом порядке (либо приходят не все или не приходят вовсе).
3. Энтропия. Фактически все минусы возникают в неосознанном и неумелом контроле энтропии в системе. Ее «утечка» происходит, либо в меру нелинейного роста сложности топологии при неосозанном подходе к декомпозиции (так как степень свободы в топологии растет в общем случае квадратично N^2, а конфигуративное множество — факториально, следовательно редукцию делать все сложнее), либо в меру вытеснения в мета-конфигурации (вытеснение конфигурирования частей системы в рантайм — фактически это так называемая проблема интерпретации в контексте нейросетей), создает ощущение «минусов», либо очевидные с практической точки зрения ограничения. Но все эти минусы и ограничения — это следствия малой степени осознания процесса управления сложностью (контроль энтропии).
4. Накладные расходы. Дело в том, что любая сериализация данных, будь то трансфер по шине между кешами, преобразование в форматы для передачи, образование пакетов, межпроцессные взаимодействия и т.д. сопряжены с накладными расходами на абстрагирование, но эти накладные расходы должны быть осознаны с точки зрения принципиального снятия ограничения на масштабирование и параллелизм. В случае, когда не возникает осознания в том, зачем создавать абстракцию (сериализовать данные), очевидным образом следует, что на практике не возникали естественные причины, которые побудили бы к необходимости решать проблему вертикального масштабирования и неконтролируемого роста сложности, только и всего.
Так в чем же сакральный смысл микросервисов?
Сутью микросервисов является намеренное и осознанное абстрагирование функциональной сущности от «канального уровня» передачи сообщений.
Система формируется таким образом, что в ней принципиально заранее нету договоренностей между отправителями и адресатами (подписчиками в общем случае). Ее конфигурационная неопределенность (высокая степень энтропии в топологии), закладывается как часть дизайна. Эта же неопределенность формирует принципиальную неконсистентность глобального состояния.
Да, вы можете намеренно внедрить в систему консистентность глобального состояния путем внедрения кворума на синхронизацию, тем же блокчейном (как классом взаимозависимости в данных), или создать систему с высокой степенью синхронизации по времени, но сам факт консолидации состояний при декомпозированном дизайне обладает стоимостью на сериализацию + синхронизацию (выборы, кворум). Вы должны четко понимать, зачем вам это нужно, почему вы это делаете, готовы ли вы заплатить стоимость такого latency, не станет ли сам факт синхронизации бутылочным горлышком системы. Вы должны четко понимать, какие свойства для вашей системы целевые, иначе это басня Крылова «Мартышка и очки».
Так как микросервисы абстрагированы от «канального уровня» у них есть лишь одна точка входа — канал передачи сообщений. Его реализация вносит вклад в свойства обмена сообщениями, но не имеет принципиального значения для архитектуры. Как правило, этот канал либо пассивный, либо активный (активный фильтр), который представляет собой очередь, — своего рода «конвейер», либо с одной «лентой», либо со множеством параллельных «лент», либо даже множеством множеств таких конфигураций, которые между собой зеркалируют сообщения (допустим, при объединении в один логический контур совокупности имплементаций шин на разных технологиях).
При таком подходе выбор топологии связей между сущностями не предполагает единой декларации протоколов, правил взаимодействия, а предполагает декларацию понятия «шины», внутри которой происходит трансфер сообщений с той сигнатурой, которую определили между собой конечные функциональные сущности. Иными словами формируется множество протоколов между «черными коробками», образуя конечную конфигурацию связей функциональных сущностей, которые в свою очередь (микросервисы) могут асинхронно (если вы намеренно не внесли консистентность, как я писал выше) влиять на глобальное состояние.
Микросервисы выбирают не только и не столько потому, что они снимают ряд ограничений на масштабирование, сколько потому, что асинхронная природа разнесенных во времени рантаймов коррелирует с высокой степенью энтропии воздействующих на систему в реальном времени событий.
Иными словами, микросервисная архитектура позволяет создавать масштабируемые системы (любого масштаба), которые пытаются «скальпировать» реальность с минимальным latency, но лишь при условии, что создатели осознают высокую стоимость сериализации на передачу сигналов, а также зависимость между стоимостью сериализации и степенью параллелизма, которые и формируют сходимость системы к некоторому минимальному latency в процессе проекции асинхронных потоков в глобальное состояние (в global state — с точки зрения понятия statefull, что упрощенно можно представить как некий консолидированный map-reduce по всем данным, или «отчет»), которое в свою очередь будет консистентно на момент времени t-1, но в настоящий момент времени будет оставаться принципиально неактуальным по аналогии с вашим намерением прокрутить скролл на странице с самим фактом прокручивания и наблюдением результата в меру latency на «сериализацию» данных через органы восприятия.
Все мы интерпретируем «прошлое», считая его актуальным настоящим. Это лишь вопрос масштабов времени. Для коммерческих систем реального времени необходимость реагировать быстро эквивалентна инстинкту самосохранения.
P.S. На правах моего субъективизма.
Представьте, что у вас две «спутанные лампочки», которые загораются одновременно для простоты метафоры.
Вы берете одну и другую и разносите их в разные части пространства, скажем, одна на Земле, другая на Марсе.
Вы включаете одну лампочку и фиксируете время, когда она зажглась (будем считать, что зажигается она мгновенно), тоже самое фиксируют относительно другой лампочки.
Но вот в чем вопрос — а как сверить результаты? Для этого у вас должны быть высокоточные синхронизированные (насколько это возможно) часы. Допустим, у вас есть часы идеально синхронизированные, по которым ведется логирование событий.
Но когда вы перемещаетесь в пространстве для того, чтобы «отнести как можно подальше» лампочку, возникает эффект искажения пространства-времени из-за факта перемещения.
В итоге тот факт, что явление «зажигания лампочки» происходит в «один момент времени», в действительности может сам по себе включать необходимую задержку на синхронизацию состояний в самих часах.
Я хочу сказать, что сама пространственно-временная конфигурация эксперимента от его начала до его завершения со сверкой логов и часов может включать в себя необходимый объем энтропии (необходимое время и энергию), который мы по ошибке не замечаем, предполагая, что пространство-время линейно и интерпретируем результат как «мгновенную передачу состояния», но это не обязательно так, это лишь гипотеза о мгновенности, либо явная ошибка в интерпретации пространственно-временной конфигурации.
P.S.
Это в принципе фундаментальная проблема суперпозиции.
Раскрывая мысль, я хотел бы задаться вопросом, можно ли каким-либо образом проверить, куда этот объект направляется (если допустить, что он движется без существенной коррекции траектории, вне зависимости от природы этой коррекции, газ ли это или давление солнечного ветра) с точки зрения его возможных пересечений с другими звездными системами в будущем?
Подскажите, был ли опыт создания кастомных стоек (стеллажей), совершенно неформатных. У меня возникла задача построения лабораторного стенда с оборудованием (совокупность микро-серверов, кастомные платы, наборы дисков), для чего требуется что-то вроде гибкого конструктора. Все что нашел — это довольно габаритные и грубые конструкционные профили.
Может быть кто-то сталкивался с изящным решением данной задачи?
Как говорится, буду иметь в виду при выборе дисков!
Предупреждения должны быть исключительно об опасности здоровью и жизни на объектах, представляющих такую опасность, например, на трансформаторных щитках, где явно написано — Осторожно! Высокое напряжение! Опасно для жизни! Либо на опасных участках дороги, где совсем неочевидно, что покрытие может быть скользким, а поворот слишком крутым и т.д.
В таких сообщениях есть смысл, так как любое наивное касание элементов под напряжением с высокой долей вероятности именно убьет. Не каждый человек обязан знать электрику, особенности схем, фазы, что можно трогать, а что нет, и тем более предсказывать будущее в ограниченном наборе информации.
Критерием для подобных предупреждений является «НЕЗНАНИЕ» человека в полной форме, то есть человек может даже не догадываться о том, что какой-то силовой кабель или дверка трансформаторного щитка из-за неисправности под напряжением, а безобидный закрытый поворот может увести его в кювет даже на малой скорости из-за, скажем, песка на дороге.
В случае же с тем, что люди имеют какие-то недостатки со здоровьем, о которых они знают или НЕ знают, касаются субъектов, а не относятся к объектам.
То есть, как в примере выше, если у человека гастрит явный или только в начальной стадии, о которой он не подозревает, и ему запрещено или дискомфортно употреблять в пищу сильно острое, кислое, жареное, но он это упорно делает, испытывая дискомфорт, боль, то это говорит в первую очередь о том, что субъект по отношению к своему здоровью невнимателен, и он не может перекладывать свою ответственность на других, мол, меня не предупредили, что пить водку нельзя при язвенной болезни желудочно-кишечного тракта!
Чем эпилепсия принципиально отличается, если человек о ней знает, но продолжает смотреть на быстрые контрастные сцены?
Но даже если не знает, что говорит о том, что он никогда не сталкивался прежде, ни с гастритом, ни с эпилепсией, то мы можем полагать, что у любого человека, не обладающего явным знанием есть ненулевая вероятность любой болезни, начиная от эпилепсии, защемлением нервов в позвоночнике, риском развития сколиоза, уменьшению кровообращения в сидячем положении, риском развития кариеса, если в игре есть сцены с изображением пищи, что провоцирует игрока принести «покушать бутер», не говоря уже о том, что при низкой частоте модуляции подсветки будут сильно напрягаться глаза, что приведет к ухудшению зрения.
Неужели было бы разумным к каждому объекту выдавать сборник томов противопоказаний?
Я полагаю — нет. Более того, есть достаточно формальный критерий адекватности предупреждений, где они действительно необходимы, и где они мягко говоря избыточны, либо дискриминируют права на безопасность других групп граждан, которые могут нанести вред своему здоровью, «так как не было написано, что нельзя!»
Было бы хорошо, чтобы все правила, включая законодательную базу, имели под собой не просто частный случай условно субъективной оценки, а хотя бы более-менее целостную логическую систему суждений, но, к сожалению, это где-то в идеальном мире, в реальности же люди будут занимать позицию субъективно правильных выводов, но в своем очень узком scope, относительно общей картины.
Мне хотелось проверить, насколько такое вибропоглощающее крепление сможет снизить шум.
Я был впечатлен, но шум практически полностью исчез, включая шум работы головок диска. Как оказалось, любой слышимый шум в основном создается поверхностями корпуса, при передачи ему вибраций, даже малейший, по крайней мере, в моем случае, так как корпус был выполнен из цельных листов металла.
Тоже самое касается всех вентиляторов, они почти перестают издавать шум, как только они ставятся через прорезиненные крепления (из мягкой резины) или силиконовые прокладки.
То, что раньше казалось мне шумом работы HDD — оказалось по сути шумом всяческих резонансов корпуса.
То, что раньше казалось мне шумом работы вентиляторов, оказалось все тем же шумом от корпусных конструкций. В действительности же шум воздушного потока в чистом виде достаточно тихий, даже на высоких оборотах вентиляторов.
В итоге даже системный блок ножками ставлю на прорезиненные подкладки, так как малейшая вибрация может передаваться на поверхность, на котором он стоит (в моем случае на пол, на паркетную доску).
P.S. Я также пробовал звукопоглощающие материалы ставить на стенки, но они лишь немного приглушают общий шум системы.
Попробуйте, возможно, такой совет кажется банальным, но он может дать неожиданный эффект! По крайней мере для меня это был настоящий Wow-эффект, так как я не ожидал, что незначительные вибрации могут вносить свой вклад в общий шум системы на ~80% (субъективная оценка).