Мозг и когнитивные функции

Показаны сообщения с ярлыком architecture. Показать все сообщения
Показаны сообщения с ярлыком architecture. Показать все сообщения

среда, 16 июня 2010 г.

Мысли вслух


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

Причем, не опосредовано, как менеджер или исполнитель, а именно как системный архитектор/лидер группы/технический директор/играющий тренер. Не скажу, что это было что-то новое, это приходилось делать много и много раз до того. НО! тот раз был особый. И дело даже не в сложности задачи и не в фантастических и противоречивых бизнес требованиях, нет. Дело в обстановке, в которой приходилось это выполнять.

Вообще, системная архитектура - это всегда компромисс. Существует множество способов реализации и множество архитектурных решений поставленных бизнесом задач. Каждый способ имеет свои достоинства и недостатки. Сложность работы архитектора заключается в том, что бы правильно расставить весовые коэффициенты этим достоинствам и недостаткам. Иногда, мало значительный (для других) фактор архитектор оценивает как критический и делает выбор в пользу не популярного "в массах" решения. Однако, мало сделать выбор, необходимо еще за него и отвечать. Здесь степень ответственности такая же как у бизнеса. А допущенная архитектурная ошибка, и не правильно сделанный выбор (не верно расставлены веса) обязательно проявится потом. В виде невозможности расширения системы (из-за архитектурных ограничений) или выльется в большие затраты при переделке. Причем, чем раньше такие ошибки проявятся, тем они более дёшевы в исправлении. Отчасти, выявлению таких ошибок способствуют тестеры. Но что бы выявить такие ошибки тестеры должны быть ооочень профессиональными и иметь за плечами несколько таких самостоятельно построенных систем. Иначе, вероятность обнаружения архитектурных ошибок не высока, а количество "возможных проблем" поглотит даже здравый смысл (+ истерия).

Дак, что же делать, если такая ошибка, все же, была допущена? Именно случилась, а не искусственно создана. Что делать, если такая архитектурная ошибка была допущена и проявилась? Мое личное мнение - гнать такого "архитектора". В больших системах, стоимость допущенной ошибки соизмерима с ошибкой сапера на минном поле. Хотя, конечную стоимость ошибки определяет бизнес, но архитектор не имеет права на ошибку (так же как не имеет такого права директор). Однако, я встречал человека, который именовал себя по всякому и старался быть в каждой "дырке пробкой". Он, в частности, практиковал 2-ва принципа (думаю и сейчас практикует, такое не лечится): "лучше перебдеть, чем недобдеть" и "не бывает единственно правильного решения, и вы правы и вы правы". Для меня он стал примером абсолютной некомпетентности при колоссальной работоспособности. Никогда, а тем более в архитектуре сложных систем, не занимайте позицию "ни вашим ни нашим" или "и тем и другим". Правильная архитектура - это смесь пограничных решений, за которые и отвечает архитектор! Кстати, для того человека, стоимость его ошибки так и не была им воспринята адекватно (его просто выгнали из компании которую он же и основал).

К чему я расписываю такие банальности? Нет в этом ничего нового и необычного - факт. Необычной, для меня, была обстановка в которой приходилось заниматься своей профессиональной деятельностью. Дизайнить большую систему когда тебя подставляют, БЕЗ требований и в окружении блатных бездарей (пытающихся навязать вам который из протоколов или технологий следует использовать) - это сущая ерунда, если у вас есть вербальный канал получения информации от заказчика (бизнеса). Когда вы можете напрямую задать вопрос и получить на него ответ. А когда в голове уже сложилась мозаика того "что же хочет бизнес", остается рутина. Остается просто расписать это (если надо в сценариях, если надо в UML, если надо в коде). Но, когда ... лишают вас единственного (хоть и вербального) канала получения информации и "мозаика не сложена" - вы будете вынуждены изобретать абсолютно круглого коня в вакууме.

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

P.S.
Любые совпадения с реальными людьми, компаниями и проектами случайны и не имеют ничего общего с реальностью.

суббота, 16 августа 2008 г.

myPicturetown - "горизонтальное" расширение

