Горизонтальне масштабування. Що, навіщо, коли і як?

Олександр Макаров

Олександр Макаров ( SamDark
Доброго дня! Я Олександр Макаров, і ви можете мене знати по фреймворку «Yii» — я один з його розробників. У мене також є full-time робота — і це вже не стартап   Stay.com, який займається подорожами.

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

Що таке масштабування, взагалі? Це можливість збільшити продуктивність проекту за мінімальний час шляхом додавання ресурсів.

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

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

Самий класний питання, яке задають, — а навіщо воно треба, якщо в мене все і на одному сервері прекрасно працює? Насправді, треба перевірити, що буде. Тобто, зараз воно працює, але що буде потім? Є дві чудові утиліти — ab і siege, які наганяють хмару користувачів конкурента, які починають довбати сервер, намагаються запросити сторінки, послати якісь запити. Ви повинні вказати, що їм робити, а утиліти формують такі звіти:



і



Головні два параметри: n — кількість запитів, які треба зробити, з — кількість одночасних запитів. Таким чином вони перевіряють конкурентність.

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

Є ще один параметр, — Responce time — час відповіді, за яке в середньому сервер віддав сторінку. Воно буває різне, але відомо, що близько 300 мс — це норма, а що вище — вже не дуже добре, тому що ці 300 мс відпрацьовує сервер, до цього додаються ще 300-600 мс, які відпрацьовує клієнт, тобто поки все завантажиться — стилі, картинки та інше — теж проходить час.

Буває, що насправді поки що й не треба піклуватися про масштабуванні — йдемо на сервер, оновлюємо PHP, отримуємо 40% приросту продуктивності і все круто. Далі налаштовуємо Opcache, тюним його. Opcache, до речі, тюнится так само, як і APC, скриптом, який можна знайти в репозиторії у Расмуса Лердорфа і який показує хіти і мисы, де хіти — це скільки разів PHP пішов в кеш, а мисы — скільки раз він пішов у файлову систему діставати файлики. Якщо прогнати весь сайт або запустити туди якийсь краулер за посиланнями, або вручну потикати, то у нас буде статистика за цим хітам мисам. Якщо хітів 100%, а мисов — 0%, значить, все нормально, а якщо є мисы, то треба виділити більше пам'яті, щоб весь наш код вліз у Opcache. Це часта помилка, яку допускають — зразок Opcache є, але щось не працює…

Ще часто починають масштабувати, але не дивляться, взагалі, з чого все працює повільно. Найчастіше ліземо в базу, дивимося — індексів немає, ставимо індекси — все відразу залітало, ще на 2 роки вистачить, краса!

Ну, ще треба включити кеш, замінити apache на nginx і php-fpm, щоб заощадити пам'ять. Буде все класно.

Все перераховане досить просто і дає вам час. Час на те, що коли-то цього стане мало, і до цього вже зараз треба готуватися.

Як, взагалі, зрозуміти, в чому проблема? Або у вас вже настав highload, а це не обов'язково якесь скажене число запитів і т. д., це коли у вас проект не справляється з навантаженням, і тривіальними способами це вже не вирішується. Треба рости або вшир, або вгору. Треба щось робити і, швидше за все, на це мало часу, щось треба придумувати.

Перше правило — ніколи нічого не можна робити наосліп, тобто нам потрібен відмінний моніторинг. Спочатку ми виграємо час на якийсь очевидною оптимізації типу включення кешу або кешування Головною і т. п. Потім налаштовуємо моніторинг, він нам показує, чого не вистачає. І все це повторюється багаторазово – зупиняти моніторинг і доопрацювання ніколи не можна.

Що може показати моніторинг? Ми можемо впертися в диск, тобто в файлову систему, пам'ять, процесор, в мережу… І може бути таке, що, начебто, все більш-менш, але якісь помилки валяться. Все це вирішується по-різному. Можна проблему, припустимо, з диском вирішити додаванням нового диска в той же сервер, а можна поставити другий сервер, який буде займатися тільки файлами.

На що потрібно звертати увагу прямо зараз при моніторингу? Це:

  1. доступність, тобто живий сервер, взагалі, чи ні;
  2. нестача ресурсів диска, процесора і т. д.;
  3. помилки.
Як це все моніторити?

Ось список чудових інструментів, які дозволяють моніторити ресурси і показувати результати в дуже зручному вигляді:

Перші 4 інструменту можна поставити на сервер, вони потужні, класні. А ServerDensity хоститься у когось, тобто ми за неї платимо гроші, і вона може збирати з серверів всі дані, і відображати їх для аналізу.

Для моніторингу помилок є два хороших сервісу:

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

Sentry можна поставити до себе на сервер, є вихідний файл, а Rollbar   ні, але Rollbar краще, тому що він бере гроші за кількість помилок, тобто стимулює їх виправляти.

Про нотифікації повторю, що спамити не варто, втрачається увага.

Що, взагалі, треба аналізувати?



RPS і Responce time — якщо у нас починає час відповіді падати, то треба щось робити.

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

Також варто дивитися на бізнес-аналіз. Google Analytics для сайтовых типів відмінно підходить, а mixpanel — для логування івентів, він працює на десктопних додатках, на мобільних, веб. Можна й на основі якихось своїх даних писати, але я б радив готові сервіси. Сенс в тому, що наш моніторинг може показувати, що сервіс живий, що все працює, що загальний Responce time нормальний, але коли ми, припустимо, реєстрацію в mixpanel'е починаємо трекать, він показує, що їх якось замало. В цьому випадку треба дивитися, наскільки швидко відпрацьовують певні івенти, сторінки, і в чому полягають проблеми. Проект завжди повинен бути «обвішаний» аналізом, щоб завжди знати, що відбувається, а не працювати наосліп.

Навантаження, взагалі, виникає або заплановано, чи ні, може виникати поступово, не може поступово:



Як боротися з навантаженням? Вирішує всі бізнес, і важлива тільки ціна питання. Важливо:

  1. щоб сервіс працював,
  2. щоб це було не сильно дорого, не розорило компанію.
Решта не дуже важливо.



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



На малюнку синя штука — це Інтернет, з якого йдуть запити. Ставиться балансувальник, єдине завдання якого — розподілити запити на окремі фронтенды-сервера, прийняти від них відповіді і віддати клієнту. Сенс тут в тому, що 3 сервера можуть обробити (в ідеалі) у 3 рази більше запитів, виключаючи якісь накладні витрати на мережу та на саму роботу балансувальника.

Що це нам дає? Вказану вище можливість обробити більше запитів, а ще надійність. Якщо в традиційній схемі валиться nginx або додаток, або в диск вперлися і т. п., то все встало. Тут же, якщо у нас один фронтенд відвалився, то нічого страшного, балансувальник, швидше за все, це зрозуміє і відправить запити на 2 сервера. Може, буде трохи повільніше, але це не страшно.

Взагалі, PHP — відмінна штука для масштабування, тому що він дотримується принципу Share nothing за замовчуванням. Це означає, що якщо ми візьмемо, скажімо, Java для вебу, то там програма запускається, читає весь код, записує по максимуму даних в пам'ять програми, все там крутиться, працює, на request йде дуже мало часу, дуже мало додаткових ресурсів. Однак є засідка — т. к. додаток написано так, що воно має на одному инстансе працювати, кешуватися, читати з своїй пам'яті, то нічого хорошого у нас при масштабуванні не вийде. А в PHP за замовчуванням нічого спільного немає, і це добре. Все, що ми хочемо зробити загальним, ми поміщаємо в memcaсhed, а memcaсhed можна читати з декількох серверів, тому все чудово. Тобто досягається слабка зв'язаність для шару серверів додатків. Це прекрасно.

Чому, взагалі, балансувати навантаження?

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

Проблеми, які вирішує балансувальник — це як вибрати сервер і як зберігати сесії? Друга проблема — чисто PHP'шна, а сервер може вибиратися або по черзі зі списку, або з географії якихось IP'шників, або за якоюсь статистикою (nginx підтримує least-connected, тобто до якого сервера менше коннектов, на нього він і буде перекидати). Можемо написати для балансувальника якийсь код, який буде вибирати, як йому працювати.

Ось за цим посиланням описаний балансувальник, свежепартированный в nginx:



Всім рекомендую, там дуже прості конфіги, все максимально просто.

Що, якщо ми зіткнемося в балансувальник?

Є така штука як DNS Round robin — це чудовий трюк, який дозволяє нам не витрачатися на апаратний балансувальник. Що ми робимо? Беремо DNS-сервер (зазвичай DNS-сервера у себе ніхто не хостить, це дорого, несильно надійно, якщо він вийде з ладу, то нічого доброго не вийде, всі користуються якимись компаніями), А-записи прописуємо не один сервер, а кілька. Це буде А-записи різних балансировщиков. Коли браузер туди йде (гарантій, насправді, немає, але всі сучасні браузери так діють), він вибирає по черзі який-небудь IP-адресу, А-записів і потрапляє або на один балансувальник, або на другий. Навантаження, звичайно, може розмазуватися не рівномірно, але, принаймні, вона розтікається, і балансувальник може витримати трохи більше.

Що робити з сесіями?

Сесії у нас за замовчуванням у файлах. Це не справа, тому що кожен з серверів-фронтендов у нас буде тримати сесії у своїй файловій системі, а користувач може потрапляти то на один, то на другий, на третій, тобто сесії він буде кожен раз втрачати.

Виникає очевидне бажання зробити загальну файлову систему, підключити NFS. Але робити так не треба — вона до остраху повільна.

Можна записати в БД, але теж не варто, оскільки БД не оптимальна для цієї роботи, але якщо у вас немає іншого виходу, то, в принципі, зійде.

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

Redis — нормальне рішення. Сенс в тому, що Redis у нас на окремому сервері, і всі наші фронтенды ломляться туди і починають з Redis'а свої сесії зчитувати. Але Redis однопотоковий і рано чи пізно можемо гарненько впертися. Тоді роблять sticky-сесії. Ставиться той же nginx і повідомляється йому, що потрібно зробити сесії так, щоб юзер, коли він прийшов на сервер і йому видалася сесійний coockies, щоб він згодом потрапляв тільки на цей сервер. Найчастіше це роблять за IP-хешу. Виходить, що якщо Redis на кожному инстансе, відповідно, сесії там свої, і пропускна здатність читання-запису буде набагато краще.

Як щодо coockies? Можна писати в coockies, ніяких сховищ не буде, все добре, але, по-перше, у нас все ще кудись треба дівати дані про сесії, а якщо ми почнемо писати в coockies, вона може розростися і не влізти в сховище, а, по-друге, можна зберігати у coockies тільки ID, і нам все одно доведеться звертатися до БД за якимись сесійними даними. В принципі, це нормально, вирішує проблему.

Є класна штука — проксі для memcached і Redis:



Вони, ніби як, підтримують розпаралелювання з коробки, але робиться це, я не сказав би, що дуже оптимально. А ось ця штука — twemproxy — вона працює приблизно як nginx з PHP, тобто як тільки отримано відповідь, він відразу відправляє дані і на тлі закриває з'єднання, виходить швидше, менше ресурсів споживає. Дуже гарна штука.



Дуже часто виникає така помилка «велосипедирования», коли починають писати, типу «мені сесії не потрібні! я зараз зроблю чудовий маркер, який буде туди-сюди передаватися»… Але, якщо подумати, то це знову ж сесія.

В PHP є такий механізм як session handler, тобто ми можемо поставити свій handler і писати в coockies, в БД, Redis — куди завгодно, і все це буде працювати зі стандартними session start і т. д.



Сесії треба закривати ось цим чудовим методом.

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

Що робити з файлами?

З ними можна справлятися двома способами:

  1. якесь спеціалізоване рішення, яке дає абстракцію, і ми працюємо з файлами як з файловою системою. Це щось на зразок NFS, але NFS не треба.
  2. «шардирование» засобами PHP.
Спеціалізовані рішення з того, що дійсно працює, — це GlusterFS. Це те, що можна поставити собі. Воно працює, воно швидке, дає той же інтерфейс, що NFS, тільки працює з нормальною нормальною швидкістю.

І Amazon S3 — це, якщо ви в хмарі Amazon'а, — теж хороша файлова система.

Якщо ви реалізуєте з боку PHP, є чудова бібліотека Flysystem, покрита відмінними тестами, її можна використовувати для роботи з різними файловими системами, що дуже зручно. Якщо ви напишете всю роботу з файлами з цією бібліотекою, то потім перенести з локальної файлової системи на Amazon S3 або ін. буде просто — в конфіги сходинку переписати.

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

Найкраще роздавати файли nginx'ом або Varnish'їм, але краще все робити nginx'ом, т. до. ми всі його любимо і використовуємо — він впорається, він хороший.



Що у нас відбувається з базою даних?

Якщо у вас все вперлося в код PHP, ми робимо купу фронтендов і все ще звертаємося до однієї БД — вона впорається досить довгий час. Якщо навантаження не страшна, то БД живе добре. Наприклад, ми робили JOIN'и по 160 млн. рядків у таблиці, і все було чудово, все бігала добре, але там, правда, треба більше оперативки виділити на буфери, на кеш…

Що робити з БД, якщо ми вперлися в неї? Є такі техніки як реплікація. Зазвичай робиться реплікація майстер-слэйв, є реплікація майстер-майстер. Можна робити реплікацію вручну, можна робити шардирование і можна робити партицирование.

Що таке майстер-слэйв?



Вибирається один сервер головним і купа серверів — другорядними. На головний пишеться, а читати ми можемо з майстра, а можемо і з слэйвов (на малюнку червоні стрілочки — це те, що ми пишемо, зелені — те, що ми читаємо). У типовому проекті у нас операцій читання набагато більше, ніж операцій запису. Бувають нетипові проекти.

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

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

Ну, і бекапи. Бекапи бази все роблять по-різному, іноді це робиться MySQL-дампом, при цьому він фризит весь проект намертво, що не дуже добре. Але якщо робити бекап з якого-небудь слэйва, попередньо зупинивши його, то користувач нічого не помітить. Це прекрасно.

Крім цього, на слэйвах можна робити важкі обчислення, щоб не торкнутися основну базу, основний проект.

Є така штука як read/write split.Робиться 2 пулу серверів — майстер, слэйв, з'єднання на вимогу, і логіка вибору з'єднання варіюється. Сенс в тому, що якщо ми будемо читати зі слэйвов, а писати завжди у майстер, то буде невелика засідка:



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

Є два типи вибірок:

  1. для читання або для виводу;
  2. для запису, тобто, коли ми щось вибрали і потім це щось треба змінити і записати назад.
Якщо вибірка для запису, то ми можемо завжди читати з майстра і писати на майстер, або ми можемо виконати «SHOW SLAVE STATUS» і подивитися там Seconds_Behind_Master (для PostgreSQL теж супер-запит є на картинці) — він покаже нам число. Якщо це 0 (нуль), значить, все у нас вже реплицировалось, можна сміливо читати з слэйва. Якщо число більше нуля, то треба дивитися значення — або нам варто почекати трохи і тоді прочитати з слэйва, або відразу читати з майстра. Якщо у нас NULL, значить ще не реплицировали, щось застрягло, і треба дивитися логи.

Причини такого лага — це або повільна мережа, або не справляється репліка, або занадто багато слэйвов (більше 20 на 1 майстер). Якщо повільна мережа, то зрозуміло, її треба прискорювати, збирати в єдині дата-центри і т. д. Якщо не справляється репліка, значить треба додати реплік. Якщо ж занадто багато слэйвов, то треба вже придумувати щось цікаве, швидше за все, робити якусь ієрархію.

Що таке майстер-майстер?



Це ситуація, коли варто кілька серверів, і скрізь і пишеться і читається. Плюс в тому, що воно може бути швидше, воно надійне. В принципі, все те ж, що і у слэйвов, але логіка, взагалі, проста — ми просто обираємо рандомное з'єднання і з ним працюємо. Мінуси: лад реплікації вище, є шанс отримати якісь неконсистентные дані, і, якщо сталася якась поломка, то вона починає розкидатися по всім майстрам, і нікому невідомо, який майстер нормальний, який поламався… Це все справа починає правильно по колу, тобто дуже неслабо забиває мережу. Взагалі, якщо довелося робити майстер-майстер, треба 100 разів подумати. Швидше за все, можна обійтися майстер-слэйвом.

Можна робити реплікацію завжди руками, тобто організувати пару з'єднань і писати відразу в 2, в 3, або щось робити в тлі.

Що таке шардирование?

Фактично це розмазування даних з декількох серверів. Шардировать можна окремі таблиці. Беремо, скажімо, таблицю фото, таблиці користувачів та ін., растаскиваем їх на окремі сервера. Якщо таблиці були великі, то все стає менше, пам'яті їсть менше, все добре, тільки не можна JOIN'ить і доводиться робити запити типу WHERE IN, тобто спочатку вибираємо купу ID'шників, потім всі ці ID'шники підставляємо запитом, але вже до іншого коннекту, до іншого сервера.

Можна шардировать частина одних і тих же даних, тобто, наприклад, ми робимо кілька БД з юзерами.



Можна досить просто вибрати сервер — залишок від ділення на кількість серверів. Альтернатива — завести карту, тобто для кожного запису тримати в якому-небудь Redis'е або т. п. ключ значення, тобто де яка запис лежить.

Є варіант простіше:



Складніше — це коли не вдається згрупувати дані. Треба знати ID даних, щоб їх дістати. Жодних JOIN, ORDER і т. д. Фактично ми зводимо наш MySQL або PostgreSQL до key-valuе сховища, тому що ми з ними нічого робити не можемо.

Звичайні завдання стають незвичайними:

  • Вибрати TOP 10.
  • Посторінкова розбиття.
  • Вибрати з найменшою вартістю.
  • Вибрати пости юзера X.
Якщо ми зашардировали так, що все розлетілося по всьому серверів, це вже починає вирішуватися дуже нетривіально. В цій ситуації виникає питання — а навіщо нам взагалі SQL? Не писати нам в Redis відразу? А чи правильно ми вибрали сховище?

З коробки шардінг підтримується такими штуками як:

  • memcache;
  • Redis;
  • Cassandra (але вона, кажуть, з якогось моменту не справляється і починає падати).
Як бути зі статистикою?

Часто статистику люблять рахувати з основного сервера — з єдиного сервера БД. Це чудово, але запити в статистиці зазвичай моторошні, багатосторінкові і т. д., тому вважати статистику по основним даними — це велика помилка. Для статистики у більшості випадків realtime не потрібен, так що ми можемо налаштувати майстер-слэйв реплікацію і на слэйве цю статистику вже порахувати. Або ми можемо взяти що-небудь готове — Mixpanel, Google Analytics або подібне.



Це основна ідея, яка допомагає розкидати всі з різних серверів і масштабувати. По-перше, від цього відразу видно профіт — навіть якщо у вас один сервер і ви починаєте в тлі щось виконувати, юзер отримує відповідь набагато швидше, але і згодом розмазувати навантаження, т.тобто ми можемо перетягнути всю цю обробку на інший сервер, можна обробляти навіть не на PHP. Наприклад, в Stay.com картинки ресайзятся на Go.

Як?

Можна відразу взяти Gearman. Це готова штука для обробки в тлі. Є під PHP бібліотеки, драйвера… А можна використовувати черги, тобто ActiveMQ, RabbitMQ, але черги пересилають тільки повідомлення, самі обробники вони не викликають, не виконують, і тоді доведеться щось вигадувати.

Загальний сенс завжди один — є основне, яке поміщає в черзі якісь дані (зазвичай це «що зробити?» і дані для цього), і якийсь сервіс – він або дістає, або йому прилітають (якщо чергу вміє активно себе вести) ці дані, він все обробляє в тлі.

Перейдемо до архітектури.

Найголовніше при масштабуванні — це в проекті зробити якомога менше зв'язаності. Чим менше зв'язаності, тим простіше міняти одне рішення на інше, тим простіше винести частину на інший сервер.

Зв'язність буває в коді. SOLID, GRASP — це принципи, які дозволяють уникнути пов'язаності саме в коді. Але зв'язаність у коді на рознос по серверам, звичайно, впливає, але не настільки, наскільки зв'язаність доменного шару з нашим оточенням. Якщо ми в контролері пишемо багато-багато коду, виходить, що в іншому місці ми це використовувати, швидше за все, не зможемо. Нам буде непросто все це переносити з веб-контролера в консоль і, відповідно, складніше переносити на інші сервера і там обробляти по-іншому.



Service-oriented architecture.

Є 2 підходи розбивки систем на частини:

  1. коли б'ють на технічні частини, тобто, наприклад, є черга, винесли сервіс черг, є обробка зображень, винесли і цей сервіс і т. д.

    Це добре, але коли ці черги, зображення і т. п. взаємодіють в рамках двох доменних областей… Наприклад, у проекті є область Sales і область Customer — це різні області, з ними працюють різні люди, але і в тих, і в тих є різні черги. Коли все починає звалюватися в купу, проект перетворюється на місиво;
  2. правильне рішення   бити на окремі логічні частини, тобто якщо в областях Sales і Customer використовується модель user, то ми створюємо 2 моделі user. Вони можуть читати одні і ті ж дані, але представляють вони їх трохи по-різному. Якщо розбити систему таким чином, то все набагато краще сприймається і набагато простіше все це розкидати.

    Ще важливо те, що завжди повинні взаємодіяти через інтерфейси. Так, у нашому прикладі, якщо Sales з чимось взаємодіє, то він не пише в БД, не використовує загальну модель, а з іншими областями «розмовляє» через певний контракт.
Що з доменним шаром?

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

Є 2 книги про доменний шар, які всім раджу:

  • «Domain-Driven Design: Tackling Complexity in the Heart of Software» від Eric Evans,
  • «Implementing Domain-Driven Design, Implementing Domain-Driven Design».
Також раджу сходити за посиланнями:

В архітектурі, знову ж таки, варто дотримуватися принципу share nothing, тобто якщо ви хочете щось зробити загальним, робіть це завжди свідомо. Логіку переважно закидати на бік додатки, але і в цьому варто знати міру. Ніколи не варто, припустимо, робити збережені процедури в СУБД, тому що масштабувати це дуже важко. Якщо це перенести на бік додатка, то стає простіше — зробимо кілька серверів і все буде виконуватися там.

Не варто недооцінювати браузерну оптимізацію. Як я вже говорив, з тих 300-600 мс, які запити виконуються на сервері, до них додається 300-600 мс, які витрачаються на клієнті. Клієнтові все одно, сервер у нас швидкий, або це сайт так швидко відпрацював, тому раджу використовувати Google PageSpeed і т. д.

Як зазвичай, абстракція і дроблення зовсім не безкоштовні. Якщо ми роздробити сервіс на багато микросервисов, то ми більше не зможемо працювати з новачками і доведеться багато платити нашій команді, яка буде у всьому цьому ритися, всі верстви перебирати, крім цього сервіс може почати повільніше працювати. Якщо в компилируемых мовами це не страшно, то в PHP, принаймні, до версії 7, це не дуже…

Ніколи не дійте наосліп, завжди моніторте, аналізуйте. Наосліп практично всі рішення за замовчуванням неправильні. Думайте! Не вірте, що існує «срібна куля», завжди перевіряйте.

Ще трохи корисних посилань:



ruhighload.com супердоступной формі розписані практично всі принципи, дуже поверхово, але класно, з малюнками і т. д. Раджу там подивитися огляди того, як різні великі компанії знаходили класні рішення.

В англомовному Інтернеті не знають слова «highload», тому там шукайте за словом «sclability».



Часто це пробують на живих серверах. Робити цього у жодному випадку не треба, є такі класні штуки як DigitalOcean і Linode, де можна підняти ноду, розгорнути там будь-яке оточення, будь-сервер, всі потестить, заплативши за це 1-2 бакса, максимум.

P. S. Повні слайди цього виступу див. на slides.rmcreative.ru/2015/horizontal-scaling-highload/ і в блозі rmcreative.ru.

Контакти
» SamDark

Ця доповідь — розшифровка одного з кращих виступів на навчальній конференції розробників високонавантажених систем HighLoad++ Junior за 2015 рік.

— Мотлох! — скажіть ви.
— Вічні цінності! — відповімо ми.

Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!

Ну і головна новина — ми почали підготовку весняного фестивалю "Російські інтернет-технології", в який входить вісім конференцій, включаючи HighLoad++ Junior.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.