Nginx и фронтенд разработка

Nginx и Node.js

«Nginx — это легкий HTTP-сервер, использующий управляемую событиями асинхронную неблокирующую структуру обработки, которая обеспечивает превосходную производительность ввода-вывода и часто используется для обратного проксирования на стороне сервера и балансировки нагрузки».

Как фронтенд-разработчик, даже если вы никогда не использовали Nginx, вы наверняка слышали это предложение. Это классическое предложение в основном составляет первое впечатление каждого о Nginx.

Nginx был выпущен в 2004 году. После нескольких лет осадков он быстро стал «сетевой знаменитостью» и в том году стал самым популярным словарем и технологией в кругу интернет-технологий. Однако после многих лет разработки, до сих пор, интернет-знаменитость года уже давно «прошла». Поскольку в настоящее время практически все крупные веб-сайты строятся на Nginx, Nginx уже не новое слово, а одна из необходимых технологий для создания веб-сайтов в Интернете. Увидев здесь «HTTP-сервер», «управляемый событиями», «асинхронный неблокирующий» и опыт знаменитостей в Интернете, Nginx, думает ли детская обувь о Nodejs?

На работе из-за рабочей платформы и языка для большинства фронтендовских детских ботинок больше склонны использовать Nodejs для сборки сервера, а затем для достижения некоторых требований возникает естественное чувство сопротивления Nginx. Действительно, большинство функций в Nginx можно удовлетворить и реализовать, просто используя Node.js. Но на самом деле Nginx и Node.js не конфликтуют, и у обоих есть свои области знаний: Nginx лучше обрабатывает базовые ресурсы на стороне сервера (обработка и пересылка статических ресурсов, обратный прокси-сервер, балансировка нагрузки и т. д.), Node.js лучше справляется с обработкой конкретной бизнес-логики на верхнем уровне. Эти два могут достичь идеального сочетания, чтобы помочь в разработке интерфейса.

Несколько слов в конце первой главы. Цель этой статьи — дать понять тем, кто занимается фронтендом, что благодаря краткому введению в Nginx Nginx может эффективно помочь фронтенд-разработке: можно поместить часть предыдущей работы Node.js в Nginx вместо мучительно в нпм найди мешки или построй колеса. Но на самом деле кажущаяся простой конфигурация Nginx на самом деле сложна. Для достижения одной и той же функции в Nginx эффективность может быть разной в несколько раз при разных способах написания конфигурации. И все это основано на глубоком понимании принципов Nginx и многолетнем опыте настройки, эксплуатации и обслуживания.Даже серверная часть вашей компании может не иметь глубокого понимания Nginx. Если вы действительно хотите подробно изучить Nginx, вам следует обратиться за советом к профессиональному SA или PE.

обратный прокси

Что такое обратный прокси? Интернет-приложения в основном основаны на базовой структуре CS, то есть на стороне клиента и на стороне сервера. Прокси — это фактически сервер, который предоставляет определенную услугу перед клиентом и настоящим сервером, то есть прокси-сервером.

1. прямой проксиОбратный прокси не так просто понять,прямой проксиВсе всегда использовали его, и инструмент для скалолазания на самом деле является прямым прокси-инструментом. это поставит Они получают доступ к запросу веб-страницы сервера за стеной и прокси-серверу прокси-сервера, который может получить доступ к веб-сайту.Прокси-сервер прокси-сервера получает содержимое веб-страницы на сервере-сервере за стеной и пересылает его клиенту. Конкретный процесс заключается в следующем.

   

   В двух словах: то есть клиент и прокси-сервер могут напрямую обращаться друг к другу и принадлежать к ЛВС (локальной сети); прокси-сервер принадлежит пользователюнепрозрачныйДа, то есть пользователь должен действовать или воспринимать, что его запрос отправляется на прокси-сервер, прокси-сервер передаетЗапросы прокси-клиентовдля запроса содержимого ответа с сервера вне домена.
