Об интерфейсной архитектуре масштабных проектов (оригинал на 8000 слов)

Архитектура внешний интерфейс внешний фреймворк

Об архитектуре фронтенда масштабных проектов

обновление: 2019.06.17 обновление 2.4 ссылка на статью

содержание:

  • 1. Комплексный
  • 1.1. Сценарии использования
  • 1.2, основная идея
  • 1.3, угол врезки
  • 1.4. Прочее
  • 2. Базовый дизайн слоя
  • 2.1. Самостоятельно построенный Gitlab
  • 2.2, управление версиями
  • 2.3 Автоматически компилировать и публиковать Jenkins
  • 2.4, выпущена чистая фронтальная версия
  • 2.5.Унифицированные леса
  • 2.6, средний уровень узла
  • 2.7 Система погребенных точек
  • 2.8 Система мониторинга и сигнализации
  • 2.9 Управление безопасностью
  • 2.10. Эслинт
  • 2.11. Выпуск оттенков серого
  • 2.12. Разделение переднего и заднего концов
  • 2.13. Макет
  • 2.14 Регулярное резервное копирование
  • 3. Дизайн прикладного уровня
  • 3.1. Многостраничные и одностраничные
  • 3.2 Разделите интерфейсные проекты по приложениям
  • 3.3 Построение библиотеки базовых компонентов
  • 3.4 Унификация стека технологий
  • 3.5, совместимость с браузером
  • 3.6 Контент-платформа_конструкция платформы
  • 3.7. Платформа управления правами_платформа
  • 3.8 Дизайн системы входа (единый вход)
  • 3.9. CDN
  • 3.10, балансировка нагрузки
  • 3.11 Несколько портов совместно используют набор интерфейсов
  • 4. Резюме

1. Комплексный

Два года назад я написал краткое введение в архитектуру интерфейса малых и средних проектов. Имея возможность расти и опыт работы в Alibaba, пришло время написать анализ архитектуры внешнего интерфейса большого проекта.

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

Из-за ограниченных возможностей автора могут быть упущения или некоторые ошибки, и читатели могут указать на них.

1.1. Применимые сценарии:

Эта статья подходит для одного/нескольких крупных проектов с более чем 10 сценариями фронтенд-разработки.

Соотношение затрат и выгод будет варьироваться в зависимости от размера внешнего проекта. Вообще говоря, чем больше персонала и чем сложнее проект, тем больше соотношение выгоды/затраты.

Для команды разработчиков с небольшим количеством людей и простым проектом некоторые меры могут быть неприменимы, поэтому их следует подбирать в соответствии с конкретной ситуацией.

1.2, основная идея:

[1] Решение проблем. Архитектура внешнего интерфейса должна использоваться для решения существующих или будущих технических проблем и повышения управляемости, стабильности и масштабируемости проекта.

[2] Коэффициент человеческой эффективности: для транзакций, требующих дополнительной рабочей нагрузки на разработку (в этой статье есть некоторый контент, требующий определенного объема разработки), когда мы решаем, делать ли это, мы должны учитывать два фактора: первый — это стоимость Человеческие затраты, вторая - это время и деньги, которые могут быть сэкономлены в будущем, предотвращение проектных рисков и капитальных потерь, улучшение возможностей поддержки бизнеса для повышения ценности, которую можно измерить в бизнесе, и другие ценности.

[3] Качественный и количественный: содержимое, разработанное в архитектуре, должно быть измеримым, предпочтительно количественным, то есть выгоды или снижение затрат могут быть измерены или, по крайней мере, качественными. дайте понять, что это важно, например, для повышения безопасности и снижения риска.

[4] Конфиденциальность данных. Эта статья специально написана, чтобы подчеркнуть важность данных как основы. Когда нам нужно убедить другие отделы/старших менеджеров продвигать то, что мы разработали, только данные, особенно данные, связанные с деньгами, являются наиболее убедительным доказательством.

Из-за нехватки места в этой статье трудно привести количественные значения напрямую, поэтому рекомендуется, чтобы архитектор сначала удостоверился, что в дизайне проекта используется система скрытых точек в 2.7. Запишите это в PPT. и координировать свои действия с другими отделами/высшими руководителями.

