Высокая доступность и масштабируемая платформа для Java / C ++ на Solaris

Question

У меня есть приложение, которое представляет собой смесь Java и C ++ в Solaris. Java-аспекты кода запускают веб-интерфейс и устанавливают состояние на устройствах, с которыми мы разговариваем, а код C ++ выполняет в реальном времени анализ данных, возвращаемых с устройств. Общая память используется для передачи информации о состоянии устройства и контекста из кода Java в код C ++. Код Java использует базу данных PostgreSQL для сохранения своего состояния.

Мы сталкиваемся с довольно серьезными узкими местами в производительности, и сейчас единственный способ масштабирования - это увеличить память и количество процессоров. Мы застряли на одном физическом боксе из-за конструкции с общей памятью.

---

По-настоящему большой успех здесь - это код C ++. Веб-интерфейс довольно легко используется для настройки устройств; где мы действительно боремся за обработку томов данных, которые устройства доставляют после настройки.

Каждая часть данных, которую мы получаем от устройства, имеет идентификатор, который указывает на контекст устройства, и нам нужно это найти. Прямо сейчас есть ряд объектов совместно используемой памяти, которые поддерживаются кодом Java / UI и на которые ссылается код C ++, и это узкое место. Из-за этой архитектуры мы не можем перенести обработку данных C ++ на другую машину. Нам необходимо иметь возможность масштабирования, чтобы различные подмножества устройств могли обрабатываться на разных машинах, но тогда мы теряем способность выполнять поиск по контексту, и вот эту проблему я пытаюсь решить: как разгрузить реальный время обработки данных для других блоков, но при этом они могут ссылаться на контекст устройства.

Должен отметить, что мы не контролируем протокол, используемый самими устройствами, и нет никаких шансов, что ситуация изменится.

---

Мы знаем, что нам нужно отойти от этого, чтобы иметь возможность масштабирования путем добавления большего количества машин в кластер, и я на начальных этапах работы над тем, как именно мы это сделаем.

Прямо сейчас я рассматриваю Terracotta как способ масштабирования Java-кода, но я не дошел до того, как решить, как масштабировать C ++ для соответствия.

Помимо повышения производительности мы должны учитывать и высокую доступность. Приложение должно быть доступно практически все время - не совсем на 100%, что неэффективно с точки зрения затрат, но мы должны сделать разумную работу, чтобы пережить сбой машины.

Если бы вам пришлось выполнить задание, которое мне дали, что бы вы сделали?

РЕДАКТИРОВАТЬ: Основываясь на данных, предоставленных @john channing, я смотрю на GigaSpaces и Gemstone. Похоже, что Oracle Coherence и IBM ObjectGrid доступны только для java.

Answer 1

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

Далее я бы собрал некоторые точные эмпирические данные, которые точно характеризуют производительность вашей системы. Это что-то вроде клише, что вы не можете управлять тем, что не можете измерить, но я видел, как многие люди пытались оптимизировать программную систему, основанную на догадках, и с треском проваливались.

Тогда я бы использовал Принцип Парето (правило 80/20) , чтобы выбрать небольшое количество вещей, которые принесут наибольший выигрыш, и сосредоточиться только на них.

Для горизонтального масштабирования Java-приложения я использовал Oracle Coherence . Хотя некоторые считают его очень дорогим распределенным хеш-таблицей , его функциональность гораздо богаче, и вы можете, например, напрямую получить доступ к данным в кэше из C ++ кода .

Другими альтернативами горизонтального масштабирования Java-кода могут быть Гига пробелы , IBM Object Grid или Gemstone Gemfire .

Если ваш код C ++ не имеет состояния и используется исключительно для обработки чисел, вы можете посмотреть на распределение процесса, используя ICE Grid , который имеет привязки для всех языков, которые вы используете.

Answer 2

Эндрю, (помимо моделирования в виде конвейера и т. Д.), Важно измерять вещи. Вы запустили профилировщик над кодом и получили метрики того, где большую часть времени проводит?

Как часто меняется код базы данных? Вы сейчас смотрите на кеширование? Я предполагаю, что вы просматривали индексы и т. Д. По данным, чтобы ускорить Db?

Какой уровень трафика у вас на входе? Вы кешируете веб-страницы? (Нетрудно сказать, использовать API-интерфейс JMS-типа для взаимодействия между компонентами. Затем можно разместить компонент веб-страницы на одном компьютере (или более), а затем поместить код интеграции (c ++) на другом и для многих JMS. продукты обычно бывают нативными для C ++ API, т. е. ActiveMQ приходит на ум), но это действительно помогает узнать, сколько времени занимает Web (JSP?), C ++, Database ops.

Хранит ли база данных бизнес-данные или она также используется для передачи данных между Java и C ++? Вы говорите, что используете общий мем, а не JNI? Какой уровень многопоточности в настоящее время существует в приложении? Вы бы описали код как синхронный по природе или асинхронный?

Существуют ли физические отношения между кодом Solaris и устройствами, которые должны поддерживаться (т. Е. Регистрируются ли все устройства с кодом c ++, или это может быть указано). то есть. Если бы вы разместили веб-балансировщик нагрузки на внешнем интерфейсе и просто включили 2 машины сегодня, это отношение каких устройств управляется блоком, инициализированным заранее или заранее?

Каковы требования к HA? то есть. просто указать информацию? Можно ли выполнить HA только на веб-уровне путем кластеризации данных сеанса?

БД работает на другой машине?

Насколько велика БД? Оптимизировали ли вы свои запросы, т.е. попытка использования явных внутренних / внешних объединений иногда помогает по сравнению с вложенными подзапросами (иногда). (снова посмотрите на статистику sql).

Answer 3

Вам нужно масштабировать вбок и наружу. Может быть, что-то вроде очереди сообщений может быть бэкэндом между внешним интерфейсом и обработчиком.