Недавно ко мне подошел один из моих сотрудников и задал вопрос: «А что такое аякс?». Вот прямо молодец, ни разу не про САП, не поленился, погуглил, сформировал мнение, пришел удостовериться. Андрюха, молодец! Хвалю. Аякс, это AJAX — технология, которая позволила ускорить интернет в разы. Если раньше информация о каждой страничке, всех ее составляющих формировалась на стороне сервера, заставляла выделить отдельный поток (через старый fork, а не thread), следом по старому протоколу HTTP 1.0 создавалась куча запросов вида клиент-сервер. Все это вываливалось на клиента = браузер, который оголтело начинал разбирать синтаксис полукривого HTML приправленного CSS соусом в неупакованном виде. Каналы перегружены, сервера перегружены, клиенты перегружены. Тотальный перегруз на планете.
И тут один умник придумывает передавать информацию кусочками, только то, что нужно конкретно сейчас, а не вообще. Простой пример — загрузка картинок в гугле в поиске. Вы пишите слово, картинки начинают подгружаться по мере пролистывания страницы вниз. Представьте тоже самое на старой технологии, когда весь интернет загружался бы к вам на компьютер. В те времена трафик еще был по-мегабайтный. Так вот аякс умеет загружать в фоновом режиме только то, что нужно или его намеренно попросили. Переключили вкладку на страничке — быстро сформировался запрос только той информации, которая нужна для этой вкладки. Оформление все отрисуется на клиенте в браузере. Результат — свободный сервер (он отдал минимум информации за короткое время), свободные каналы связи, довольный клиент. Современные компьютеры, смартфоны, *фоны умеют быстро анализировать документы и отрисовывать их на экранах, поэтому эту часть работы переложили с серверов на клиентов.
Вы, наверное, догадались, что я опять гадости писать буду про фиори. Покопаемся в кишках. Сервер приложений САП написан на базе бесплатного сервера J2EE Tomcat (если я не ошибаюсь). Это бесплатный опенсорсный продукт. Соблюдена правильная MVC архитектура с логикой на клиенте на базе JavaScript. Созданы хорошие курсы по разработке приложений на коленке. Сейчас все индусы и консультанты ринуться изучать, разрабатывать, наполнять рынок продуктами. Все как бы клево. У меня только появляется вопрос, а кто же учит тем вещам, которые скрыты за курсами и High Load системами? Представьте себе компанию с десятками тысяч сотрудников. Бывшие консы сели за фиори, наколбасили прожект. Например, табель рабочего времени. Простая вроде бы вещь. Однако в период закрытия месяца все пользователи начинают ломиться в систему, вешают все что можно и расстраиваются. Почему?
На мой взгляд ответ прост. Люди начали заниматься не своим делом. Что такое высоконагруженное приложение (а табель в данном случае именно высоконагруженное приложение)? Это продукт, который построен на сервисной архитектуре, где каждый сервис независим и достаточен. Каждый сервис может масштабироваться без ущерба другим. Возьмем простой пример. Табель. Пользователь открывает приложение, где загружаются справочники. Давайте разрисую на пальцах, что происходит внутри систем. AJAX клиент отправляет запрос на справочник в САП через OData сервис. Умные ребята используют JSON для обмена, олдскульные — XML (тупо размер пакета в разы больше — overload!). Сервер запускает контроллер (АБАП), который через кучу прослоек сделает запрос к базе данных и вернет справочник. Умные ребята справочник отфильтруют уже на клиенте в момент запроса, чтобы не гонять данные по всей T550A. При правильно настроенной СУБД одинаковый запрос будет индексирован, структурирован и кеширован. Оптимизация. Но таких справочников много! А если нам нужно изменить данные? Внести изменения в 2001, 2002, 2003 инфотипы? Каждый раз INSERT INTO, перестроение индексов — жуть!
Обратите внимание, на демо-облаках САП их же приложения открываются достаточно долго. А вроде облако, безграничные просторы. Теперь обратимся к опыту таких компаний как Amazon, Uber, Booking, Wargaming, Airbnb. Посмотрите в интернете их выступления и презентации по архитектуре решений. Очень хочу увидеть такое же в САП среде в свете новых тенденций. Поясню. Фиори к нам прилетело из мира веб разработки, который стар как я сам. Этот мир освоил все возможные инструменты для создания качественных решений любого уровня. Что делают эти компании для оптимизации своих массовых решений (САПу до них далеко)? Из того что лежит на поверхности:
- Создание проксирующих серверов для веб-решений. Статический контент раздается через CDN сети. Динамика фильтруется и балансируется на уровне первого слоя nginx серверов или Apache.
- Абсолютная минификация промышленного кода, который уходит на клиента. Это означает, что все лишние пробелы, символы удаляются из той информации, которая передается в браузер, где это возможно. Это экономит огромный объем информации для передачи — снижение нагрузки. Особо умные еще кэшируют каркасы страниц, картинки и упаковывают текст в zip (gzip). То есть, вместо 1 мегабайта от сервера к вам идет 50 кб. Экономия в 20 раз. Мало кто об этом думает, когда пишет приложения в SAP.
- Использование in-memory хранилищ. Это всемирно известные Redis, memcached. По сути это сервера, которые хранят в памяти часто используемую информацию. Те же справочники загружаются один раз в память, а потом мгновенно отдаются клиентам минуя базу данных. Скорость возврастает в тысячи раз. И никакой ханы не надо, кстати. Это бесплатно.
- Использование очередей. Что происходит, когда вы загружаете ваше клевое резюме на сайт в приложениях рекрутинга? Сервер под вас выделяет отдельный процесс (это процессор и память), и ждет, пока браузер отдаст ему весь файл. А вы ждете пока оно скушает. Потом оно все внутри обрабатывается, сервер сообщает: «Ну, я скушал. Вот тебе мой ответ — 200 ОК». И это медленно всем. Очереди позволяют разделить потоки и резюме загружать быстро на сервер, саму страничку тоже отдельно обрабатывать. А анализировать резюме уже потом, расслабленно в фоне.
- Шардинг и кластеризация баз данных. Есть такая штука, статистика. Так вот по ней соотношение входящего трафика к исходящему раньше было что-то вроде 10/1. На этом провайдеры зарабатывали, говоря, что входящий трафик платный, исходящий бесплатный. Такая же схема работает с операциями чтения и изменения данных. Читаем данные мы обычно чаще, чем записываем. Это означает, что чтение используется чаще, оно менее ресурсоемко (не надо перестраивать индексы в базе), поэтому операцию чтения можно вынести на отдельный сервер. Получается красивая схема, когда массовые операции по чтению данных идут через read-only сервера, запись через отдельные сервера на запись. Скорость работы увеличивается. Синхронизация серверов идет в фоне. И это все на уровне базы данных.
- Оптимизация картинок. Моя любимая тема. Один студент у меня долго удивлялся, почему страничка так долго открывается. Оказалось, что он туда залил фоточку свою. JPEG высшего качества на 30 мб. Вот сеть и переваривала это каждый раз при открытии странички. Интернету и всем Fiori приложениям не нужно такого шика. PNG формат наше все и в минимальном — доступном для чтения — виде.
Что-то еще умного было, не вспомню сходу. Мораль басни такова, что если все это объединить и делать грамотные приложения с правильной архитектурой под ними, то скорость работы приложений, удовлетворенность вырастут в разы. В США на курсах вождения мотоцикла мне говорили, что по статистике наибольшее количество аварий происходит в первые 5 минуту после трогания с места и на скорости до 5 миль в час. Вдумайтесь! Также и с приложениями. Каждое приложение уже проектировать нужно как кирпичик в высоконагруженном приложении с правильным каркасом.
А вторая мораль такова, что не надо САП консультантам лезть в это дело. Есть профи — веб-разработчики, которые стоят в 2-3 раза дешевле САПеров, делают в разы лучше и быстрее. Каждый должен кушать свой хлеб, зарабатывать на икру и стремиться стать еще лучше в своем. Это сервисный подход в реальной жизни, а не ИТ.
ЗЫ. Тут надо было бы накидать кучу ссылок на гугл, википедию, вставить красивые картинки, чтобы совсем понятно было. Мне лень, поздно уже 🙂