1.3 Угол резки:

Он делится на базовый уровень и прикладной уровень.

Базовый слой ориентирован на строительство инфраструктуры и менее важен для бизнеса.

Прикладной уровень ближе к пользователю и используется для решения определенной задачи.

Некоторые из них связаны с обоими, и они делятся на одно в соответствии с опытом.

1.4. Прочее

Поскольку мы говорили об уровне архитектуры, многие содержания находятся не только в области фронтенда, но и в составной области (фронтенд, бэкэнд, эксплуатация и обслуживание, тестирование), поэтому люди, которые отвечают за требуется архитектура, а технологический стек достаточно всеобъемлющ. Будущее развитие достаточно перспективно.

Структура содержания статьи следующая: [Проект] —> [Решенные проблемы и полученная польза] —> [Практическая значимость проекта]

2. Базовый дизайн слоя

2.1. Самостоятельно построенный Gitlab

Это основная основа. Это не следует упоминать, но, учитывая несколько компаний, с которыми я недавно беседовал, некоторые компании (людей немного) не используют Gitlab, поэтому я специально упоминаю об этом, и сложность использования этого очень низкая.

Настоятельно рекомендуется использовать Gitlab для управления версиями.Самостоятельно созданный Gitlab несложный и простой в управлении, включая управление кодом, управление разрешениями, запрос журнала отправки и привязку к некоторым сторонним плагинам.

значимость:

Код компании является важным активом компании, и использование Gitlab, созданного самостоятельно, может эффективно защитить активы компании.

2.2, управление версиями

Несколько ключевых моментов управления версиями:

  • После выпуска ветка блокируется и не может быть изменена: Когда, например, версия 0.0.1 успешно выпущена, код на ветке 0.0.1 нельзя изменить, иначе управление версиями может быть хаотичным.
  • Полностью автоматический выпуск процесса: это означает, что после отправки разработчиком следует избегать таких операций, как ручная компиляция и упаковка. Разработчики не имеют прямого контакта с соответствующей средой. Для этого см. 2.3 ниже.
  • Сосуществование нескольких версий; означает, что после выпуска версии 0.0.2 код версии 0.0.1 по-прежнему должен храниться в сети (например, в CDN), чтобы при возникновении онлайн-ошибок было удобно быстро вернуться к исходной версии. Предыдущая версия.

значимость:

Улучшить управляемость проекта.

2.3 Автоматически компилировать и публиковать Jenkins

Этот инструмент используется для выполнения ряда процессов после публикации кода, таких как автоматическая компиляция, упаковка и слияние, а затем публикация из Gitlab на CDN или сервер статических ресурсов.

Использование этого инструмента позволяет обычным разработчикам не заботиться о том, что происходит после передачи кода в Gitlab, а сосредоточиться только на разработке.

значимость:

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

2.4, выпущена чистая фронтальная версия

Чистая версий для интерфейсных версий разделена на два шага:

  • Внешний интерфейс выпущен в производственную среду — в это время вы можете получить доступ к новой версии кода через внешнюю сетевую ссылку и правильный номер версии, но ресурсы на странице по-прежнему имеют старую версию;
  • Внешний интерфейс использует инструмент конфигурации (или напрямую обновляет html-файл), чтобы изменить ресурсы, представленные в html, на новую версию.

Решаемая проблема заключается в следующем: когда фронтенду нужно выпустить новую версию, он не зависит от бэкенда (или эксплуатации и обслуживания, в зависимости от реальной ситуации). Ведь есть много требований, не требующих вмешательства бэкенда, очевидно, очень хлопотно выпустить бэкенд один раз после простой смены версии фронтенда.

Для этого нужны специализированные инструменты для настройки выпусков релизов, о которых я недавно писал.

значимость:

Повысить эффективность релиза, уменьшить потери времени персонала, вызванные релизом (это все деньги), а также может быть быстрее при откате фронтенд версии.

Ссылка на статью:

nuggets.capable/post/684490…

2.5.Унифицированные леса

