Время написания: 2018-11-29 11:18:10
Описание окружающей среды
Ubuntu 16.04 LTS
Nginx version: nginx/1.10.3 (Ubuntu)
PHP 7.1.18
Laravel 5.5
Заявление о потребностях
Для проектов разработки WeChat необходимо отлаживать интерфейс WeChat.Для локальной разработки можно использовать инструменты разработчика WeChat и тестовую общедоступную учетную запись WeChat для имитации работающей среды и интерфейса. Однако некоторые интерфейсы мерчант-аккаунтов WeChat, такие как оплата WeChat, в настоящее время необходимо разрабатывать с помощью моделирования песочницы, что недостаточно удобно.
Поэтому мы хотим создать среду онлайн-тестирования, которую можно использовать для проектов разработки WeChat, а интерфейс, который может получить реальную общедоступную учетную запись WeChat, удобен для онлайн-тестирования.
идеи
Самая простая идея создать тестовую онлайн-среду — это приобрести дополнительный сервер с точно такими же параметрами оборудования и конфигурацией среды, что и у сервера рабочей среды. В плане стыковки с платформой WeChat необходимо зарегистрировать дополнительную официальную учетную запись WeChat с аутентификацией WeChat.
Хотя это может решить проблему, это добавляет дополнительные расходы и дополнительные работы по обслуживанию серверов, учетных записей WeChat и т. д., что не является лучшей политикой для такой начинающей технической команды, как мы.
Есть ли ещебюджетныйи большеУпрощение обслуживания и итерации системыПрограмма тогда?
После некоторых мучений мы разработали схему обмена, чтобы приветствовать обмен.
Обмен решениями
Ключ к проблеме в том, как решить проблемуПроблема с доступом в WeChat
Друзья, которые занимались разработкой WeChat, знают, что для доступа к WeChat необходимо заполнить запись доменного имени, привязанного к серверу, на фоне официальной учетной записи WeChat.
www.project.com/loginуказать на производствоdev.project.com/loginУказать на онлайн-среду тестирования Тогда публичный счет WECHAT может выбрать только для доступа к одному доменому имени.
Берем функцию обратного прокси Nginx для ее решения, то есть при запросе доступаwww.project.comДля этого доменного имени сервер Nginx сопоставляет правила пути, чтобы реализовать переадресацию запросов, чтобы они указывали на разные каталоги проекта. Например:
www.project.com/loginуказать на производствоwww.project.com/dev/loginУкажите на среду онлайн-тестирования
Настроив сервер Nginx так, чтобы запрос соответствовал /dev/, запрос перенаправляется в проект в тестовой среде для обработки.
Вот код реализован конфигурация Nginx
Действия Управление профилями /etc/nginx/sites-available/project.proxy.conf
server {
listen 80;
server_name 127.0.0.1 www.project.com;
index index.html index.php;
charset utf-8;
access_log /var/log/nginx/project.proxy.access.log;
error_log /var/log/nginx/project.proxy.error.log;
# 生产环境
location / {
proxy_pass http://127.0.0.1:9001;
proxy_set_header Host $host:$server_port;
}
# 线上测试环境
location ^~ /dev/ {
proxy_pass http://127.0.0.1:9002;
proxy_set_header Host $host:$server_port;
}
}
В дополнение к настройке сервера Nginx вам также необходимо установить среду конфигурации проекта. В основном просьба войти в проект плюсединый префикс, этот другой фреймворк имеет разные реализации, ниже в качестве примера используется только php-фреймворк Laravel: В рамках проекта Laravel, Сначала добавьте переменную PREFIX в среду конфигурации .env.
PREFIX=/dev // 前面加 / 是为了解决后续静态资源处理的问题，算是一个小坑
Затем измените mapWebRouters() в файле app/Providers/RouterServiceProvider.php:
protected function mapWebRoutes()
{
// 从配置文件中获取前缀
$prefix = env("PREFIX") === "" ? "" : explode('/',env("PREFIX"))[1];
Route::prefix($prefix) // 给路由添加统一前缀
->middleware('web')
->namespace($this->namespace)
->group(base_path('routes/web.php'));
}
В фактическом развертывании ПРЕФИКС в файлах .env рабочей среды и среды онлайн-тестирования можно настроить как «» и «/dev» соответственно.
Здесь мысль, что все готово.
Визит, но обнаружил, что статические файлы 404.
После расследования выяснилось, что проблема кроется в пути ссылки на статический файл, например:
<script src="/dev/test/test.js"></script>
При доступе к фактической странице путь запроса ресурса будет сращен с доменным именем, то есть в конечном итоге он станет:
Все статические ресурсы Laravel размещаются в общедоступном каталоге.Из-за добавления унифицированного префикса маршрутизации приведенный выше URL-адрес не указывает на каталог ресурсов, в котором находится общедоступный каталог, а обрабатывается как запрос маршрутизации...
В конце концов, мое решение состоит в том, чтобы изменить конфигурацию Nginx, выполнить проверку правил для пути URI запроса, сопоставить запросы, заканчивающиеся на .js или .css, и удалить строку /dev/ в URL-адресе.
Модифицированный код конфигурации /etc/nginx/sites-available/project.proxy.conf выглядит следующим образом:
server {
listen 80;
server_name 127.0.0.1 www.project.com;
index index.html index.php;
charset utf-8;
access_log /var/log/nginx/project.proxy.access.log;
error_log /var/log/nginx/project.proxy.error.log;
# 生产环境
location / {
proxy_pass http://127.0.0.1:9001;
proxy_set_header Host $host:$server_port;
}
# 线上测试环境
location ^~ /dev/ {
proxy_pass http://127.0.0.1:9002;
# 静态资源过滤 /dev/
if ($request_uri ~* .(?:js|css)$) {
rewrite /dev/(.+)$ /$1 break;
}
proxy_set_header Host $host:$server_port;
}
}
сейчас в гостях
После того, как запрос будет перенаправлен, он будет обработан как
Таким образом, к каталогу общедоступных ресурсов в проекте Laravel можно получить доступ в обычном режиме.
пит-рекорд
В процессе я еще наступил на много ям:
- Настройка прокси-сервера Nginx
proxy_set_header Host $host:$server_port;
Эта строка кода необходима, иначе первое посещениеwww.project.com/dev/loginможет перейти в правильный каталог, но все последующие запросы в проекте будут установлены вhttp://127.0.0.1:9002начало...
- Также следует изменить путь ссылки на статический ресурс в проекте, например:
<script src="/dev/test/test.js"></script>
Выше приведен скомпилированный рабочий код, фактический код разработки должен быть таким (синтаксис блейд-шаблона фреймворка Laravel):
<script src="{{ env('PREFIX') }}/test/test.js"></script>
- В статических ресурсах все еще есть скрытые опасности, если ссылки на ресурсы асинхронные, это будет круто. Эта ситуация в основном возникает в справочной библиотеке инструментов, и будет сложнее обращаться к статическим ресурсам, таким как изображения...
задача для оптимизации
Скрытые опасности статических ссылок на ресурсы вызывают потребность в более эффективных решениях. Текущие решения по оптимизации, которые приходят на ум, следующие:
- На все статические ресурсы ссылается CDN, чтобы избежать проблем с путями.
- Все значки стилей используют метод font-icon, чтобы избежать проблем с путями элементов значков.
Суммировать
В этой статье в основном рассказывается о методе построения онлайн-тестовой среды для проектов WeChat с одним сервером (одной и той же официальной учетной записью) со следующими основными моментами:
- Реализовать распределение запросов через механизм обратного прокси Nginx.
- Через конфигурацию среды проекта реализуйте запрос на добавление унифицированного префикса маршрутизации в проект.
- Яма, вызванная проблемой пути статического ресурса в проекте, метод лечения и идея оптимизации
использованная литература:
Артефакт proxy_pass конфигурации nginx!
Описание того, следует ли добавлять / после URL-адреса в конфигурации обратного прокси-сервера proxy_pass
Laravel получает текущий URL-адрес и текущую сводку методов базового доменного имени.
Условия суждения в операторах if в Nginx