2. обратный прокси обратный проксиНаоборот, сначала посмотрите на блок-схему.

   

   существуетобратный проксиНа самом деле (на самом деле эта ситуация в основном происходит в запросе страницы всех крупных веб-сайтов) запрос, отправленный клиентом, хочет получить доступ к контенту на сервере-сервере. Но он будет отправлен на прокси-сервер proxy, который будет проксировать запрос на внутренние серверы, принадлежащие к той же LAN, что и он сам, и на этих внутренних серверах хранится тот контент, который пользователь действительно хочет получить. Видите разницу?Прокси-сервер здесь не клиент, а сервер, то есть он предоставляет единую прокси-запись для внешних клиентов.Запрос клиента сначала проходит через прокси-сервер.Что касается того,куда собственно выйти в интранет Контент сервера контролируется этим прокси. Общий прокси относится к прокси-клиенту, а объектом прокси здесь является сервер, что и означает слово «обратный». Nginx должен выступать в качестве этого прокси. В двух словах: то есть прокси-сервер и реальный сервер-сервер могут напрямую обращаться друг к другу и принадлежать к локальной сети (внутренняя сеть сервера);Прозрачный, то есть никакого восприятия. Независимо от того, добавлен обратный прокси или нет, пользователь делает один и тот же запрос и не требует никаких дополнительных действий, прокси-сервер передаетпрокси внутренний серверПринимать запросы от клиентов за пределами домена и отправлять запросы на соответствующий внутренний сервер.
3. Почему обратный прокси NginxДве основные причины использования обратного прокси: 1) Безопасность и разрешения. Видно, что после использования обратного прокси клиент не сможет получить доступ к серверу реального контента напрямую через запрос, а должен сначала пройти через Nginx. Безопасность сервера можно обеспечить путем фильтрации опасного или несанкционированного содержимого запросов на уровне Nginx. 2) Балансировка нагрузки. Например, контент веб-сайта развернут на нескольких серверах, и эти машины можно рассматривать как кластер, тогда Nginx может «равномерно» распределять полученные клиентские запросы на все серверы в кластере (внутренний модуль обеспечивает различные алгоритмы балансировки нагрузки) для достижения балансировки нагрузки сервера. Кроме того, в nginx также есть функция проверки работоспособности (проверка сердцебиения сервера), которая будет периодически опрашивать и отправлять запросы проверки работоспособности на все серверы в кластере, чтобы проверить, не находятся ли какие-либо серверы в кластере в ненормальном состоянии. клиентские запросы, поступающие от прокси-сервера, не будут отправляться на сервер (до тех пор, пока последующая проверка работоспособности не обнаружит, что сервер возвращается в нормальное состояние), что обеспечивает стабильность клиентского доступа.

Что может интерфейс сделать с Nginx

Следующий контент основан на базовом понимании конфигурации Nginx. Если нет, сначала проверьте информацию в Интернете (например,базовая конфигурация), чтобы сделать простое понимание. Если вы хотите установить Nginx локально, настоятельно рекомендуется использоватьКомпиляция исходного кода и установка, чтобы потом было удобнее добавлять модули.

1. Быстро внедряйте простые ограничения доступаЧасто возникает ситуация, когда вы хотите, чтобы к веб-сайту обращались определенные группы пользователей (например, только из внутренней сети компании) или чтобы запретить доступ к определенному URI. Nginx настроен следующим образом:

       location / {
           deny  192.168.1.100;
           allow 192.168.1.10/200;
           allow 10.110.50.16;
           deny  all;
       }
   

   На самом деле запретить и разрешитьngx_http_access_moduleСинтаксис в модулях (уже встроен). Метод сопоставления применяется сверху вниз, и сопоставление выскочит, а не продолжит сопоставление. Смысл приведенной выше конфигурации заключается в том, чтобы сначала запретить доступ к 192.168.1.100, затем разрешить доступ в сегменте ip 192.168.1.10-200 (исключая 192.168.1.100) и разрешить доступ к единственному ip 10.110.50.16, оставив все непревзойденные. Нет доступа. В реальном производстве часто иngx_http_geo_moduleмодуль (для лучшего управления таблицей ip-адресов, встроенный).

