Забудьте САР теорему как более не актуальную

или «Прекратите характеризовать БД как CP или AP»

capДжеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие похоже восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

Я согласен со всеми пунктами статьи кроме того, что касается САР теоремы. Она слишком всё упрощает и слишком многие понимают её неверно для того, чтобы использовать для определения характеристик системы. Так что я прошу перестать ссылаться на САР теорему, говорить о ней и дать ей уже спокойно уйти на покой. Вместо неё мы должны использовать более точную терминологию для обсуждения различных компромиссов.

(Да, я понимаю всю иронию написания целой статьи по теме того, о чём призываю не писать других вообще. Но как минимум у меня будет ссылка, которую я смогу давать интересующимся, когда меня будут спрашивать, почему я не одобряю обсуждение САР теоремы. Также, я хочу извиниться если статья вам покажется слишком напыщенной, но эта напыщенность опирается на множество ссылок.)

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

  • Согласованность (Consistency) в САР на самом деле означает линеаризуемость, что является (и очень сильным) принципом согласованности. В частности, это не имеет ничего общего с «С» из ACID, даже если эта С так же означает «согласованность». Я на пальцах объясню, что такое линеаризуемость чуть позже.
  • Доступность (Availability) в САР определено как «каждый запрос, полученный работающим узлом [базой данных] в системе должен приводить к ответу [не содержащему ошибок]». Недостаточно чтобы некоторые узлы могли обработать запрос: любой работающий узел должен быть способен обработать запрос. Множество так называемых «высокодоступных» (high abailability), т.е. с низким уровнем простоя, систем в реальности не отвечают определению доступности.
  • Устойчивость к разделению (Partition tolerance) ужасное название – в общих словах означает что вы для связи используете асинхронную сеть, которая может терять или задерживать сообщения. Интернет и все датацентры обладают этим свойством, так что в реальности у вас нет выбора в этом контексте.

Подробнее

Характеристики микросервисов, приложений и систем

Всем привет!

Сегодня хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

В презентации Стефан также рассказывает о том, что традиционные предположения о том, каким образом строить программные системы подвергаются сегодня тотальному пересмотру. Одно из таких предположений, что большая система должна иметь единое окружение, часто с однозначным соответствием между функциональными требованиями проекта и реализацией, что выливается в формулу «1 проект = 1 система». Хотя такое решение не всегда самое лучшее, оно получается очень жестким.

Рассматривая способ построения логических систем из малых частей, Тильков описывает три стиля:

  • Микросервисы – маленькие программы, каждая из которых работает сама по себе. Используют простые механизмы для общения и строятся вокруг нужд бизнеса.
  • Приложения – небольшие, отдельные, исполняемые программы, использующие модель «share nothing». Имеют много общего с микросервисами.
  • Самодостаточные системы – это крупные автономные программы, которые содержат и данные и логику. Контролируются одной командой. Не используют синхронные удаленные вызовы, могут предоставлять API.

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

Screenshot

Наиболее интересным параметром для Тилькова является количество модулей в системе, потому что это показывает степень декомпозиции большой системы.  Большие системы в этом плане проигрывают, но микросервисы сложнее в поддержке и оркестровке, тем самым увеличивая уровень сложности системы. В общем, нет какого-то одного правильного решения, «серебряной пули» и мы на конференции API & Backend хотели бы поднять дискуссию на эту тему. Если у вас есть интересные случаи из практики касающиеся типичных проблем для той или иной модели, пути решения этих проблем – мы ждем ваших историй.

 

Hard’n’Heavy!

Управление API и SOA

Для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) достижение начального успеха определяется:

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

Множество команд разработчиков разрабатывают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

Простое приложение чаще всего работает с неким сервисом и спагетти-сетью конечных точек, поставщиков данных этого сервиса, которые переплетены связями один-к-одному. Многие команды в этом случае сходятся во мнении что фокус на SOA и REST не то чтобы помогал в решении вопросов гибкости решений. Скорее просто происходит подмена набора IT инструментов, форматов сообщений и протоколов.

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура

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

Подробнее

Шаблон Хранитель в АОП реализации

Вторым на очереди в описании оказался шаблон проектирования Хранитель (Memento). На мой взгляд этот шаблон достаточно просто реализовать, по крайней мере его идеологическая суть ясна многим без детальных объяснений.

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

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

Общая информация

Для полноты картины, я считаю, что надо все так же привести основные характеристики и назначение шаблона.

Хранитель относится к категории Поведенческих шаблонов.

Намерение

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

Суть

Сохранить состояние объекта, и иметь возможность вернуться к исходному состоянию, не раскрывая своего содержимого внешнему миру.