Применимые сценарии: существует множество независимых малых и средних проектов. выгода:

  • Это может сократить потери времени, вызванные конфигурированием скаффолдинга разработчиками (специальные функции можно настроить после разветвления скаффолдинга);
  • Унифицировать структуру проекта, облегчить управление и сократить время, необходимое для ознакомления с проектом при передаче проекта;
  • Удобно унифицировать стек технологий, а фиксированную библиотеку компонентов можно ввести заранее;

значимость:

Улучшите способность разработчиков быстро переключаться между несколькими проектами, улучшите ремонтопригодность проектов, унифицируйте стек технологий компании и избегайте странных проблем, вызванных разными средами.

2.6, средний уровень узла

Применимые сценарии: требуется поисковая оптимизация, а внешний интерфейс использует React, vue или внешний интерфейс вмешивается в внутреннюю логику для прямого чтения внутренней службы или базы данных.

  • SEO: Благожелательный видит благожелательный, а мудрый видит мудрость.Хотя многие компании перестали это делать, обычно считается, что это все еще имеет смысл (особенно когда требуется осушение поисковой системы), поэтому необходим изоморфизм React или Vue . И изоморфизм также может уменьшить время белого экрана главной страницы;
  • Внешний интерфейс считывает внутренний сервис/базу данных: преимущество заключается в повышении эффективности разработки внешнего интерфейса и способности поддерживать бизнес, а недостатком является то, что это может привести к сбоям уровня P0.

значимость:

Позвольте внешнему интерфейсу вторгнуться в область серверных и качественно улучшите возможности поддержки бизнеса.

2.7 Система погребенных точек

Настоятельно рекомендуется, чтобы внешний интерфейс был вашей собственной встроенной системой. Это отличается от внутренней системы ведения журнала.

Преимущества фронтальной встраиваемой системы:

  • Зафиксировать количество посещений каждой страницы (UV, PV дня, недели, месяца, года);
  • записывать использование каждой функции;
  • зафиксировать ошибочные состояния;
  • Графический дисплей, удобный для отображения другим отделам;

Система скрытых баллов - это острый меч, позволяющий интерфейсу активно участвовать в бизнесе и понимать его развитие.Благодаря этой системе мы можем глубже понять привычки пользователей, чем серверная часть, и предоставить точная база данных для менеджеров по продуктам, операций и другого персонала. Когда данные доступны, персонал внешнего интерфейса может целенаправленно оптимизировать функции, макеты, логику взаимодействия со страницами и процессы использования пользователями.

Система скрытых баллов должна быть отделена от бизнеса, зарегистрирована разработчиками при ее использовании, а затем внедрена в проект. Затем проверьте соответствующие данные в системе скрытых точек (например, проверьте циклы часов, дней, недель, месяцев и лет) [Исходный водяной знак — Автор: Zero Zero Water (Ванг Донг), WeChat: qq20004604].

значимость:

Данные — это деньги, данные — источник жизненной силы компании, а данные — лучшее оружие.

2.8 Система мониторинга и сигнализации

Система мониторинга и сигнализации должна быть установлена ​​на основе системы скрытых точек, которая срабатывает в следующих сценариях [Оригинальный водяной знак — Автор: Zero Zero Water (Wang Dong), WeChat: qq20004604]:

  • Когда происходит относительно большое изменение количества посещений (например, ежедневный PV/UV составляет менее 20% от предыдущего), автоматически срабатывает сигнал тревоги, и на почтовый ящик соответствующего персонала отправляется электронное письмо;
  • Например, если количество сообщений об ошибках значительно увеличивается (например, на 200 % или выше), срабатывает сигнал тревоги;
  • При отсутствии трафика в течение определенного периода времени (не в соответствии с предыдущей ситуацией) срабатывает тревога;
  • Через некоторое время автоматически обобщать соответствующую информацию о посетителе/триггере ошибки (например, о системе, версии браузера и т. д.);

