-
Последняя статья этой серии написана для обычных программистов. Если вам не интересно, вы можете просто прочитать последние несколько абзацев этой статьи.
Прежде чем приступить к проектированию структуры кода, давайте рассмотрим то, что мы подготовили ранее: у нас есть WEB-сервер с балансировкой нагрузки, главный-подчиненный сервер БД и, возможно, шардинг, кэш и масштабируемое хранилище. Все аспекты организации кода тесно связаны с этими приготовлениями. Я перечислю их один за другим, два за тремя, и каждый из них будет начинаться с классического предложения «упомянутого выше» для удобства сравнения.
Не спешите читать классические схемы предложений, у меня в голове подскочило и я вставлю абзац. В реальной разработке мы всегда идем на компромисс между производительностью и элегантностью кода. Для современных компьютеров и языковых интерпретаторов вопрос о том, сколько слоев вызовов объектов и сколько слоев вызовов объектов и следует ли объявлять переменные как Map или HashMap, является последним, что следует учитывать. Всегда рассматривайте самую медленную часть системы и решайте ее. из самой медленной части. Например, посмотрите, делает ли используемый вами ORM много ненужных вещей и есть ли повторяющиеся вызовы данных. Мы занимаемся разработкой веб-приложений, а не базового API-интерфейса. Легко читаемый и понятный код — очень важный аспект для обеспечения качества. Для чего предназначена ваша программа? Есть разные методы... Забудьте об этом. будет обсуждаться отдельно. Эта статья слишком далека от темы. Если вы хотите пообщаться, вы можете подписаться на мой Weibo : http://t.sina.com.cn/liuzhiyi . Продолжим.
Как упоминалось ранее, веб-сервер должен быть сбалансирован по нагрузке, а сервер изображений должен быть отделен. Что касается этого момента, когда код обрабатывает статус клиента, не помещайте статус на одну машину. Например, не используйте файловый сеанс. Что ж, здравый смысл. Если возможно, лучше всего с самого начала разработать единый интерфейс для одноточечной аутентификации пользователей, включая определение статуса между доменами, определение статуса на статических страницах и определение параметров перехода и возврата при входе в систему. . Обеспечьте хороший интерфейс на нижнем уровне и примените его. Уровень используется напрямую (см. службу поддержки пользователей GAE). Дизайн входа в систему должен учитывать характеристики мобильных устройств. Например, компьютеры могут использовать окна с плавающими слоями, но собственный браузер NOKIA или UCWEB не могут обрабатывать эту форму выражения. Программа должна иметь возможность обрабатывать как Ajax-запросы, так и напрямую через URL-адрес. . просить. Сервер изображений отделен, и файлы ресурсов лучше всего размещать на сервере изображений, то есть WEB-сервер обслуживает только динамические программы. Хотя его немного сложно разрабатывать и тестировать (поскольку для доступа к нему требуется абсолютный URI), в будущем будет намного проще оптимизировать внешний интерфейс страницы, а также оптимизировать ввод-вывод вашего веб-сервера. быть намного проще. Когда программа ссылается на файлы ресурсов, должен быть единый метод обработки. Многие вещи могут быть автоматически выполнены в рамках этого метода, например объединение CSS/js в файл или автоматическое добавление QUERYSTRING после сгенерированного URI. используется служба кэширования, генерация QUERYSTRING – это самый простой способ обновления кэша сервера и клиента.
Как упоминалось ранее, база данных будет реплицироваться, может иметь несколько главных и несколько подчиненных устройств и может быть сегментирована. В процессе обработки данных в нашей программе лучше всего абстрагировать их и вынести на отдельный слой. В качестве примера возьмем популярную модель MVC, которая заключается в размещении уровня данных ниже уровня M. Этот уровень данных не является общеизвестным JDBC/PDO/ActiveRecord и т. д., а является вашим собственным уровнем данных доступа, который предоставляет методы только внешний мир. Скрыть сведения о доступе к данным. Не бойтесь некрасивого написания внутри этого уровня данных, но он должен обеспечивать все функции хранения данных. Не встречайте слов, касающихся базы данных на каком-либо другом уровне. Причина этого в том, что в случае одной реляционной базы данных вы можете SELECT...JOIN... или непосредственно INSERT...INTO..., но вы можете хранить некоторые таблицы в базе данных "ключ-значение" или После этого нужно будет изменить все исходные утверждения и методы. Если они будут слишком разбросаны, то при трансплантации будет затрачено много усилий или получится очень большая Модель. С точки зрения проектирования на уровне данных старайтесь избегать запросов JOIN. Мы можем обеспечить большую избыточность и кэширование. Для каждого типа данных требуется только один запрос, а затем объединить его в вашей программе. Для более сложных комбинаций данных, когда требования к реальному времени не высоки, можно использовать асинхронную обработку, и пользователи получают обработанные результаты только при доступе. При работе с первичными ключами избегайте использования автоинкрементных идентификаторов и используйте в качестве первичных ключей уникальные значения, сгенерированные по определенным правилам. Этот первичный ключ представляет собой простейшую стратегию распределения по сегментированию. Даже если вы используете идентификатор с автоматическим увеличением, лучше всего использовать генератор идентификаторов с автоматическим увеличением. В противном случае, если подчиненная база данных будет случайно записана, первичный ключ легко приведет к конфликту.
Как упоминалось ранее, есть несколько кешей, блокирующих переднюю часть нашей базы данных. Не рассматривайте кеш запросов MySQL как кеш. Если приложение немного сложное, QUERY CACHE станет обузой. Кэширование тесно интегрировано с базой данных и бизнесом. Поскольку оно тесно связано с бизнесом, не существует универсального подхода. Но у нас все еще есть некоторые правила, которым мы должны следовать. Правило 1: Чем ближе к интерфейсу, тем выше степень детализации кэша. Например, вся страница кэшируется во внешнем интерфейсе Интернета, часть страницы кэшируется на следующем уровне, а отдельная запись в области кэшируется на следующем уровне. Потому что чем ближе мы к бэкенду, тем гибче наша работоспособность, а фронтенд-код, который меняется больше всего, легче писать. На практике, поскольку требования к продукту меняются очень быстро, а цикл итерации становится все короче и короче, иногда сложно четко разграничить Контроллер и Модель. Частичное кэширование неизбежно на уровне Контроллера, но в этом случае необходимо обеспечить его. случае, Контроллер. Используемый кэш не должен влиять на другие стороны, запрашивающие данные, то есть необходимо гарантировать, что эти кэшированные данные используются только этим Контроллером. Правило 2: Программа не может допускать ошибок без кэширования. Если не учитывать лавинный эффект, вызванный аннулированием кеша, ваша программа должна иметь кеш и быть такой же, как и без кеша. Она не может быть такой, как Sina Weibo. Если кеш выйдет из строя, вентилятор Weibo станет пустым, и все приложение станет пустым. испортился. Когда кэширование имеет важное значение, лучше предоставить пользователю сообщение об ошибке, чем сообщение, вводящее в заблуждение. Правило 3. Обновления кэша должны быть атомарными или потокобезопасными. Особенно при использовании пассивного кэширования очень вероятно, что один и тот же кэш будет обновлен при доступе к нему двух пользователей. Обычно это не является большой проблемой, и кэш можно перестроить. после истечения срока действия. Это может быть одной из причин цепной реакции. Правило 4. Кэширование также имеет свою цену. Не только стоимость технологии, но и стоимость рабочего времени. Если функция использует кэширование и не использует его, то разница в обозримом объеме доступа невелика, но использование кэширования увеличит сложность, то в этом нет необходимости. Мы можем добавить метку TODO и добавить обработку кэширования в следующей итерации.
Как упоминалось ранее, файловое хранилище независимо, поэтому все файловые операции представляют собой удаленные вызовы. Вы можете предоставить очень простой интерфейс RESTful на файловом сервере или предоставить сервис xmlrpc или json. Все файлы, созданные и обработанные веб-сервером, передаются файловому серверу через интерфейс для обработки. обеспечить любое файловое хранилище. По этой причине вы обнаружите, что загрузка изображений и сохранение статей на многих крупных веб-сайтах выполняется в два этапа.
Вышеупомянутое «упомянутое ранее» на самом деле было сказано бесчисленным количеством людей. Я просто повторил их своими словами, основываясь на предыдущих статьях. Суть настоящего анализа очень проста — помимо хорошей функциональной логики нам также нужен Дизайн. отдельные интерфейсы для вызовов внешних ресурсов, таких как хранилище базы данных, кэширование, очереди и файловые службы. Вы можете представить, что ваша программа работает на Amazon EC2 и использует все ее веб-сервисы. Ваша база данных — это его SimpleDB. Ваша очередь — это его SQS, а ваша — ваша. хранилище - его S3, разница лишь в том, что у Амазона интерфейс - удаленный вызов, а у тебя - внутренний вызов.
Взаимодействие со службой поддержки означает, что замена MySQL на PostgreSQL не требует внесения изменений в программу бизнес-обработки, а команде миграции даже не нужно слишком много общаться с командой развития бизнеса, это означает, что команда развития бизнеса программирует интерфейс; чем программирование базы данных; это означает, что производительность не снизится из-за ошибки бизнес-разработчика.
Если вас не интересует программная грамотность, просто посмотрите здесь——
После завершения проектирования продукта и создания структуры программы на этом этапе могут возникнуть конфликты. От дизайнеров продуктов постоянно поступают жалобы на то, что их идеи не приносят желаемых результатов, а программисты жалуются, что проекты продуктов нереалистичны. Жалобы такого рода в основном связаны с тем, что персонал, производящий продукцию, не разбирается в технологиях, а технический персонал не разбирается в продуктах. В широком смысле продукты включают в себя рыночные стратегии, методы маркетинга и функциональный дизайн. При спорах о продуктах и технологиях основное внимание часто уделяется функции, но в действительности основное внимание уделяется затратам на реализацию этой функции и выгодам, которые дает эта функция. может принести. Можно ли это преобразовать и можно ли это принять во внимание. Если возможно, разрешите спор. Если нет, подбросьте монетку и испытайте удачу. Есть много примеров срыва показателей из-за улучшения функции или задержек в бою из-за задержек проекта. Лица, принимающие радикальные решения, сосредотачиваются на выгодах, лица, принимающие консервативные решения, сосредотачиваются на потерях, а лица, принимающие умные решения, размышляют, действительно ли проблема настолько серьезна.
Никто не может предсказать, что произойдет в будущем, иначе половина открытия бизнеса зависит от удачи. Но всегда есть вещи, о которых можно сказать точно, и вам приходится полагаться на данные, которые говорят сами за себя.
Не на 100%, а на 99,9% веб-сайтов установлен код статистики доступа, даже мой http://zhiyi.us не является исключением, а сеть Xinwen всегда говорит о принятии научных решений и научных разработках. С помощью статистики можно определить множество вещей. Например, вы можете проанализировать, какие каналы имеют самую низкую стоимость привлечения на душу населения на основе коэффициента конверсии источника и целевой аудитории, угадать причины показателей отказов пользователей на основе доступа к исходному контенту и определить, является ли позиция ссылки разумной на основе кликов пользователя. поведение. Объединяйте данные разными способами, чтобы найти внутренние связи, проанализировать внутренние и внешние факторы, сформулировать соответствующие стратегии и сократить количество необдуманных решений. Опора на данные для поддержки операций — очень профессиональное дело. Хотя я не разбираюсь в глубоких математических моделях и сложных вычислениях по формулам, постепенно я понял, что B возникает из-за A, а C — из-за A и B. Это все еще относительно просто. .
Автор статьи: Лю Чжии (при перепечатке просьба указывать ссылку на источник и автора)
Источник статьи: http://zhiyi.us/