Как говорят некоторые коллеги: "тихо и незаметно"...
Дак вот, тихо и незаметно, проект www.mypicturetown.com перешел от простого кластера к полноценной "grid" архитектуре. Если ранее - это был кластер из нескольких серверов поверх условно "центральной" базы данных, то теперь - это большая сеть состоящая из множества, так называемых, "AB" пар (primary-secondary).

Каждая "AB" пара в гриде представляет собой клатер из 2-х хостов (primary - secondary). Причем, кластеризация самопальная. Каждый AB хост имеет как файловое хранилище, так и базу данных (PostgreSQL). Разделение между ними, скорее, master-master нежели master-slave. Дублирование в файловом хранилище реализовано на уровне бизнес логики, а вот дублирование в базу выполняется посредством собственной имплементации JDBC драйвера (на основе HA-JDBC). Конечно же, каждый пользователь (его данные и файлы) "привязан" (размещается) на конкретной AB паре. Ничего удивительного :) Тем более, что это довольно распространенная практика. Конечно встает вопрос о неком "центральном" реестре пользователей. Где хранится информация о том что данный пользователь (с таким то UID) размещается на такой то AB паре.

Однажды, Иван Блинков (кстати, рекомендую посетить его блог) задавал мне вопросы связанные с деталями реализации наших AB кластеров и центрального реестра пользователей (у нас в системе его называют CDC). Теперь, когда мы уже зарелизилист, могу рассказать некоторые "секреты" :)

Итак, про JDBC репликацию я уже рассказал. Конечно же, процедуры восстановления базы данных после сбоя выписаны "руками" поверх все того же HA-JDBC.

Центральный реестр пользователей (CDC) - реализован как кластер из одного или более хостов. В качестве хранилища, использующий Berkeley DB (Java Edition) от ORACLE. Я, как автор CDC, могу "похвастать" еще и тем - что механизм распределенных транзакций сделан собственный. Кроме того, сервис полностью удовлетворяет требованиям "zero administration" и умеет "самовосстанавливаться" и "самореплицироваться".

Для построения кластеров мы активно используем JGroups.

Вот пожалуй и все "секреты", остальное - дело техники :)

Желаю удачи, коллеги!

понедельник, 9 июня 2008 г.

Хороший фотохостинг

Что необходимо, что бы создать хороший сервис? Будь то фотохостинг, блогосферу, соц.сеть, ...
Конечно архитектура, скажут многие. Такая, что бы с горизонтальной масштабируемостью, с 24x7x365, резервированием, кластеризацией и прочей хренью... Нет, скажут другие, нужно что бы были всякие бантики, мулечки, удобности, полезности, и прочий функционал (причем лучше чем у конкурентов).

Реальная система же не может обходится ни без первой ни без второй составляющей. Проблема лишь в том, что первый пункт уже не представляет из себя какой-либо сложности. При таком количестве открытых публикаций про архитектуру больших систем, уровня Flickr или Google, наверное уже только самый ленивый студент не сможет построить нечто, обладающее всеми качествами первой составляющей. Эта самая "инженерная" составляющая все меньше волнует реальных бизнесов, как раз по причине ее доступности (что конечно же 100% правильно).

В качестве "закладки", я бы хотел оставить ссылку на пост Ивана Матвеева, руководителя сервиса Яндекс.Фотки и его обсуждение. Примечательно в нем то, что не чистым гением в одно литцо и в полумраке офиса высиживается, вынашивается и рожается новая "так нужная всем" фича, а в режиме открытого обсуждения. Т.е. ребята молодцы! Они не только не боятся услышать критику, но и таким образом получают чужие идеи в "чистом виде".

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

пятница, 30 мая 2008 г.

Обновление myPicturetown

Доброго времени суток, коллеги!

Как говориться "тихо и незаметно" вышел очередной релиз фотохостинга www.mypicturetown.com. Он значительно отличается от предыдущей версии прежде всего тем, что это интеграция 3-х различных систем. Расположенных на большом удалении друг от друга территориально и состоящих из различных платформ. Объединила все back-end'ы идеалогия SSO (single sign-on). Вендоров SSO, предоставляющих свои решения под различные платформы, достаточно много, однако компания Nikon (как заказчик может диктовать свои требования) остановилась на RSA решении. Теперь, 3-ри части системы, подкрепленные соответствующими RPC взаимодействиями друг с другом, могут работать как единое целое. Одна система отвечает за хранение пользовательской информации и аккаунтов [I], другая за биллинг и обслуживание кредитных карт на аккаунтах кастомеров [II], и третья (это мы) отвечает за хранение картинок, видео, аудио и RAW файлов [III].