2. разрешать междоменныеСреди многих кросс-доменных решений неизбежна необходимость поддержки сервера.Использование Nginx может решить проблему кросс-доменных запросов исключительно с внешнего интерфейса. Особенно, когда внешний и внутренний интерфейс разделены и отлажены, часто необходимо запускать внешний проект локально, и интерфейс надеется получить фактические данные сервера вместо локального макета. И если локальная программа напрямую обращается к удаленному интерфейсу, она обязательно столкнется с междоменными проблемами. Теперь зрелый подход к внешнему интерфейсу заключается в интеграции прокси-сервера узла. На самом деле Nginx тоже может решить проблему, и его даже можно применять онлайн. Запустите сервер nginx локально. имя_сервера — это mysite-base.com, например, теперь вам нужно запросить онлайн-интерфейс под онлайн-доменом www.kaola.comwoohoo.koala.com/get PC баннер…Данные, при запросе непосредственно на странице, браузер сообщит об ошибке:

   

   Чтобы обойти ограничения междоменной безопасности браузера,Теперь вам нужно изменить запрошенное доменное имя на mysite-base.com.. В то же время правило URL согласуется, чтобы указать идентичность запроса прокси, а затем Nginx прокси запрос обратно в исходный домен, соответствующую правилу. Nginx настроен следующим образом:

       #请求跨域，这里约定代理请求url path是以/apis/开头
       location ^~/apis/ {
           # 这里重写了请求，将正则匹配中的第一个()中$1的path，拼接到真正的请求后面，并用break停止后续匹配
           rewrite ^/apis/(.*)$ /$1 break;
           proxy_pass https://www.kaola.com/;
       }  
   

   В коде страницы замените URL-адрес запроса на http://mysite-base.com/apis/getpcbannerList.html. Это будет запросить данные нормально. Это на самом деле через Nginx, избегая ограничения перекрестного домена браузера способом, аналогичным взлому и реализует перекрестный доступ.

3. Адаптация к ПК и мобильной средеМногие веб-сайты теперь имеют два сайта: сайт для ПК и сайт H5, поэтому обычно требуется автоматически переключать сайты в зависимости от среды просмотра пользователя. Nginx может получить userAgent запрашивающего клиента через встроенную переменную $http_user_agent, чтобы узнать, находится ли пользователь на мобильном терминале или ПК, а затем управлять перенаправлением на станцию ​​H5 или станцию ​​ПК. Возьмем, к примеру, местный автор,Сторонний сайт для ПК — mysite-base.com.,Сторона H5 — mysite-base-H5.com.. Конфигурация Nginx на стороне ПК выглядит следующим образом:

       location / {
           # 移动、pc设备适配
           if ($http_user_agent ~* '(Android|webOS|iPhone|iPod|BlackBerry)') {
               set $mobile_request '1';
           }
           if ($mobile_request = '1') {
               rewrite ^.+ http://mysite-base-H5.com;
           }
       }  
   

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

   

4. запрос на слияниеВажным моментом в оптимизации производительности внешнего интерфейса является минимизация количества HTTP-запросов ресурсов. пройти черезnginx-http-concatМодули (сторонние модули, разработанные Taobao, которые необходимо устанавливать отдельно) используют специальное правило URL запроса (пример:example.com/1.js, 2.js, 3.js) внешний интерфейс может объединять несколько запросов ресурсов в один запрос, а фоновый Nginx будет получать каждый ресурс и объединять его в один результат для возврата. Например, в приведенном выше примере три js-ресурса 1.js, 2.js и 3js объединяются в один запрос через один запрос, что снижает нагрузку на браузер. В качестве примера возьмем локальный сервер mysite-base.com, в папке static/js находятся три файла, содержимое которых очень простое, а именно:

   

   Nginx настроен следующим образом:

       # js资源http-concat
       # nginx-http-concat模块的参数远不止下面三个，剩下的请查阅文档
       location /static/js/ {
           concat on; # 是否打开资源合并开关
           concat_types application/javascript; # 允许合并的资源类型
           concat_unique off; # 是否允许合并不同类型的资源
           concat_max_files 5; # 允许合并的最大资源数目
       }
   

   При запросе http://mysite-base.com/static/js/??a.js,b.js,c.js в браузере обнаруживается, что три js объединяются в один и возвращаются, как показано ниже:

   

5. Обработка изображенияВо фронтенд-разработке часто требуются изображения разного размера. Текущее облачное хранилище в основном предоставляет услуги по обработке изображений (обычно путем добавления параметров к ссылке на изображение). Фактически, с Nginx вы можете создать свой собственный локальный сервис обработки изображений с помощью десятков строк конфигурации, которые могут полностью удовлетворить ежедневные потребности в обработке изображений, таких как обрезка/масштабирование/поворот/качество изображения. использоватьngx_http_image_filter_moduleмодуль. Этот модуль не является базовым и требует установки. Ниже приведена конфигурация Nginx для раздела функции масштабирования изображения:

       # 图片缩放处理
       # 这里约定的图片处理url格式：以 mysite-base.com/img/路径访问
       location ~* /img/(.+)$ {
           alias /Users/cc/Desktop/server/static/image/$1; #图片服务端储存地址
           set $width -; #图片宽度默认值
           set $height -; #图片高度默认值
           if ($arg_width != "") {
               set $width $arg_width;
           }
           if ($arg_height != "") {
               set $height $arg_height;
           }
           image_filter resize $width $height; #设置图片宽高
           image_filter_buffer 10M;   #设置Nginx读取图片的最大buffer。
           image_filter_interlace on; #是否开启图片图像隔行扫描
           error_page 415 = 415.png; #图片处理错误提示图，例如缩放参数不是数字
       }
   

   

   Вот только самая основная конфигурация. Кроме того, кеш Nginx можно настроить через proxy_cache, чтобы избежать повторной обработки изображений для каждого запроса и снизить нагрузку на сервер Nginx при обработке;nginx-upload-moduleИспользуйте функцию добавления загрузки изображений вместе и т. д.

