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

Зараз ми працюємо над нашим новим продуктом / проектом, це програма-клієнт-сервер, спрямована на певні конкретні промислові / сервісні підприємства. Ми будуємо сервер (лише мова C та Linux), на якому працює протокол користувальницького протоколу поверх TCP з фронтальним Java. Нас близько 20% займається кодування, і ми стикаємося з ситуацією, коли потрібно вибирати між мікро- або монолітною архітектурою ядра.

Мені відомо, що Micro vs. Monolithic зазвичай стосується архітектури ядра, але ми спеціально говоримо про сервери.

Чому нестандартний сервер, а не щось існуюче?

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

А як щодо мікро- та монолітного сервера? Що ви говорите?

Розглянемо наступний (гіпотетичний) запит клієнта:

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

Отримуючи такий запит, сервер, як правило, робить (ми ігноруємо методику одночасності, як нитка і форкс для простоти):

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

• Відформатуйте дані відповідно до протоколу. Наприклад:

  response-id: 123
  успіх: вірний
  текст відповіді: Набори даних

• Відповідайте на клієнта таким чином відформатованими даними.

Це те, що ми називаємо Monolithic Server (подібний до монолітного ядра, де всі роботи ОС виконуються в просторі ядра).

Розглянемо той же запит ще раз, при отриманні, цього разу сервер (ми вважали, що спільна пам'ять є IPC, знову ж таки для простоти):

• Вкладає запит у загальну пам'ять для Parserпроцесу
• ParserРозбирає рядок, ідентифікує завдання і направляє Executionerпроцес для виконання цих завдань.
• ExecutionerПотім передає дані до Fomatterпроцесу , який, після форматування даних в рядок протоколу, повертається до сервера.
• Сервер посилає його клієнту (відповідь).

Звичайно, замість цього Parser, Executionerі Formatterце міг бути єдиний, але окремий процес. Це те , що ми називаємо в Micro - сервер (на кшталт мікро ядро робить ледь мінімум , який потрібен). Сервер ефективно лише слухає та реагує, тоді як усі кроки доглядають за різними процесами.

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

Питання (-ла)
- Які (можливо, можуть бути) плюси і мінуси кожного підходу?
- Коли користуватися якими? (Це також можна інтерпретувати як загальне питання: Коли використовувати IPC?)
- Якщо вибрано Micro ядро, то які функції потрібно входити до складу основного сервера, а що ні?

Подібні / Пов'язані питання

• Небезпеки величезного монолітного застосування
• Зовнішній вбудований Vs-браузер (Tangential)
• Поради щодо перетворення монолітного додатку в багатопотокове (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. Нарешті, хоча я, можливо, не в змозі знати точні потреби, але вам може знадобитися або поширити багато даних, або зробити багато обчислень, якщо вам потрібно і те, і інше - все ще є деякі основні архітектурні неефективи.

Для мене створення нового протоколу і ніж створення нового серверного каркасу - це подвійний експеримент, який вам не слід робити разом. Якщо ваші ставки настільки високі, спершу вам слід спробувати експериментувати з існуючими інструментами, щоб побачити межі того, що зроблено дотепер - лише тоді ви дізнаєтесь справжні проблеми.

У дослідженні розподілених систем було досягнуто набагато більше, ніж просто веб-додатків. Тож вам слід це дослідити.

Діпан.

Це здається мені дуже академічним. І, чесно кажучи, я вважаю, що другий підхід такий же монолітний. Це так далеко, як вам слід:

1. Проаналізуйте запит
2. Обробіть запит

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

1. Монолітне ядро ​​набагато старше, ніж Microkernel . Він використовується в Unix. в той час як Ідея мікроядер з'явилася наприкінці 1980-х .

2. прикладом os з монолітними ядрами є UNIX, LINUX, тоді як os з Microkernel є QNX, L4, HURD , спочатку Mach (не mac os x), пізніше він перетвориться в гібридне ядро, навіть MINIX не є чистим ядром, оскільки драйвер пристрою є складений як частина ядра.

3. Монолітні ядра швидші, ніж мікрокери . в той час як Перший мікроелектричний Мах на 50% повільніше, ніж ядро ​​моноліту, тоді як пізніша версія, як L4, лише на 2% або на 4% повільніше, ніж ядро ​​Моноліт .

4. Монолітні ядра, як правило, громіздкі . в той час як чисте монолітне ядро ​​має бути невеликих розмірів, навіть вписуватися в кеш-пам'ять першого рівня процесора (мікрокерелля першого покоління).

5. у драйвері пристрою Monolithic ядра перебувають у просторі ядра . в той час як у драйвері пристрою Microkernel перебувають у просторі користувача .

6. Оскільки драйвер пристрою знаходиться в просторі ядра, це робить монолітне ядро менш захищеним, ніж мікрокенер. (Збій у драйвері може призвести до аварії), тоді як Microkernel надійніші, ніж монолітне ядро, яке використовується в деяких військових пристроях.

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

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