Как это работает?
Собственно секрета никакого нет, работает так же как описано в любом букваре по SSO. Пользователь попадает на login страничку (I системы) авторизуется там, получает много секретного себе в кукисы и редиректится к нам (III система). Далее, специальный модуль от RSA на Apache сервере проверяет валидность этого секрктного и пускает на главную страничку пользователя где он колдует над своими картинками (файлами). Для платных аккаунтов, в связку добавляется еще и II система.

Помимо этого, в релиз вошли новые UI удобности и бантики. Появилась возможность просмотра upload history просто кликнув на дату в календаре, а также, возможность присваивать рэйтинги картинкам. Причем, только СВОИМ картинкам - странно, не правда ли?

Ну и конечно, с новыми мульками мы стали еще более неповоротливыми и тормрзными!

Желаю удачи, коллеги!

среда, 13 февраля 2008 г.

Сравнение архитектуры Flickr и myPicturetown

Недавно коллега дал ссылку на очень интересный пост.
Там достаточно подробно описывается архитектура Flickr сервиса. Кроме всего, сам блог Ивана Блинкова содержателен, рекомендую! Там же, кстати можно прочесть и про Google

Мне был интересен именно Flickr потому, что делаю систему фотохостинга. Задачи похожие. И... пришло разочарование. Не только ничего нового в этой сфере не придумано, но и "одинаковые вещи делаются одинаковым образом". Однако, в нашей системе есть некоторые отличия:


  • Система полностью на Java;

  • Обработка изображений - imagemagick, видео - ffmpeg;

  • PostgreSQL вместо MySQL;

  • Репликация рукописная;

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

  • Обработка изображений, полученных от пользователей по электронной почте, происходит прямо на SMTP сервере (тоже Java).;

  • В среднем при загрузке одной страницы выполняется 5-7 SQL-запросов;

  • Миграция пользователей с хоста на хост осуществляется автоматически (!) по команде из web UI администратора;

  • По состоянию на дату поста добавляем поддержку SSO - один логин на все сервисы;



Ну и один из корневых компонент в подобных системах - это реестр пользователей. У Flickr это зовется центральной базой данных.
"... Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе."

У нас "CDC" - Central Dispatcher Cluster. Но суть не в том как этот компонент называют, а в его функциональности.

Делайте выводы, коллеги и не копируйте "вслепую" чужие схемы.

среда, 5 декабря 2007 г.

Про футуру и архитектуру

Ранее, я работал в компании FutureTrade Rus. которую купила
Interactive Brokers Group о чем официально стало известно 20 ноября 2007 года. Покупка, к сожалению, состоялась по цене гораздо ниже ожидаемой и желаемой. Затем, стало известно о публикации в журнале. Про которую 'злые языки' говорят что она полностью заказная и предназначалась для 'набивания цены' объекту покупки. Трудно оспаривать источники инсайдеровской информации, да и не по мужски это.

Рассмотрим предмет продажи а не флуд вокруг сего факта, более детально с позиции архитектуры. Система в FutureTrade'е имеет полностью Java платформу как на стороне клиента так и на сервере. Бухгалтерские проводки, отчеты, импорты/эксопрты, тоталы и остальной 'backoffice' - рассматриваться не будет.

Архитектура в кубиках

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

Клиент общается со специализированными серверами frontend'а (которые называются 'Connection Server') по защищенному протоколу поверх TCP/IP. Клиенты имеют различные модули подключения к 'Connection Server'ам. Причем, каждый такой сервер подключения работает с клиентом по своему протоколу. Существовало решение (на тот момент когда я там еще работал) для протоколов: FIX (4.0-4.2), пропраитари протокол поверх TCP/IP и HTTP. Не зависимо от выбора протокола обеспечивается гарантированная доставка сообщений.