6. модификация содержимого страницыNginx может изменять содержимое страницы, вставляя дополнительные файлы css и js внизу или вверху страницы. Эта функция требует поддержки дополнительных модулей, таких как:nginx_http_footer_filterилиngx_http_addition_module(оба должны быть установлены). По работе часто приходится переключать различные тестовые среды, а после переключения через такие инструменты, как switchhosts, иногда необходимо очистить DNS-кеш браузера. Легкое и быстрое переключение среды может быть достигнуто за счет модификации содержимого страницы + обратного прокси-сервера Nginx. Здесь сначала пишем кусок js-кода (switchhost.js) локально, логика внутри такая: когда страница вставляет меню переключения хостов и нажимает на конкретную среду, сохраняет ip и имя хоста хоста в куки, и, наконец, обновите страницу, затем напишите фрагмент кода css (switchhost.css), чтобы установить стиль меню переключения хостов. Затем конфигурация скрипта Nginx:

   server {
           listen 80;
           listen  443 ssl;
           expires -1;
           # 想要代理的域名
           server_name m-element.kaola.com;
           set $root /Users/cc/Desktop/server;
           charset utf-8;
           ssl_certificate      /usr/local/etc/nginx/m-element.kaola.com.crt;
           ssl_certificate_key  /usr/local/etc/nginx/m-element.kaola.com.key;
   
           # 设置默认$switch_host，一般默认为线上host，这里的1.1.1.1随便写的
           set $switch_host '1.1.1.1';
           # 设置默认$switch_hostname，一般默认为线上'online'
           set $switch_hostname '';
           # 从cookie中获取环境ip
           if ($http_cookie ~* "switch_host=(.+?)(?=;|$)") {
               set $switch_host $1;
           }
           
           # 从cookie中获取环境名
           if ($http_cookie ~* "switch_hostname=(.+?)(?=;|$)") {
               set $switch_hostname $1;
           }
           
           location / {
               expires -1;
               index index.html;
               proxy_set_header Host $host;
               #把html页面的gzip压缩去掉，不然sub_filter无法替换内容
               proxy_set_header Accept-Encoding '';
               #反向代理到实际服务器ip
               proxy_pass  http://$switch_host:80;
               #全部替换
               sub_filter_once off;
               #ngx_http_addition_module模块替换内容。
               # 这里在头部插入一段css，内容是hosts切换菜单的css样式
               sub_filter '</head>' '</head><link rel="stylesheet" type="text/css" media="screen" href="/local/switchhost.css" />';
               #将页面中的'网易考拉'文字后面加上环境名，便于开发识别目前环境
               sub_filter '网易考拉' '网易考拉:${switch_hostname}';
               #这里用了另一个模块nginx_http_footer_filter，其实上面的模块就行，只是为了展示用法
               # 最后插入一段js，内容是hosts切换菜单的js逻辑
               set $injected '<script language="javascript" src="/local/switchhost.js"></script>';
               footer '${injected}';
           }
           # 对于/local/请求，优先匹配本地文件
           # 所以上面的/local/switchhost.css，/local/switchhost.js会从本地获取
           location ^~ /local/ {
               root $root;
           }
   }
   

   

   Эта функция фактически предоставляет безграничные возможности для применения Nginx во фронтенд-разработке. Например, различая локальную, тестовую и онлайн-среды, многие функции помощи при разработке могут быть добавлены на страницу локальной/тестовой среды: добавление резидентного QR-кода на локальную страницу удобно для сканирования и отладки на мобильном телефоне; вставляется в конец файла js для облегчения локальной отладки и так далее.

Суммировать

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