Очень важным моментом является — «не раскрывая своего содержимого внешнему миру» — это суть инкапсуляции и ООП. В качестве быстрого примера, могу привести пример с объектом, который получает при конструировании уникальный номер. Этот номер нельзя никак задать с помощью публичного API. При восстановлении объекта из Memento есть доступ к внутренним полям и эта операция пройдет абсолютно честно и просто.

Реализация

Классическая реализация говорит о следующих особенностях реализации шаблона:

  • Необходимо создать класс-хранитель «мгновенных снимков» целевого класса
  • Целевой класс должен уметь сохранять и принимать свои «мгновенные снимки»

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

memento

Подробнее

SoftLab.NET 2014

20 Декабря была веб-конференция SoftLab.NET 2014 компании Luxoft на которой я рассказывал про Threading Pattern Library из комплекта поставки PostSharp. Эта библиотека шаблонов действительно упрощает работу с многопоточностью. В следующем году я хочу подробно про это написать, так как там много нюансов обнаруживается, но сейчас краткий обзор доступен в презентации.

Hard’n’Heavy!

What I’ve learned about DDD since the book

Не далее как на прошлых выходных побывал на тренинге Patterns and Practices of Effective Domain Modeling, который вел Dino Esposito. Тренинг понравился, хотя я и не узнал фактически ничего нового. Ну это я сам виноват, так как давно копаю эту тему и много уже всякого переслушал и перечитал. Так вот, на этом тренинге на одном из слайдов была ссылка на выступление Эрика Эванса (Eric Evanse), где тот рассуждал на тему, как бы он переписал книгу «Domain Driven Design. Tackling complexity in the heart of software». Я посмотрел это выступление и оно в целом очень интересное. Вообще мне нравятся темы, когда инициаторы каких-то идей, через несколько лет пишут или говорят о том, как они бы сейчас изменили свою книгу\концепцию. Это наверно наталкивает на мысли, что же наиболее важно оказалось. Второстепенные вещи редко поддаются сильным изменениям.

В общем, советую посмотреть тоже выступление What I’ve learned about DDD since the book

На сегодня это все =)

Hard’n’heavy!

Поведение при подписке на события

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

Для иллюстрации рассмотрим следующий пример. Пусть у нас есть некоторое приложение со списком опций и общей картинкой. Т.е. приложение выглядит примерно следующим образом:

sample

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

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

Код в реальности выглядит вот так. Т.е. это то, как вы его напишите с первого раза. Собственно я написал так же.

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

Итак, что вы ожидаете от такого кода? Посмотрите внимательно на названия методов, событий – решите для себя, что вы ожидаете.

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

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

Это очень странно на первый взгляд, так как я подписываюсь на событие и ожидаю, что его получат все заинтересованные компоненты, и обработка не прервется на самом интересном месте. Для того, чтобы сработало передвижение на новый элемент из listBox, необходимо дописать IsHandled = false:

С другой стороны, если совсем внимательно и формально отнестись к названию события, то получаем что «команда получена, а дальше вы сами разбирайтесь как с ней поступать». Но тогда странно, что это событие.

На мой взгляд надо сделать два события:

  • ArrowNavigationCommandReceived – нет возможность использовать IsHandled для прерывания цепочки обработки.
  • ArrowNavigationCommandReceiving – есть возможность использовать IsHandled.

Ближайшая аналогия прослеживается с событиями Closed и Closing для окон (WinForm, WPF).

Что вы думаете по этому поводу? Комментарии как всегда приветствуются.

UPD: голосование пока что запилить не могу.

[poll id=»2″]

Hard’n’Heavy!

Логика на INotifyProperyChanged

Сложность 200-300

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

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

Я уже не раз писал и говорил насколько мне не нравится явная реализация INPC при реализации MVVM для WPF, но недавнее открытие в проекте коллег не смогло меня оставить равнодушным. Честно сказать, я не представлял, что таким образом можно построить логику приложения, но что есть, то есть. Итак, не будем более затягивать вступление и обратим взор на код.

Подробнее

Domain, Context, Integration. Как увидеть динамику в статике кода.

Доклад с конференции, вы не поверите, «Java сегодня и завтра. Просто о сложном».

Большинство из нас, если не все, для разработки больших приложений, для бизнес-приложений по большому счету, используют Domain Driven Design подход описанные Эриком Эвансом в 2004 году. Это способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике. Однако реальные связи в таком коде чаще всего строятся и можно увидеть только в режиме run-time. Данный доклад ставит своей целью не столько показать конкретный код, сколько направить мысль разработчика на новую тему.

 

Hard’n’Heavy!

Конвейер (Pipeline) — IV

Ближе к жизни

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

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

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

Подробнее