Комментарии 16
да.. и еще очень интересна тема организации back-end (админки)
зачастую это более сложный и важный функционал чем front-end
туда входит конфигурация и настройка различных cron-процессов (scheduling)
возможно есть какие-то налаженные конфигурации
например я работал с подобной системой у amazon, но мог ознакомиться только с некоторыми частями
системы.
что интересно не смотря на то, что куча конечных компонентов даже у них написана
вроде и хрен знает как (много оутсорса и у индусов и у других) -
в целом система легко расширяется и ее сложность от этого не увеличивается.
зачастую это более сложный и важный функционал чем front-end
туда входит конфигурация и настройка различных cron-процессов (scheduling)
возможно есть какие-то налаженные конфигурации
например я работал с подобной системой у amazon, но мог ознакомиться только с некоторыми частями
системы.
что интересно не смотря на то, что куча конечных компонентов даже у них написана
вроде и хрен знает как (много оутсорса и у индусов и у других) -
в целом система легко расширяется и ее сложность от этого не увеличивается.
Роберт К. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс
Быстрая разработка программ. Принципы, примеры, практика
http://www.ozon.ru/context/detail/id/157…
Быстрая разработка программ. Принципы, примеры, практика
http://www.ozon.ru/context/detail/id/157…
http://oz.by/books/more101783.html вот хорошая книга
ага .. это известная книга.. вроде была у меня или на работе у кого-то
но она больше как раз фундаментального характера
но она больше как раз фундаментального характера
http://ooad.asf.ru тут есть справочник шаблонов из книги
Чисто прикладная.
Вот бы еще электронное издание кто-небудь вспомнил.)
Возможно, помимо классических книжек, Вам стоит почитать на какой архитектуре работают большие и сложные системы, например: Amazon Architecture. Про Google почитать не предлагаю, ибо у них слишком уж специфические задачи и среда, а вот Amazon - типичный большой и сложный веб-проект.
Я лично у себя в проектах много лет использую аналогичный подход. И, хотя мои масштабы далеки от амазона, такая архитектура очень сильно упрощает жизнь.
В Вашем случае громадный плюс - нет необходимости всё переписывать с нуля, можно новую архитектуру начинать внедрять постепенно, для отдельных частей системы, по мере их добавления или изменения.
Суть архитектуры в том, что в большой системе выделяются очень небольшие, иногда даже элементарные элементы функциональности, для доступа к которым разрабатывается специальный интерфейс (тоже, зачастую, довольно тривиальный), и эти элемены выносятся в отдельные сервисы.
Обычно интерфейс позволяет использовать разные транспорты, напр. unix-сокеты или tcp, что облегчает масштабирование системы (разные сервисы можно разместить на разных серверах).
Так же наличие чёткого и стабильного интерфейса позволяет делать разные фокусы типа подмены реального сервиса на проксик, который реализует функциональность подменённого сервиса через другие сервисы - при этом клиенты этого сервиса об этом даже не знают.
Ещё один немаловажный факт: пока часть системы скрыта за интерфейсом, и работает корректно - вас не будут сильно интересовать качество кода этой системы, язык программирования на котором она написана и ОС под которой она крутится.
Один из важнейших принципов - эти сервисы должны быть связаны друг с другом только через интерфейсы. Если два сервиса будут лазить в одну и ту же базу данных, знать формат её таблиц, etc. - фокус не сработает, и вы получите ту же самую большую и сложную систему, дополнительно переусложнённую этими внутренними интерфейсами.
При использовании такой архитектуры сложность не исчезает сама собой "magically", она переходит с уровня кода и логики системы на уровень проектирования: может оказаться очень непросто выделять достаточно независимые сервисы внутри текущей большой системы, и очень непросто разрабатывать достаточно простые и стабильные интерфейсы для доступа к этим сервисам.
Я лично у себя в проектах много лет использую аналогичный подход. И, хотя мои масштабы далеки от амазона, такая архитектура очень сильно упрощает жизнь.
В Вашем случае громадный плюс - нет необходимости всё переписывать с нуля, можно новую архитектуру начинать внедрять постепенно, для отдельных частей системы, по мере их добавления или изменения.
Суть архитектуры в том, что в большой системе выделяются очень небольшие, иногда даже элементарные элементы функциональности, для доступа к которым разрабатывается специальный интерфейс (тоже, зачастую, довольно тривиальный), и эти элемены выносятся в отдельные сервисы.
Обычно интерфейс позволяет использовать разные транспорты, напр. unix-сокеты или tcp, что облегчает масштабирование системы (разные сервисы можно разместить на разных серверах).
Так же наличие чёткого и стабильного интерфейса позволяет делать разные фокусы типа подмены реального сервиса на проксик, который реализует функциональность подменённого сервиса через другие сервисы - при этом клиенты этого сервиса об этом даже не знают.
Ещё один немаловажный факт: пока часть системы скрыта за интерфейсом, и работает корректно - вас не будут сильно интересовать качество кода этой системы, язык программирования на котором она написана и ОС под которой она крутится.
Один из важнейших принципов - эти сервисы должны быть связаны друг с другом только через интерфейсы. Если два сервиса будут лазить в одну и ту же базу данных, знать формат её таблиц, etc. - фокус не сработает, и вы получите ту же самую большую и сложную систему, дополнительно переусложнённую этими внутренними интерфейсами.
При использовании такой архитектуры сложность не исчезает сама собой "magically", она переходит с уровня кода и логики системы на уровень проектирования: может оказаться очень непросто выделять достаточно независимые сервисы внутри текущей большой системы, и очень непросто разрабатывать достаточно простые и стабильные интерфейсы для доступа к этим сервисам.
13 октября на семинаре jug.ru "Designing High-Performance Distributed Systems for Event Processing" был полезный доклад Романа Елизарова, даже осталась презентация: http://www.jug.ru/servlets/images/meetin…
Там же рекомендуются две мегаполезные книжки:
* Design Patterns book by Erich Gamma
* Introduction to Algorithms by Cormen
Там же рекомендуются две мегаполезные книжки:
* Design Patterns book by Erich Gamma
* Introduction to Algorithms by Cormen
ЛУЧШЕ НЕ ИЗОБРЕТАЙТЕ ВЛЕСИПЕД. ВОТ ВАМ ССЫЛОЧКА: http://www.slideshare.net/vishnu/livejournals-backend-a-history-of-scaling/
комментить перестали) видимо, понравилась ссылочка)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Джошуа Кериевски
"Рефакторинг с использованием шаблонов (паттернов проектирования)"
Переплёт: мягкий
Объём: 400 стр.
ISBN: 5845910870
Формат: 70x100/16
Серия: Signature Series
Дата выхода: 2006 г.
Издательство: Вильямс
URL: http://www.williamspublishing.com/Books/5-8459-1087-0.html
"Рефакторинг с использованием шаблонов (паттернов проектирования)"
Переплёт: мягкий
Объём: 400 стр.
ISBN: 5845910870
Формат: 70x100/16
Серия: Signature Series
Дата выхода: 2006 г.
Издательство: Вильямс
URL: http://www.williamspublishing.com/Books/5-8459-1087-0.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Что почитать по проектированию архитектуры?