Преимущество построения этой системы заключается в том, чтобы найти некоторые баги, которые не так просто найти заранее (нужно основательно закопать). Есть некоторые онлайн-ошибки, которые не могут быть обнаружены разработчиками и тестировщиками из-за особой пользовательской среды. Тем не менее, некоторые из ошибок не приведут к потере капитала, потому что они не связаны с финансированием (и, следовательно, не будут обнаружены серверной системой мониторинга), такие ошибки могут легко повлиять на нормальное использование ссылки в проекте.

значимость:

Улучшите стабильность проекта и улучшите возможность контроля бизнеса. Сократите количество ошибок, уменьшите вероятность потери капитала и найдите ошибки в определенных функциях заранее (до прихода тикета).

2.9 Управление безопасностью

Управление безопасностью фронтенда обычно зависит от бэкенда, а что касается основных, таких как dom.innerHTML= 'xxx ', которые относятся только к простым, я не буду их упоминать.

Сложно полностью избежать управления безопасностью при разработке фреймворка, но есть некоторые решения общих проблем безопасности, а именно:

  • Внедрение XSS: контент, вводимый пользователем, должен быть перекодирован (большую часть времени он должен обрабатываться на стороне сервера, а иногда он должен обрабатываться внешним интерфейсом), и использование функции eval запрещенный;
  • https: это, очевидно, обязательно, и есть много преимуществ;
  • CSRF: метод обработки, требующий от сервера присоединения к CSRF (по крайней мере, на ключевых страницах);

значимость:

Уменьшите количество лазеек в системе безопасности, предотвратите потерю пользователей, избегайте злонамеренных атак и повысьте стабильность и безопасность системы.

2.10. Эслинт

Преимущества Eslint многочисленны и настоятельно рекомендуются:

  • Уменьшить вероятность низкоуровневых ошибок (таких как орфографические проблемы);
  • повысить ремонтопригодность и читабельность кода;
  • Жесткий единый стиль кода упрощает совместную работу команд;

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

значимость:

Улучшите ремонтопригодность кода и сократите затраты на совместную работу команды.

2.11. Выпуск оттенков серого

Выпуск в градациях серого — распространенный метод для крупномасштабных проектов. Это означает, что при выпуске версии изначально разрешена только небольшая часть (например, 1–5 % пользователей). вернуться к старой версии версии, подходящей для основных ссылок и часто посещаемых страниц.

Преимущества следующие:

  • Производственная среда более сложна, чем среда разработки.Когда выпускаются оттенки серого, вы можете попытаться пронаблюдать, может ли новая версия нормально работать в небольшой области производственной среды.Даже если есть проблема, вы можете контролировать потеря.
  • Для крупного обновления версии вы можете сначала оттенить часть в оттенках серого, чтобы наблюдать эффект скрытой точки и отзывы пользователей (так называемая упреждающая пробная версия). Если эффект нехороший, то откат на старую версию тоже может вовремя остановить проигрыш;
  • Когда нам нужно проверить какие-то идеи или проблемы, мы можем сначала сделать часть в градациях серого, чтобы быстро проверить эффект, а затем проверить на наличие упущений или провести целевую оптимизацию;

Публикация в оттенках серого обычно делится на несколько этапов: [1] 1%; [2] 510% [3] 3050% [4] Полный толчок (100%). Версия в оттенках серого должна позволять настроить определенный доступ IP/учетной записи для прямого доступа к версии в оттенках серого.

значимость:

Уменьшите риск и повысьте гибкость выпуска.

2.12. Разделение переднего и заднего концов

Это не относится к общему разделению интерфейсной и конечной частей, а относится к области контроля до и после распространения.

Обычная ситуация для малых и средних проектов заключается в том, что серверная часть предоставляет только интерфейс и указывает определенный URL-адрес на определенный html, а передняя часть отвечает за статические ресурсы, такие как html, css и js.

