Архитектура

Когда нужно сделать код в проекте гибким и удобным, на помощь приходит разделение архитектуры на несколько слоев. Рассмотрим подробнее этот подход и альтернативы, а также поделимся рекомендациями, которые могут быть полезны как начинающим, так и опытным разработчикам Vue.js, React.js, Angular.

В старые времена, когда JQuery только появился, а о фреймворках для серверных языков лишь читали в редких новостях, веб-приложения реализовывали целиком на серверных языках. Зачастую для этого использовали модель MVC (Model-View-Controller): контроллер (controller) принимал запросы, отвечал за бизнес-логику и модели (model) и передавал данные в представление (view), которое рисовало HTML.

Объектно-ориентированное программирование (ООП) на тот момент только начинало формироваться, поэтому разработчики зачастую интуитивно решали, где и какой код надо писать. Таким образом, в мире разработки зародилось такое понятие, как Божественные объекты, которые первоначально отвечали практически за всю работу отдельных частей системы. Например, если в системе была сущность Пользователь, то создавался класс User и в нем писалась вся логика, так или иначе связанная с пользователями. Без разбиения на какие-то ещё файлы. И если приложение было большим, то такой класс мог содержать тысячи строк кода.

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

1. Выход есть

Как известно, Vue.js, React.js и прочие подобные фреймворки основаны на компонентах. То есть, по большому счету, приложение состоит из множества компонентов, которые могут заключать в себе и бизнес-логику и представление и много чего еще. Таким образом, разработчики во многих проектах пишут всю логику в компонентах и эти компоненты, как правило, начинают напоминать те самые божественные классы из прошлого. То есть, если компонент описывает какую-то крупную часть функционала с большим количеством (возможно сложной) логики, то вся эта логика и остается в компоненте. Появляются десятки методов и тысячи строк кода. А если учесть то, что, например, во Vue.js еще есть такие понятия как computed, watch, mounted, created, то логику пишут еще и во все эти части компонента. В итоге, чтобы найти какую-то часть кода, отвечающую за клик по кнопке, надо перелистать десяток экранов js-кода, бегая между methods, computed и прочими частями компонента.

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

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

Вот о таком разбиении кода на слои и пойдет речь, но уже применительно к frontend-фреймворкам, таким как Vue.js, React.js и прочим.

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

2. Создание удобной архитектуры приложения

Рассмотрим пример, в котором вся логика находится в одном компоненте.

2.1. Логика в компоненте

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

