Микро против монолитной архитектуры сервера

В настоящее время мы работаем над нашим новым продуктом / проектом, это клиент-серверное приложение, предназначенное для определенных конкретных промышленных / сервисных предприятий. Мы создаем сервер (только на языке C и Linux), на котором выполняется настраиваемый протокол поверх TCP с внешним интерфейсом Java. Мы занимаемся программированием примерно на 20% и сталкиваемся с ситуацией, когда приходится выбирать между микро- или монолитной архитектурой ядра.

Я знаю, что Micro против Monolithic обычно имеет отношение к архитектуре ядра, но мы конкретно говорим о серверах.

Почему пользовательский сервер, а не что-то существующее?

• Наши потребности в пользовательском интерфейсе значительны и очень динамичны, поэтому решения на основе Web / Web-браузера не подходят.
• Статистическая обработка важна на стороне клиента, и поэтому, опять же, браузеры мало помогали. (Конечно, мы можем выполнить обработку на стороне сервера и передать обработанные данные клиенту, но это будет означать большую нагрузку на сервер и потерю ресурсов клиента).
• Более того, по крайней мере три технологии (JS / HTML / CSS) для управления даже одним событием превращают весь процесс в подобие уборки дома посреди пустынной бури - вы подметаете его n раз, а пыль накапливается n + 1 раз.

А как насчет микро и монолитного сервера? О чем ты говоришь?

Рассмотрим следующий (гипотетический) клиентский запрос:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Получив такой запрос, сервер, как правило, делает (мы игнорируем методы параллелизма, такие как поток и вилки для простоты):

• Разобрать строку запроса
• Определите действие (Fetch HistoricDataSets LIMIT Year (2010)в нашем случае)
• Взаимодействуйте со слоем персистентности (например, Oracle, в нашем примере) и извлекайте данные.

• Отформатируйте данные в соответствии с протоколом. Пример:

  идентификатор ответа: 123
  успех: верный
  текст ответа: наборы данных

• Ответьте клиенту с таким образом отформатированными данными.

Это то, что мы называем Монолитным Сервером (сродни монолитному ядру, где все операции ОС выполняются в пространстве ядра).

Рассмотрим тот же запрос еще раз при получении, на этот раз сервер (мы предположили, что в качестве IPC мы использовали только общую память, опять же для простоты):

• Помещает запрос в общую память для Parserпроцесса
• ParserРазбирает строку, идентифицирует задачу и направляет Executionerпроцесс для выполнения этих задач.
• Затем Executionerон передает данные для Fomatterобработки, которые после форматирования данных в строку протокола возвращаются на сервер.
• Сервер отправляет его клиенту (ответ).

Конечно, вместо Parser, Executionerи Formatterэто мог быть один, но отдельный процесс. Это то, что мы называем микро-сервером (сродни микроядру, выполняющему едва ли не минимум, что требуется). Сервер фактически только слушает и отвечает, тогда как все шаги выполняются разными процессами.

Какой выбрать? Мы в замешательстве! В то время как монолитные серверы проверены и протестированы (большинство HTTP-веб-серверов?), Их легче программировать, и они могут справиться с параллелизмом. Микро-серверы, prima facie, кажутся быстрыми и соответствуют принципу UNIX одной программы для выполнения одной задачи, но также сложны в разработке, особенно. имея в виду параллелизм.

Вопрос (ы)
- Каковы (возможно, могут быть) плюсы и минусы каждого подхода?
- Когда использовать что? (Это также можно интерпретировать как общий вопрос: когда использовать IPC?)
- Если выбрано ядро ​​Micro, то какие функции должны быть частью core-server, а какие нет?

Похожие / похожие вопросы

• Опасности огромного монолитного применения
• Внешний против встроенного браузера (тангенциальный)
• Рекомендации по преобразованию монолитного приложения в многопоточное (Tangential)

• Наши потенциальные клиенты можно разделить на две категории:
  • Большой: около 1700 - 2000 запросов в минуту
  • Малый: около 650 - 700 запросов в минуту