Однако это не рекомендуется для больших проектов.Рекомендуется, чтобы передняя часть отвечала за статические ресурсы, отличные от html, а html передавался на обработку в заднюю часть.Причин много:

  • Бэкэнд визуализируется для облегчения унифицированной вставки некоторых кодов и ресурсов, таких как встроенные js, мониторинг js, интернационализированные текстовые ресурсы, идентификаторы страниц и т. д. Обычно они пишутся непосредственно бэкендом, вызывая какой-либо сервис;
  • Когда странице требуется унифицированная голова и хвост (см. мою страницу Taobao в Taobao), внешний интерфейс не должен обращать внимание на эти вещи, которые не имеют ничего общего с текущей страницей;
  • Если что-то управляется через html, то сцепление слишком высокое, что нарушает принципы развязки и разделения;
  • После выпуска front-end версии и внедрения определенного функционального модуля в back-end, контентом front-end можно управлять с отдельной страницы, что удобнее, чем обновление html, а также способствует публикации в градациях серого. ;

значимость:

Более стандартизированное управление страницами, уменьшение связи между страницами и функциями и сокращение времени настройки среды для сложных страниц.

2.13. Макет

Mock также является одной из распространенных интерфейсных систем, которая используется для генерации возвращаемых данных, когда внутренний интерфейс не очень хорош.

Лично я не рекомендую разрабатывать специальную систему для мокинга, лучший метод мокинга — встроить его прямо в скаффолдинг. Идея заключается в следующем:

  • В среде разработки ссылка доступа обычно имеет вид localhost:8000/index.html, и в это время добавляется суффикс ?debug=true;
  • Когда инкапсулированный асинхронный запрос обнаруживает, что текущая ссылка имеет вышеуказанные флаги, он считается тестовой средой, при доступе к /userinfo он не читает онлайн-данные (потому что их нельзя прочитать), а читает src/test_ajax/ в локальном окружении userinfo.json и вернуть содержимое пользователю;
  • Асинхронный запрос получает данные нормально, и они отображаются на странице [Original Watermark - Author: Zero Zero Water (Wang Dong), WeChat: qq20004604];
  • После того, как онлайн-интерфейс сможет получить данные, найдите возвращенные данные из сети и поместите их в /src/test_ajax/userinfo.json.В это время, если вы снова отлаживаете локально, это эквивалентно использованию реальных онлайн-данных.
    </li>

Такая обработка может уменьшить сложность макета, макет возвращается, когда данные могут быть изменены, разработка макета, чем одна рентабельная система.

значимость:

Когда интерфейс и серверная часть разрабатываются параллельно, стоимость связи снижается, и удобно подключаться сразу после завершения разработки.

2.14 Регулярное резервное копирование

Резервное копирование — это вещь, которую часто упускают из виду, но когда мы сталкиваемся с разрушительными сценариями, потери, вызванные отсутствием резервного копирования, очень велики.Обычные сценарии:

  • Сервер поврежден, что приводит к уничтожению всего содержимого на сервере;
  • Вызвать фатальную ошибку или неправильную операцию (например, rm -f), в результате чего все файлы и данные исчезнут;
  • Произошла неправильная операция или проблема в базе данных, что привело к серьезной потере пользовательских данных и активов компании;

В общем, никто не хочет сталкиваться с таким сценарием, но нам приходится учитывать возникновение таких крайних случаев, поэтому эту проблему нужно решать на архитектурном уровне. Распространенными методами являются регулярное резервное копирование, резервное копирование нескольких машин, построение системы аварийного восстановления и т. д.

значимость:

Избегайте неисчислимых потерь для компании при столкновении с экстремальными сценариями.

3. Дизайн прикладного уровня

3.1. Многостраничные и одностраничные

За исключением особых случаев, обычно рекомендуется многостраничная архитектура. Причины следующие:

  • Для многостраничных проектов страницы независимы и нет взаимодействия, поэтому, когда страницу нужно рефакторить отдельно, это не повлияет на другие страницы, для проектов с многолетней историей ремонтопригодность и реконфигурируемость намного выше;
  • Недостатком многостраничных проектов является то, что при переключении между разными страницами будет время пустого экрана, но в целом это время невелико.Большинство онлайн-страниц существующих крупных компаний такие, поэтому считается приемлемый из;
  • Многостраничные проекты могут обновлять версию только одной страницы за раз, и если необходимо обновить один из функциональных модулей одностраничного проекта (особенно обновление общедоступного компонента), легко сделать так, чтобы все страницы нуждались в обновлении. обновляться;
  • Контроль версий многостраничных проектов проще, если вам нужно разбить страницы, будет проще настроить процесс использования некоторых страниц;
  • Публикация в оттенках серого более удобна;