methods: {    duplicateCollage (collage) {      this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: true })      dataService.duplicateCollage(collage, false)        .then(duplicate => {          this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: false })        })        .catch(() => {          this.$store.dispatch('updateCollage', { id: collage.id, isDuplicating: false })          this.$store.dispatch('errorsSet', { api: `We couldn't duplicate collage. Please, try again later.` })        })    },    deleteCollage (collage, index) {      this.$store.dispatch('updateCollage', { id: collage.id, isDeleting: true })      photosApi.deleteUserCollage(collage)        .then(() => {          this.$store.dispatch('updateCollage', {            id: collage.id,            isDeleting: false,            isDeleted: true          })          this.$store.dispatch('setUserCollages', { total: this.userCollages.total - 1 })          this.$store.dispatch('updateCollage', {            id: collage.id,            deletingTimer: setTimeout(() => {              this.$store.dispatch('updateCollage', { id: collage.id, deletingTimer: null })              this.$store.dispatch('setUserCollages', { items: this.userCollages.items.filter(userCollage => userCollage.id !== collage.id) })               // If there is no one collages left - show templates              if (!this.$store.state.editor.userCollages.total) {                this.currentTabName = this.TAB_TEMPLATES              }            }, 3000)          })        })    },    restoreCollage (collage) {      clearTimeout(collage.deletingTimer)      photosApi.saveUserCollage({ collage: { deleted: false } }, collage.id)        .then(() => {          this.$store.dispatch('updateCollage', {            id: collage.id,            deletingTimer: null,            isDeleted: false          })          this.$store.dispatch('setUserCollages', { total: this.userCollages.total + 1 })        })    }}

2.2. Создание слоя сервисов для бизнес-логики

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

Один из классических способов хоть какого-то разбиения логики это деление на сущности. Например, почти всегда в проекте есть сущность Пользователь или, как в описываемом примере, Коллаж. Таким образом, можно создать папку services и в ней файлы user.js и collage.js. Такие файлы могут быть статическими классами или просто возвращать функции. Главное чтобы вся бизнес-логика, связанная с сущностью, была в этом файле.

services  |_collage.js  |_user.js

В сервис collage.js следует поместить логику дублирования, восстановления и удаления коллажей.

export default class Collage {  static delete (collage) {    // ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА  }   static restore (collage) {    // ЛОГИКА ВОССТАНОВЛЕНИЯ  КОЛЛАЖА  }   static duplicate (collage, changeUrl = true) {    // ЛОГИКА ДУБЛИРОВАНИЯ КОЛЛАЖА  }}

2.3. Использование сервисов в компоненте

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

methods: {  duplicateCollage (collage) {    CollageService.duplicate(collage, false)  },  deleteCollage (collage) {    CollageService.delete(collage)  },  restoreCollage (collage) {    CollageService.restore(collage)  }}

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

Также многие разработчики на пути к удобной архитектуре выносят вызовы методов API в отдельный файл (файлы). Это как раз создание слоя вызовов API, которое также приводит к удобству и структурированности кода.

import axios from '@/plugins/axios' export default class Api {   static login (email, password) {    return axios.post('auth/login', { email, password })      .then(response => response.data)  }   static logout () {    return axios.post('auth/logout')  }   static getCollages () {    return axios.get('/collages')      .then(response => response.data)  }    static deleteCollage (collage) {    return axios.delete(`/collage/${collage.id}`)      .then(response => response.data)  }    static createCollage (collage) {    return axios.post(`/collage/${collage.id}`)      .then(response => response.data)  }}

3. Что и куда выносить?

На вопрос, что же именно и куда выносить, однозначно ответить невозможно. Как вариант, можно разбить код на три условные части: бизнес-логика, логика и представление.

Бизнес-логика это все то, что описано в требованиях к приложению. Например, ТЗ, документации, дизайны. То есть все то, что напрямую относится к предметной области приложения. Примером может быть метод UserService.login() или ListService.sort(). Для бизнес-логики можно создать сервисный слой с сервисами.

Логика это тот код, который не имеет прямого отношения к предметной области приложения и его бизнес-логике. Например, создание уникальной строки или поиск некоего объекта в массиве. Для логики можно создать слой хэлперов: например, папку helpers и в ней файлы string.js, converter.js и прочие.

Представление все то, что непосредственно связано с компонентом и его шаблоном. Например, изменение реактивных свойств, изменение состояний и прочее. Этот код пишется непосредственно в компонентах (methods, computed, watch и так далее).

login (email, password) {  this.isLoading = true  userService.login(email, password)    .then(user => {      this.user = user      this.isLoading = false    })}

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

Если же сервисы или хэлперы начнут разрастаться, то сущности всегда можно разделить на другие сущности. К примеру, если у пользователя в приложении маленький функционал в 3-5 методов и пара методов про заказы пользователя, то разработчик может вынести всю эту бизнес-логику в сервис user.jsрешить всю эту бизнес-логику написать в сервисе user.js. Если же у сервиса пользователя сотни строк кода, то можно все, что относится к заказам, вынести в сервис order.js.

4. От простого к сложному

В идеале можно сделать архитектуру на ООП, в которой будут, помимо сервисов, еще и модели. Это классы, описывающие сущности приложения. Те же User или Collage. Но использоваться они будут вместо обычных объектов данных.

Рассмотрим список пользователей.

Классический способ вывода ФИО пользователей выглядит так.

<template><div class="users">  <div    v-for="user in users"    class="user"  >    {{ getUserFio(user) }}  </div></div></template> <script>import axios from '@/plugins/axios' export default {  data () {    return {      users: []    }  },  mounted () {    this.getList()  },  methods: {    getList() {      axios.get('/users')        .then(response => this.users = response.data)    },    getUserFio (user) {      return `${user.last_name} ${user.first_name} ${user.third_name}`    }  }}</script>

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

Для начала следует создать модель Пользователь.

export default class User {  constructor (data = {}) {    this.firstName = data.first_name    this.secondName = data.second_name    this.thirdName = data.third_name  }   getFio () {    return `${this.firstName} ${this.secondName} ${this.thirdName}`  }}

Далее следует импортировать эту модель в компонент.

import UserModel from '@/models/user'

С помощью сервиса получить список пользователей и преобразовать каждый объект в массиве в объект класса (модели) User.

methods: {   getList() {     const users = userService.getList()     users.forEach(user => {       this.users.push(new UserModel(user))     })   },

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

<template><div class="users">  <div    v-for="user in users"    class="user"  >    {{ user.getFio() }}  </div></div></template>

К вопросу о том, какую логику выносить в модели, а какую в сервисы. Можно всю логику поместить в сервисы, а в моделях вызывать сервисы. А можно в моделях хранить логику, относящуюся непосредственно к сущности модели (тот же getFio()), а логику работы с массивами сущностей хранить в сервисах (тот же getList()). Как будет удобнее.

5. Заключение

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

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

Спасибо за внимание! Будем рады ответить на ваши вопросы.

Представьте ситуацию: вам нужно воспользоваться оплаченным (как вы думаете) сервисом и вдруг оказывается, что он отключен за неуплату. Такая неприятность портит впечатление от бренда, снижая поток прибыли, а внезапно отключенный клиент может не вернуться к сервису. К старту курса о глубоком и машинном обучении делимся переводом о том, как эту проблему решили в Dropbox, где обнаружили, что внедрение ML в обработку клиентских платежей помогает пользователям оставаться довольными и работает лучше внедрённых за 14 лет политик биллинга.

Платежи в Dropbox

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

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

Продление подписки и сбои

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

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

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Сбои в оплате могут произойти по ряду причин. Среди них:

• нехватка средств;

• карта с истекшим сроком действия;

• заблокированная карта возможно, сообщается о потере или краже;

• непредсказуемые сбои обработки.

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

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

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

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

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

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

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

• устранение ручного вмешательства и сложной логики на основе правил;

• например, Повторяйте каждые X дней или Избегайте попыток оплаты в выходные;

• глобальная оптимизация множества параметров для конкретных сегментов клиентов;

• устойчивость к изменениям клиентов и рынка;

• увеличение общего числа успешных платежей и сокращение времени сбора платежей.

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

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

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

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

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

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

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

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

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

2. Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.

3. Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.

4. Генерация прогноза. Модель возвращает ранжированное наилучшее время оплаты. Этот прогноз отправляется обратно в модуль Predict, в свою очередь, результаты в биллинговую политику.

5. Логирование результатов прогнозов. Модуль Predict, кроме прочего, логирует результаты прогнозирования модели, а также другую необходимую информацию, которая может использоваться для устранения неполадок и анализа.

6. Расписание следующего платежа. Как только сервис платежей получает наилучшее время списания средств, он учитывает это время при планировании следующей попытки оплаты и сохраняет в Edgestore.

ML-операции

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

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

Бизнес-метрики

• Коэффициент одобрения счетов. Основная метрика, которую нужно улучшить. При каждом продлении подписки в Dropbox все платежи за продление отслеживаются как часть единого счёта. Эта метрика сообщает нам, было ли обновление подписки успешным.

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

Внутренний мониторинг модели

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

• Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.

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

• Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

Наряду с мониторингом и оповещением для платёжной платформы и сервиса Predict мы также отслеживаем следующее, чтобы определить, насколько хорошо работает инфраструктура:

• свежесть и задержки в конвейерах данных признаков;

• доступность и задержка сервиса Predict;

• доступность EdgeStore.

Для мониторинга нашей модели и метрик инфраструктуры мы используем дашборды Grafana и Vortex. Для бизнес-метрик мы используем Superset. Все эти живые метрики и дашборды помогают нам проактивно отслеживать ожидаемое поведение модели, позволяя принимать соответствующие меры, когда оно отклоняется.

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

Дальнейшие шаги

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

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные я посмотрел архитектуру и там ошибка или вот я добавил новый модуль, который нам может пригодиться в будущем ну и, конечно, я сделал всё проще и быстрей. Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и подготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

В чём интрига? В самой сцене. В самом начале дня у нас обычно дейли разработчиков. Там все делятся успехами и проблемами. Охотно так делятся. Долго и много. Как раковые клетки. Даже анализы можно делать. Чем больше тем на этом daily, тем больше опухоль в проекте. Потом придётся выжигать и резать. Но команд много, а архитектора мало. Поэтому его не зовут, если не уже дымится.

Дальше отсеиваются разработчики и в следующий тур идут только тимлиды. Они более практичны и рассказывают о своих успехах и как всё по плану, а проблемы выносят в оффлайн. Сухо так и без шуток. С dev. менеджером обычно всё позитивно, если менеджер сам не станет копать или не возникнет подозрение о том, что дедлайн слишком близко к носу. И так как начальник - человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз и отдаёт), команд много и проекты глобальные, то представитель от каждого сайта (ротация среди лидов) подключается к общему митингу, куда обычно и приглашают архитектора. Это самые бесполезные пол часа. Каждый уже пару раз рассказал свою историю и пережевал проблемы (а тут, видимо, как и с шутками: проблема, повторенная дважды, перестаёт быть проблемой). Вдобавок говорить то на английском надо, который для большинства неродной и куча акцентов Короче, каждый chosen one пытается сказать одно-два предложения, так чтоб не дай бог не задали вопросов. Как на приёме в налоговой.

В итоге каждая команда поделилась своими проблемами только с собой. Оставшись внутри закрытого спектра бизнес-задач и решений, которые знакомы всем её участникам. Я не против психотерапии, но если у вас проблема и вы можете решить её внутри команды, то зачем ждать планёрки? А если не можете то, чем поможет её озвучить в том же кругу? Но я не менеджер и даже не Agile тренер мне не понять. Я - Винни Пух и по утрам хожу в гости. К кому-нибудь. Желательно без приглашения (иначе рискуете услышать заученный текст на английском) на ту самую первую сцену, где профилактика будет стоить дешевле лечения. Это здорово экономит время, так как альтернативой будет просмотр коммитов. Код ревью тот же рыбий жир. Может и полезно, но никто не любит. Любят мёд. Но мёд, как известно, странный предмет он есть лишь там, где тебя нет.

В чём же будни архитектора, помимо кофе и рисования? Ведь многие считают, что гнездо архитекторы вьют только из одноразовых стаканчиков в местах большого скопления whiteboard-ов. Конечно же в ловле личинок bug-ов! В первую очередь, конечно, интересуют ошибки проектирования. То есть свои же собственные промахи. До начала разработки архитектуру семь раз замеряли, но когда приходит время отрезать, выясняется, что попасть в метку тяжело, пила не та, то брус не тот. Все стройные теории начинают сползать с вакуумного глобуса. На этапе разработки первичной версии начинают выясняться все детали, которые попали в финальную версию контракта. Самые главные: дата и точный спектр функционала первого демо для клиента.

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

Ад у каждого свой. Мой похож на ежедневные диспуты с начальниками разных отделов, каждый из которых предлагает вместо твоей глупой инфраструктуры, давай сделаем анимированные кнопочки. Случалось же слышать: а юнит тесты точно нужно писать? А может можно как-то без них? или нам же сейчас не нужно это твоё скалкобилити, а красивый интерфейс это лицо продукта. Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с бетонной реальностью лучше приземлиться на пятую точку. Особенную нишу занимают вот тут 20 дней на безопасность выделено, нужно сделать за 10, чтоб ещё пару фишек втиснуить из бессмертной серии а семь шапок можешь?. Мне всегда сложно объяснить кому-то почему же 2+2 = 4. На сложные вещи аргументация всегда находится, а как объяснить то, что ты считаешь базовым, да еще и когда экспериментально доказать за 5 минут не получится.

Чтобы понизить градус ада приходиться заниматься презентациями, которые бы наглядно показали как у нас всё работает и почему. Хочется, конечно, Босха, но приходится сводить простые зарисовки со стрелочками. Анализировать бэклог, искать пересекающиеся требования и показывать, что кнопочки сейчас по затратам равны кнопочки завтра, а безопасность сейчас намного дешевле безопасность завтра. Строится цепочка требований ведущих или исходящих из кнопочки и такая же для требования безопасности. Так как бизнес-требования обычно не пересекаются, то цепочку таких требований легко двигать в плане вперёд и назад. А значит и цена будет неизменной. Инфраструктура же пронизывает все модули и цепочки, а значит если завтра будет в 10 раз больше модулей, то будет и в 10 раз больше интеграции/внедрения и проверок (важная статья расходов и времени). Кто бы мог подумать!? И обязательно гуглите что-то из серии цена ошибки безопасности в своём промышленном/деловом секторе. Для производства всегда хорошо работает пример Иранских центрифуг. В финтехе или ритейле примеров полным-полно. Хорошая страшилка лучше любых формул. Детей пугают сказкой про волка, а не расчётами семейного бюджета (хотя последнее может быть намного страшней).

Вот прошли вы семь кругов дневных совещаний и можно начинать работать. Ваша компания выиграла большой тендер в том числе и благодаря волшебной пыли, которой вы сдобрили своё видение решения в документах и диаграммах. Кто и как употребляет эту пыль не наша забота. Контракт подписан и пора её сдуть со всех чертежей. Под пылью много пустых мест, которые как раз сейчас время заполнять. Заполнять, конечно, можно с фантазией в начале всё легко исправить и цена ошибки минимальна. Поэтому я советую подключать к проектированию модулей инфраструктуры самих разработчиков. Если хорошему программеру выдать конечный результат в стиле сделай вот так, то он может и сделает, но осадочек то останется. Основные узлы строят специалисты и у них есть свое мнение, которое они хотят высказать не просто в стену, а чтоб их услышали. Это не плохо, но я люблю дело делать, а не говорить и слушать. Умел бы слушать и говорить играл бы в тиндеры, а не в тендеры. Да и мнение ключевых специалистов я уже выслушал, когда строил наброски и готовил решение. Теперь, когда всё утверждено и подписано, начинать с начало как минимум не практично.

Мой know-how в этом процессе направляемый мозговой штурм. У вас есть готовый вариант архитектуры модуля. В моём случае это значит, что определена модель (абстракции) и контракты (данные) и есть сопутствующая диаграмма взаимодействий или сущностей. Так вот эту диаграмму я начинаю строить с разработчиком, скармливая ему требования и проблемные аспекты так, чтоб он посмотрел в конце на моё решение и сказал классно мы с тобой придумали!. Ну ещё бы.

Работает это примерно так:

Нужен модуль, который получает пакет цифровых документов и мапит их в базу. Разработчик сразу предлагает какой-нибудь pub-sub, асинхронные (так почему-то 80% людей называют параллельные процессы) таски и пару микросервисов. Куда же без них.

Теперь надо подхватить его под руку и вести туда, куда хотите вы. Закидывается проблема и предлагается решение, которое у вас прописано в архитектуре. Как-то так: Хорошее решение, но если у нас будет асинхронный маппинг, то возникнут проблемы совместного доступа. А что, если вместо параллельности мы сделаем последовательность?.

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

За шага 3-4 мы уже достигаем желаемого результата. В отличии от варианта, когда вы просто объясняете почему стоит сделать именно так, вы не лишаете человека самого важного поиска решения. Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал за кем-то построчно. Если лишить его загадки, то работа может вызвать протест и кучу отрицательных эмоций. С другой стороны, он не знает всей картины. Ни того, что и как будут делать в других командах, ни того, что запланировано на полгода вперёд. В этом основная причина существования должности архитектора широкий и далекий взгляд на проект. Но ничего не получится, если ваша архитектура не обоснована требованиями. Нечем будет вести разработчика, да и незачем. В таком случае лучше честно партбилет на стол. У нас с этим строго. Это по утрам я Винни-Пух, а к концу дня я свинья с ружжом!

И стрелять всегда есть в кого. Пока все усердно пишут код нужно следить, что б всё неусерднулось. Тут на помощь нам всякие индикаторы и статические анализаторы кода. Делать метрики для программистов удел менеджеров. Я лично озабочен метриками кода. Индикаторы здоровья проекта:

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

• Длинные функции и классы не плохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.

• Сложность кода можно отследить по количеству юнит тестов при высоком покрытые. Много тестов значит много веток, а значит опять что-то попахивает.

• Нарушение конвенций тоже стоит заавтоматить и следить. Закладывается фундамент дома, в котором нам всем жить долго.

• Много статики (классов, методов, полей), обычно, проявления антипаттернов.

• И, конечно, проверки безопасности на вшитые пароли и вшивые референсы на какие-нибудь опенсорсы с уязвимостями или сложными лицензиями.

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

Для подготовки к следующему этапу необходимо выстроить хороший механизм логирования. Желательно на два уровня один с понятной историей для бизнеса, а второй для технического анализа, что же всё-таки навернулось. Когда со стадии демо мы шагнём, пусть и в ограниченный, но production, то там будут первые кострища и охота на ведьм. Наблюдать в полнолуние как кто-то седеющими руками набирает код прям в проде плохая примета. По возможности старайтесь избегать этого. Так что одним стримом пишем: пользователь ****341 запросил функцию Поиск Заказа с аргументом 3480-4341-1334. Результат: не найдено. На этот лог сядет саппорт, когда процесс встанет. А второй стрим со стеком, сервисами и всеми деталями (опять-таки, кроме тех, что нужно замазать ради безопасности или для сохранения личных и коммерческих секретов). Тут уже пойдут разработчики, когда процесс ляжет. Логи делать необходимо с самого начала. Они всегда нужны вчера, когда всё случилось, а вот завтра от них будет мало толку. Клиент как-то не любит слышать: У вас тут вчера производство встало, а мы не знаем почему. Но когда встанет в следующий раз у нас будет больше данных для анализа!. Хотя в некоторых компаниях лишь под угрозой штрафов начинают понимать, что стоило вложиться сразу в аудит и мониторинг да начинают чесать головы (те в которые едят и те на которых сидят).

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

Вступление

Это третья часть серии статей об архитектуре android приложения vivid.money. В ней мы расскажем об Elmslie - библиотеке для написания кода под android с использованияем ELM архитектуры. Мы назвали ее в честь Джорджа Эльмсли, шотландского архитектора. С сегодняшнего дня она доступна в open source. Это реализация TEA/ELM архитектуры на kotlin поддержкой android. В первой статье мы рассказали о том почему выбрали ELM. Перед прочтением этой статьи лучше ознакомиться как минимум со второй частью, в которой мы более подробно рассказывали том собственно такое ELM.

Оглавление

• Часть первая. Как мы выбрали архитектуру слоя представления на новом проекте и не прогадали.

• Часть вторая. Разбираем ELM архитектуру в рамках мобильного приложения.

• Часть третья. Пишем под android с Elmslie.

Что будем писать

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

Модель

Написание экрана проще начинать с проектирования моделей. Для каждого экрана нужны State, Effect, Command и Event. Рассмотрим каждый из них по очереди:

State

State описывает полное состояние экрана. В каждый момент времени по нему можно полностью восстановить то что сейчас показывается пользователю. Правильнее делать исключения, если это усложняет логику. Не нужно сохранять, показывается ли сейчас диалог на экране или что сейчас находится в каждом EditText.

На нашем экране будет отображаться либо числовое значение, либо состояние загрузки. Это можно задать двумя полями в классе: val isLoading: Boolean и val value: Int?. Для удобства изменения, State лучше реализовывать как data class. В итоге получается так:

data class State(  val isLoading: Boolean = false,  val value: Int? = null)

Effect

Каждый Effect описывает side-effect в работе экрана. То есть это события, связанные с UI, происходящие ровно один раз, причем только когда экран виден пользователю. Например, это могут быть навигация, показ диалога или отображение ошибки.

В нашем примере единственной командой UI будет показ Snackbar при ошибке загрузки value. Для этого заведем Effect ShowError. Для удобства Effect можно создавать как sealed class, чтобы не забыть обработать новые добавленные эффекты:

sealed class Effect {  object ShowError : Effect()}

Command

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

У нас будет одна операция - загрузить данные. Эту Command назовем LoadValue. Команды так же удобнее задавать как sealed class:

sealed class Command {  object LoadValue : Command()} 

Event

Все события, которые влияют на состояние и действия на экране: Ui: ЖЦ экрана, взаимодействие с пользователем, все что приходит из View слоя Internal: Результаты операций с бизнес логикой

Теперь перейдем к событиям. В нашем проекте мы разделяем события на две категории:

• Event.UI: все события, которые происходят во View слое

• Event.Internal: результаты выполнения команд в Actor.

В этом примере будет два UI события: Init - открытие экрана и ReloadClick - нажатие на кнопку обновления значение. Internal события тоже два: ValueLoadingSuccess - успешный результат Command LoadValue и ValueLoadingError, которое будет отправляться при ошибке загрузки значения.

Если использовать разделение на UI и Internal, то Event удобнее задавать как иерархию sealed class:

sealed class Event {  sealed class Ui : Event() {    object Init : Ui()    object ReloadClick : Ui()  }     sealed class Internal : Event() {    data class ValueLoadingSuccess(val value: Int) : Internal()    object ValueLoadingError : Internal()  }}

Реализуем Store

Закончив с моделями, перейдем собственно к написанию кода. Сам Store реализовывать не нужно, он предоставляется библиотекой классом ElmStore.

Repository

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

object ValueRepository {private val random = Random()fun getValue() = Single.timer(2, TimeUnit.SECONDS)    .map { random.nextInt() }    .doOnSuccess { if (it % 3 == 0) error("Simulate unexpected error") }}

Actor

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

Для его создания нужно реализовать интерфейс Actor, который предоставляется библиотекой. Actor получает на вход Command, а результатом его работы должен быть Observable<Event>, с событиями, которые сразу будут отправлены в Reducer. Для удобства в библиотеке есть функции mapEvents, mapSuccessEvent, mapErrorEvent и ignoreEvents, которые позволяют преобразовать данные в Event.

В нашем случае Actor будет выполнять только одну команду. При выполнении команды загрузки мы будем обращаться к репозиторию. В случае получения успешного значения будет оправляться событие ValueLoaded, а при ошибке ErrorLoadingValue. B итоге получается такая реализация:

class Actor : Actor<Command, Event> {override fun execute(command: Command): Observable&lt;Event&gt; = when (command) {    is Command.LoadNewValue -&gt; ValueRepository.getValue()        .mapEvents(Internal::ValueLoaded, Internal.ErrorLoadingValue)}}

Reducer

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

В этом классе нужно реализовать функцию reduce для обработки событий. Помимо вашей логики в Reducer можно использовать 3 функции:

• state - позволяет изменить состояние экрана

• effects - отправляет эффект во View

• commands - запускает команду в Actor

class Reducer : DslReducer<Event, State, Effect, Command>() {override fun Result.reducer(event: Event) = when (event) {    is Internal.ValueLoaded -&gt; {        state { copy(isLoading = false, value = event.value) }    }    is Internal.ErrorLoadingValue -&gt; {        state { copy(isLoading = false) }        effects { +Effect.ShowError }    }    is Ui.Init -&gt; {        state { copy(isLoading = true) }        commands { +Command.LoadNewValue }    }    is Ui.ClickReload -&gt; {        state { copy(isLoading = true, value = null) }        commands { +Command.LoadNewValue }    }}}

Собираем Store

После того как написаны все компоненты нужно создать сам Store:

fun storeFactory() = ElmStore(    initialState = State(),    reducer = MyReducer(),    actor = MyActor()).start()

Экран

Для написания android приложений в elmslie есть отдельный модуль elmslie-android, в котором предоставляются классы ElmFragment и ElmAсtivity. Они упрощают использование библиотеки и имеют схожий вид. В них нужно реализовать несколько методов:

• val initEvent: Event - событие инициализации экрана

• fun createStore(): Store - создает Store

• fun render(state: State) - отрисовывает State на экране

• fun handleEffect(effect: Effect) - обрабатывает side Effect

В нашем примере получается такая реализация:

class MainActivity : ElmActivity<Event, Effect, State>() {override val initEvent: Event = Event.Ui.Initoverride fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    setContentView(R.layout.activity_main)    findViewById&lt;Button&gt;(R.id.reload).setOnClickListener {        store.accept(Event.Ui.ClickReload)     }}override fun createStore() = storeFactory()override fun render(state: State) {    findViewById&lt;TextView&gt;(R.id.currentValue).text = when {        state.isLoading -&gt; &quot;Loading...&quot;        state.value == null -&gt; &quot;Value = Unknown&quot;        else -&gt; &quot;Value = ${state.value}&quot;    }}override fun handleEffect(effect: Effect) = when (effect) {    Effect.ShowError -&gt; Snackbar        .make(findViewById(R.id.content), &quot;Error!&quot;, Snackbar.LENGTH_SHORT)        .show()}}

Заключение

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

Эта серия статей вольный и очень краткий пересказ книги Роберта Мартина (Дяди Боба) Чистая Архитектура, выпущенной в 2018 году. Начало тут.

Парадигмы программирования

Дисциплину, которая в дальнейшем стала называться программированием, зародил Алан Тьюринг в 1938 году. В 1945 он уже писал полноценные программы, которые работали на реальном железе.

Первый компилятор был придуман в 1951 году Грейс Хоппер (бабушка с татуировкой Кобола). Потом начали создаваться языки программирования.

Обзор парадигм

Существует три основных парадигмы: структурное, объектно-ориентированное и функциональное. Интересно, что сначала было открыто функциональное, потом объектно-ориентированное, и только потом структурное программирование, но применяться повсеместно на практике они стали в обратном порядке.

Структурное программирование было открыто Дейкстрой в 1968 году. Он понял, что goto это зло, и программы должны строиться из трёх базовых структур: последовательности, ветвления и цикла.

Объектно-ориентированное программирование было открыто в 1966 году.

Функциональное программирование открыто в 1936 году, когда Чёрч придумал лямбда-исчисление. Первый функциональный язык LISP был создан в 1958 году Джоном МакКарти.

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

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

Структурное программирование

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

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

С тех пор оператора goto не стало практически ни в одном языке программирования.

Таким образом, структурное программирование позволяет делать функциональную декомпозицию.

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

Объектно-ориентированное программирование

ООП это парадигма, которая характеризуется наличием инкапсуляции, наследования и полиморфизма.

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

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

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

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

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

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

Любая зависимость всегда может быть инвертирована. В этом и есть мощь ООП.

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

Функциональное программирование

В основу функционального программирования лежит запрет на изменение переменных. Если переменная однажды проинициализирована, её значение так и остаётся неизменным.

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

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

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

Заключение

Таким образом, каждая из трёх парадигм ограничивает нас в чём-то:

• Структурное отнимает у нас возможность вставить goto где угодно.

• ООП не позволяет нам доступаться до скрытых членов классов и навязывает нам инверсию зависимостей.

• ФП запрещает изменять переменные.

Продолжение следует...

Эта серия статей вольный и очень краткий пересказ книги Роберта Мартина (Дяди Боба) Чистая Архитектура, выпущенной в 2018 году.Предыдущая часть здесь.

Принципы дизайна

Принципы SOLID говорят нам, как нам соединять наши функции и данные в классы, и как эти классы должны быть взаимосвязаны. То есть эти принципы относятся к уровню модулей (mid-level). Однако они также применимы и к уровню компонентов (high-level архитектура).

Принципы SOLID зародились в конце 80-х и стабилизировались в начале 2000-х.

SRP: Принцип единственной ответственности

Исторически этот принцип был сформулирован так: модуль должен иметь одну и только одну причину для изменения.

Однако Дядя Боб предлагает другую, более точную формулировку: модуль должен быть ответственным за одного и только за одного актёра.

Модуль это некоторое связанное множество функций и структур данных.

Пример нарушения принципа: класс Employee с тремя методами calculatePay(), reportHours(), save(). Все эти три метода относятся к разным актёрам. calculatePay() это бухгалтерия, reportHours() это отдел кадров, save() это администратор базы данных. Если один из актёров просит внести изменения в свой метод, то это может сломать логику других методов. Также это вносит трудности при слиянии изменений от разных актёров.

Решение проблемы вынести функции в отдельные классы. В каждом классе будут только та логика, которая относится к соответствующему актёру.

OCP: Принцип открытости/закрытости

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

Простыми словами: артефакт должен быть расширяемым без необходимости изменения его кода.

Этот принцип очень важен для архитектурных компонент.

Пример: финансовый отчёт умеет отображаться на веб-странице. Теперь клиент просит печатать его на чёрно-белом принтере. Если OCP выполняется, то доля кода, которого придётся изменить, будет близка к нулю. Чтобы этого достичь, компонент представления отчётов должен быть защищённым от изменения, а для этого он должен зависеть не от конкретной реализации это представления, а от интерфейса. Далее конкретные компоненты будут добавляться путём расширения, т.е. имплементации интерфейса.

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

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

LSP: Принцип подстановки Лисков

Принцип замещения: если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких-либо изменений желательных свойств этой программы.

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

Пример нарушения LSP: классическая проблема квадрата/прямоугольника.

Пример более высокоуровневого нарушения LSP: агрегатор сервисов такси, где в одном из сервисов название одного из параметров REST-запроса отличается от остальных. Тогда добавление этого сервиса приведёт к нарушению работы всего агрегатора. Эту проблему можно решить, например, путём вынесения маппинга параметров во внешнюю БД.

ISP: Принцип разделения интерфейса

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

Толстые интерфейсы нужно разделять на более мелкие, чтобы сущности знали только о тех методах, которые необходимы им в работе.

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

DIP: Принцип инверсии зависимостей

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

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

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

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

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

Как создавать инстансы конкретных классов, если мы не можем от них зависеть? Для этого есть несколько решений:

• Шаблон Абстрактная Фабрика

• Контейнеры, которые сами внедряют зависимости (XML, аннотации)

• Сервисы

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

Продолжение следует...

Не всегда более производительное решение - решение, требующее меньше ресурсов при своей работе, - является лучшим. Часто сопутствующие факторы являются более значимыми: предсказуемость поведения при сбоях, скорость восстановления работоспособности после сбоев и т.п. Рассмотрим это на примере систем межсервисного взаимодействия.

• Курьер доставил заказ. По смене статуса заказа надо уведомить заинтересованные стороны об этих событиях.

• Клиент отправляет сообщение в чат поддержки. Нужно уведомить сервисы поддержки о поступивших данных от клиента.

• Построение отчёта завершено. Ожидающий отчёт пользователь может его загрузить. Надо его уведомить об этом.

Знакомые/типовые ситуации. Одному сервису надо уведомить другой (другие) о происшедших событиях.

Давайте немного усложним:

Сервер - находится в нашей юрисдикции. Мы следим за тем, чтоб ресурсов ему на всё хватало. Добавляем ноды в кластер и т.п.

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

Какие способы уведомления есть?

Активность со стороны сервера

Это, в общем-то, типовое решение. Сервер держит список заинтересованных сторон. По мере появления событий выполняет HTTP-запросы к клиентам.

Подвариант этого решения: Websocket. Сервер отправляет события в сокеты всем подписанным сторонам.

Повторы, обработка ошибок

Рано или поздно любой TCP/HTTP-канал сталкивается с недоступностью другой стороны. Что делать после возникновения ошибки? Повторять запросы? Что делать с вновь поступающими запросами? Ждать, пока успешно выполнятся предыдущие?

Рассмотрим виды ошибок:

1. Сетевые

2. Устранимые (после повтора могут исчезнуть) HTTP (500, 502, 504, и т.п.)

3. Неустранимые (4xx)

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

Идя по этому пути, надо постоянно и внимательно следить за мониторами таких ошибок. Анализировать трафик на тему "почему возникла неустранимая ошибка?" и "можно ли жить дальше с этой ошибкой".

Но это не самая большая проблема.

Более интересными являются проблемы:

• повторов

• 500-х ошибок

500-е ошибки

Мы выполняем запрос-передачу данных для сервера X. Происходит 500-я ошибка. Что это?

Возможны два варианта:

1. Сервис-приёмник данных по какой-то причине именно сейчас не работает (перегружается, переключается БД итп). В этом случае повтор запроса в дальнейшем приведёт нас к успеху.

2. В сервисе допущена ошибка, приводящая к 500. В этом случае, сколько бы повторов мы ни сделали, до исправления кода в приёмнике ситуация не изменится.

То есть, по повторяемости запросов ошибки у нас делятся на три вида:

1. Те, которым повтор поможет (сетевые, устранимые 500-ки).

2. Те, которым повтор не поможет, но выглядят как те, которым поможет (неустранимые 500-ки).

3. Те, которым повтор не поможет (например 40x-ки).

Разрабатывая политику повторов, помимо указанной проблемы, имеем ещё множество других проблем:

1. Как часто повторять запросы?

2. Не будем ли мы "укладывать" внешний сервис, повторяя запросы?

3. Не будем ли сами "укладываться", если одна из внешних систем по какой-то причине имеет некорректный TCP-стек (iptables DROP)?

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

Подытожим:

Если сервис, генерирующий событие, и занимается доставкой его до заинтересованных сторон, то имеем

плюсы:

• минимальный лаг доставки

• минимальная нагрузка на хранилище сообщений;

минусы:

• необходимость повторов в случае неуспеха доставок

• необходимость ведения реестра, кому что доставлено и кому что нужно доставить

• двусмысленность некоторых ошибок: непонятно, можно (нужно) ли повторять, или нет

• зависимость от стека TCP на стороне клиентов (iptables -j DROP занимает слот отправки вплоть до таймаута)

• система повторов может быть причиной DDoS для клиентских сервисов.

Также есть некоторое количество организационных минусов:

• После того, как клиент прекратил де-факто работу (тут два варианта: сервера выключены, сервера не выключены), система продолжает доставлять ему уведомления.

Вебсокет в режиме клиент-сервер

Часть описанных проблем решает постоянное соединение, инициируемое клиентом. Однако именно часть.

Необходимость повторов и двусмысленность ошибок - снимаются. Однако, необходимость ведения реестра, кому и что нужно доставить (если мы говорим о системе сообщений "без потерь") остаётся. Зависимость от стека TCP на стороне клиента снижается, но не до нуля. Система также может быть причиной DDoS для клиентских сервисов.

Пулинг

Достоинства пулинга

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

• После того, как клиент отключается (организационный момент), - он перестаёт делать запросы

• Максимально быстрое восстановление работоспособности после факапов.

Недостатки пулинга

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

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

Ещё один неочевидный, организационный недостаток пулинга: часто способ получения новой порции данных связан со структурой хранения данных.

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

• отсутствие двусмысленности, описанной выше

• наиболее быстрое восстановление работоспособности после сбоя

• максимальная независимость от сетевого стека TCP на клиенте

• нет необходимости хранить/майнтенить список клиентов.

Лаг доставки

Для чего вводят интервал пулинга? Каждый клиент, делающий 1 запрос за данными в секунду, - это 1RPS нагрузки. Почему нельзя пулить, не используя интервал (делать запрос сразу после получения результатов предыдущего)? Потому что обычно запрос за данными является сравнительно дорогим. А дорогим он является потому, что, как правило, некорректно спроектирован.

Как правило, запросы для пулинга формулируются как "есть ли данные для меня; если есть, то какие?". Такие запросы (в случае, если они некорректно спроектированы) зачастую имеют следующие проблемы:

• запрос неиндексирован

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

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

А сейчас давайте рассмотрим алгоритм работы традиционного пулера.

1. Первичная инциализация пулера. index := 0. index - это обобщённая переменная, указывающая на позицию запрашиваемых данных.

2. Выполняется запрос limit данных с позиции index.

3. Обрабатываем полученные данные

4. index := index + 1

5. Пауза соответствующая интервалу

6. Перейти к шагу 2

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

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

Почему разработчик попадает в такую ситуацию? Потому что проектирует БД и API отдельно друг от друга. А нужно посмотреть на все компоненты в целом и на влияние их друг на друга.

Проблема состоит в том, что в БД, как правило, данные хранятся в виде плоских таблиц. Когда мы получаем очередную порцию данных с одними и теми же условиями фильтрации, то приходится делать что-то вроде следующего:

SELECT    *FROM    "table"WHERE    "somefield" = $1LIMIT    100OFFSET    $2

То есть, index из алгоритма пересчитывается в смещение ($2). Такой запрос из БД имеет всё более ухудшающийся план выполнения по мере роста смещения (которое растёт с ростом index).

Как сделать план независящим от положения смещения? Использовать вместо смещения выборку из индекса:

SELECT    *FROM    "table"WHERE    "id" > $1ORDER BY    "id"LIMIT    100

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

1. Первичная инициализация. index := 0

2. Выполняем запрос limit данных, передавая в запрос index

3. Вычисляем новое значение index, как максимум от id в ответе

4. Обрабатываем данные

5. Пауза, соответствующая интервалу

6. Перейти к шагу 2

В системе с такой архитектурой, как правило, уже нет существенных препятствий к снижению интервала до минимальных значений (вплоть до нуля).

Но давайте ещё порефлексируем над архитектурой. Что плохого в ней?

• Алгоритм привязан к структуре данных

• Выполняется практически полностью на стороне клиента

• Вследствие предыдущей проблемы сложно, например, централизованно модифицировать его на иную работу после факапов/проблем.

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

Давайте ещё раз модифицируем алгоритм. Заменим index на state и управлять им будем с сервера:

1. Первичная инициализация. state := null.

2. Выполняем запрос limit данных, передавая в запрос значение state

3. В каждом ответе, помимо данных, сервер возвращает new_state. state := new_state

4. Обрабатываем данные

5. Пауза-интервал

6. Перейти к шагу 2

Что мы получили? Гибкость.

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

• При желании можем ограничить возможности пользователя "хачить" запросы (использовать другие значения index, помните выше мы об этом говорили?). Этого можно достичь, например криптоподписывая state.

Если в переменной state хранится не только позиция окна, а, например, и значения фильтров и криптоподпись, то эту переменную имеет смысл называть курсором. Переименуем переменную ещё раз и избавимся от постоянных задержек:

1. Первичная инициализация. cursor := null, filters = значения_фильтров.

2. Выполняем запрос limit данных, передавая в запрос значение cursor, filters.

3. В каждом ответе, помимо данных, сервер возвращает cursor. cursor := response.cursor

4. Обрабатываем данные

5. Если данные были, перейти к шагу 2

6. Пауза-интервал

7. Перейти к шагу 2

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

Рекомендации по работе с курсорами:

• Поскольку хранением курсора между запросами озадачен клиент, то имеет смысл хранить в курсоре и версию ПО сервера. В этом случае можно написать дополнительный код, обеспечивающий обратную совместимость (конвертацию форматов курсоров).

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

• Во избежание введения в соблазн пользователей использовать в своём коде какие-то данные из курсора, лучше не использовать человекочитаемую строку в значении курсора. JSON, пропущенный через base64-кодирование (и криптоподписанный) подходит идеально.

Пример. Изменение алгоритма после сбоя.

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

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

То есть, limit делим, например, пополам. Половину limit'а заполняем данными из обычного курсора. А во второй половине начинаем передавать данные, начиная от id, с небольшим отставанием.

Таким образом, пользователи, запросившие отчёт прямо во время факапа, продолжат его ждать (и дождутся). А пользователи, запросившие отчёт после факапа, получат его с небольшой задержкой.

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

Пофантазировав, схему можно дополнить не одним, а несколькими фолбеками.

Курсорная репликация

Описанные курсоры можно использовать для репликации данных с сервиса на сервис.

Часто один сервис должен иметь у себя кеш/реплику части данных другого сервиса. При этом требований синхронности к этой реплике нет. Поменялись данные в сервисе A. Они должны максимально быстро поменяться и в сервисе B.

Например, мы хотим реплицировать табицу пользователей с сервиса на сервис.

Для такой репликации можно использовать что-то готовое из инструментария баз данных, а можно сделать небольшой "велосипед". Предположим, что пользователи хранятся в БД PostgreSQL. Тогда делаем следующее:

• создаём дополнительный столбик SERIAL/BIGSERIAL в таблице users, назовём его lsn (Last sequence number).

• модифицируем изменяющие пользователей запросы, чтобы на каждое изменение записи пользователя значение lsn устанавливалось бы из растущей последовательности

• строим по полю lsn (уникальный) BTREE индекс.

В этом случае обновление записи пользователя будет выглядеть примерно так:

UPDATE   "users"SET   "name" = $1,   ...   "lsn" = DEFAULT /* последовательность */WHERE   "user_id" = $21

А запрос для работы курсора будет выглядеть как-то так:

SELECT    *FROM    "users"WHERE    "lsn" > $1ORDER BY    "lsn"LIMIT    $2

Каждое обновление пользовательской записи будет перемещать её в конец списка lsn. При этом общий размер отставания никогда не превысит размер таблицы пользователей.

Итоги

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

2. При этом проблемы доступности клиентов, настроек, работоспособности TCP-стека останутся у клиентов

3. Максимально быстрое и простое восстановление после простоя/сбоев. Отсутствие двусмысленностей в кодах ошибок.

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

Ты только посмотри, какие спикеры нам в этом помогут!

Михаил Беляев из Прософт-Системы с докладом Проблемы embedded или как мы от sqlite ушли

При embedded разработке существует очень большая проблема весьма ограниченные ресурсы устройства, на котором выполняется твой код. В ходе разработки, когда запросы клиентов растут, а ресурсы embedded устройства на исходе, очень часто стандартные и проверенные решения не подходят. Разработчик сталкивается с выбором: или сказать, что наше устройство не может справиться с требуемыми задачами, или сделать нестандартный ход и выиграть. Вот именно об этом процессе перехода от использования SQLite к собственному хранилищу данных, которое позволяет читать и писать данные значительно быстрее, Михаил поведает другим разработчикам.

Андрей Цветцих из EPAM представит доклад Чистая Архитектура на практике. Вот что он рассказал нам о своем выступлении:

С момента выхода книги Дяди Боба Clean Architecture прошло уже достаточно времени. Кто-то ее прочитал, а кто-то только смотрел доклады на youtube. Но все эти доклады идейные. У их авторов обычно нет практического опыта создания больших проектов по данной архитектуре (как и запуска этих проектов в production). А все примеры слишком простые! На практике все равно остается много вопросов. Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Это корпоративные приложения на C# (API, backend). Enterprise, который еще не успел стать кровавым :) Но этого вполне достаточно чтобы получить первые результаты и поделиться опытом.

Роман Неволин из Контура выступит с докладом про Функциональные языки для бизнес-разработки

Функциональные языки зачастую воспринимаются как красивые и модные игрушки посмотреть и повертеть забавно, а вот в суровом энтерпрайзе им не место. Принято считать, что здесь лучше всего подходят проверенные годами, простые и надежные языки, такие как Java. Роман же с этим согласиться никак не может и постоянно пытается применить любимый функциональный язык F# - к очередной бизнес-задаче. На выступлении обсудим, как Роман это делает, зачем оно ему (и всем остальным) нужно, и какие именно грабли он успел собрать на пути.

Кстати, Романа можно будет услышать в нашем бесплатном стриме, о котором мы подробно рассказали здесь.

Евгений Пешков из JetBrains с докладом Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler

На первый взгляд кажется, что отправить HTTP запрос это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален RFC на него содержит более 150 страниц, кроме того браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же провальными и явно временными.

В докладе Евгений расскажет о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберет некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.

Александр Поляков из Яндекса расскажет Как Яндекс.Афиша 2 раза переезжала на GraphQL

Этот доклад о том, как мы переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

Разберемся со следующими вопросами:

почему мы выбрали технологию GraphQL

какие проблемы и задачи решали с ее помощью

расскажем и покажем, как эволюционировала наша архитектура

для каких команд и проектов подходит наше решение, а для каких нет и почему

А также дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL

Фагим Садыков из SpectrumData представит нам свой доклад Kotlin как основной язык разработки бэкенда и обработки данных

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

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда. История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1. Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

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

Про Аспектно-ориентированное программирование на C# и .NET вчера, сегодня и завтра расскажет Денис Цветцих из Invent

Аспектно-ориентированное программирование (АОП) позволяет без дублирования кода добавлять инфраструктурный функционал вроде кеширования и логгирования на разные слои вашего приложения. И все это не меняя уже написанный код! Это очень мощная, удобная а также редко используемая техника. Отчасти это оправдано, 10 лет назад инструменты для реализации аспектов были не развиты, поэтому за АОП закрепилась слава подхода, используемого только энтузиастами. Но с тех пор мир изменился и сегодня АОП можно увидеть даже в веб-фреймворках, важно только уметь его распознать.

В своем докладе Денис поделится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой. Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.

А под занавес программный комитет поставил Антона Шишкина из SKB LAB с докладом Рекомендации и фичи первой свежести . Здесь Антон расскажет про свой опыт построения рекомендательной системы от offline расчетов до online. И отдельно про то, как обеспечивается актуальность фичей для онлайн расчетов. Будут разобраны "допущения", благодаря которым фичи сохраняют свою "свежесть", при этом обеспечивается высокая доступность хранилища признаков.

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

А здесь можно выбрать билеты в онлайн и офлайн формате.

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

О подводных камнях такого пути поговорим в этой статье.

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

• Заказ выполнен, нужно отправить СМС-уведомление пользователю.

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

• Работа выполнена, нужно списать деньги со счёта клиента.

Во всех перечисленных примерах изменения в какой-то бизнес-сущности фиксируются в БД (или сервисе с БД), и возникает большой соблазн соблазн отправлять уведомления с использованием очередей.

Что мы имеем в данной ситуации? Первоначальная, простейшая структура кода:

• Сервис (наша программа) фиксирует изменение данных в БД.

• Затем сервис кладёт задание в очередь.

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

И в общем случае, получается, здесь мы имеем две записи в две различные БД: сервиса и очереди.

Теперь перенесёмся в реальный мир и рассмотрим, какие ситуации могут возникнуть:

• Всё в порядке. БД доступна, БД очереди доступна;

• БД недоступна, БД очереди доступна;

• БД доступна, БД очереди недоступна;

• БД недоступна, БД очереди недоступна.

Наиболее опасен для бизнеспроцессов тут третий случай: после того, как данные были зафиксированы в БД, уведомить заинтересованные стороны не получилось.

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

Но со сложными решениями всё понятно, давайте подумаем о более простых.

Неправильные решения

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

1. Открываем транзакцию в БД.

2. Изменяем запись в БД.

3. Записываем в очередь.

4. Закрываем транзакцию в БД.

В этом случае, если одна из БД недоступна, то и в другую запись не запишется.

Однако тут имеются следующие проблемы:

• Данное решение условно работоспособно только в том случае, если обработчик очереди никогда не будет обращаться к записи в БД. Поскольку обработчик очереди может взять задачу на исполнение между пунктами 3 и 4 (Записи в БД ещё не зафиксированы).

• Закрытие транзакции также может завершиться с ошибкой. В этом случае задание в очереди останется неотменённым.

Выполнение всей работы в обработчике

Простейшее решение.

Вместо изменения записи кладём в очередь задание о том, что надо это сделать. Обработчик очереди выполняет оба действия: и изменения записи в БД, и триггерное. Это решение сложнее, чем первоначальное, но всё равно довольно простое.

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

Дополнительная таблица в БД

Более простое решение, нежели двухфазный коммит.

В игре у нас появляется дополнительный процесс/демон, перекладывающий задачи из дополнительной таблицы БД (назовём её queue) в очередь.

В этом случае запросы, модифицирующие БД, пишут записи в две таблицы в той же транзакции (или в том же запросе):

/* было */UPDATE   "orders"SET   "status" = 'complete'WHERE   "order_id" = $1RETURNING   *

/* стало */WITH "o" AS (    UPDATE       "orders"    SET       "status" = 'complete'    WHERE       "order_id" = $1    RETURNING       *),"q" AS (   INSERT INTO        "queue"   (      "key",      "data"   )   SELECT      "o.order_id",      "o.status"   FROM      "o")SELECT   *FROM   "o"

Примечание: Код записи в таблицу queue можно вынести в триггер уровня БД, а также спроектировать так, чтобы сообщения были универсальными и подходили не только для orders.

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

Простейший алгоритм цикла демона:

• Взять задачу из таблицы queue.

• Положить её в очередь.

• Удалить задачу в таблице.

Локальный лог/кеш сообщений

Если потеря данных для нас только неприятна, но не критична, то в целом можно ограничиться первоначальным решением. Однако, если частота возникающих проблем всё-таки заставляет обратить на себя внимание (пользователи жалуются на периодически зависающий интерфейс, на неполучение СМС и т.п.), то можно применить следующий подход:

• резко понизить вероятность неуспеха при отправке сообщения в очередь.

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

• сервис (наша программа) фиксирует изменение данных в БД,

• затем сервис кладёт задание в локальный лог.

• Дополнительный демон перекладывает сообщения из этого лога (или локальной очереди) в общую очередь.

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

Итоги

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

А обобщённое решение предполагает использование двухфазного коммита.

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

Что лучше: монолит или микросервис?

Рассмотрим пример.

Допустим, у нас есть микросервис A, выполняющий авторизационные запросы "имеет ли право пользователь выполнить операцию?".

Поскольку изолированно такой микросервис существовать не может, то в паре с ним существует другой микросервис B, который сохраняет в хранилище список соответствий пользователи-права (Фактически это структура одного микросервиса, разделённого на два, чтоб распределить нагрузку по логическим подмодулям. То есть деление даже более мелкое, нежели обычные микросервисы).

Примерная схема микросервисов показана на рисунке:

В результате изменений в пользовательских данных (регистрация новых пользователей, ограничения на существующих и т.п.) микросервис B "следит" за актуальностью данных в хранилище, которое использует микросервис A для выполнения авторизационных запросов.

Простая схема. Просто устроена, надёжно работает.

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

• нагрузка на CPU в микросервисе A

• нагрузка io-read/select в БД

• нагрузка на CPU в микросервисе B

• нагрузка io-write в БД

Вопросы с CPU в микросервисах решаются просто добавлением экземпляров в игру. Здесь масштабирование простое, и не стоит его обсуждать:

Давайте посмотрим, что будет с ростом нагрузки на микросервис A и B?

В определённый момент времени БД перестанет справляться с потоком запросов на чтение от микросервиса A. При наступлении этих проблем обычно вводят в игру RO-реплики БД:

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

Но вот вопрос: а что делать, когда микросервис B приведёт master-БД к лимиту, определённому максимумом нагрузки на запись (io-write)?

Вариантов решения этих проблем довольно немного. Все они сводятся к тому, чтоб распределить запись в БД по нескольким хостам. Используем схему шардинга или иной масштабируемый multi-master:

Вместо одной БД у нас имеется X шардов БД, позволяющих масштабировать нагрузку на запись, и к каждому шарду - реплики (всего - Y), позволяющие масштабировать нагрузку на чтение.

Итого:

По мере роста нагрузки в нашем примере сами микросервисы претерпели немного изменений. Большинство изменений при масштабировании было в хранилище данных.

Если рассмотреть более обобщённо, то при масштабировании микросервисная архитектура сталкивается со следующими проблемами масштабирования:

1. Ограничения CPU на хостах

2. Ограничения IO в хранилищах данных

3. Ограничения пропускной способности сети между хостами

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

Выводы

1. Микросервисная архитектура не является способом масштабирования проекта. Микросервисная архитектура - это способ разделения проекта на модули и инкапсуляции кода (и данных).

2. Основу масштабирования практически любого большого проекта следует искать в области хранения и обработки хранящихся данных.

Монолиты и микросервисы: граница

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

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

Если один и тот же код, не будучи выделен в библиотеку, работает во множестве микросервисов, то это - монолитная архитектура.

Построение проектов с нуля: Монолит vs микросервис

Если не рассматривать вновь запускаемые проекты на лямбдах/FaaS, то можно отметить одну чуть ли не во всех проектах встречающуюся особенность:

Как правило, проект на стадии запуска реализации и на стадии запуска MVP отличается довольно сильно. Видение бизнес-развития проекта в стадии после MVP отличается от стартового ещё сильнее. И, чем больше времени проект развивается, тем сильнее эти отличия.

Бизнес-требования к стартующему проекту обычно меняются прямо в процессе реализации его MVP. Да, это не для всех случаев так, но для огромного пула стартапов это именно так.

Что из этого следует? Из этого следует эмпирическое правило: для запуска стартапов необходимо выбирать технологии, исходя из критериев:

• в дальнейшем понятно, как масштабировать (в основном, это относится к хранилищу)

• сравнительно просто рефакторить (это относится к выбору технологии построения кода)

• простое покрытие автоматическими тестами

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

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

Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб.

С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?

Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.

Недавно я получил письмо с примерно следующими соображениями:

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

Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - Пишите простой код

В ответ я написал следующее письмо.

Принципы SOLID сегодня остаются такими же актуальными, как они были 20 лет назад (и до этого). Потому что программное обеспечение не особо изменилось за все эти годы, а это в свою очередь следствие того, что программное обеспечение не особо изменилось с 1945 года, когда Тьюринг написал первые строки кода для электронного компьютера. Программное обеспечение - это все еще операторы if, циклы while и операции присваивания - Последовательность, Выбор, Итерация.

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

Итак, пройдемся по принципам по порядку.

SRP - Single Responsibility Principle Принцип единственной ответственности.

Объединяйте вещи, изменяющиеся по одним причинам. Разделяйте вещи, изменяющиеся по разным причинам.

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

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

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

OSP - Open-Closed Principle Принцип открытости-закрытости

Модуль должен быть открытым для расширения, но закрытым для изменения.

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

Или... хотим ли мы отделить абстрактные понятия от деталей реализации? Хотим ли мы изолировать бизнес-правила от надоедливых мелких деталей графического интерфейса, протоколов связи микросервисов и тонкостей поведения различных баз данных? Конечно хотим!

И снова слайд Дэна преподносит это совершенно неправильно.

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

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

LSP - Liskov Substitution Principle Принцип подстановки Лисков

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

Люди (включая меня) допустили ошибку, полагая что речь идет о наследовании. Это не так. Речь о подтипах. Все реализации интерфейсов являются подтипами интерфейса, в том числе при утиной типизации. Каждый пользователь базового интерфейса, объявлен этот интерфейс или подразумевается, должен согласиться с его смыслом. Если реализация сбивает с толку пользователя базового типа, то будут множиться операторы if/switch.

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

Слайды Дэна по этой теме полностью верны, он просто упустил суть принципа. Простой код - это код, который поддерживает четкие отношения подтипов.

ISP - Interface Segregation Principle Принцип разделения интерфейса

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

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

Проблема особенно остро стоит в статически типизированных языках, таких как Java, C#, C++, GO, Swift и т.д. Динамически типизированные языки страдают гораздо меньше, но тоже не застрахованы от этого - существование Maven и Leiningen тому доказательство.

Слайд Дэна на эту тему ошибочен.

(Примечание. На слайде Ден обесценивает утверждение Клиенты не должны зависеть от методов, которые они не используют фразой Это же и так правда!!)

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

(Примечание. Речь о фразе Если классу нужно много интерфейсов - упрощайте класс!)

Да, если вы можете разбить класс с двумя интерфейсами на два отдельных класса, то это хорошая идея (SRP). Но такое разделение часто недостижимо и даже нежелательно.

DIP - Dependency Inversion Principle Принцип инверсии зависимостей

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

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

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

Лучший способ создать путаницу - сказать всем будьте проще и не дать никаких дальнейших инструкций.

Ссылка на статью в моем блоге

Тропические леса и фикусы-душители

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

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

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

Рефакторинг сервиса приложения доставки продуктов

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

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

Допустим имеются следующие действия, которые у нас хранятся в одной таблице:

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

• Можно оформитьвозврат товара. Если вам не понравился кефир - вы оформляете возврат и вам возвращают его цену.

• Можносписать бонусысо счета. В таком случае часть стоимости оплачивается этими бонусами.

• Начисляются бонусы. Каким-либо алгоритмом нам не важно каким конкретно.

• Также заказ может бытьзарегистрирован в некотором приложении-партнере(ExternalOrder)

Все перечисленная информация по заказам и пользователям хранится в таблице (пусть она будет называтьсяOrderHistory):

Логика такой организации данных вполне справедлива на раннем этапе разработки системы. Ведь наверняка пользователь может посмотреть историю своих действий. Где он одним списком видит что он заказывал, как начислялись и списывались бонусы. В таком случае мы просто выводим записи, относящиеся к нему за указанный диапазон. Организовать в виде одной таблицы банальная экономия на создании дополнительных таблиц, их поддержании. Однако, по мере роста бизнес-логики и добавления новых типов операций число столбцов с null значениями начало расти. Записей в таблице сотни миллионов. Причем распределены они очень неравномерно. В основном это операции открытия и закрытия заказов. Но вот операции начисления бонусов составляют 0.1% от общего числа, однако эти записи используются при расчете новых бонусов, что происходит регулярно.В итоге логика расчета бонусов работает медленнее, чем если бы эти записи хранились в отдельной таблице. Ну и расширять таблицу новыми столбцами не хотелось бы в дальнейшем. Кроме того заказы в закрытом статусе с датой создания более 2 месяцев для бизнес-логики интереса не представляют. Они нужны только для отчетов не более.

И вот возникает идея.Разделить таблицу на две, три или даже больше.

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

Изменение структуры хранения в три этапа

Предположим, что наше legacy монолитное приложение хоть и плохое, но не совсем. Как минимум зарезервировано. То есть работает как минимум два экземпляра. Так, что при падении одного из них - второй продолжит обслуживать пользователей:

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

Оба экземпляра работают с одной базой данных. Реализуя паттернShared Database.

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

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

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

BonusOperations:

Отдельную таблицу для данных из внешних систем -ExternalOrders:

Для операций с заказами моложе, чем 2 недели (предположим, что ограничение бизнес-логики было как раз определено на это уровне. Ведь если заказ был произведен более двух недель назад его нельзя отменить, изменить и прочее) новая таблицаOrderHistoryс уменьшеным числом столбцов.

Для оставшихся типов записей -OrderHistoryArchive(старше 2х недель). Где теперь также можно удалить несколько лишних столбцов.

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

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

Монолит версии 1 и монолит версии 2 вполне могут работать совместно. Лишь для тех запросов, которые обрабатывались монолитом версии 1 в новой базе данных будут пробелы. Эти пробелы, а также недостающие данные можно будет в дальнейшем скопировать отдельным скриптом или утилитой.

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

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

Итого. Внешне система никогда не менялась. Однако внутренняя организация радикально преобразилась. Возможно под капотом теперь работает новая система. Которая лишена недостатков предыдущей. Не напоминает фикусов-душителей? Что-то похожее есть. Поэтому именно такое название паттерн и получил Strangler.

Очевидно, что аналогичным образом можно подходить к рефакторнгу не только структуру данных, но и кода. Например, разделять монолит на микросервисы.

Выводы

• ПаттернStranglerпозволяет совершенствовать системы с высокими требованиями к SLA.

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

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

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

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

Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.

Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.

Снаружи для пользователя, внутри для команды разработки

Архитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.

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

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

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

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

Модель

Объектная модель должна быть понятна не только разработчикам, но и пользователям.

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

При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.

Логика

Упрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте.

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

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

Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде.

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

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

Нейминг решает

Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.

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

Метод должен реализовывать ровно то, о чем говорит его название. Название должно быть таким, чтобы другому разработчику не нужно было залезать внутрь и раскапывать, что еще здесь можно неожиданно встретить в реализации. Лучше, когда название метода описывает результат его работы, но не его реализацию.

Имена объектов и методов в конечном счете становится языком команды разработки, заказчика ПО и даже пользователей.

MVP и прототипы

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

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

Рефакторинг

Это придется делать. Это нормально и это важно. Даже для задач, выпущенных в продакшн совсем недавно.

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

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

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

Документация

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

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

Выводы

Не усложнять.

Ничего не прятать.

Называть все своими именами.

Не стоять на месте.

Не поддаваться отчаянию, если не получилось.

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

Всем привет! Меня всё ещё зовут Антон. В предыдущейстатьея провел небольшой обзор APIM Gravitee и в целом систем типа API Management. В этой статье я расскажу,как поднять ознакомительный стенд APIM Gravitee (https://www.gravitee.io), рассмотрим архитектуру системы, содержимое docker compose file, добавим некоторые параметры, запустим APIM Gravitee и сделаем первую API. Статья немного погружает в технические аспекты и может быть полезна администраторам и инженерам, чтобы начать разбираться в системе.

Архитектура

Для ознакомительного стенда будем использовать простейшую архитектуру

Все в докере, в том числе и MongoDB и Elasticsearch. Чтобы сделать полноценную среду для тестирования крайне желательно компоненты MongoDB и Elasticsearch вынести за пределы Docker. Также для простоты манипулирования настройками можно вынести конфигурационные файлы Gateway и Management API: logback.xml и gravitee.yml.

docker-compose.yml

Среду для начальных шагов будем поднимать, используяdocker-compose file, предоставленный разработчиками наgithub. Правда,внесемнесколькокорректив.

docker-compose.yml# Copyright (C) 2015 The Gravitee team (<http://gravitee.io>)## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at##<http://www.apache.org/licenses/LICENSE-2.0>## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.#version: '3.5'networks:frontend:name: frontendstorage:name: storagevolumes:data-elasticsearch:data-mongo:services:mongodb:image: mongo:${MONGODB_VERSION:-3.6}container_name: gio_apim_mongodbrestart: alwaysvolumes:- data-mongo:/data/db- ./logs/apim-mongodb:/var/log/mongodbnetworks:- storageelasticsearch:image: docker.elastic.co/elasticsearch/elasticsearch:${ELASTIC_VERSION:-7.7.0}container_name: gio_apim_elasticsearchrestart: alwaysvolumes:- data-elasticsearch:/usr/share/elasticsearch/dataenvironment:- http.host=0.0.0.0- transport.host=0.0.0.0- xpack.security.enabled=false- xpack.monitoring.enabled=false- cluster.name=elasticsearch- bootstrap.memory_lock=true- discovery.type=single-node- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimits:memlock:soft: -1hard: -1nofile: 65536networks:- storagegateway:image: graviteeio/apim-gateway:${APIM_VERSION:-3}container_name: gio_apim_gatewayrestart: alwaysports:- "8082:8082"depends_on:- mongodb- elasticsearchvolumes:- ./logs/apim-gateway:/opt/graviteeio-gateway/logsenvironment:- gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000- gravitee_ratelimit_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000- gravitee_reporters_elasticsearch_endpoints_0=http://elasticsearch:9200networks:- storage- frontendmanagement_api:image: graviteeio/apim-management-api:${APIM_VERSION:-3}container_name: gio_apim_management_apirestart: alwaysports:- "8083:8083"links:- mongodb- elasticsearchdepends_on:- mongodb- elasticsearchvolumes:- ./logs/apim-management-api:/opt/graviteeio-management-api/logsenvironment:- gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000- gravitee_analytics_elasticsearch_endpoints_0=http://elasticsearch:9200networks:- storage- frontendmanagement_ui:image: graviteeio/apim-management-ui:${APIM_VERSION:-3}container_name: gio_apim_management_uirestart: alwaysports:- "8084:8080"depends_on:- management_apienvironment:- MGMT_API_URL=http://localhost:8083/management/organizations/DEFAULT/environments/DEFAULT/volumes:- ./logs/apim-management-ui:/var/log/nginxnetworks:- frontendportal_ui:image: graviteeio/apim-portal-ui:${APIM_VERSION:-3}container_name: gio_apim_portal_uirestart: alwaysports:- "8085:8080"depends_on:- management_apienvironment:- PORTAL_API_URL=http://localhost:8083/portal/environments/DEFAULTvolumes:- ./logs/apim-portal-ui:/var/log/nginxnetworks:- frontend

Первичные системы, на основе которых строится весь остальной сервис:<o:p>

1. MongoDB - хранение настроек системы, API, Application, групп, пользователей и журнала аудита.

2. Elasticsearch(Open Distro for Elasticsearch) - хранение логов, метрик, данных мониторинга.

MongoDB

docker-compose.yml:mongodb

mongodb:image: mongo:${MONGODB_VERSION:-3.6}<o:p>container_name: gio_apim_mongodb<o:p>restart: always<o:p>volumes:<o:p>- data-mongo:/data/db<o:p>- ./logs/apim-mongodb:/var/log/mongodb<o:p>networks:<o:p>- storage<o:p>

С MongoDB всё просто поднимается единственный экземпляр версии 3.6, если не указано иное, с volume для логов самой MongoDB и для данных в MongoDB.<o:p>

Elasticsearch

docker-compose.yml:elasticsearch

elasticsearch:image: docker.elastic.co/elasticsearch/elasticsearch:${ELASTIC_VERSION:-7.7.0}<o:p>container_name: gio_apim_elasticsearchrestart: alwaysvolumes:- data-elasticsearch:/usr/share/elasticsearch/dataenvironment:- http.host=0.0.0.0- transport.host=0.0.0.0<o:p>- xpack.security.enabled=false- xpack.monitoring.enabled=false- cluster.name=elasticsearch- bootstrap.memory_lock=true- discovery.type=single-node- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimitsmemlock:soft: -1hard: -1nofile: 65536networks:- storage

elasticsearch:

elasticsearch:image: docker.elastic.co/elasticsearch/elasticsearch:${ELASTIC_VERSION:-7.7.0}container_name: gio_apim_elasticsearchrestart: alwaysvolumes:- data-elasticsearch:/usr/share/elasticsearch/data<o:p>environment:- http.host=0.0.0.0- transport.host=0.0.0.0- xpack.security.enabled=false- xpack.monitoring.enabled=false- cluster.name=elasticsearch- bootstrap.memory_lock=true- discovery.type=single-node- "ES_JAVA_OPTS=-Xms512m -Xmx512m"ulimits:memlock:soft: -1hard: -1nofile: 65536networks:- storage

С Elasticsearch также всё просто поднимается единственный экземпляр версии 7.7.0, если не указано иное, с volume для данных в Elasticsearch. Сразу стоит убрать строки xpack.security.enabled=false и xpack.monitoring.enabled=false, так как хоть они и указаны как false, Elasticsearch пытается найти XPack и падает. Исправили ли этот баг в новых версиях не понятно, так что просто убираем их, или комментируем. Также стоит обратить внимание на секцию ulimits, так как она требуется для нормальной работы Elasticsearch в docker.<o:p>

Дальше уже поднимаются компоненты сервиса:

1. Gateway

2. Management API

3. Management UI

4. Portal UI

Gateway/APIM Gateway

docker-compose.yml:gatewaygateway:image: graviteeio/apim-gateway:${APIM_VERSION:-3}container_name: gio_apim_gatewayrestart: alwaysports:- "8082:8082"depends_on:- mongodb- elasticsearchvolumes:- ./logs/apim-gateway:/opt/graviteeio-gateway/logs      environment:    - gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000      - gravitee_ratelimit_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000- gravitee_reporters_elasticsearch_endpoints_0=http://elasticsearch:9200networks:- storage- frontend<o:p>

С Gateway всё несколько сложнее поднимается единственный экземпляр версии 3, если не указано иное. Если мы посмотрим, что лежит наhub.docker.com, то увидим, что у версий 3 и latest совпадают хеши. Дальше мы видим, что запуск данного сервиса, зависит от того, как будут работать сервисы MongoDB иElasticsearch. Самое интересное, что если Gateway запустился и забрал данные по настроенным API из mongodb, то дальше связь с mongodb и elasticsearch не обязательна. Только в логи будут ошибки сыпаться, но сам сервис будет работать и соединения обрабатывать согласно той версии настроек, которую последний раз закачал в себя Gateway. В секции environment можно указать параметры, которые будут использоваться в работе самого Gateway, для переписывания данных из главного файла настроек: gravitee.yml. Как вариант можно поставить теги, тенанты для разграничения пространств, если используется Open Distro for Elasticsearch вместо ванильного Elasticsearch. Например, так мы можем добавить теги, тенанты и включить подсистему вывода данных о работе шлюза.

environment:- gravitee_tags=service-tag #включаемтег: service-tag- gravitee_tenant=service-space #включаемтенант: service-space- gravitee_services_core_http_enabled=true # включаем сервис выдачи данных по работе Gateway  - gravitee_services_core_http_port=18082 # порт сервиса- gravitee_services_core_http_host=0.0.0.0 # адрес сервиса- gravitee_services_core_http_authentication_type=basic # аутентификация либо нет, либо basic - логин + пароль  - gravitee_services_core_http_authentication_type_users_admin=password #логин: admin,пароль: password  Чтобы к подсистеме мониторинга был доступ из вне, надо ещё открыть порт 18082.ports:- "18082:18082"Management API/APIM APIdocker-compose.yml:management_apimanagement_api:image: graviteeio/apim-management-api:${APIM_VERSION:-3}container_name: gio_apim_management_apirestart: alwaysports:- "8083:8083"links:- mongodb- elasticsearchdepends_on:- mongodb- elasticsearchvolumes:- ./logs/apim-management-api:/opt/graviteeio-management-api/logsenvironment:- gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000  - gravitee_analytics_elasticsearch_endpoints_0=http://elasticsearch:9200 networks:    - storage- frontend

ManagementAPI это ядро всей системы и предоставляет службы для управления и настройкиAPI, логи, аналитики и веб-интерфейсовManagementUIиPortalUI. Зависит от MongoDB и Elasticsearch. Также можно через секцию environment указать параметры, которые будут использоваться в работе самого ядра системы. Дополним наши настройки:

environment:- gravitee_email_enable=true # включаем возможность отправлять письма- gravitee_email_host=smtp.domain.example # указываем сервер через который будем отправлять письма- gravitee_email_port=25 # указываем порт для сервера- gravitee_email_username=domain.example/gravitee #логиндлясервера- gravitee_email_password=password #парольдлялогинаотсервера  - gravitee_email_from=noreply@domain.example # указываем от чьего имени будут письма- gravitee_email_subject="[Gravitee.io] %s" #указываемтемуписьма

Management UI/APIM Console

docker-compose.yml:apim_consolemanagement_ui:image: graviteeio/apim-management-ui:${APIM_VERSION:-3}container_name: gio_apim_management_uirestart: alwaysports:- "8084:8080"depends_on:- management_apienvironment:- MGMT_API_URL=http://localhost:8083/management/organizations/DEFAULT/environments/DEFAULT/      volumes:    - ./logs/apim-management-ui:/var/log/nginxnetworks:- frontend

Management UI предоставляет интерфейс для работы администраторам и разработчикам. Все основные функции можно осуществлять и выполняя запросы непосредственно к REST API. По опыту могу сказать, что в переменной MGMT_API_URL вместоlocalhostнадо указать IP адрес или название сервера, где вы это поднимаете, иначе контейнер не найдет Management API.

Portal UI/APIM Portaldocker-compose.yml:apim_portalportal_ui:image: graviteeio/apim-portal-ui:${APIM_VERSION:-3}container_name: gio_apim_portal_uirestart: alwaysports:- "8085:8080"depends_on:- management_apienvironment:- PORTAL_API_URL=http://localhost:8083/portal/environments/DEFAULTvolumes:- ./logs/apim-portal-ui:/var/log/nginxnetworks:- frontend

Portal UI это портал для менеджеров. Предоставляет доступ к логам, метрикам и документации по опубликованным API. По опыту могу сказать, что в переменной PORTAL_API_URL вместоlocalhostнадо указать IP-адрес или название сервера, где вы это поднимаете, иначе контейнер не найдет Management API.<o:p>

Теперь соберем весь файл вместе.

docker-compose.yml

# Copyright (C) 2015 The Gravitee team (<http://gravitee.io>)## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at##         <http://www.apache.org/licenses/LICENSE-2.0>## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.#version: '3.5'networks:  frontend:    name: frontend  storage:    name: storagevolumes:  data-elasticsearch:  data-mongo:services:  mongodb:    image: mongo:${MONGODB_VERSION:-3.6}    container_name: gio_apim_mongodb    restart: always    volumes:      - data-mongo:/data/db      - ./logs/apim-mongodb:/var/log/mongodb    networks:      - storage  elasticsearch:    image: docker.elastic.co/elasticsearch/elasticsearch:${ELASTIC_VERSION:-7.7.0}    container_name: gio_apim_elasticsearch    restart: always    volumes:      - data-elasticsearch:/usr/share/elasticsearch/data    environment:      - http.host=0.0.0.0      - transport.host=0.0.0.0      - cluster.name=elasticsearch      - bootstrap.memory_lock=true      - discovery.type=single-node      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"    ulimits:      memlock:        soft: -1        hard: -1      nofile: 65536    networks:      - storage  gateway:    image: graviteeio/apim-gateway:${APIM_VERSION:-3}    container_name: gio_apim_gateway    restart: always    ports:      - "8082:8082"      - "18082:18082"    depends_on:      - mongodb      - elasticsearch    volumes:      - ./logs/apim-gateway:/opt/graviteeio-gateway/logs    environment:      - gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000      - gravitee_ratelimit_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000      - gravitee_reporters_elasticsearch_endpoints_0=http://elasticsearch:9200         - gravitee_tags=service-tag # включаем тег: service-tag         - gravitee_tenant=service-space # включаем тенант: service-space         - gravitee_services_core_http_enabled=true # включаем сервис выдачи данных по работе Gateway         - gravitee_services_core_http_port=18082 # порт сервиса         - gravitee_services_core_http_host=0.0.0.0 # адрес сервиса          - gravitee_services_core_http_authentication_type=basic # аутентификация либо нет, либо basic - логин + пароль         - gravitee_services_core_http_authentication_type_users_admin=password # логин: admin, пароль: password    networks:      - storage      - frontend  management_api:    image: graviteeio/apim-management-api:${APIM_VERSION:-3}    container_name: gio_apim_management_api    restart: always    ports:      - "8083:8083"    links:      - mongodb      - elasticsearch    depends_on:      - mongodb      - elasticsearch    volumes:      - ./logs/apim-management-api:/opt/graviteeio-management-api/logs    environment:      - gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee?serverSelectionTimeoutMS=5000&connectTimeoutMS=5000&socketTimeoutMS=5000      - gravitee_analytics_elasticsearch_endpoints_0=http://elasticsearch:9200         - gravitee_email_enable=true # включаем возможность отправлять письма         - gravitee_email_host=smtp.domain.example # указываем сервер через который будем отправлять письма         - gravitee_email_port=25 # указываем порт для сервера         - gravitee_email_username=domain.example/gravitee # логин для сервера         - gravitee_email_password=password # пароль для логина от сервера         - gravitee_email_from=noreply@domain.example # указываем от чьего имени будут письма          - gravitee_email_subject="[Gravitee.io] %s" # указываем тему письма    networks:      - storage      - frontend  management_ui:    image: graviteeio/apim-management-ui:${APIM_VERSION:-3}    container_name: gio_apim_management_ui    restart: always    ports:      - "8084:8080"    depends_on:      - management_api    environment:      - MGMT_API_URL=http://localhost:8083/management/organizations/DEFAULT/environments/DEFAULT/    volumes:      - ./logs/apim-management-ui:/var/log/nginx    networks:      - frontend  portal_ui:    image: graviteeio/apim-portal-ui:${APIM_VERSION:-3}    container_name: gio_apim_portal_ui    restart: always    ports:      - "8085:8080"    depends_on:      - management_api    environment:      - PORTAL_API_URL=http://localhost:8083/portal/environments/DEFAULT    volumes:      - ./logs/apim-portal-ui:/var/log/nginx    networks:      - frontend

Запускаем

Итоговый файл закидываем на сервер с примерно следующими характеристиками:

vCPU: 4

RAM: 4 GB

HDD: 50-100 GB

Для работы Elasticsearch, MongoDB и Gravitee Gateway нужно примерно по 0.5 vCPU, больше только лучше. Примерно тоже самое и с оперативной памятью - RAM. Остальные сервисы по остаточному принципу. Для хранения настроек много места не требуется, но учитывайте, что в MongoDB еще хранятся логи аудита системы. На начальном этапе это будет в пределах 100 MB. Остальное место потребуется для хранения логов в Elasticsearch.

docker-compose up -d # если не хотите видеть логиdocker-compose up # если хотите видеть логи и как это все работает

Как только в логах увидите строки:

gio_apim_management_api_dev | 19:57:12.615 [graviteeio-node] INFO  i.g.r.a.s.node.GraviteeApisNode - Gravitee.io - Rest APIs id[5728f320-ba2b-4a39-a8f3-20ba2bda39ac] version[3.5.3] pid[1] build[23#2f1cec123ad1fae2ef96f1242dddc0846592d222] jvm[AdoptOpenJDK/OpenJDK 64-Bit Server VM/11.0.10+9] started in 31512 ms.

Можно переходить по адресу: http://ваш_адрес:8084/.

Нужно учесть, что Elasticsearch может подниматься несколько дольше, поэтому не пугайтесь если увидите такое "приглашение":

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

Вводим стандартный логин и пароль: admin/admin и мы в системе!

Первичная настройка

Настройки самой системы

Переходим в менюSettings PORTAL Settings

Здесь можно настроить некоторый параметры системы. Например: доступные методы аутентификации наших клиентов: Keyless, API_KEY, Oauth2 или JWT. Подробно их мы рассмотрим скорее всего в третьей статье, а пока оставим как есть. Можно подключить Google Analytics. Время обновления по задачам и нотификациям. Где лежит документация и много ещё чего по мелочи.

Добавление tags и tenant

ПереходимвменюSettings GATEWAY Shardings Tags

Здесь надо добавить теги, по которым у нас будут различаться шлюзы. Нажимаем "+" и добавляем тег и его описание.

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

ПереходимвменюSettings GATEWAY Tenants

То же самое и с настройкой тенантов. Только тут нет кнопки "+", но есть серенькая надпись "New tenant", которую надо нажать для добавления нового тенанта. Естественно, данный тенант должен быть создан в Open Distro for Elasticsearch, и к нему должны быть выданы права.

Добавление пользователей

Переходим вSettings USER MANAGEMENT Users

Здесь можно добавлять пользователей, вот только работать это будет, если у нас настроена рассылка по email. Иначе новым пользователям не придёт рассылка от системы со ссылкой на сброс пароля. Есть ещё один способ добавить пользователя, но это прям хардкод-хардкод!

В файле настроек Management API: gravitee.yml есть такой кусочек настроек:

security:  providers:  # authentication providers    - type: memory      # password encoding/hashing algorithm. One of:      # - bcrypt : passwords are hashed with bcrypt (supports only $2a$ algorithm)      # - none : passwords are not hashed/encrypted      # default value is bcrypt      password-encoding-algo: bcrypt      users:        - user:          username: admin          password: $2a$10$Ihk05VSds5rUSgMdsMVi9OKMIx2yUvMz7y9VP3rJmQeizZLrhLMyq          roles: ORGANIZATION:ADMIN,ENVIRONMENT:ADMIN

Здесьперечисленытипыхранилищдляпользователей: memory, graviteeиldap.Данные из хранилищаmemoryберутся из файла настроек:gravitee.yml. Данные из хранилищаgraviteeхранятся вMongoDB. Для хранения пользовательских паролей, по умолчанию используется тип хеширования BCrypt с алгоритмом $2a$. В представленных настройках мы видим пользователя: admin с хешированным паролем: admin и его роли. Если мы будем добавлять пользователей через UI, то пользователи будут храниться в MongoDB и тип их будет уже gravitee.

Создание групп пользователей

Переходим вSettings USER MANAGEMENT Groups

При нажатии на "+" получаем возможность добавить группу и пользователей в эту группу.

Проверка доступных шлюзов

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

Здесь мы видим настройки шлюза. В частности, Sharding tags и Tenant. Их мы добавили чуть раньше.

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

Публикация первого API

Для публикации первого API нам сначала потребуется сделать какой-нибудь backend с API.

BackEnd с API, балеринами и Swagger.

Возьмём FastAPI и сделаем простейшее backend с API.

#!/bin/env python3import uvicornfrom fastapi import FastAPIapp = FastAPI()@app.get('/')@app.get('/{name}')def read_root(name: str = None):    """    Hello world    :return: str = Hello world    """    if name:        return {"Hello": name}    return {"Hello": "World"}@app.get("/items/{item_id}")@app.post("/items/{item_id}")@app.put("/items/{item_id}")def gpp_item(item_id: str):    """    Get items    :param item_id: id    :return: dict    """    return {"item_id": item_id}if __name__ == "__main__":    uvicorn.run(app, host="0.0.0.0", port=8000)

Это иAPIможно назвать с трудом, но для примера работы вполне хватит.

Теперь запустим его! Можно даже на том же сервере.

python3 main.py

Теперь, если мы зайдем на этот серверhttp://backend_server:8000/,мы увидим приветствие миру! Если подставим своё имя, типа так:http://backend_server:8000/Anton, то приветствовать уже будут вас! Если же хотите познать всю мощьFastAPI, то сразу заходите на адрес:http://backend_server:8000/docsилиhttp://backend_server:8000/redoc. На этих страницах можно найти все методы, с которым работает данное API и также ссылку на swagger файл. Копируем URL до swagger файла.

В прошлый раз мы создавали наш план вручную. Было несколько утомительно. Сегодня мы сделаем все быстрее, через импорт swagger файла!

На главном экране Gravitee нажимаем большой "+", выбираем "IMPORT FROM LINK", вставляем URL и нажимаем "IMPORT".

Получается как-то так

Нажимаем "IMPORT"!

Почти полностью сформированный API! Теперь немного доработаем напильником...

Для начала нажимаем "START THE API" чтобы API запустить.

Переходим в "Plans" и нажимаем "+".

Создаем тестовый план.

Тип аутентификации выбираем Keyless (public) и нажимаем "NEXT".

Ограничения по количеству запросов и путям пропускаем. Нажимаем "NEXT".

Политики нам тоже пока не нужны. Нажимаем "SAVE".

План создан, но пока находиться в стадии "Staging"

Нажимаем на кнопку публикации плана - синее облачко со стрелочкой вверх! Подтверждаем кнопкой "PUBLISH"

И получаем опубликованный план и какую-то желтую полоску с призывом синхронизировать новую версию API.

Нажимаем "deploy your API" и подтверждаем наше желание "OK"

Переходим вAPIs Proxy Entrypoints

Здесь можно указать точки входа для нашего API и URL пути. У нас указан только путь "/fastapi". Можно переключиться в режим "virtual-hosts" и тогда нам будет доступен вариант с указанием конкретных серверов и IP. Это может быть актуально для серверов с несколькими сетевыми интерфейсами.

ВAPIs Proxy GENERAL CORSможнопроизвестинастройкиCross-origin resource sharing.

ВAPIs Proxy GENERAL Deploymentsнадоуказатьвсеsharding tags,которыебудутиспользоватьсяэтимAPI.

ВAPIs Proxy BACKEND SERVICES Endpointsможно указать дополнительные точки API и настроить параметры работы с ними.

Сейчас нас интересуют настройки конкретной Endpoint, поэтому нажимаем на нижнюю шестеренку.

Исправляем "Target" на http://backend_server:8000/, устанавливаем tenant, сохраняем и деплоим!

ВAPIs Proxy Deploymentsнадо указать те sharding tags, которые могут использовать данное API. После этого необходимо вернуться в созданный план и в списке Sharding tags выбрать тег "service-tag".

ВAPIs Designможно указать политики, которые будут отрабатывать при обработке запросов.

ВAPIs Analytics Overviewможно смотреть статистику по работе данного конкретного API.

ВAPIs Analytics Logsможно настроить логи и потом их смотреть.

ВAPIs Auditможно посмотреть, как изменялись настройки API.

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

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

Переходим наhttp://gravitee_host:8082/fastapi/ , и вам покажется приветствие миру:

Также сразу можно заглянуть вAPIs Analytics Overview/Logsдля просмотра статистики обработки запросов.

Заключение

Итак, поздравляю всех, кто дочитал до сюда и остался в живых! Теперь вы знаете, как поднять ознакомительный стенд APIM Gravitee, как его настроить, создать новое API из swagger файла и проверить, что всё работает. Вариантов настройки шлюзов, точек входа и выхода, сертификатов, балансировок нагрузки и записи логов много. В одной статье всего и не расскажешь. Так что в следующей статье я расскажу о более продвинутых настройках системы APIM Gravitee. В Телеграмме есть канал по данной системе:https://t.me/gravitee_ru, вопросы по нюансам настройки можно задавать туда.

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

Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.

Обычно здесь можно встретить упрёк: "Ты чё пёс А MISRA? А стандарты AUTOSAR? Ты, может, и руководства HIC++ не читал? У нас тут серьёзный бизнес, а не эти ваши побрякушки. Кран на голову упадёт, совсем мёртвый будешь." Тут нужно аккуратно осознать, что адекватное проектирование ПО и практики обеспечения функциональной корректности в ответственных системах не взаимоисключающи. Если весь ваш софт проектируется по V-модели, то вы, наверное, в этой заметке узнаете мало нового хотя бы уже потому, что ваша методология содержит пункт под многозначительным названием проектирование архитектуры. Остальных эмбедеров я призываю сесть и подумать над своим поведением.

Не укради

Что, в конечном итоге, говорят нам вышеупомянутые стандарты в кратком изложении? Примерно вот что:

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

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

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

• Не забывай об асимптотической сложности. Ответственные системы обычно являются системами реального времени. Адептов C++ призывают воздержаться от злоупотреблений RTTI и использования динамической памяти (хотя последнее к реальному времени относят ошибочно, потому что подобающим образом реализованные malloc() и free() выполняются за постоянное время и даже с предсказуемой фрагментацией кучи).

• Не игнорируй ошибки. Если что-то идёт не так, обрабатывай как следует, а не надейся на лучшее.

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

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

Я имел несчастье ознакомиться с некоторым количеством встраиваемого ПО реального времени, к надёжности которого предъявляются повышенные требования, и в пугающем числе случаев я ощущал, как у меня шевелятся на голове волосы. Меня, например, сегодня уже не удивляет старая байка об ошибках в системе управления Тойоты Приус, или байка чуть поновее про Boeing 737MAX (тот самый самолёт, который проектировали клоуны под руководством обезьян). В нашем новом дивном мире скоро каждая первая система станет программно-определяемой, что (безо всякой иронии) здорово, потому что это открывает путь к решению сложных проблем затратой меньших ресурсов. Но с повальной проблемой качества системоопределяющего ПО нужно что-то делать.

Если взять типичную встраиваемую систему достаточно высокой сложности, можно выделить примерно следующие сгустки логики:

• Класс-бог, отвечающий за всё сущее.

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

• Utils или helpers, без них никуда.

Что в итоге: модульное тестирование невозможно, потому что нет модулей; толковая поддержка невозможна, потому что всё сложно; о гарантиях функциональной корректности трудно рассуждать всерьёз, нам бы для начала научиться выполнять вменяемую декомпозицию задачи, а не решать все проблемы в одном цикле сразу. Это зачастую преподносится как неотвратимая данность, нельзя по-другому, потому что это же не десктоп система с неограниченными ресурсами, вы не понимаете, это другое.

Инфоцыгане

Косвенным образом масла в огонь подливают некоторые поставщики программных инструментов для разработчиков встраиваемого ПО: Mbed, Arduino, и т.п. Их маркетинговые материалы вполне могут заставить начинающего специалиста поверить, что суть этой работы заключается в низкоуровневом управлении железом, потому что именно на этом аспекте диспропорционально фокусируются упомянутые поставщики ПО. Вот у меня на соседнем рабочем столе открыт в CLion проект ПО для одной встраиваемой системы; проект собирается из чуть более чем ста тысяч строк кода. Из этой сотни примерно три тысячи приходятся на драйверы периферии, остальное приходится на бизнес-логику и всякий матан. Моя скромная практика показывает, что за исключением простых устройств сложность целевой бизнес-логики приложения несопоставима с той его частью, что непосредственно работает с железом.

В один прекрасный день я обсуждал детали своего опенсорсного проекта (тесно связанного с эмбедами) с разработчиком из сторонней компании; назовём его Ильёй (в целях деанонимизации имя не было изменено). Илья работал над фичей для моего проекта, которая требовалась его работодателю. Илья работал внимательно и неспешно в силу своей аккуратности. Илья регулярно созванивался со мной, и мы обсуждали, как лучше сделать то да сё. Илья однажды сообщил, что пришёл к нему его начальник, отверз уста и изрёк:

Смотри, что я нашёл! Есть крутая новая система, Mbed называется, значит, для эмбедеров. Гляди, как можно быстро прототипы лепить! Клац, клац, и мигалка готова! Вот же, на видео. А ты, Илья, свой алгоритм оптимизации CAN фильтров пилишь уже неделю, не дело это, давай переходить на Mbed.

Я, разумеется, не хочу сказать, что права на существование сии продукты не имеют. Конечно, имеют, и более того: они чрезвычайно полезны, когда бизнес-логика проста и сосредоточена вокруг интеграции нескольких компонентов. За примерами ходить не надо, просто откройте любой их рекламный проспект это то, для чего они созданы. Но у меня подгорает, когда я слышу о менеджере, продвигающем эмбеддед-фреймворк для проекта, где работа с периферией и её отладка едва ли займёт 1% внимания программиста.

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

Когда один бэкэндер лучше двух эмбедеров

Ранее я публиковал большую обзорную статью о нашем открытом проекте UAVCAN (Uncomplicated Application-level Vehicular Computing And Networking), который позволяет строить распределённые вычислительные системы (жёсткого) реального времени в бортовых сетях поверх Ethernet, CAN FD или RS-4xx. Это фреймворк издатель-подписчик примерно как DDS или ROS, но с упором на предсказуемость, реальное время, верификацию, и с поддержкой baremetal сред.

Для организации распределённого процесса UAVCAN предлагает предметно-ориентированный язык DSDL с помощью которого разработчик может указать типы данных в системе и базовые контракты, и вокруг этого затем соорудить бизнес-логику. Это работает примерно как REST эндпоинты в вебе, XMLRPC, вот это вот всё. Если взять одного обычного бэкендера человека, измученного сервис-ориентированным проектированием и поддержкой сложных распределённых комплексов и объяснить ему суть реального времени, то он в короткие сроки начнёт выдавать хорошие, годные интерфейсы на UAVCAN.

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

Допустим, ответ подопытного является вариацией на тему "измерение воздушной скорости, барометрической высоты и статического давления". Тогда на свет появляются примерно следующие строки DSDL:

# Calibrated airspeeduavcan.time.SynchronizedTimestamp.1.0 timestampuavcan.si.unit.velocity.Scalar.1.0    calibrated_airspeedfloat16                               error_variance

# Pressure altitudeuavcan.time.SynchronizedTimestamp.1.0 timestampuavcan.si.unit.length.Scalar.1.0      pressure_altitudefloat16                               error_variance

# Static pressure & temperatureuavcan.time.SynchronizedTimestamp.1.0 timestampuavcan.si.unit.pressure.Scalar.1.0    static_pressureuavcan.si.unit.temperature.Scalar.1.0 outside_air_temperaturefloat16[3] covariance_urt# The upper-right triangle of the covariance matrix:#   0 -- pascal^2#   1 -- pascal*kelvin#   2 -- kelvin^2

Мы получаем законченный сетевой сервис, который предоставляет данные системы воздушных сигналов (конечно, этот пример не претендует на звание законченного сервиса, но суть вы поняли). Если потребитель хочет, например, знать барометрическую высоту, он просто берёт и подписывается на соответствующий топик.

Знакомый с физикой полёта читатель здесь уместно поинтересуется: откуда оконечному устройству (что поставляет сервис воздушных сигналов) знать калибровочные параметры датчика воздушной скорости? Ведь это предполагает осведомлённость датчика о собственном положении на летательном аппарате и об его аэродинамических свойствах. Принципы инкапсуляции и разделения ответственности предписывают, что соответствующие параметры настраиваются на самом поставщике сервиса воздушных сигналов (т.е. сетевом узле датчика) с целью сокрытия деталей реализации сервиса от его потребителей.

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

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

uint16 differential_pressure_readinguint16 static_pressure_readinguint16 outside_air_temperature_reading

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

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

Художника каждый может обидеть

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

Коллеги, одумайтесь.

Я вижу, как нашим микроскопом заколачивают ржавые гвозди, и представляю, сколько ещё подобного происходит за пределами моего поля зрения. В прошлом году уровень отчаяния в нашей скромной команде был столь высок, что мы опубликовали наноучебник, где объясняется, как выглядит сетевой сервис здорового человека: UAVCAN Interface Design Guidelines. Это, конечно, капля в море, но в один прекрасный день я всё-таки переведу его на русский язык ради подъёма уровня профессиональной грамотности.

Непонимание основ организации распределённых вычислений затрудняет внедрение новых стандартов на замену устаревших подходов. Наши наработки в рамках стандарта DS-015 (созданного в коллаборации с небезызвестными NXP Semiconductors и Auterion AG) встречают определённое сопротивление ввиду своей непривычности для целевой аудитории, в то время как ключевые принципы, на которых они основаны, известны индустрии информационных технологий уже не одно десятилетие. Этот разрыв должен быть устранён.

Желающие принять участие в движении за архитектурную чистоту и здравый смысл могут причаститься в телеграм-канале uavcan_ru или на форуме forum.uavcan.org.

Оригинал статьи находится по адресу

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

Три типовых решения при работе с бизнес-логикой по Фаулеру

С одной стороны сложно писать об организации бизнес-логики в приложении. Получается очень абстрактная статья. Благо есть книги, где затронута эта тема и даже есть примеры кода. Мартин Фаулер в книге "Шаблоны корпоративных приложений" выделял три основных типовых решения. Сценарий транзакции (Transaction Script), модуль таблицы (Table Module) и модель предметной области (Domain Model).Самый элементарный из них - это сценарий транзакции. Не будем их здесь обсуждать подробно - они очень хорошо описаны в первоисточнике с примерами. Приведем для дальнейших рассуждений лишь схему все из той же книги:

На этом графике показана _приблизительная_ зависимость между сложностью доменной логики и стоимостью реализации для трех видов типовых решений. Сразу бросается в глаза очевидная схожесть между тем как ведет себя сценарий транзакции и модуль таблицы. И совсем особняком стоит модель предметной области, которую применяют для сложной бизнес-логики. Как выбирать решение для вашего проекта? Очень просто, вы оцениваете насколько сложная будет бизнес-логика. Например расчет скидочной программы для клиентов. Какое типовое решение выбрать? Обычно при расчете скидок пользователи могут быть в разных категориях скидочной программы, в зависимости от категории можно получать скидки на разные группы товаров, причем товары могут входить в иерархические группы. Категории скидок распространяются на категории товаров. А еще есть число посещений заведения за заданный период. Периоды с разными характеристиками, заведения в сети заведений - различаются и т.д. и т.п. Если представить код - это приложение, в котором большое число классов с разнообразными свойствами и большое число связей между этими классами. А также разнообразные стратегии, которые оперируют всеми этими сущностями. В таком случае ответ очевиден - проектирование с использованием модели предметной области позволит вам совладать со всеми сложностями. Другой пример - у вас простое приложение, которое хранит свои данные в 3-х таблицах и никаких особенных операций с ними не делает. Рассылка сообщений по почте - список почтовых ящиков и список отправленных писем. Здесь нет смысла тащить какой-то сложный фреймворк. Простое приложение должно оставаться простым и тут лучше выбрать модуль таблицы или даже сценарий транзакции. В зависимости от того на какой платформе вы собираетесь разрабатывать.

Сколько типовых решений на самом деле?

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

Понятно, что речь не идет о чистой реализации той или иной парадигмы. Всегда есть компромиссы, вызванные ограничениями используемых технологий. Если вы пишете на C# или Java, объектно-ориентированных языках по своей природе, то это совсем не значит, что ваш код автоматически становится объектно-ориентированным. Всю программу вполне могут поместить в один единственный класс, объявить все методы статическими и использовать их из любого фрагмента кода. Таким образом в каждом конкретном приложении будет своя кривая. Нужно лишь понять к какой из этих двух категорий она ближе.

Как влияют фреймворки и инструменты разработки на кривую стоимости?

Сразу обозначим, что в качестве хранилища данных может выступать не только реляционная СУБД, но и NoSQL хранилище,NewSQL и даже обычные файлы, сериализованные в json, бинарный формат и т.п. Мы смотрим на ситуацию в комплексе. Если говорить про работу с обычными SQL хранилищами, здесь также огромный выбор. Вы можете писать простые запросы, писать хранимые процедуры, можете использовать ORM, использовать Code First, либо DB First подходы - все это в конечном счете сказывается на стиле в котором написана бизнес логика. В большей степени процедурном, либо в большей степени объектно-ориентированном. Ниже я примерно обозначил свое мнение о популярных схемах работы с БД.

Проблема в том, что используемые средства накладывают ограничения, которые не позволят вам реализовать тот или иной подход в полной мере. Например, с помощью Dapper не удобно работать со сложными ассоциациями внутри доменных сущностей. А при использовании ORM уровня Entity Framework вы добавляете код для отображения сущностей на таблицы. Если говорить о NoSQL СУБД, для примера Neo4j, то там очень выразительный и мощный для своих задач язык. Но опять же это приведет к использованию процедурной парадигмы.

Насколько легко сменить выбранное решение?

Давайте попробуем представить ситуацию, где мы решили кардинально изменить схему работы с хранилищем данных. С чем мы можем в таком случае столкнуться? До этого мы обсудили два важнейших аспекта - сложность кода и стоимость его сопровождения. Но на практике этого оказывается мало. Есть еще как минимум вопрос производительности - создаваемое приложение должно быть быстрым. И это сказывается на стиле написания кода. Чем жестче требования производительности, тем более процедурный код мы получаем на выходе. В каком-то экстремальном случае это может быть сервис или приложение, написанное с использованием полностью SQL, где вся логика скрыта в хитрообразных джойнах, оконных функция и обобщенных табличных выражениях. Работает быстро, но перевести его на ORM уже не так просто - все равно что переписать с нуля. Развитие такого продукта также может столкнуться с сложностями, учитывая график выше и процедурный стиль. Еще один вопрос - консистентность данных. Например, реляционные СУБД предоставляют очень богатые возможности по работе с транзакциями. Разобравшись с ними один раз - можно легко писать код, где вы точно знаете какие данные увидит пользователь, какие сможет изменить. С другой стороны, если вы пользуетесь ORM и выносите всю вашу бизнес-логику в классы работать в терминах транзакций становится сложнее. Обычно происходит реорганизация структуры таблиц и даже бизнес-сценариев таким образом, что они начинают работать в стиле согласованности данных в конечном счете (eventual consistency). Очевидно, что это также затрудняет перевод с одной схемы на другую, если вы заранее не заложили такую возможность. Компетенцию команды также не следует сбрасывать со счетов. Часто разработчики знают хорошо либо SQL, либо ORM и при переходе можно неожиданно столкнуться с проблемами.

Выводы

Из всего, что мы обсудили можно сделать выводы:

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

• Если дальнейшее развитие для сервиса не очевидно, то лучше сразу позаботиться о возможной смене парадигме. Например, предпочитая eventual consistency. При добавлении нового функционала всегда держать в уме возможность смены решения.

• Для доставшегося в "наследство" программного кода одно из первых действий - это оценка степени соответствия выбранного типового решения и объема уже реализованной логики. Как показывает практика - это наиболее частая причина технического долга.

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