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

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

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

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

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

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

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

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

Подробнее

Проектирование Web API в 7 шагов

7stepsРазработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Подробнее

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

Всем привет!

Сегодня хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в 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 вместе будут укладываться в общую архитектурную картину.

Подробнее

WPF 4.6 и дальнейшие планы

На недавно прошедшей онлайн конференции dotNetConf организованной Microsoft, рассказывалось множество интересных вещей. И коль скоро было большое количество обсуждений по поводу WPF, что он живее всех живых, то хочется сделать краткий обзор доклада программных менеджеров WPF, что нового нас ждет в релизе, что уже можно посмотреть и к чему все идет. Действительно все так плохо и будет ли аналог нового движка для WPF, как например Razor для ASP.NET.

12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.


Здесь и далее, скриншоты с видео, так что качество не очень, но разглядеть все можно.

В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.

Подробнее

Façade and AOP

Давненько я не писал по теме шаблонов и аспектов. И этот пост будет для разогрева темы снова.

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

facade_aop

Википедия дает следующее определение:

Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

С помощью аспектов не выделить отдельный класс для такого функционала.

По сути, исследователи признали, что только «Фасад» никоим образом из классических 23 шаблонов не может быть хотя бы частично реализован с помощью АОП.

Вот такой короткий рассказ.

 

Hard’n’Heavy!

Patterns on the Road – Russia 2015

Коллеги по .Net разработке,

Разрешите представить вам тур Гаэля Фрэтё (Gael Fraiteur) Patterns On The Road, который состоится с 12 по 17 марта в Москве и Санкт-Петербурге. Главной идеей этого тура является представление и продвижение идеи разработки приложений с помощью шаблонов проектирования. Не просто прорабатывать дизайн с помощью шаблонов проектирования, которые были представлены Бандой Четырех, но также думать и писать код с помощью шаблонов. Гаэль хочет показать, как шаблоны могут быть вынесены на новый уровень абстракции. Эту идею он продемонстрирует в применении к убийственной задаче: потокобезопасность. Для тех, кто желает глубже узнать о PostSharp, мы подготовили бесплатный однодневный курс в обоих городах.

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

Вечерний семинар: Taking Design Patterns to the Next Level

Шаблоны проектирования доказали свою полезность и сейчас воспринимаются как базовое знание многими разработчиками. Со времени Банды Четырех шаблоны значительно облегчили и улучшили процесс дизайна структуры ПО. Однако со времен публикации практически не изменились способы того, как мы применяем их. Гаэль постарается раскрыть и показать на примерах новый путь применения шаблонов для всего цикла разработки. Его примеры бросают вызов сложившимся догмам касательно применения шаблонов и показывают новые аспекты применения гибких методологий. Беседа будет строится не вокруг абстрактных понятий, а на примере популярной и волнующей темы: многопоточности.

Тренинг: Advanced PostSharp From the Horse’s Mouth

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

Тренинг откроет небольшой экскурс в историю языков программирования и шаблонов проектирования ПО, после чего будет рассмотрен фундаментальный вопрос: почему мы думаем в терминах шаблонов, создаем дизайн ПО руководствуясь шаблонами, но по сути отметаем эти принципы во время непосредственного написания кода? Расписания дня в общих чертах можно описать как: потокобезопасность, undo/redo, АОП вообще и архитектурная валидация кода. Все примеры будут работать на новой Visual Studio 2015.

Количество мест ограничено. При достижении лимита, мы выберем участников рандомно.

Если у вас возникли какие-то вопросы, пишите по адресу my@violet-tape.net — Гордиенков Андрей.

Мастер-класс основателя PostSharp в Москве

Gael Fraiteur

В начале марта с 10 по 15, Гаэль приезжает в Россию и хочет провести мастер-классы и вечерние беседы в Москве и Питере. Я ему помогаю в этом деле и фактически организую визит. Мне хотелось бы знать, сколько человек желает с ним побеседовать вечером (это конечно будет не просто сессия вопросов и ответом, а будет практика и лекция часа на 3-4) или посетить мастер-класс. Цена на мероприятия по большей части будет символической для покрытия расходов на аренду.

Если есть желающие, можете сразу писать мне на почту my@violet-tape.net.

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

Программа курса, представленного ниже, читается основателем и ведущим программистом PostSharp Гаэлем Фрэтером (Gael Fraiteur). В курсе раскрываются концепции аспектно-ориентированного программирования, как автоматизировать реализации шаблонов проектирования, а также как внедрить проверку дизайна кода. В конце дня у вас появится общее понимание того, как PostSharp может облегчить жизнь вашей команде.

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

Ключевые моменты тренинга

  • Получите совершенно новый и захватывающий взгляд на процесс программирования, шаблоны проектирования и на то, что компилятор может сделать для вас. Это будет как глоток свежего воздуха, даже если вы не собираетесь использовать PostSharp.
  • Изучите использование готовых решения из PostSharp Pattern Libraries (threading design patterns и INotifyPropertyChanged).
  • Поймете, как автоматизировать ваши собственные шаблоны используя АОП.
  • Узнаете о построении автоматической проверки архитектурных решений в вашем коде.
  • Получите ответы напрямую от создателя PostSharp!

Подробнее

Определение места ошибки в исходном файле

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

После плодотворного общения с программистами PostSharp, оказалось, что это была ошибка в последней сборке и новый релиз, начиная с 4.0.41, ее исправляет. Дальше я хочу отдельно обратить внимание на то, что надо делать и рассказать немного о том, как вообще можно получить эту информацию в C#: до версии 4.5, с версии 4.5 и старше.

PostSharp

Эта часть статьи в целом задумана как обновление и привлечение внимания к статье про шаблон Singleton. Я ее обновил, но тем не менее.

Использование Архитектурного фреймворка из состава PostSharp рано или поздно приведет вас к тому, что надо будет уведомлять программистов об ошибках/недочетах. Лучше всего это делать с помощью специализированных классов, которые построены с учетом специфики работы PostSharp на этапе сборке проекта. К таким специализированным классам относятся:

  • MessageLocation – статический класс, который позволяет узнать место ошибки (строка, файл) на основе служебной информации о составной части класса (MethodInfo, ConstructorInfo и так далее).
  • Message – класс со статическими и динамическими методами, который помогает сформировать сообщение для отображения для конечного пользователя – программиста.

Общий шаблон работы с этими классами выглядит так:

Подробнее

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

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

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

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

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

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

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

Намерение

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

Суть

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

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

Реализация

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

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

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

memento

Подробнее