Connection Server - Java приложение, которое принимает от клиента сообщения в одном формате по конкретному протоколу и транслирует их во внутренний формат системы с последующей их передачей серверам backend'а (и наоборот). Поддерживает уровень сессии и отвечает за балансировку нагрузки при распределении сообщений между серверами backend'а (которые называются 'Execution Server'). Между серверами фронтенда и бекенда используется RMI/IIOP протокол. Причем, при проектировании я старался объединить приемущества Java удаленных вызовов RMI и транспарантность CORBA протокола. В результате получились быстрые удаленные вызовы лишенные недостатков RMI и использующие все достоинства IIOP.

Execution Server - Java приложение, которое отвечает за маршрутизацию сообщений, их обработку и диспетчеризацию ответов. Имеет бизнесс логику и связь с БД. Видоизменяет оригинальные сообщения пользователя и принимает решание по их дальнейшему распространению. Под сообщениями пользователя подразумеваются различные команды на покупку/продажу еквити, опционов, хомяков... Дальнейшее распространение сводится к передаче результирующего сообщения либо назад к клиенту либо к 'Transceiver' модулю для последующей передачи в точку назначения (NASDAQ,SOES,...). Передача осуществяется также по RMI/IIOP.

Transceiver - Java приложение, обеспечивает функциональность ассиметричную 'Connection Server'у. Получает сообщения в пропраитари формате и транслирует их во внешний формат с поддержкой уровня сессии и секъюрности. Типичный пример - FIX соединение с прайм брокером.

Архитекторы
Сие, как на этапе проектирования так и при дальнейшем развитии осуществлялось моими коллегами. Хоть и заказная статья в журнале 'Мурзилка' совершенно без деталей делает заключение о превосходстве архитектурных решений примененных в FutureTrade (в футуре) они, по крайней мере не ошибаются в неординарности и нестандартности таковых. Те кто построили такую архитектуру - это люди не побоявшиеся инноваций и отвечающие за свои слова и решения. Они не делают примеры из учебников и букварей по J2EE (хотя это они могут), они не строят 'классику' как истребитель в крыльях Люфтваффе под крышей, и мне приятно что я с ними работал!

Борис Беркман - технический директор и координатор всей технологии.

Клиент:
Валерий Иванов, Михаил Яковлев, Дмитрий Тарасов

Connection Server / Execution Server:
Александр Антропов, Павел Абушик

Transceiver:
Евгений Трунов, Алексей Антипин, Михаил Власов

Футура для футуры

Что ждет FutureTrade в ближайшее время? С учетом того, что их новый хозяин имеет много наработок и backend писанный на C++ и заинтересован в клиенте от FutureTrade и его кастомеровской базе, то самой большой глупостью будет потерять тех специалистов которые все это поднимали. Я не буду обсуждать намерения и уж тем более осуждать их. Но если новый хозяин хочет интеграции футуровского клиента со своими серверами, даже в этом случае (если новому хозяину не нужен backend) не нестандартность, но дальновидность архитектуры футуры поможет. Когда новый хозяин захочет клиента от футуры а сервера от себя, потребуется всего лишь подпилить компонент типа 'Connection Server' научив его работать с новым сервером по новому пропраитари протоколу. А заложенная в фундамент архитектуры CORBA позволит легко осуществить взаимодействие между Java Connection Server и C++ Execution Server :) Однако, если новый хозяин выкинет нахрен все наработки футуры и оставит только девелоперов - он потеряет но не проиграет.


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

пятница, 2 ноября 2007 г.

Анатомия сетевого стека в Linux


Одна из величайших возможностей операционной системы Linux® — ее сетевой стек. Он является производной стека BSD и хорошо оснащен добротным набором интерфейсов, которые варьируются от протоколо-независимых (protocol agnostic), таких как интерфейс уровня общих сокетов или уровня устройств, до специальных интерфейсов конкретных сетевых протоколов. В этой статье исследуется структура сетевого стека Linux с точки зрения его уровней, а также рассматриваются некоторые из основных структур.

Далее...

Самая мощная сеть распределенных вычислений Folding@home

Как сообщает "КОМПЬЮТЕРРА" сеть распределенных вычислений Folding@home занесена в Книгу рекордов Гиннеса. Статистика впечатляет.

