Много лет назад
Peter Villadsen рассказывал - еще до выхода AX 2012 - про выполнение кода X++ в IL, недетерминированный сборщик мусора в CLR и клиент-серверное взаимодействие:
Цитата:
В X++ у вас может быть объект на одном уровне (клиенте или сервере), который ссылается на объекты на другом уровне и вызывает методы этих объектов, и так далее. По целому ряду причин это плохая модель. Мы в любом случае хотим уйти от этой модели, потому что не хотим поддерживать слишком много информации о состоянии на каждом из уровней (клиенте и сервере). Мы, напротив, хотим прийти к более облегченной модели, как, например, модель на базе веб-сервисов, где не было бы подобных недостатков. Таким образом, код, который мы переводим в IL, будет в общем случае выполняться на одном уровне (серверном или клиентском).
В AX 2012 часть кода может выполняться на сервере в IL, так что клиенту не нужно хранить много информации о состоянии, однако, падение одного из AOS'ов является весьма заметным для пользователей событием. Работа всех сессий одномоментно прерывается, нужно заново запускать клиента, ждать, пока он загрузится, заново открывать нужную форму и т.д. Для веб-сервисов требуется предварительно настроить NLB, а потом еще как-то оповестить ее о том, что на данном хосте сервисы AOS'а более недоступны (потому что NLB в общем случае отслеживает доступность хостов, а не отдельных сервисов).
В D365FO озвученные идеи, наконец, воплотились в полной мере: код X++ стал серверным, он выполняется полностью в IL, клиент теперь не хранит информацию о состоянии объектов на сервере, и модель взаимодействия стала облегченной до такой степени, что пользователи практически не замечают падения одного из AOS'ов в кластере. Может появиться окно о потере подключения, но достаточно перезагрузить страницу в браузере - и можно продолжить работу почти с того же места. Это тем более применимо к веб-сервисам на стороне D365FO, вызываемым извне.
В On-Premises версии такая гладкая отказоустойчивость обеспечивается, помимо прочего, инфраструктурой Service Fabric, распределяющей нагрузку на кластеры приложений, отслеживающей доступность отдельных узлов в кластере и в случае недоступности одного из них оперативно перераспределяющей запросы на другие. Но механизмы, обычно используемые для обеспечения отказоустойчивости при сбоях, точно так же могут работать и при плановых простоях узлов во время обновления...