• Можно предположить, что объем данных за цикл запроса (запрос и последующий ответ) обычно распределяется со средним значением ~ 1,20 МБ, а в худшем случае - около 250-300 МБ.
• Концепция продукта является относительно новой, но она способна влиять на основные операции, поэтому мы ожидаем, что бюджеты клиентов будут гибкими только после определенного отставания (9-12 месяцев) после развертывания, что ограничивает количество оборудования, которое клиент будет готов совершать esp. маленькие.
• У каждого клиента будет свой стек клиент-сервер. Сервер будет работать на оборудовании клиента, управляемом командой клиента, а клиенты будут развернуты на компьютерах функциональных сотрудников.
• Необходимо удаленное обновление как клиентского, так и серверного приложения.
• PUSHУслуги сервера в режиме реального времени могут быть «очень» желанными, если продукт нажмет!

Экономика иногда руководствуется гораздо более критическим ответом, чем основная теория выбора. Самое главное, что если вы смотрите на что-то «обширное» в вашем случае, когда ваше приложение нуждается в действительно жестком развертывании - чем меньше число колес, которые вы изобретаете сами, тем лучше. Если это сработает, мне все равно, монолитный он или микро; если это не так, мне тоже все равно!

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

1. Если вам действительно нужна очень высокая масштабируемость, подумайте, как ваши серверы будут делить задачу, а не отрабатывать цифры настолько быстро, насколько это возможно. В конце концов, у вас будет нагрузка, которую один сервер не сможет принять на себя, даже если Intel производит самый быстрый процессор в мире, а клиент готов платить! Поэтому маршрутизация запросов и балансировка нагрузки важнее, чем эффективность самого протокола.

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

3. HTTP не означает, что вам нужно разбираться с HTML, java-скриптом вообще. Это даже не значит, что вам нужен обычный сервер Apache и веб-браузер. Вы можете использовать HTTP между двумя настраиваемыми клиентами и такими элементами, как сервер AOL или lighthttpd, которые можно использовать в качестве библиотеки, если обмен данными не является огромной передачей данных. Вы можете также использовать SOAP с обеих сторон с наборами инструментов , как gSOAP .

4. Даже если HTTP определенно не подходит, рассмотрите что-то вроде BEEP , это поможет вам сделать вещи более эффективными. В качестве альтернативы существует множество проверенных механизмов RPC, RMI.

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

6. Наконец, хотя я, возможно, не в состоянии узнать точные потребности, но вам может понадобиться либо распределить много данных, либо выполнить много вычислений, если вам нужны оба - все еще есть некоторые основные архитектурные недостатки.

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

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

Dipan.

Это кажется мне очень академичным. И, честно говоря, я считаю второй подход таким же монолитным. Это так далеко, как вы должны идти:

1. Разобрать запрос
2. Обработать запрос

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

1. Монолитное ядро ​​намного старше Микроядра . Он используется в Unix. Идея микроядра появилась в конце 1980-х годов .

2. Примером ОС с монолитными ядрами являются UNIX, LINUX, в то время как ОС с Микроядром - QNX, L4, HURD , первоначально Mach (не Mac OS X), позже она преобразуется в гибридное ядро, даже MINIX не является чистым ядром, поскольку драйвер устройства скомпилирован как часть ядра.

3. Монолитное ядро быстрее микроядра . в то время как первое микроядерное ядро ​​на 50% медленнее, чем монолитное ядро, в то время как более поздняя версия, такая как L4, всего на 2% или 4% медленнее, чем монолитное ядро .

4. Монолитное ядро ​​обычно громоздкое . в то время как чистое монолитное ядро ​​должно быть небольшого размера, даже вписываться в s в кэш первого уровня процессора (микроядро первого поколения).

5. в монолитном ядре драйвер устройства находится в пространстве ядра . В то время как в Микроядерном устройстве драйвер находится в пользовательском пространстве .

6. поскольку драйвер устройства находится в пространстве ядра, это делает монолитное ядро менее безопасным, чем микроядро. (Сбой в драйвере может привести к сбою), в то время как микроядра более безопасны, чем монолитное ядро, следовательно, используемое в некоторых военных устройствах.

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

8. Добавление новой функции в монолитную систему означает перекомпиляцию всего ядра, в то время как вы можете добавить новую функцию или патчи без перекомпиляции .