пятница, 5 октября 2007 г.

Коггерентность данных и стандартные схемы

Часто приходится сталкиваться с множеством "велосипедов" в различных архитектурах которые изобретают и переизобретают вновь. Между тем, такие "архитекторы", зачастую страдают банальной некомпетентностью. Что я имею в виду? А вот, что - когда выдумывается очередной концепт с нуля (как думает аффтар) и при этом, он (концепт) представляет собой убогое подобие некого кастрированного гибрида давно уже существующих и опробованных подходов. Т.е. концепт родился по причине незнания аффтара о существовании уже готовых решений. Готовое решение - это не закодированная функция, класс, ... а - алгоритм, подход, ... Конечно я не рассматриваю такие случаи когда концепт изобретается "сознательно" и по причине не применимости ничего уже существующего (это подразумевает глубокое изучение существующего с анализом недостатков и пр.).

Очередной случай из жизни, столкнул меня с человеком имя которого останется неозвученным (не будем переходить на личности). И случай этот был связан с изобретением самопальной системы кеширования. При этом, результат получился не совсем нежизнеспособным. Помочь горю смогло изучение стандартных схем организации кешей. Огромное спасибо Крису Касперски, за внятное (на пальцах) описание озов MESI и прочего.

четверг, 27 сентября 2007 г.

среда, 29 августа 2007 г.

Установка большого Linux-кластера


Создайте работающий Linux-кластер из множества отдельных частей аппаратного и программного обеспечения, включая системы System X и IBM TotalStorage. Это третья статья серии, в которой предоставляется первая часть инструкций по настройке системы хранения данных, включая подробную информацию об архитектуре системы хранения данных, требуемом аппаратном обеспечении и Storage Area Network.
Ссылка из linux.org.ru


Часть 3. Система хранения данных и файловые системы с совместным доступом
Грэхем Уайт (Graham White), специалист по системному управлению, IBM
28.08.2007

Введение

Это третья статья серии, в которой описывается процесс установки и настройки большого Linux-кластера. Целью данной серии является объединение в одном месте последней информации из разнообразных общедоступных источников о создании работающего Linux-кластера из множества отельных частей аппаратного и программного обеспечения. В этих статьях не описываются основы проектирования нового большого Linux-кластера, а лишь предоставляются ссылки на соответствующие справочные материалы и Redbooks™ по общей архитектуре...

Оригинальная статья

понедельник, 27 августа 2007 г.

Архитектура распределенной сети Skype



http://www.xakep.ru/post/38543/default.asp

На атомарном уровне структура Skype-сети состоит из обычных узлов (normal/ordinal node/host/nest), обозначаемых аббревиатурой SC (Skype Client), и super-узлов (super node/host/nest), которым соответствует аббревиатура SN. Любой узел, который имеет публичный IP-адрес (тот, который маршрутизируется в интернет) и обладает достаточно широким каналом, автоматически становится super-узлом и гонит через себя трафик обычных узлов, помогая им преодолеть защиты типа брандмауэров или трансляторов сетевых адресов (NAT) и равномерно распределяя нагрузку между хостами. В этом и состоит суть самоорганизующейся распределенной децентрализованной пиринговой сети, единственным централизованным элементом которой является Skype-login-сервер, отвечающий за процедуру авторизации Skype-клиентов и гарантирующий уникальность позывных для всей распределенной сети.

Важно подчеркнуть, что связь между узлами осуществляется не напрямую, а через цепочку super-узлов. Серверов в общепринятом смысле этого слова (таких, например, как в сети eDonkey) в Skype-сети нет. Любой узел с установленным Skype-клиентом является потенциальным сервером, которым он автоматически становится при наличии достаточных системных ресурсов (объема оперативной памяти, быстродействия процессора и пропускной способности сетевого канала).

Каждый узел Skype-сети хранит перечень IP-адресов и портов известных ему super-узлов в динамически обновляемых кэш-таблицах (Host Cache Tables, HC-tables). Начиная с версии Skype 1.0, кэш-таблица представляет собой простой XML-файл, в незашифрованном виде записанный на диске в домашней директории пользователя.