Тот, у которого я брал интервью ранее, использовал одностраничный формат, по разным причинам ng и react использовались одновременно. Из-за долгой истории проекта (более 3-х лет) его очень сложно продолжать поддерживать и обновлять в настоящее время, даже если вы хотите провести частичный рефакторинг, это очень хлопотно.

значимость:

Уменьшить сложность итеративного обслуживания долгосрочных проектов,

3.2 Разделите интерфейсные проекты по приложениям

Когда проект относительно большой, интерфейсные файлы всех страниц помещаются в один и тот же репозиторий кода.Я уже участвовал в разработке внешнего интерфейса компании и обнаружил, что это то, что он делает. По опыту использования [Original Watermark - Автор: Zero Zero Water (Wang Dong), WeChat: qq20004604], проблем много:

  • Это значительно увеличит сложность обслуживания кода;
  • Проекты могут быть уродливыми;
  • Неудобно управлять разрешениями, легко вызвать изменение страницы или утечку кода;
  • Любой человек имеет право изменить любую страницу, которую он может видеть (при слиянии кода менеджер не может определить, является ли страница, которую он изменил на этот раз, той страницей, которую он должен изменить в требованиях);
  • Стоимость публикации высока, даже если страница изменена, все ресурсы должны быть опубликованы;

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

  • Это удобно для управления.Когда бизнесу нужно измениться, он может только дать разработчикам разрешение разработчика внешнего приложения бизнеса;
  • Когда сервис необходимо опубликовать, необходимо опубликовать только приложение сервиса;

значимость:

Стандартизируйте проекты, повысьте безопасность кода и сократите затраты на обслуживание проектов.

3.3 Построение библиотеки базовых компонентов

Это довольно просто.Для построения библиотеки компонентов не рекомендуется делать это, когда мало R&D персонала.Когда количество штатных фронтенд-разработчиков меньше 10, рекомендуется использовать более надежная сторонняя библиотека пользовательского интерфейса, такая как Antd, которая экономически выгодна.

Предпосылка проектирования базовой библиотеки компонентов состоит в том, чтобы требовать унифицированного стека технологий, чтобы максимально использовать преимущества базовой библиотеки компонентов. Библиотека компонентов рекомендует использовать следующие эталонные стандарты:

  • использовать тс;
  • Сильная масштабируемость;
  • Высокая степень применимости;
  • Документация четкая и подробная;
  • Изоляция версий, оптимизация небольших версий и функций, серьезные изменения требуют обновлений больших версий;
  • Согласовывать с пользовательским интерфейсом и требовать взаимодействия с пользовательским интерфейсом для участия;

В целом, после строительства преимущества перевешивают недостатки, но он требует особого обслуживания, так что определенная стоимость все же есть.

значимость:

Унифицируйте стили между разными/одними линейками продуктов, предоставьте пользователям лучший опыт, сократите время и трудозатраты при написании компонентов пользовательского интерфейса в рамках одной разработки и повысьте эффективность разработки.

3.4 Унификация стека технологий

Существует три основных интерфейсных фреймворка, а также наиболее совместимый jQuery, а также различные сторонние библиотеки и UI-фреймворки. Поэтому, если требования к проекту более сложные, легко сформировать солянку. Поэтому стек фронтенд технологий должен быть унифицирован, в частности рекомендуется реализовать следующие меры:

  • Один из трех основных вариантов выбора платформы, уровень команды обычно рекомендует Vue, более высокий уровень рекомендует React, а внешний проект выбирает React или ng;
  • jQuery рекомендуется для совместимости с IE8 или более ранними версиями;
  • Библиотека компонентов создается самостоятельно или единообразно выбирается фиксированная третья сторона;
  • Некоторые специальные сторонние библиотеки используют одну версию единообразно, например, когда вам нужно использовать карты, фиксированно используйте карты AutoNavi или Baidu или Tencent;
  • Инфраструктурное строительство должно избегать повторного строительства колес, все команды должны как можно больше делиться друг с другом, а за объединение этих вещей отвечает специальная фронтенд-платформа.Для особых нужд можно сделать новое строительство, но оно должно быть убедительным;

