Передмова
Оновлення в 2016 році. Все розвивається, всі сервери стають все кращими, всі вони підтримують SSL та Інтернет більш дивовижно, ніж будь-коли.
Якщо не зазначено, наступне спрямоване на професіоналів у бізнесі та стартапах, підтримуючи тисячі мільйонів користувачів.
Ці інструменти та архітектура вимагають багато користувачів / обладнання / грошей. Ви можете спробувати це в домашній лабораторії або вести блог, але це не має особливого сенсу.
Як правило, пам’ятайте, що ви хочете зробити це просто . Кожне додане проміжне програмне забезпечення - це ще одна важлива частина проміжного програмного забезпечення. Вдосконалення не досягається тоді, коли немає чого додати, але коли не залишається нічого для видалення.
Деякі поширені та цікаві розгортання
HAProxy (балансування) + nginx (програма php + кешування)
Веб-сервер - це nginx за допомогою php. Коли nginx вже є, він може також керувати кешуванням та переадресаціями.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (балансування) + лак (кешування) + Tomcat (програма Java)
HAProxy може перенаправляти на Varnish на основі URI запиту (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (балансування) + nginx (SSL для хоста та кешування) + веб-сервер (додаток)
Веб-сервери не розмовляють з SSL, навіть якщо ВСЕ ОБОВ'ЯЗКОВО говорити SSL ( особливо це посилання HAProxy-WebServer з приватною інформацією про користувачів, що проходить через EC2 ). Додавання локального nginx дозволяє піднести SSL до хоста. Після того, як nginx є, він також може зробити кешування та перезапис URL-адрес.
Примітка . Перенаправлення портів 443: 8080 відбувається, але це не є частиною функцій. Немає сенсу робити перенаправлення портів. Балансир навантаження може говорити безпосередньо на веб-сервері: 8080.
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
Посереднє програмне забезпечення
HAProxy: балансир навантаження
Основні характеристики :
- Балансування завантаження (TCP, HTTP, HTTPS)
- Кілька алгоритмів (кругла робота, вихідний ip, заголовки)
- Наполегливість сесії
- Закінчення SSL
Подібні альтернативи : Nginx (багатоцільова веб-сервер налаштовуються в якості балансування навантаження)
Різні Альтернативи : Хмара (Amazon ELB, Google балансування навантаження), Hardware (F5, Fortinet, Citrix NetScaler), Інший і по всьому світу (DNS, нечіткий, CloudFlare)
Що робить HAProxy і коли ви його повинні використовувати?
Щоразу, коли вам потрібно балансувати навантаження. HAProxy - це шлях до рішення.
За винятком випадків, коли ви хочете дуже дешево АБО швидко і брудно АБО не маєте наявних навичок, тоді ви можете використовувати ELB: D
За винятком випадків, коли ви працюєте в банківській / урядовій / подібній службі та вимагаєте використовувати власний центр обробки даних із жорсткими вимогами (спеціальна інфраструктура, надійний відхід, 2 шари брандмауера, аудиторські матеріали, домовленості про сплату послуг за угоду про оплату x% за хвилину простою, все в одному) ви можете поставити 2 F5 поверх стійки, на якій розміщені 30 серверів додатків.
За винятком випадків, коли ви хочете пройти 100k HTTP (S) [та декількох сайтів], ви ОБОВ'ЯЗКОВО маєте кілька HAProxy із шаром [глобального] навантаження, що балансує перед ними (cloudflare, DNS, anycast). Теоретично глобальний балансир може спілкуватися прямо з веб-серверами, що дозволяють вирватися з HAProxy. Однак, як правило, ви повинні зберігати HAProxy (s) як публічну точку входу у свій центр обробки даних і налаштовувати розширені параметри, щоб справедливо балансувати між хостами та мінімізувати дисперсію.
Особиста думка : Невеликий, вміщений проект з відкритим кодом, повністю присвячений ОДИНІ ПРАВИЛЬНОМУ МЕТАЛІ. Серед найпростішої конфігурації (файл ONE), найкорисніше і найнадійніше програмне забезпечення з відкритим кодом, з яким я потрапив у своєму житті.
Nginx: Apache, який не смокче
Основні характеристики :
- WebServer HTTP або HTTPS
- Запускайте програми в CGI / PHP / деяких інших
- Перенаправлення / перезапис URL-адрес
- Управління доступом
- Маніпулювання заголовками HTTP
- Кешування
- Зворотний проксі
Подібні альтернативи : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache був фактичним веб-сервером, відомим також як гігантський кластерний набір з десятків модулів і тисяч рядків httpd.confповерх зламаної архітектури обробки запитів. nginx повторює все це, маючи менше модулів, (трохи) простішу конфігурацію та кращу архітектуру ядра.
Що робить nginx і коли ви його повинні використовувати?
Веб-сервер призначений для запуску програм. Коли ваша програма розробляється для запуску на nginx, у вас вже є nginx, і ви також можете використовувати всі його функції.
За винятком випадків, коли ваша програма не призначена для запуску на nginx, а nginx ніде не знайдено у вашому стеку (хтось у магазині Java?), То в nginx мало сенсу. Функції веб-серверів, ймовірно, існують у вашому поточному веб-сервері, а інші завдання краще вирішуються відповідним спеціальним інструментом (HAProxy / Varnish / CDN).
За винятком випадків, коли у вашого веб-сервера / програми не вистачає функцій, важко налаштувати та / або ви краще помріть роботу, ніж подивіться на неї (хтось із Gunicorn?), Тоді ви можете поставити nginx попереду (тобто локально на кожному вузлі) для виконання URL-адреси переписувати, надсилати 301 переадресацію, застосовувати контроль доступу, забезпечувати шифрування SSL та редагувати заголовки HTTP на ходу. [Це функції, які очікуються від веб-сервера]
Лак: сервер кешування
Основні характеристики :
- Кешування
- Розширений кешування
- Дрібнозернистий кекінг
- Кешування
Подібні альтернативи : nginx (багатоцільовий веб-сервер, який можна налаштувати як кешування-сервер)
Різні альтернативи : CDN (Akamai, Amazon CloudFront, CloudFlare), апаратне забезпечення (F5, Fortinet, Citrix Netscaler)
Що робить лак і коли ви його повинні використовувати?
Це робить кешування, лише кешування. Зазвичай це не варте зусиль і це марна трата часу. Спробуйте натомість CDN. Пам’ятайте, що кешування - це останнє, про що ви повинні піклуватися під час роботи веб-сайту.
За винятком випадків, коли ви користуєтесь веб-сайтом виключно з зображеннями чи відео, тоді вам слід ретельно заглянути в CDN і подумати про кешування серйозно.
За винятком випадків, коли ви змушені користуватися власним обладнанням у власному центрі обробки даних (CDN не є варіантом), і ваші веб-сервери страшні при доставці статичних файлів (додавання більшої кількості веб-серверів не допомагає), тоді Varnish є крайнім засобом.
За винятком випадків, коли у вас є веб-сайт із в основному статичним, але ще складним динамічно генерованим контентом (див. Наступні параграфи), тоді лак може заощадити багато процесорних потужностей на ваших веб-серверах.
Статичне кешування завищено у 2016 році
Кешування майже без конфігурації, без грошей та часу. Просто підпишіться на CloudFlare, або CloudFront, Akamai або MaxCDN. Написати цей рядок потрібно більше часу, ніж час, необхідний для налаштування кешування І пиво, яке я тримаю в руці, коштує дорожче, ніж медіанна передплата CloudFlare.
Усі ці сервіси працюють з вікна для статичного * .css * .js * .png та багато іншого. Насправді вони здебільшого шанують Cache-Controlдирективу в заголовку HTTP. Першим кроком кешування є налаштування веб-серверів для надсилання правильних кеш-директив. Не має значення, який CDN, який Varnish, який браузер знаходиться посередині.
Розгляд продуктивності
Лак був створений у той час, коли середні веб-сервери задихалися подавати зображення кота в блозі. На сьогоднішній день єдиний екземпляр середнього сучасного багатопотокового асинхронного веб-сервера, керований голосною мовою, може надійно доставити кошенят на всю країну. Надано людьми sendfile().
Я зробив кілька швидких тестувань продуктивності для останнього проекту, над яким працював. Один екземпляр tomcat може обслуговувати від 21 000 до 33 000 статичних файлів за секунду через HTTP (тестування файлів від 20B до 12kB з різним числом з'єднань HTTP / клієнта). Стійкий вихідний трафік перевищує 2,4 Гбіт / с. Виробництво матиме лише 1 Гбіт / с інтерфейси. Не вдається краще, ніж обладнання, немає сенсу навіть пробувати Varnish.
Кешування комплекс, зміна динамічного змісту
Сервери CDN і кешування зазвичай ігнорують URL-адреси з такими параметрами, як ?article=1843ігнорують будь-який запит із файлами cookie-сеансів або автентифікованими користувачами, і вони ігнорують більшість типів MIME, включаючи application/jsonз /api/article/1843/info. Існують варіанти конфігурації, але, як правило, не дрібнозернисті, швидше "все або нічого".
Лак може мати спеціальні складні правила (див. VCL) для визначення того, що підлягає керуванню, а що ні. Ці правила можуть кешувати певний вміст за допомогою URI, заголовків та поточного файлу cookie сеансу користувача та типу MIME та вмісту ВСІ РАЗОМ. Це може зекономити багато процесорних потужностей на веб-серверах для дуже специфічної моделі завантаження. Ось тоді лак зручний і ДУЖЕ.
Висновок
Мені знадобилося певний час, щоб зрозуміти всі ці фрагменти, коли їх використовувати і як вони поєднуються. Сподіваюся, що це може вам допомогти.
Це виявляється досить довгим (6 годин для написання. OMG!: O). Можливо, я повинен почати блог чи книгу про це. Факт забави: здається, що обмеження щодо тривалості відповіді не існує.