книги хакеры / журнал хакер / 162_Optimized

СОЗДАЕМОБЪЕКТЫ КЛАССОВЛЕГКО ИСУЛЫБКОЙ

В объектно-ориентированном программировании понятие классов — основа основ. У них есть конструкторы и деструкторы, которые позволяют выполнять определенные действия при инициализации и уничтожении объектов классов. Казалось бы, что тут еще можно придумать? Но в сложных системах зачастую базовых механизмов для конструирования объектов классов бывает недостаточно. Специально для таких случаев был придуман паттерн «Абстрактная фабрика».

редставим,чтомызанимаемсяразработкойнекойсистемы,

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

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

Класс пользовательского аккаунта

class User

{

public:

User(string login, string password)

: m_login(login), m_password(password)

{

};

~User();

string getLogin() { return m_login; }

string getPassword() { return m_password; }

void setLogin(string login) { m_login = login; }

void setPassword(string password) { m_password = password; }

// ...

private:

string m_login;

string m_password;

}

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

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

Первое, что приходит в голову, — это создать отдельный класс и назвать его как-нибудь типа AdminUser. Код его будет такой.

Класс администраторского аккаунта

class AdminUser

{

public:

AdminUser(string login, string password)

: m_login(login), m_password(password)

{};

~AdminUser();

//Код методов getXXX и setXXX идентичен

//коду из класса User

//Другой код, специфичный для админского аккаунта

private:

string m_login;

string m_password;

}

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

Код создания экземпляров классов пользователей

const int SIMPLE_USER = 1;

const int ADMIN_USER = 2;

int userType;

string login;

string password;

//Инициализация переменных userType, login, password

//…

if (userType == SIMPLE_USER)

{

User user(login, password);

}

else if (userType == ADMIN_USER)

{

AdminUser user(login, password);

}

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

Диаграммаклассовпаттерна«Абстрактнаяфабрика»

Классы пользовательских аккаунтов и их создание

class UserBase

{

public:

User(string login, string password)

: m_login(login), m_password(password)

{

};

~User();

virtual string getLogin() { return m_login; }

virtual string getPassword() { return m_password; }

virtual void setLogin(string login) { m_login = login; }

virtual void setPassword(string password) {

m_password = password; }

// ...

private:

string m_login;

string m_password;

}

class User : public UserBase

{

public:

User(string login, string password)

: UserBase(login, password)

{

};

virtual ~User();

//Код, специфичный для обычных пользовательских

//аккаунтов

}

class AdminUser : public UserBase

{

public:

AdminUser(string login, string password)

: UserBase(login, password)

{

};

virtual ~AdminUser();

ПримеркодафабрикинаPython

//Код, специфичный для админских пользовательских

//аккаунтов

}

// Клиентский код

UserBase *user;

if (userType == SIMPLE_USER)

{

user = new User(login, password);

}

else if (userType == ADMIN_USER)

{

user = new AdminUser(login, password);

}

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

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

классов (AdminUser, User и так далее) может принимать различные параметры. Клиент должен знать и помнить, какому классу какие данные нужны для успешного создания объекта. Это опять-таки не очень хорошая манера кодинга. Чем проще интерфейс взаимодействия клиентов с классами, тем надежней наш код.

Все эти проблемы нам поможет решить «Абстрактная фабрика». Суть этого объектно-ориентированного паттерна заключается в том, что он инкапсулирует все действия по созданию объектов классов. То есть всё, что мы до этого момента делали в разных

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

Код фабрики class UserFactory

{

public:

// ...

UserBase* createUser(int userType, string login,

string password)

{

BaseUser *user;

switch (userType)

{

case ADMIN_USER:

user = new AdminUser(login, password);

break;

case SIMPLE_USER:

user = new User(login, password);

break;

}

return user;

}

}

Итак, что мы сделали? У нас есть класс UserFactory, который в своем арсенале имеет всего один-единственный значимый метод — createUser(). Метод этот, помимо типа пользовательского аккаунта, принимает еще и данные, которые нужны для конструирования объектов. Причем если наборы параметров для создания разных юзеров отличаются друг от друга, то фабрика сама выбирает те, что нужны для криэйта заданного объекта. На выходе createUser() отдает указатель на объект базового типа.

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

Использование фабрики классов в клиентском коде

AdminUser *admin;

UserFactory uf();

admin = uf.createUser(ADMIN_USER, login, password);

ЗАКЛЮЧЕНИЕ

Фабрики классов широко используются в объектноориентированном программировании. Любой проект со сложностью немногим выше минимальной может извлечь достаточно весомые преимущества из их применения. Поэтому, если ты собираешься начать кодить что-то грандиозное, очень рекомендую испробовать фабрики классов у себя в проекте. z