В целом, унификация стека технологий дает много преимуществ, которые могут эффективно повысить эффективность разработки и снизить стоимость серийного производства колес.

значимость:

Упростите набор сотрудников, упростите затраты на развитие членов команды и повысьте устойчивость проекта.

3.5, совместимость с браузером

Распространенными проблемами являются IE6, 7, 8 и некоторые странные проблемы с нишевыми браузерами (ПК и мобильные). Поэтому следует рассмотреть унифицированное решение, чтобы избежать дублирования ошибок. Общие решения:

  • Настройте postcss, чтобы добавить префикс совместимости к некоторым css;
  • Напишите загрузчик wepback для обработки некоторых особых сценариев;
  • Стандартизируйте командный код и используйте более стабильный метод написания (например, избегайте использования фиксированного макета на мобильных устройствах);
  • Для общих проблем и сложных проблем обобщайте решения и делитесь ими с командой;
  • Рекомендовать или направлять пользователей по использованию браузера с более высокой версией (например, Chrome);

значимость:

Избегайте ошибок, создаваемых средой браузера, и траты большого количества времени на устранение таких ошибок.

3.6 Контент-платформа_конструкция платформы

В целях повышения эффективности коммуникации внутри компании, обобщить опыт и причины конфиденциальности. Необходимо создать внутренний форум + блог. Его преимущества заключаются в следующем:

  • История компании может быть записана;
  • Обмен опытом среди студентов НИОКР;
  • Обобщите и перепечатайте несколько относительно качественных статей из внешнего мира, чтобы улучшить общее видение;
  • Увеличить обмен студентами внутри компании, что способствует командному и культурному строительству компании;
  • Можно обсудить некоторые технические вопросы, чтобы уменьшить потери связи, вызванные отсутствием консенсуса;

Как мы все знаем, крупные интернет-компании обычно имеют такой внутренний форум и блог. Это снижает коммуникационные расходы и коммуникации компании, а также повышает накопление технологий компании.

значимость:

Блоги способствуют накоплению технологий, а форумы расширяют возможности внутренней коммуникации компании.

3.7. Платформа управления правами_платформа

Когда в компании много людей, должна быть специальная платформа для управления и стандартизации разрешений пользователей и доступного контента [Исходный водяной знак — Автор: Zero Zero Water (Ванг Донг), WeChat: qq20004604]. Платформа управления правами platform_platform имеет несколько особенностей:

  • Естественно, он должен быть тесно связан с серверной частью, поэтому для решения проблем с разрешениями требуется специальный модуль управления (отвечающий за разработку и обработку на стороне сервера, или внешний интерфейс вмешивается через средний уровень, такой как уровень Node);
  • Автоматизированное управление процессом, т. е. создание пользователя, подача заявления, утверждение и автоматическое удаление заявления об уходе, должно поддерживаться системой и напоминать соответствующим людям, а также иметь возможность при необходимости вызывать сигнал тревоги;
  • Разрешения должны быть привязаны ко времени, чтобы сократить количество постоянных разрешений;
  • Процесс согласования должен быть хорошо виден, а процесс на каждом этапе должен быть конкретным и понятным;
  • Он должен быть тесно интегрирован с процессами компании и улучшать возможность модификации, чтобы облегчить дальнейшую оптимизацию процессов компании;

значимость:

Сделать внутренние процессы компании формализованными и информатизированными.

3.8 Дизайн системы входа (единый вход)

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

  • улучшить пользовательский опыт;
  • Открытые пользовательские данные между разными бизнес-системами;
  • Обеспечить единое управление пользователями;
  • способствует дренажу;
  • Снизить стоимость разработки системы (не нужно разрабатывать систему входа и контроля пользовательского состояния для каждого бизнеса);

В целом, для средних и крупных веб-приложений SSO может принести множество преимуществ и несколько недостатков.

