Как веб-инженер, я больше всего уделяю внимание производительности и архитектуре. К счастью, на этот раз я принял участие в конференции sd2.0 и смог активно общаться со своими коллегами. В этих двух аспектах я не осмелюсь оставить что-то из своего. Мой собственный опыт архитектурного проектирования. Эта статья, которой поделились друзья, представляет собой опыт участия в этой конференции и общения с другими.
Несколько мыслей об архитектурном проектировании:
1. Никогда не переусердствуйте с дизайном: никогда не переусердствуйте с дизайном
Эту тему часто упоминают, но если вы задумаетесь о том, сколько функций в вашей архитектуре вообще не используются или окончательно заброшены, вы поймете ее важность. Когда вы впервые занимаетесь проектированием архитектуры, вы часто понимаете ее важность. Мы склонны разрабатывать крупномасштабные проекты. Что касается архитектуры Huayi, мы надеемся разработать инкрементную архитектуру, которая будет чрезвычайно масштабируемой и сможет адаптироваться ко всем потребностям. Область веб-разработки - это очень динамичный процесс. Нам трудно предсказать. изменения на следующей неделе, и нам нужно реагировать на изменения как можно быстрее. Самый эффективный ответ.
Инженеры eBay заявили, что их архитектурный проект никогда не был в состоянии удовлетворить рост системы, поэтому их систему постоянно переделывают и переделывают. Обратите внимание, что у архитекторов eBay нет никаких проблем. Архитектура, которую они проектируют, всегда опирается на узкие места старой версии, надеясь, что новая архитектура принесет прорыв. Однако прорывы, принесенные новой архитектурой, всегда будут достигнуты. за короткий период времени, ошеломленные новыми требованиями, им пришлось использовать новую архитектуру.
Веб-разработка — очень гибкий процесс. Изменения происходят в любое время. Потребности пользователей постоянно меняются. По сравнению с разработкой программного обеспечения нереалистично надеяться на использование одной архитектуры для планирования всех будущих проектов.
2. Жизненный цикл веб-архитектуры: жизненный цикл веб-архитектуры.
Поскольку нам необходимо исключить чрезмерное проектирование и обеспечить определенную степень предусмотрительности, как нам найти баланс? Я надеюсь, что следующий жизненный цикл веб-архитектуры поможет вам.
Разработанная архитектура должна выдерживать рост в 1–10 раз за счет простого увеличения мощности оборудования. В течение периода роста в 5–10 раз начните проектировать следующую версию архитектуры, чтобы она могла выдержать следующие 10 раз. двойной рост
Причина, по которой Google может доминировать, заключается не только в том, насколько развиты технологии поиска и сортировки. На самом деле, включая Baidu и Yahoo, используемые технологии теперь схожи. Однако Google может добиться этого, добавив десятки тысяч серверов. в месяц действительно сложно воспроизвести достаточную мощность системы.
3. Кэш: Кэш
Пространство заменяется временем. Кэш всегда является главным приоритетом при проектировании компьютера. От процессора до ввода-вывода, проектирование веб-архитектуры важно, а проектирование кэша имеет важное значение. jbosscache Основатель Taobao сказал следующее: «На самом деле конструкция веб-кеша и кеша корпоративного уровня сильно различается. Кэш корпоративного уровня ориентирован на логику, в то время как веб-кеш прост и быстр. .
В чем проблема, связанная с кэшированием? Это увеличение сложности программы. Поскольку данные распределяются по нескольким процессам, синхронизация становится проблематичной. С добавлением кластеров сложность еще больше возрастет. Стратегии часто необходимо привязывать к бизнесу?
Лаоцянь разработал кэш связанных списков для сообщений, разработанных Sohu, который может не только удовлетворить потребности в гибкой вставке, но и обеспечить быстрое чтение. Некоторые другие крупные сообщества часто используют аналогичные структуры для оптимизации списков сообщений. Memcache также часто используется. инструмент
Ссылка: видео Цянь Хунву об архитектурном проектировании http://211.100.26.82/CSDN_Live/140/qhw.flv
Общая стратегия Cache — хранить данные в памяти, а не на более трудоемком диске. С этой точки зрения механизм кучи (метод хранения), предоставляемый MySQL, также является методом, о котором стоит подумать. Этот метод хранения может хранить данные в памяти и сохранять мощные возможности запросов SQL. Убивает ли он двух зайцев одним выстрелом?
Мы говорили здесь только о кэшировании чтения. На самом деле существует еще и кэш записи, который редко используется в контентно-ориентированных сообществах, поскольку основная проблема, которую приходится решать таким сообществам, — это проблема чтения, но когда вычислительная мощность ниже. чем емкость запроса. Когда или когда один запрос кэшируется для формирования блока, а затем обрабатывается пакетами, появляется кэширование записи. Мы можем легко найти такой кэш в высокоинтерактивном проекте сообщества.
В-четвертых, основной модуль должен быть разработан самостоятельно: сделайте свой основной модуль своими руками.
Мы глубоко осознаем это, Цянь Хунву и Юньфэн также отметили, что мы часто склонны использовать некоторые модули с открытым исходным кодом. Если основные модули не задействованы, то это действительно возможно, тогда мы должны быть осторожны, потому что, когда они есть. количество посещений достигает определенного уровня, у этих модулей часто возникают те или иные проблемы. Конечно, мы можем списать проблему на незнание модулей с открытым исходным кодом, но неважно, когда возникает проблема с ядром. очень страшно не понять полностью его код.
5. Разумное хранение данных: разумное хранение данных.
Должны ли мы использовать базу данных? Не обязательно. Лэй Мин говорит нам, что для поиска не обязательно требуется база данных. Так почему бы просто не использовать файлы? заменить его?
Прежде всего, нужно признать, что база данных также работает с файлами. Нам нужна база данных, главным образом, для использования следующих функций: одна — для хранения данных, а другая — для извлечения данных. В реляционных базах данных мы действительно очень заботимся о сложных возможностях поиска в базе данных. Просто посмотрите на tsql для статистики (. Не нужно внимательно читать, достаточно взглянуть)
выберите c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(выберите count(Id) из обзора, где Reviewid=a.Id) в качестве countNum из Creativity как a,User_info как b,класс как c,class2 как d где a.user_id=b.id и a.Creativity_Class=c.Id и a.Creativity_Class_2=d.Id
выберите a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) как countNum из Creativity как a,User_info как b ,класс как c, класс2 как d, обзор как e, где a.user_id=b.id и a.Creativity_Class=c.Id и a.Creativity_Class_2=d.Id и a.Id=e.Reviewid группируется по a.Id … ………………………………….