1 3 4 5 6

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

высоконаг систем.

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

ВЫСОКИМ

ОТАВТОРОВ

Основнымнаправлениемдеятельностинашейкомпании

архитектур,проведениенагрузочныхтестированийиоптимизациясай .Вчислонашихклиентоввходятинвесторы из России и с всегомира,атакжепроекты«ВКонтакте», «Эльдорадо «Имхонет»,Photosight.ruидругие.Вовремя консультаци мычастосталкиваемсястем,чтомногиене знаютсамых основ—чтотакоемасштабированиеикаким онобывает,какиеинструментыидлячегоиспользуются.

довательнорассказатьобовсехинструментах,которые используют припостроенииархитектурывысоконагру-

женныхсис .

Мыначнемописыватьпостроениеархитектурывысоконагруженныхсистемссамыхоснов.Небудемрассказыватьнио какихноу-хауипостараемсянеразделятьвозможныерешения на«правильные»и«неправильные».Конечно,унасестьизлюбленныеконцепции,однакомыпланируемдатьнаиболееполноепредставлениеоцеломнабореприемов,методов,подходов, схемиинструментов,которыеможноиспользовать.

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

МОНОЛИТНЫЕПРИЛОЖЕНИЯ ИСЕРВИС-ОРИЕНТИРОВАННАЯАРХИТЕКТУРА

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

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

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

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

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

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

Рассмотрим,например, Facebook.Онпостроенпочтиклассически.Естьразличныесервисы, каждыйизкоторыхреализует строгоопределенныйнаборфункций.Кпримеру,службасообщений илентыновостей(то,что,казалось бы,являетсяядромсети)представляютсобойотдельныесервисы, которыетесноинтегрированы. Возьмемсервисавторизации.Мы можемобратитьсякнему,передать емукукуиспросить:«Этовалидная кука?Есливалидная,токомуона принадлежит?»

Наверное,однимизсамыхизвестныхпроектов,припостроении которогосервисныйподходиспользуетсяпомаксимуму,является Amazon.Этотбольшойинтернетмагазинсталкиваетсясзадачами, которыехарактерныдлялюбого крупногопроекта.Когдавкомпаниюпришелновыйтехнический директор,онпринялгениальное решение:«Мыбудемделатьсервисы!»ВрезультатеAmazonявляется нетолькоинестолькокрупным интернет-магазином,сколько поставщикомcloud-сервисов. Теперьприсозданиикакого-либо продукта,крупногосайтавсегда возникаетвопрос:разрабатывать лисобственнуюсистемухранения,илииспользоватьсистемуот Amazon,котораяизначальнопостроенатак,чтобыееможнобыло купить?

Одинизсамыхбольшихплюсов сервис-ориентированнойархи-

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

ивашиосновныедевелоперы.Это проблема,которуюоченьсложно решить.Именнопоэтому«монолитный»подходкмонолитному приложениюосложняетмасштабированиеразработки,когдаречь, допустим,идетоединомPHPприложении.Например,обычный CGIscriptвкаком-тосмыслеявля- етсямонолитнымприложением. Когданужно,чтобыэтотCGIscript «пилило»несколькочеловек,уже начинаютсятрудности.

Если у вас сервис-ориенти- рованная разработка, вы можете прийти к сторонней команде

исказать: «Ребята, нам надо запилить эту штуку. Мы API про-

БЕРЕТСЯМОНОЛИТНОЕПРИЛОЖЕНИЕ,РАЗБИВАЕТСЯНАОТДЕЛЬНЫЕСЕРВИСЫ, КАЖДЫЙИЗКОТОРЫХОТВЕЧАЕТЗАСТРОГООПРЕДЕЛЕННЫЙНАБОРЗАДАЧ,ПОСЛЕЧЕГОДЛЯЭТИХСЕРВИСОВЗАДАЕТСЯСПОСОБКОММУНИКАЦИИ

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

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

Другойпример:софтErlyvideo, разработкойкоторогозанимается МаксимЛапшин.Этосреднего размерасофтинанаязыкепрограммированияErlang.Писать подобныевидеостриминговые штукисложнее,чемсайты,потому

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

написатьто,чтонесломалобыкод напродакшнепривыкатывании, нужноминимумполгода.Вслучае с«Эрливидео»тасамаяпроблема двухгениеврешенаинструментально.Инструментпомогаетвести параллельнуюразработкуводном коде,водномприложении,водном репозитории.Однакоэто,скорее, исключениеизобщегоправила, обусловленноекомпактностью кода.

РЕМЕСЛЕННЫЙ ИПРОМЫШЛЕННЫЙПОДХОД

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