значимость:

Улучшается пользовательский опыт, устраняется разрыв между различными услугами, а стоимость разработки и управление пользователями снижаются.

3.9. CDN

Скорость загрузки интерфейсных ресурсов — один из важных показателей для измерения пользовательского опыта. На самом деле, в силу различных факторов, пользователи будут иметь множество ограничений при загрузке ресурсов страницы. Поэтому переходить на CDN очень осмысленно, а преимущества следующие:

  • Пользователи приходят из разных регионов.Присоединение к CDN позволяет пользователям получать доступ к CDN-серверам, которые находятся ближе к ним при доступе к ресурсам, уменьшая задержки доступа;
  • Снизить затраты на использование пропускной способности сервера;
  • Поддержка видео, статических ресурсов, больших файлов, небольших файлов, прямых трансляций и других бизнес-сценариев;
  • Устранить проблему снижения скорости сети из-за кросс-операторов;
  • Уменьшить влияние на сайт, вызванное DDOS-атаками;

CDN — относительно зрелая технология, все основные облачные платформы предоставляют услуги CDN, и цена не дорогая, поэтому CDN очень рентабельна.

значимость:

Увеличьте скорость доступа пользователей, уменьшите задержку в сети, оптимизируйте пропускную способность, снизьте нагрузку на сервер и повысьте устойчивость к атакам.

3.10, балансировка нагрузки

В настоящее время для балансировки нагрузки обычно используется Nginx, а в прошлом также использовался Apache. Когда дело доходит до крупных проектов, балансировка и распределение нагрузки почти обязательны. Балансировка нагрузки имеет следующие преимущества:

  • Уменьшите нагрузку на один сервер и увеличьте пропускную способность службы;
  • Удобно бороться с пиковым трафиком, удобно расширять (например, при проведении определенных мероприятий);
  • Повышение доступности, масштабируемости и стабильности бизнеса;

Балансировка нагрузки уже является довольно распространенной технологией, преимущества которой легко понять.

значимость:

Повысьте доступность, масштабируемость и стабильность бизнеса и обеспечьте доступ большего числа пользователей.

3.11 Несколько портов совместно используют набор интерфейсов

В настоящее время распространенным сценарием является бизнес, и одновременно существуют страницы ПК и страницы H5.Поскольку бизнес один и тот же, следует избегать того, чтобы один и тот же бизнес имел несколько наборов интерфейсов, применимых к ПК и терминалам H5. соответственно. [Оригинальный водяной знак-автор: Zero Zero Water (Wang Dong), QQ: 20004604] Таким образом, решение выглядит следующим образом:

  • Интерфейс, предоставляемый серверной частью, должен включать в себя как данные ПК, так и данные H5 (то есть избыточные данные только для одного);
  • Интерфейс должен быть стабильным, то есть при изменении бизнеса он должен стараться принимать форму дополнительных данных;
  • Разрабатывайте единый уникальный интерфейс только тогда, когда одному концу нужен специальный бизнес-процесс;

Многотерминальный общий интерфейс — важное решение для снижения нагрузки на разработку и повышения удобства обслуживания.

значимость:

Сократите рабочую нагрузку на разработку и улучшите ремонтопригодность.

4. Резюме

Из-за различных специфических условий каждой компании и специфики проекта вышеуказанный дизайн не может быть принудительно включен, и сначала должны быть добавлены более важные функции и дизайн в зависимости от размера компании, хода проекта и количество личного состава. И необходимо учитывать ремонтопригодность и потребности в развитии долгосрочных проектов, а также заранее проводить исследования и разработки и проектирование некоторой инфраструктуры.

Из-за ограниченного места невозможно охватить все, я упомяну только часть содержания, которое я считаю более важным рассмотреть на архитектурном уровне, вы можете добавить. Если у вас есть собственное мнение, пожалуйста, ответьте или добавьте мой WeChat qq20004604 (псевдоним: Zero Zero Water) для обсуждения.

Наконец, если в Сиане есть компании, которые не работают сверхурочно и нуждаются во внешних архитекторах, пожалуйста, свяжитесь со мной.

Категории