Прииспользованиипромышленногоподходаэтисредстваразраба- тываютсяотдельноотбизнес-логики. Приремесленномподходесредства

ибизнес-логикаразрабатываются одновременно.Итам,итамимеются сервисы.Новодномслучаеестьодин большойслой,которыйотвечаетза то,чтовсеэтобудетработать.Объяснимнапримере.

РазработчикиGoogleв большинствесвоемнеспециализируютсянаразработкевысоконагруженныхсистем.Еслиу кого-нибудьизнихспросить:«Как тыбудешьделатьэтусистему?Как онабудетвыдерживатьмиллионы пользователей?»,то,скореевсего, услышишь:«Этооченьпросто.Я сделаюзапросксистемеbigdata,

ионабыстровернетответ».Онне знает,чтопроисходитвнутри—ему этоненадо.Еслипосмотретьна схему,тоонработаетна«зеленом» уровнеииспользуетужеготовые разработки,сделанныеотдельной командойинженеров,которые непосредственнозанимаютсявысокиминагрузками.Такработает большинствокрупныхкомпаний.

Хорошимпримеромприложения,приразработкекоторого использовалсяэтотподход,может послужитьGoogle+.Этоприложениебылосозданозасовер-

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

Аналогичнымобразомустроенобольшинствокрупныхпроек- тов—Facebook,Google,«Яндекс».В«Яндексе»тожеестьэтавол- шебнаяшинаданных,ккоторойидутзапросы,и«Яндекс»никогда непадаетцеликом,заисключениемтехслучаев,когдавозникают проблемысдата-центром.В«Яндексе»падаюткускистраниц.

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

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

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

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

КРУПНЫЕКОМПАНИИЧАСТОЯВЛЯЮТСЯПИОНЕРАМИ.ДОПУСТИМ,DYNAMODBБЫЛРАЗРАБОТАН ВAMAZONДЛЯМАСШТАБИРОВАНИЯИХСОБСТВЕННОЙСИСТЕМЫРАБОТЫСОСКЛАДОМ

ПАРАМЕТРЫ ЖЕЛЕЗА НЕЛЬЗЯ УВЕЛИЧИВАТЬ БЕСКОНЕЧНО. В КАКОЙ-ТО МОМЕНТ СТАНЕТ НУЖНА УЖЕ ТЫСЯЧА СЕРВЕРОВ, А ЗАКУПИТЬ СТОЛЬКО БУДЕТ НЕВОЗМОЖНО

являются пионерами. Допустим, DynamoDB был разработан в Amazon для масштабирования их собственной системы работы со складом. После появления DynamoDB опенсорсным сообществом были написаны Cassandra, Hadoop и так далее. Все они существуют благодаря компаниям, использующим ремесленный подход, которые нуждаются в собственных сервисах типа DynamoDB, но не в состоянии разработать их самостоятельно. Таким образом, подобный обмен происходит постоянно. Google создает какое-то новое решение. Это решение опенсорсится, потом много раз переписывается, после чего его подхватывают десятки компаний, таких как «ВКонтакте», DeNA (Япония) и многие другие. Они делают из этого решения действительно качественный софт, которым могут пользоваться все.

Укрупныхкомпанийиз-заэтогочастовозникаетпредубеж- дение,котороеможновыразитьфразой«Все,чтосделано

ненами,намнеподходит»или«Notinventedhere».Крупные компаниимогутсебепозволитьпривлекатьпрофессорови целыеуниверситеты,чтобыонивеликакое-либонаправление. Например,GoogleTranslateкурируетзнаменитыйпрофессор, по-моему,изСтэнфорда,которыйвсюжизньзанималсятеорией машинногоперевода.ТожесамоепроисходитивMicrosoft,и другихкомпанияхтакойвеличины.

Профессионалыестьвкомпанияхобоихтипов.Ноэторазного родапрофессионалы.Профессионалывтехкомпаниях,которые практикуютремесленныйподход,действительнознают,какие опенсорсныесредстванужноприкрутить,ачтонаписатьсамим, чтобывсезаработалопрямозавтра.Вбольшихкорпорациях, скореевсего,естьнетолькогуру,которыесидяти«пилят»bigdata иwebscale,ноиогромноеколичествоспециалистов,которые занимаютсяинновациямиименновобластиusability,новыхсервисовипрочего.

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

МАСШТАБИРОВАНИЕАРХИТЕКТУРНОГОРЕШЕНИЯ

Дляначаларассмотримсамыеосновы—вертикальноеигоризон- тальноемасштабирование.Вчемсостоитконцепциявертикальногомасштабирования?

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

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

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