Русский
Русский
English
Статистика
Реклама

Микросервисная архитектура

Микросервисы во фронтенде

11.09.2020 10:13:26 | Автор: admin

image


Привет, Хабр!
Микросервисы уже давно стали классикой в бэкенд архитектуре, но в отличие от бэкенда, во фронтенде одновременно можно использовать только один фреймворк. Это порождает неудобства при масштабировании и переиспользовании модулей. Микросервисный подход избавляет от необходимости придерживаться конкретного фреймворка и дает возможность программисту сосредоточиться на конкретном модуле с использованием наиболее удобных для него инструментов. Мы не пропагандируем расширение зоопарка технологий и использование каждого фреймворка необходимо тщательно обдумать, прежде чем внедрять. Подробнее в статье от разработчика команды BSL gyk007


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


Начну с того, зачем это нужно


Еще совсем недавно web был простым. Для успешной работы необходимо было знать html, css и популярную на тот момент, библиотеку jquery. На этом знания фронтенд-программиста заканчивались, да и за программистов их особо не считали, так, верстальщики или веб-мастера. Но веб стремительно развивается, интерфейсы становятся все сложнее и сейчас для многих проектов, в которых нет HighLoad и микросервисов (а они в большинстве случаев и не нужны), клиентская часть становится сложнее, чем серверная, и время жизни кода на клиенте обычно меньше, чем на сервере.
Также появляется целая армия фреймворков, которые по сути делают одно и то же, но разными способами. И программисты выбирают свой стек: кто-то React, кто-то Vue и так далее.
Но наше веб-приложение живет долго, а фреймворки и UI-библиотеки меняются быстро. В итоге через пару лет мы получаем легаси, который хочется переписать, но это долго, а бизнес не готов за это платить приложение же работает.
Я думаю, многие программисты слышали про закон Иглсона: Ваш код, который вы не просматривали 6 или более месяцев, выглядит так, будто его написал кто-то другой.


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


Учитывая все вышесказанное, хотелось бы иметь не один большой монолит, который хочется переписать, а набор микросервисов (назовем их модули, каждый из которых максимально изолирован, чтобы при необходимости мы могли быстро его заменить или написать новый на другом стеке (если, конечно, это нужно). И тестировать только те модули, код которых менялся.
Чтобы решить все проблемы, я написал фреймворк, который легко позволяет делить приложение на модули, причем каждый модуль при необходимости может иметь свой стек (React, Vue, Angular, Webix . )


Что мы получили


Модули (микросервисы)


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


Вот основные их типы:


  • Root-модуль главный модуль, один на все приложение. Отвечает за взаимодействие между модулями.
  • Page-модуль понятно из названия, модуль-страница.
  • Layout-модуль это тоже должно быть понятно, модуль-шаблон для страницы.
  • Global-модуль модуль который можно вызвать из любой страницы нашего приложения (например окно с чатом, или уведомления).
  • Embed-модуль модуль который встраивается в Page-модуль или в Global-модуль.
    Все модули устроены однотипно. Они просто встраиваются в DOM дерево. Если наш Page-модуль встраивается в Layout-модуль, то Layout-модуль должен иметь контейнер с id (<div id='content'></div>), а Page-модуль должен туда монтироваться. Все довольно просто.
    Также все модули динамически импортируются, клиент загружает файл с кодом модуля только тогда, когда это ему необходимо.
    В итоге мы получаем примерно такую структуру:
    |--project_name_dir|--src|--modules  |--Root      |--root.js      ...  |--Module1      |--module.js      ...  |--Module2      |--module.js      ...  ...
    

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

    Конфиг файл


    import Root from 'Root/module';export default {// роутинг с помощю history Api или hash.historyApi: false,// корневой путь для приложения ('/example/path/').rootPath: '/',// класс Root-модуля.rootModule: Root,// название модуля главной страницы.mainModule: 'main',// названия модуля страницы 404module404: 'notfound',// функция для динамического импорта модуля.// module - название модуля и название директории модуля.import: async (module) => await import(./modules/${module}/module),modules: {auth: {// Название модуля - названия директории, в которой находится файл с модулем.module: 'ExampleAuth',},// Ключ Page-модуля отвечает за название роута для этой страницы.main: {layout: 'ExampleLayoutWebix',module: 'ExampleWebix',embed: {// В этот модуль мы встраиваем ExampleEmbed-модуль.example: {module: 'ExampleEmbed',},},},notfound: {layout: 'ExampleLayoutWebix',module: 'ExampleError404',},// Глобальный модуль флаг global: true,globalwnd: {global: true,module: 'ExampleGlobalWnd',embed: {example: {module: 'ExampleEmbedGlobal',},},},globalnotification: {global: true,module: 'ExampleNotification',},},};
    

    Наш конфиг файл может иметь дополнительные поля, если это необходимо:

    main: {module: 'PageMain',layout: 'Layout',icon: icon,title: 'Главная Страница',inMenu: true,}
    

    Мы можем использовать разные модули для различных условий:

    main: {layout: window.innerWidth < 1000 ? 'Layout_1' : 'Layout_2' ,module: window.innerWidth < 1000 ? 'Module_1' : 'Module_2 ,embed: {example: {module: window.innerWidth < 1000 ? 'Embed_1' : 'Embed_2' ,},},},
    

    Теперь поговорим об устройстве модуля.


    Все модули, за исключением Root-модуля, наследуются от класса Onedeck.Module.
    Класс модуля имеет внутри реализацию паттерна [одиночка (Singleton)][simgleton] и [наблюдатель (Observer)][observer].
    То есть объект создается только 1 раз и может подписываться и публиковать события.
    Пример Модуля:



    import Onedeck from 'onedeck';import App from 'ExampleModule/App.vue';import Vue from 'vue';/*** Class ExampleModule* module use Vue*/export default class ExampleModule extends Onedeck.Module {// Хук жизненного цикла init.// Срабатывает при инициализации нашего модуляinit (path, state, queryParam) {console.log('init', this.constructor.name, path, state, queryParam);this.VueApp = new Vue(App);this.eventHandler();}// Обработчик событий для данного модуля.eventHandler () {this.$$on('onAuth', () => this.$$rout({  path: '/main/',  state: null,}));}// Хук жизненного цикла dispatcher.// Срабатывает при переходе на url, тут можно описать логику при переходе.dispatcher (path, state, queryParam) {console.log('dispatcher', this.constructor.name, path, state, queryParam);}// Хук жизненного цикла mounted.// Срабатывает когда модуль смонтирован в DOM дерево.mounted (module, layout) {console.log('mounted', this.constructor.name, module, layout);}// Хук жизненного цикла destroy.// Срабатывает когда нам нужно очистить DOM дерево от нашего модуляdestroy () {this.$$offAll()this.VueApp.$destroy();document.getElementById('root').innerHTML = '';}}
    

    Про хуки жизненного цикла модуля вы можете более подробно почитать в документации. Также вы можете почитать в документации про Root-модуль. Его код почти идентичен коду обычного модуля.


    Роутинг


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


    // роутинг с помощю history Api или hashhistoryApi: false,
    

    Каждый модуль имеет метод $$rout:


    import Module from 'Example/module';// Так как наш модуль реализует паттерн Одиночка (Singleton), мы получим текущий объект модуля.const module = new Module()module.$$rout({// Указываем путь, первый элемент пути - название модуляpath: '/module_name/item/1',// Данные, которые мы хотим передать по указанному пути:state: {id: 1, name: 'example'},})
    

    Далее path и state можно получить в хуках жизненного цикла init и dispatcher.


    Общение между модулями


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


    • события модуля с помощью метода $$emit;
    • глобальные события с помощью метода $$gemit;

    События модуля создает сам модуль с помощью методов $$on или $$onOnce. А глобальные события создаем Root-модуль также с помощью методов $$on или $$onOnce.


    Более подробно о событиях вы можете почитать в документации. Также там есть ссылка на github с простым примером приложения.


    Выводы


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


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


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


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


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


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


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

Подробнее..

Как создать микросервис на PaaS

08.12.2020 10:15:01 | Автор: admin
Если вам интересно, как можно автоматизировать повседневные задачи разработчиков и построить удобную систему оркестрирования зависимостей ваших сервисов, загляните под кат. Об этом в своем докладе на конференции Golang Live 2020 рассказал разработчик продуктовой команды Авито Auto B2B Иван Королев. Он затронул тему платформенных решений для создания микросервисов и на живом примере продемонстрировал, как происходит создание и развитие микросервиса в Авито.



Что такое Platform as a Service, и зачем она нужна?

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

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

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

Как в Авито появился PaaS


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



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

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

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

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

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

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

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

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

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

Как это выглядит для пользователя?



У нас есть консольная утилита и PaaS-dashboard, в котором можно получить информацию о том, что делает конкретный сервис, какие технологии использует под капотом, на каком языке написан, кто ответственный, насколько сервис покрыт тестами, когда был последний деплой. То есть это дашборд состояния сервиса с нужными ссылками на Grafana, Jaeger, репозиторий.

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

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

За прошедшее время все больные места, которые находили в команде архитектуры, выглядели разнообразно. Особенно когда кто-то вместо решения продуктовых задач половину спринта тратил на то, чтобы развернуть сервис и PG Bouncer, настроить подключение к БД, связать все сервисы воедино. Таких проблем может быть очень-очень много.

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

Жизненный цикл сервиса довольно очевиден. Мы должны его создать. Затем его нужно протестировать, задеплоить в продакшн, и дальше успешно эксплуатировать.

Что требуется для создания сервиса


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

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

Для этого у нас есть утилита Avito Service Create, которая проводит разработчика по шагам, где он выбирает шаблон, а также указывает название, описание сервиса, тип:



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

В результате, мы получаем:



Все это происходит под капотом, разработчику об этом не нужно думать.

Разработка сервиса с использованием PaaS


Главное, что болит при разработке без PaaS это отсутствие унификации. Сервисы у разных команд получаются разные, даже если они используют одинаковые подходы к проектированию. Это вызывает ряд проблем, когда хочешь прийти в другую команду и сделать им pull request. Для этого надо сначала разобраться, как устроен сервис другой команды, как он деплоится, как тестируется пройти весь спектр проблем новичка. Унификация позволила бы снять этот overhead на первичный вход.

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

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

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

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

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

В итоге мы получаем 40 килобайт манифестов в helm-директории каждого сервиса. При этом diff между этими манифестами в разных сервисах это, по сути, несколько строк. Люди копировали их из шаблона, заменяли нужные строки, и получался чистый копипаст между разными сервисами. И конечно же, они могли ошибиться в простыне yaml.

В итоге мы пришли к единому конфигурационному файлу, который называется app.toml и лежит в корне каждого проекта. Он представляет из себя именно те части сервиса, которые могут меняться: название, описание, движок под капотом, настройки для выкатки (например, CPU, память, количество реплик в разных окружениях):



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

Главная проблема в helm-чертах то, что они очень многословные. Приходится сидеть с линейкой и измерять, правильно ли сделан отступ у этой команды, иначе все сломается и не будет работать. TOML позволяет решить эту проблему.
Кроме того, сервисы конфигурируются через Environment-переменные, и их значение тоже хранятся в app.toml

Какие были проблемы с управлением секретами? Мы выбрали vault для хранения. Чтобы корректно его настроить, разработчику нужно понимать особенности его работы.

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

Кроме того, нужно сделать интеграцию в helm-чартах, чтобы поднялись init-контейнеры, которые пойдут в vault и сформируют конфигурацию для podов.
И все это может упасть в самый неожиданный момент именно в продакшене.

Казалось бы, секреты та же самая часть конфигурации. Зачем сервису вообще знать, что за обычными конфигами надо идти в Env-переменные, а за секретными в vault? Это все можно объединить.

Мы изменяем секреты непосредственно в PaaS dashboard. Они раскатываются на namespace. Таким образом мы можем изолировать сервисы от друг друга. А сами сервисы получают секреты из переменных окружения, нам в этом помогает небольшой бинарник, который на старте контейнера сходит в vault и положит конфигурацию в Environment.

По межсервисному взаимодействию тоже есть большая боль.

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

И совсем космическая штука: выставить таймауты так, чтобы они укладывались в NFR сервиса. Простой пример: сервис, который на каждый hit ходит в базу данных, отвечает по секунде, и кто-то ходит в него с таймаутом в 200 мс. Такие штуки хочется отслеживать и настраивать адекватно.

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

Как это выглядит? У нас собственный формат описания. Он является подмножеством Protobuf или Thrift.



В итоге мы описываем сервис, RPC-ручки, DTO на входе и на выходе. Типы данных: скаляры, вложенные структуры, массивы, key-value.

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

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

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

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

Синхронное взаимодействие построено на внутреннем RPC протоколе, со стороны разработчика практически нет доступа к подробностям реализации. Ему неважно, каким образом на уровне транспорта у нас передаются данные: это JSON, или Protobuf, или Msgpack. Команда архитектуры таким образом развязывает себе руки на будущее, и может безболезненно внедрить новые протоколы, если это необходимо.

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

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

Под капотом есть общий сервис data-bus, который инкапсулирует работу с Kafka. Все сервисы взаимодействуют уже непосредственно с ним.



Таким образом, собственный язык описания нам дает единый формат всей межсервисной коммуникации. При этом, синтаксис близок к Go, имеет простую структуру без импортов, и под капотом даже используется lexer, встроенный в Go.

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

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

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

Выглядит это просто: мы выбираем хранилище, например Postgres, вводим одну команду, и зависимость добавляется в app.toml:



Подобным образом подключается Redis: мы выбираем тип хранилища: кэширующий в Kubernetes, c бекапами или без, шардированный вне Kubernetes. Зависимость от Redis также добавляется в app.toml, и дается рекомендация по подключению библиотеки к сервису.

Так описание хранилищ выглядит в app.toml: указывается тип хранилища, его размер, используемую версию. По этим данным генерятся манифесты для helm чарта:



И самое главное такое описание позволяет упростить локальную разработку.

К другим сервисам, от которых мы зависим, идем в стейджинг. Локальные хранилища деплоятся в minikube, включая локальную шину данных. А конфигурационный файл с Environment переменными генерируется на основе app.toml.

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

Поговорим о тестировании


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

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

Какой существует подход? Например, у нас есть пять сервисов, которые взаимодействуют между собой. И мы хотим протестировать новую версию Service 3. Первое, что приходит в голову это развернуть в тестовом окружении весь комплект сервисов, которые взаимодействуют между собой. Но помимо того, что ресурсы не безграничны, это может привести к увеличению времени выполнения тестов и плохо повлиять на их стабильность.



Поэтому мы поднимаем Service 3 в тестовом окружении. Добавляем в запрос специальный заголовок, балансировщик трафика его принимает, разбирает и понимает, что Service 2 должен сходить с этим заголовком в новую версию Service 3, находящуюся в тестовом окружении. Таким образом мы сохраняем наш staging стабильным, но при этом позволяем end to end тестам работать с новыми версиями сервисов.

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

Deploy и эксплуатация


Каковы проблемы деплоя? Helm хороший инструмент, с его помощью можно создать высокоуровневое описание сервиса и всех его зависимостей. Тем не менее, с этим инструментом довольно трудно работать. У него много проблем и большое количество issues на github. Он не работает, когда необходимо поднять несколько кластеров для одного окружения, например, в staging или production. В этом случае все ломается, и helm не обеспечивает транзакционность деплоев. Ты не можешь гарантированно сказать, что у тебя все выкатилось в несколько окружений, и синхронно переключить трафик. В общем, начинается боль.

Поэтому команда архитектуры написала свой деплоер Jibe (он пока еще не в open source, но такие планы у ребят есть). Он решает задачу деплоя в несколько кластеров.

От helm по большей части была важна только генерация Kubernetes-манифестов, поэтому можно было, например, использовать helm для генерации, а непосредственно для деплоя Jibe. В дальнейшем можно будет генерировать манифесты самостоятельно.

Например, у нас есть два кластера, и сервис версии V5, которая задеплоена в оба кластера. Jibe, используя манифесты для новой версии, деплоит версию V6 в оба кластера:





Трафик в это время все еще идет на V5.

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

Что мы получаем? Несколько стадий деплоя, каждая из которых может идти на полуручном приводе. Мы можем откатывать сервисы либо с помощью Canary, либо blue-green деплоем, и при этом получаем гарантию консистентности версий сервисов на всех кластерах.

Чем нам помогает PaaS с точки зрения эксплуатации? Типичная боль инфраструктурных команд: когда продуктовые команды заложили слишком большие запросы на capacity, на CPU и память. И в итоге пулл по запросам забит, но утилизация машин намного ниже, чем хотелось бы, и железо простаивает.

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

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

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

Service discovery часть, о которой разработчики тоже не хотят задумываться. Она должна быть скрыта за инфраструктурой, потому что иначе мы получаем зашивание URL непосредственно в конфигурации сервиса. Одни идут через ingress-контроллер, другие по fqdn-адресу Kubernetes. Случайно пошли из прода в стейджинг все сломалось. И появляется вопрос: как нам все это масштабировать, если у нас появляется новый кластер?

Что сделано у нас? В app.toml есть специальная секция с зависимостями сервиса:



Таким образом, у нас решается две проблемы. Проблема конфигурации. Из названия сервиса по определенному шаблону формируется ENV-переменная, в которую подставится URL, куда нужно стучаться. И вторая: таким образом мы можем сформировать граф зависимости каждого сервиса не на основании статистики, а просто по манифестам.

И разработчик тоже получает преимущество. Не нужно указывать никакие URL, система сама автоматически подставит нужный путь. А балансер, который стоит перед сервисом, передаст коннект к нужному сервису нужной версии. Например, в продакшен в случае canary, или в staging в случае такого кейса с тестированием.

Кроме того, автогенерируемые клиенты автоматически собирают все значения из ENV.
Кроме того, у нас есть опенсорсный инструмент Service Navigator (его можно будет посмотреть на нашем GitHub), который обеспечивает service mesh, и походы из одних сервисов в другие. Service Navigator собирает унифицированные метрики по всем взаимодействиям, и можно построить дашборды даже без участия и отправки метрик из сервисов. В навигаторе можно подключить разнообразные circuit breakers, переотправку запросов в случае ошибок. Все эти политики прозрачно настраиваются командой продуктовой разработки.

Под капотом используется Proxy Envoy, который балансит трафик, а Navigator занимается его динамической настройкой:



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

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

Преимущества и недостатки PaaS


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

Важно соблюсти баланс между автоматизацией и гибкостью настройки.

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

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

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

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

Выводы


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

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

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

Даже в эпоху пандемии, мы совсем рядом.

Хотите получать полезные материалы о GO-разработке? Подписывайтесь на рассылку конференции GolangConf.
Подробнее..

Интеграционный слой с Kafka и микросервисами опыт построения операционной CRM контакт-центра торговой сети Пятерочка

04.03.2021 10:11:49 | Автор: admin

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



Привет Хабр, на связи Иван Большаков архитектор интеграционных решений, эксперт департамента разработки ПО КРОК. Я расскажу, как мы делали интеграционный слой для CRM-системы группы контакт-центров торговой сети Пятерочка.


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


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


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


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




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


Возможные решения



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


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



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


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



Мы решили использовать для интеграционного слоя микросервисы. Они позволяют реализовать дополнительную бизнес-логику и обеспечивают масштабируемость. Их проще распределить по нескольким ЦОД, по сравнению с ESB.


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


Архитектура интеграционного слоя


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


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


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


Так как в интеграционный слой попала бизнес-логика, выбор пал на событийно-ориентированную архитектуру. В ней проще следить за согласованностью данных.


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


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


Вся сложность во взаимодействиях


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



Внутри системы мы выделили два типа взаимодействий: модифицирующие и читающие. Модифицирующие воздействия реализовали при помощи обмена сообщениями через топики в Kafka. Каждому сервису присвоили топик, который начинается с его имени. Сервис отправляет туда сообщения обо всех событиях, произошедших с его объектами:


с бизнес-сущностью, которую обрабатывает сервис user, что-то произошло, вот ее новые данные

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


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


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



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


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


Kafka и очереди сообщений


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



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


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


Взаимодействие с фронтом


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



Ходить за несколькими сущностями в три разных сервиса, а потом собирать на фронте какую-то адекватную модель для представления не очень удобно. Куда удобнее использовать composer, который будет брать сразу несколько сущностей со связями между ними и компоновать в один JSON. Для этого отлично подошел Apache Camel. Правда, в следующий раз мы не станем заморачиваться с REST и используем graphQL.


Service mesh и безопасность


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



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


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


Конечно, полноценный service mesh на коленке не напишешь, но можно было обойтись без управления трафиком, а мониторинг настроить вручную. Главное, что нам нужно было от service mesh, это безопасность.



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


Итак, мы начали пилить собственный service mesh. В его основу легла простая идея: если нельзя (не хочется) поместить логику в код сервиса, сделаем внешний sidecar-контейнер по аналогии с Istio, использовав OpenResty и язык Lua.


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


Аудит


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



Существуют штатные библиотеки для работы с Kafka, но и с ними возникли проблемы. Все ломалось, как только для подключения к Kafka требовался SSL. Спас положение старый добрый kafka-console-producer, который лежит в каждом sidecar и вызывается с параметрами из nginx.


Получился рабочий почти-service mesh. Казалось бы, можно было расслабиться, но мы чуть не упустили еще одну важную вещь.


Балансировка gRPC


gRPC то работает на HTTP/2, а этот протокол устанавливает соединение и держит, пока оно не порвется. Возможна ситуация, когда инстанс сервиса A намертво прицепится к одному из инстансов сервиса B и будет направлять все запросы только на него. Тогда от масштабирования сервиса B не будет толка. Второй инстанс сервиса B останется не нагружен и будет впустую тратить процессорное время и память.



Мы могли сделать полноценную балансировку на клиентской стороне, но было бы неправильно тратить на это время. После внедрения полноценного service mesh эти наработки потеряют актуальность.


Поэтому мы реализовали перехват и подсчет всех вызовов gRPC на уровне кода на стороне клиента. Когда счетчики подходят к определенному значению, вызывается метод, приводящий к переустановке соединения, и балансировщик OKD задействует незагруженный инстанс сервиса B.


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


Управление версиями


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


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


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



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


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


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


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


Что мы вынесли из проекта


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


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


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


Если у вас появились вопросы, или вы знаете, как красиво сделать приоритизацию сообщений в Kafka, пишите в комментариях или на почту IBolshakov@croc.ru.

Подробнее..

Угрожает ли микросервисная (контейнеризация) архитектура светлому будущему Published Apps (Citrix amp Co.)

12.04.2021 10:16:29 | Автор: admin
Идея данного опроса возникла в результате дискуссии с коллегами, навсегда завязавшими с темой Virtual App and Desktop и нашедшие себя в направлении Kubernetes/Cloud.

Несмотря на то, что последние годы моя профессиональная деятельность непосредственно связана с темой Citrix, я также как и мои коллеги не могу не заметить отсутствие особых перспектив развития технологии доступа к Apps посредством терминальных сессий (особенно on-Premise).

Прежде чем задать пару вопросов, хотелось бы подчеркнуть, что напрямую сравнивать как технологии, лежащие в основе Kubernetes и Citrix Virtual Apps and Desktops (MS RDS, VMware Horizon, Parallels RAS), так и сами продукты не совсем правильно. Но если рассмотреть конечную цель, для чего в конечном счёте существует IT, а именно для конечного пользователя, задача которого максимальной эффективностью и удобством выполнять поставленные перед ним задачи.

Смысл и цель использования виртуального приложения


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

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

Почему сгущаются тучи?


Свою позицию коллеги объясняют следующим образом. Все больше и больше программных продуктов продолжают своё существование в качестве веб-приложений, многие просто создаются по принципу born in the cloud. Таким образом доля устанавливаемого на серверах программного обеспечения под Windows будет постоянно уменьшатся, превращая published application в ненужный анахронизм.

Буд рад Вашим комментариям! Спасибо!
Подробнее..

Шаблон микросервиса зачем нужен и как его внедрить в разработку

19.02.2021 12:19:30 | Автор: admin

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

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

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

2. Если у разработчиков нет эталона, повышается риск дополнительных ошибок. Значит, кому-то придётся потратить лишнее время, чтобы их исправить.

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

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

Что даёт шаблон микросервиса

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

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

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

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

  • Чем меньше времени уходит на лишние действия, тем меньше time-to-market. Релизы поставляются чаще, продукт развивается быстрее.

  • Шаблон помогает выполнять стандарты Production Ready. Это включает в себя не только архитектурные элементы, которые должны быть в каждом продукте, но и другие важные вещи вроде средств работы с метриками и Feature Flags, базовых тестов.

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

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

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

Что фиксируется в шаблоне

  1. Структура папок и базовые классы необходимые для любого микросервиса

  2. Настройки Rest API, баз данных, авторизации, брокеров сообщений

  3. Правильные версии базовых библиотек

  4. Наши внутренние наработки и настройки

    • Библиотеки собственной разработки

    • Пайплайны сборки и поставки (CI/CD)

    • То, что называется Observability, а именно логирование, трассировка, health check monitoring

  5. Помимо самого кода, мы стандартизуем всю экосистему для нашего будущего микросервиса: настраиваем политики работы Git репозитория, пайплайны Jenkins/Gitlab.

Как выглядит наш шаблон микросервиса для .Net

Наш базовый микросервис является расширением Microsoft Visual Studio и объединяет в себе пять компонентов:

  • Web API Project - бэк-сервис, который отвечает на HTTP-запросы.

  • Data base project база данных микросервиса.

  • HTTP Service client project позволяет вызывать методы в сервисе бэка

  • MassTransit consumers project обеспечивает получение сообщений из RabbitMQ.

  • Job Project применяется для выполнения каких-либо действий по расписанию.

Модули можно добавить в проект сразу все разом или по отдельности. Выбор сделан на основе простого UI, где достаточно галочками прощёлкать нужные компоненты:

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

Итоги

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

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

Подробнее..

Разбиваем монолит на микросервисы

30.06.2020 08:17:02 | Автор: admin

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



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


Итак, ваша организация решила разбить старый, добрый монолит на микросервисы. Почему? Ясного ответа никто дать как правило не может, но в целом все начинают описывать как им плохо живется с монолитом. Да, релизные циклы действительно очень зацеплены за разные команды. А почему вы думаете, что в МСА по-другому? Кто-то говорит, что микросервисы гораздо лучше масштабируются. Ну можно сделать и так, а вам зачем это? Нет, может и надо, но вы понимаете зачем или просто подсмотренную фразу используете? Говорят, каждый микросервис гораздо менее требователен к ресурсам: памяти, базе данных и т.д. Ну и что? У вас деньги на сервера иссякли? Бизнес ценность-то в чем?
Коллеги, я не хочу сказать, что у МСА нет преимуществ. Эти преимущества есть. Но я хочу сказать, что какие бы цели вы ни ставили при старте проекта разбивки, вы их скорее всего ставите неправильно и никогда не достигните. Не достигните просто потому, что реализацией проекта у вас будут заниматься те люди, которые довели до состояния бездарно написанного кода ваш монолитный проект. При этом все подходы при реализации МСА настолько отличаются от монолитной, насколько телефонная лапша 20-го века отличается от сетевых технологий нынешнего 21-го века. И аналогия здесь действительно очень удачная. ТФоП доставляет в квартиру одну телефонную линию. Обрыв на любом участке линии приводит к выходу ее из строя. Сетевые технологии динамичны и позволяют строить альтернативные маршруты. Даже выход из строя 60% всей сетевой инфраструктуры страны в результате ядерной войны, не приведет к отказу оставшихся сетей.


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


А сейчас разберем повсеместно встречающиеся ошибки при развитии микросервисной системы предприятия.


  1. Отказ от изменений бизнес-процессов
    Говорят, что любой бизнес реализует в коде свои бизнес-процессы. И, если вы 20 лет до этого строили свои бизнес-процессы на базе вашей монолитной архитектуры, то любая ваша попытка внедрить МСА будет заведомо обречена на провал. Просто потому, что для этого требуется менять бизнес-процессы.Пример? Сколько стадий согласования вопроса у вас существует в организации? Так вот, в микросервисной команде число таких стадий приближается к нулю. Подавляющее большинство вопросов решается внутри команды, реализующей микросервис. Команда не обязана выносить на корпоративный уровень вопросы о языке, на котором будет написан микросервис. Одни могут выбрать Java, а другие Python. Вы может быть даже сейчас не поверите, но этот вопрос является полностью в компетенции команды. И это потому, что в случае каких-то проблем, микросервис проще ПЕРЕПИСАТЬ, чем ПОДДЕРЖИВАТЬ.
    По моему опыту, разработка простейшего микросервиса при нормально поставленном производстве занимает неделю работы двух джунов, включая бюрократию по выводу его в пром, т.е. обходится компании, включая различные накладные расходы, примерно в 50-100 тыс. руб. Если у вас только аналитика занимает месяц работы 3 команд, то у вас нет никакой МСА в организации, вы опять скатываетесь в лютую монолитчину.
  2. Поручить руководство проектам опытным монолитчикам
    После того как вы отказались от модернизации своих бизнес-процессов, совершенно логичным является то, что вы поручаете новый проект очень опытному человеку, который показал себя с лучшей стороны и вообще знает все ваши бизнес-процессы. Возможно кто-то вам и нудел, что на старые проблемы должен взглянуть новый опытный человек, но вы отмахнулись от него как от глупой назойливой мухи. И вот он. Ваш новый/старый руководитель разработки на проекте. Не удивляйтесь, что результат будет тем же, что и раньше и даже хуже. Когда в МСА начинают применяться монолитные решения, ни к чему хорошему это не приведет. Именно в этот самый момент вы подписали смертный приговор вашему пилоту. Возможно, вы даже наберете опытных людей, которые уже сожрали стаю собак на микросервисных проектах, но это вас не спасет, просто потому что их начальник слушать не будет. Просто потому что у него мозги не заточены под МСА, а советы других он будет воспринимать как чудовищную глупость.
  3. Архитектура разрабатывается архитекторами без опыта разработки
    Вот сидит такой архитектор, который за свою жизнь не написал ни строчки кода и выдает распоряжения разработчикам. Очень часто, разработчики оказываются более квалифицированными чем он сам, но он как наполеончик отдает распоряжения. Распоряжения конечно же глупые. Примеры этих распоряжений смотрите дальше.
  4. Повторить функционал монолитной системы.
    Ну это же логично: надо сначала полностью воспроизвести то, что уже есть, а потом двигаться дальше. Воспроизвести все баги и костыли, все то дерьмо, от которого годами плюются разработчики.
    Мне одно не понятно: с чего эти архитекторы взяли, что потом кто-то даст денег на рефакторинг? Т.е. вы копируете вашу морально устаревшую систему, не привносите ничего положительного с точки зрения функционала и с этим 20 летним старьем вы будете жить еще как минимум 10 лет до следующего рефакторинга.
  5. Переиспользование кода
    Любой монолитчик знает, что код надо переиспользовать. Если сделал функцию User::toString, то в рамках МСА ее сейчас нужно выделить в отдельный микросервис и все 1000 других микросервисов будут ломиться к ней для сериализации каждого юзера. То, что первый же сбой в микросервисе положит всю систему в монолитах же такого не было.

Впервые с боевой микросервисной архитектурой я столкнулся в 2017 году. К тому времени система уже работала 7 лет и за это время произошла полная смена команды.
Сотни микросервисов. Документации никакой нет. Нет даже простого описания назначения каждого микросервиса. И вообще не понятен каков статус микросервиса: функционирует, деактивирован, экспериментальный и пр. В случае возникновения проблемы, трассировка микросервисов превращалась в сплошной кошмар. В итоге, в команде просто никто долго не держался. Текучка стала бичом команды. За 3 месяца команда могла просто обновиться полностью.
Это реальная история неудачно спроектированной микросервисной системы. Такой финал ждет подавляющее большинство пилотов, которые сейчас стартовали. А все из-за ошибок, которые я перечислил выше.


А сейчас я хочу рассказать как надо разрабатывать микросервисную систему.


  1. Проанализируйте свой предыдущий опыт, составьте список того, что считаете удачным, а что вам следует пересмотреть. Проведите опрос клиентов, пускай они запросят необходимые изменения в функционале. Ваша цель путем одного мелкого и ювелирно точного рефакторинга достичь нескольких бизнесовых целей. Ваша цель не переписывать одно и то же 10 раз, а создавать бизнес-продукт, который будет приносить деньги. Вы не просто должны сделать копию легаси-системы, а должны построить новейшую систему, которая выведет вас на передовой край ИТ отрасли. Зачем вам эти старые костыли?
  2. Пересмотрите свои бизнес-процессы. Если у вас любой agile всегда скатывается к жесткому водопаду, если согласования и аналитика занимают месяцы, то ваше производство ПО требует кардинальной модернизации. А для этого нужно ...
  3. найти специалиста с большим опытом разработки микросервисных систем. Пускай он не посвящен в ваши бизнес-процессы, но этот новый человек посмотрит на ваши застарелые проблемы свежим взглядом и даст действительно ценные рекомендации. Кроме того, только человек с реальным опытом микросервисной разработки способен предусмотреть те подводные камни, которые вам встретятся. Ваш опытный монолитчик только все запорет.
  4. Легаси-разработчики это ваш резерв, который в новой разработке сможет выступить ценным экспертным звеном. Но люди, которые пилили монолит в виде костылей, ни в коем случае не должны стать костяком разработки микросервисной системы и определять ее архитектуру. Монолитчиков должна ждать стажировка под руководством людей с опытом построения микросервисных систем. И главное что ждет монолитчиков это жесткий слом мозга и полная перестройка мышления.
  5. Каждый микросервис это не просто мелкая функция бэкенда. Это полный цикл разработки бизнес-функции. Одна команда полностью должна нести ответственность за всю разработку этой бизнес-функции как на фронтенде, так и в базе данных. Как только вы начинаете делегировать часть разработки другим командам, вы тут же начинаете погрязать в интеграциях. Интеграции в МСА это еще более дорого, ненадежно и неэффективно чем в монолите. Необходимо снижать их количество. В качестве микросервиса вполне нормально выбрать CRUD для какой-то сущности, например, сущности клиентского договора. Это нормально, если команда предоставит как бэкенд, так и фронтенд-микросервис (или библиотеку) для работы с договорами: список, создать, обновить, удалить. Главное это чтоб команда несла полную ответственность за то как эта функция будет работать на сайте и в мобилах.
  6. Не нужно заниматься фанатизмом при внедрении микросервисной архитектуры. При правильной микроархитектуре сервисов, вы сами решаете в какой форме выпустить приложение: в монолитной, микросервисной или бессерверной архитектуре. Ожидайте, что ваша бизнес-постановка может измениться в любой момент и вы должны с легкостью реализовать изменения. Гибкая разработка это то что просто без лишней болтовни должно реально применяться на всех уровнях.
  7. С недоверием относитесь к переиспользованию функционала. Наоборот, любой функционал должен дублироваться. Ваш выигрыш 10 гигабайт дисковой памяти никого не впечатлит, если справочник, который используют 30 микросервисов будет остановлен из-за сбоя, приведя к каскадному отключению всей микросервисной системы. Микросервисы должны КУПИРОВАТЬ сбои сторонних сервисов, а не усиливать их. И этот принцип это главная проблема для монолитчиков. После 20 лет работы с реляционными БД, после десятилетий опыта нормализации таблиц и структур данных в приложениях, очень сложно приучить себя к мысли, что дублирование, репликация, шардирование, денормализация это нормально и полезно для проекта, а переиспользование и нормализация это потенциально сбойные места, готовые положить всю систему.
  8. И вообще, что произойдет после сбоя одного из модулей? Вы просто должны моделировать все такие сбои и штатно обрабатывать их. Каскадное отключение всей системы это лишь один из сценариев. Неприятностей может быть много. Это в монолите все компоненты находятся в одном Jar-нике. В МСА каждый микросервис отделен ненадежными и компроментируемыми сетевыми коммуникациями. Это не плохо и не страшно. Это надо просто держать в голове при разработке и предусматривать сценарии разрыва этих коммуникаций.
  9. Если вы очень любите Spring, Hibernate и OracleDB, то скорее всего вы никогда не сможете построить надежную и быструю микросервисную систему. Spring был изобретен в годы становления монолитной архитектуры. Это огромный монстр, который даже в функции простого Hello World превратится в jar-файл размером в сотни мегабайт. Просто старт такого приложения растягивается на минуты. И эти гигабайты бессмысленного цифрового мусора будут пожирать ваши серверные ресурсы 24x7x365. Oracle, Postgres, MySQL это все жуткое старье, которое было построено из расчета, что база данных должна крутиться на одном сервере. Да, время идет и все эти базы данных обзавелись средствами масштабирования, но до сих пор они в этом вопросе совершенно неуклюжи и ненадежны. Существуют целые классы баз данных (NoSQL, NewSQL), которые создавались в парадигме Big Data, High Availability, распределенное хранение и т.д. И эти ораклы с постгресами с ними просто не способны конкурировать по надежности и скорости работы. Все эти крутые спринги, ораклы и хайбернейты это наследие уходящей эпохи монолита. Эпоха микросервисов и облачных функций это быстрый старт приложений при возникновении нагрузки, отсутствие состояний для высокой масштабируемости и безжалостная выгрузка всех приложений и ресурсов, которые в данный момент не нужны и лишь бессмысленно расходуют оперативную память.

Заключение.


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


Подробнее..

Скрытые расходы при переходе на микросервисы

03.12.2020 12:07:50 | Автор: admin

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

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

С этой темой я выступал на ArchDays 2020. По ссылке вы найдете слайды и видео (скоро будет опубликовано) выступления https://blog.byndyu.ru/2020/12/archdays-2020.html.

1 Изменение подхода к работе с мастер-данными

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

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

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

  1. анализ схемы данных монолита,

  2. анализ потоков обработки данных,

  3. анализ использования данных сторонними системами,

  4. бизнес-цели компании по работе с данными,

  5. "нарезка" данных по новым базам,

  6. миграция данных в новые базы микросервисов,

  7. тестирование миграции.

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

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

2 Невозможность переиспользования исходного кода монолита

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

Практика показывает, что границы ответственности так или иначе растекаются внутри монолита. Из-за этого не получается использовать "копипаст" из монолита для заполнения микросервиса кодом. Весь код и тесты придется написать с нуля для правильного разделения ответственностей по микросервисам.

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

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

3 Проектирование системы заново

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

Запланируйте время IT-архитектора, бизнес-аналитиков и стейкхолдеров на анализ бизнес-требований. Кроме этого, запланируйте время на проектирование API будущей системы.

4 Создание нового подхода к управлению инфраструктурой

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

Что нужно учесть в оценке:

  1. Создание инфраструктуры для управления API: анализ вызовов, система прав, публикация API и т.д. Для примера рекомендую посмотреть функциональность Apigee.

  2. Переход DevOps-инженеров на работу только в концепции IaC и контейнеризацию.

  3. Реализовать тотальное логирование и мониторинг микросервисной архитектуры.

5 Измерение и проверка SLA каждого микросервиса

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

Для любителей SRE уточню, что здесь было бы правильнее использовать термин SLO, потому что SLA = SLO + санкции за нарушение договоренностей.

Другими словами, ранее неявный SLA становятся явными и требует проработки:

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

6 Микросервисы добавят на порядок больше точек отказа

Вместе со значительным увеличением числа сервисов по сравнению с монолитом, вы получаете рост точек интеграции, усложнение процесса CI/CD и распределение мастер-данных, что значительно усложнит всю инфраструктуру. Шанс получить проблему на проде будет очень высоким, если целенаправлено не вкладываться в fault tolerance на всех уровнях: проектирование архитектуры, разработка и тестирование.

Чтобы создавать стабильные системы, выдерживающие "толчки" внешней среды, заложите в бюджет перехода на микросервисы следующее:

  1. Нагрузочное и стресс-тестирование, и, в идеале, применение chaos engineering.

  2. Применение шаблонов проектирования, таких как Circuit Breaker и Tolerant Reader.

  3. Настройка инфраструктуры: service discovery, health-check,...

7 Реорганизация команд

Когда монолит распадется на много маленьких независимых микро-систем, то встанет вопрос, как теперь организоваться людей вокруг этого "роя"?

Общее решение звучит так: создавайте кросс-функциональные команды (build-and-run team) под каждый микросервис. Но есть нюансы. До старта работ обсудите и выберете какая оргструктура подойдет под ваши задачи и ваш бизнес. Обратите внимание на следующее:

  1. Выберите подход к распределению ответственности команд между микросервисами. Например, возьмите вот такой Service per team.

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

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

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

Ремарка о постепенности перехода

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

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

8 Обратная совместимость с монолитом

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

Вторая часть работы связана с тем, что монолит не всегда готов принимать потоки данных в протоколах и форматах удобных для микросервисов. Например, монолит работает с SOAP, а вы всё реализовываете на protobuf, или монолит знает WCF, а вы пишите на .NET Core, где WCF реализован частично. Поэтому часто приходится доделывать функции в монолите, чтобы микросервисы могли отсылать в него данные. Чтобы эти задачи были сделаны, нужно заранее договориться с командой монолита с каким приоритетом и по какому процессу они будут принимать задачи от команды микросервисов.

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

9 Интеграция и обучение служб поддержки

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

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

10 Догоняющий поток фич от бизнеса

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

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

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

  2. Договориться с бизнесом о процессе внесения новых фич в период жизни обеих систем.

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

Чеклист

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

  1. Мастер-данные

  2. Написание кода по-новому

  3. Проектирование IT-продукта заново

  4. Создание новой инфраструктуры

  5. Измерение и проверка SLA

  6. Вклад в fault tolerance на всех уровнях

  7. Реорганизация команд

  8. Работы по обратной совместимости

  9. Интеграция служб поддержки

  10. Догоняющий поток фич

Если в плане перехода вы учли все пункты, то скорее всего довольно точно попадете в оценку.

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


Ссылки для погружения:

  1. The Death of Microservice Madness in 2018, Dave Kerr

  2. The hidden costs of microservices, Wayne Geils, Mike Hostetler

  3. Microservice Trade-Offs, Martin Fowler

  4. Pattern: Microservice Architecture, Chris Richardson

  5. The Hidden Costs of Microservices, Justin Leitgeb

  6. Challenges and benefits of the microservice architectural style Part 1 + Part 2, Andr Fachat

Подробнее..

Перевод Мониторинг и управление потоком задач в рамках взаимодействия микросервисов

14.01.2021 14:20:31 | Автор: admin


Ключевые тезисы:

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


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

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


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


Хореографируемый поток событий.

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


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

Потеря прозрачности потока событий


Я хочу сосредоточиться на вопросе, возникающем чаще всего, когда я участвую в обсуждениях этой архитектуры: Как избежать потери прозрачности (и, вероятно, контроля) потока событий? В одном из исследований сотрудники Camunda (где я работаю) спрашивали об использовании микросервисов. 92 % респондентов как минимум рассматривали их, а 64 % уже использовали в том или ином виде. Это уже не хайп. Но в том исследовании мы также спрашивали и о трудностях, и получили чёткое подтверждение наших опасений: чаще всего нам говорили о потере сквозной прозрачности бизнес-процессов, задействующих многочисленные сервисы.


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

Обеспечение прозрачности


Что можно сделать в такой ситуации? Следующие подходы помогут вам вернуть прозрачность, но у каждого из них есть свои достоинства и недостатки:

  1. Распределённая трассировка (например, Zipkin или Jaeger).
  2. Озёра данных или аналитические инструменты (например, Elastic).
  3. Контроль и анализ процессов (process mining) (например, ProM).
  4. Отслеживание с помощью автоматизации потоков задач (например, Camunda).

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

Распределённая трассировка


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


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

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

  • В трассировке трудно разобраться неспециалистам. Все мои попытки показать трассировки людям, далёким от техники, с треском провалились. Оказалось гораздо лучше потратить время на перерисовку той же информации в виде блоков и стрелок. И даже если вся эта информация о вызовах методов и сообщениях очень полезна для понимания схем взаимодействия, она оказывается слишком подробна для понимания ситуации с межсервисными бизнес-процессами.
  • Для управления избыточным объёмом подробных данных в распределённой трассировке применяется так называемое сэмплирование. Это означает, что собирается лишь небольшая доля запросов, и обычно больше 90 % всех запросов вообще не регистрируется. Об этом хорошо написано в статье Three Pillars with Zero Answers towards a New Scorecard for Observability. Так что у вас никогда не будет полной картины происходящего.

Озёра данных или аналитические инструменты


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


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


Пример интерфейса мониторинга событий.

К недостаткам можно отнести отсутствие графиков, облегчающих работу со списком событий. Но вы можете добавить их в инфраструктуру, скажем, проецируя события в средство визуализации вроде BPMN. Небольшие фреймворки наподобие bpmn.io позволяют добавлять информацию в диаграммы, выводимые в виде простых HTML-страниц (пример), которые можно запаковать в Kibana плагин.


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

Инструменты для контроля и анализа процессов (process mining)


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

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


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


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

Отслеживание с помощью автоматизации потоков задач


Другой интересный подход моделирование потоков задач с последующим развёртыванием и исполнением посредством модуля управления. Эта модель особенная в том смысле, что она только отслеживает события, а сама ничего активно не делает. То есть ничем не управляет только регистрирует. Я рассказывал об этом на Kafka Summit San Francisco 2018, используя для демонстрации Apache Kafka и open source-модуль управления рабочими процессами Zeebe.


Эта возможность особенно интересна. В сфере модулей управления немало инноваций, что приводит к появлению инструментов, которые компактны, удобны для разработки и высокомасштабируемы. Я писал об этом в статье Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation. К очевидным недостаткам относится необходимость предварительного моделирования потока задач. Но зато эту модель можно исполнять с помощью модуля управления процессами, в отличие от мониторинга событий. По сути, вы запускаете экземпляры процессов для входящих событий или соотносите события с каким-либо экземпляром. Также это позволяет проверить, соответствует ли реальность вашей модели.

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


Пример мониторинга потока задач.

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

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

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


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

От отслеживания к управлению


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

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


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

Оркестрация


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

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

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

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


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

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


Заключение


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

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

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

Перевод О наблюдаемости микросервисов в Kubernetes

17.03.2021 16:04:48 | Автор: admin

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

Привет, Хабр. В рамках курса "Microservice Architecture" подготовили для вас перевод материала.

Также приглашаем на открытый вебинар по теме
Распределенные очереди сообщений на примере кафки.


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

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

Наблюдаемость зиждется на трех столпах:

  • Логи (журналы) событий: запись событий, произошедших в системе. События (events) дискретны и содержат метаданные о системе на тот момент, когда они происходили.

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

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

Теперь к насущному вопросу как все это реализовать для наших микросервисов в кластере Kubernetes?

Микросервисы Kubernetes-приложение

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

Давайте рассмотрим микросервисное приложение, которое предоставляет информацию о погоде для конкретного города.

  • Weather-front: компонент, который состоит из фронтенда с интерфейсом для ввода названия города и просмотра информации о погоде. Смотрите скриншот выше.

  • Weather-services: компонент, который в качестве входных данных принимает название города и вызывает внешний погодный API для получения сведений о погоде.

  • Weather-db: это компонент с базой данных Maria, в которой хранятся данные о погоде, которые извлекаются для отслеживаемого города в фоновом режиме.

Указанные выше микросервисы развертываются с помощью объекта развертывания (Deployment object) Kubernetes, а ниже результат выполнения команды kubectl get deploy.

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

Weather-front:

- image: brainupgrade/weather:microservices-front  imagePullPolicy: Always  name: weather-front

Weather-services:

- image: brainupgrade/weather-services:2.0.0  imagePullPolicy: Always  name: weather-services

Weather-db:

- image: mariadb:10.3  name: mariadb  ports:  - containerPort: 3306    name: mariadb

Наблюдаемость Столп первый Логи событий

Чтобы реализовать первый столп наблюдаемости, нам нужно установить стек EFK: Elasticsearch, Fluentd и Kibana. Ниже приведены несложные шаги по установке.

Elasticsearch и Kibana:

helm repo add elastic https://helm.elastic.cohelm repo updatehelm install --name elasticsearch elastic/elasticsearch --set replicas=1 --namespace elasticsearchhelm install --name kibana elastic/kibana

Fluentd:

containers:- name: fluentd  imagePullPolicy: "Always"  image: fluent/fluentd-kubernetes-daemonset:v1.12.0-debian-elasticsearch7-1.0  env:    - name:  FLUENT_ELASTICSEARCH_HOST      value: "elasticsearch-master.elasticsearch.svc.cluster.local"    - name:  FLUENT_ELASTICSEARCH_PORT      value: "9200"

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

При запуске Fluentd вы увидите следующее (Fluentd запускается как Daemonset - скриншот 4):

Вскоре логи начнут помещаться в Elasticsearch. Их можно будет просмотреть в Kibana:

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

Наблюдаемость Столп второй (распределенная) трассировка

Для распределенной трассировки (distributed tracing) у нас есть несколько альтернатив Java-приложения, такие как Zipkin, Jaeger, Elasticsesarch APM и т. д.

Поскольку у нас уже есть стек EFK, давайте воспользуемся APM, предоставляемым Elasticsearch. Во-первых, давайте запустим сервер APM как Kubernetes Deployment.

Код развертывания сервера Elastic APM:

containers:- name: apm-server  image: docker.elastic.co/apm/apm-server:7.5.0  ports:  - containerPort: 8200    name: apm-port

Как только сервер APM запущен, нам следует неинвазивно добавить агента APM в наши микросервисы. Смотрите приведенный ниже фрагмент кода, используемый для микросервиса weather-front. Аналогичный код следует использовать и для компонента weather-services.

Код агента APM для микросервиса weather-front:

initContainers:- name: elastic-java-agent  image: docker.elastic.co/observability/apm-agent-java:1.12.0  volumeMounts:  - mountPath: /elastic/apm/agent    name: elastic-apm-agent  command: ['cp', '-v', '/usr/agent/elastic-apm-agent.jar', '/elastic/apm/agent']   containers:  - image: brainupgrade/weather:microservices-front    imagePullPolicy: Always    name: weather-front    volumeMounts:    - mountPath: /elastic/apm/agent      name: elastic-apm-agent             env:      - name: ELASTIC_APM_SERVER_URL        value: "http://apm-server.elasticsearch.svc.cluster.local:8200"      - name: ELASTIC_APM_SERVICE_NAME        value: "weather-front"      - name: ELASTIC_APM_APPLICATION_PACKAGES        value: "in.brainupgrade"      - name: ELASTIC_APM_ENVIRONMENT        value: prod      - name: ELASTIC_APM_LOG_LEVEL        value: DEBUG      - name: JAVA_TOOL_OPTIONS        value: -javaagent:/elastic/apm/agent/elastic-apm-agent.jar

После повторного развертывания компонентов микросервисов, вы можете перейти в Observability -> APM console в Kibana, чтобы наблюдать, как появляются сервисы (смотрите на скриншот 6).

После того, как вы кликните на сервис weather-front, вы сможете увидеть транзакции:

Кликните на любую из транзакций, и вы увидите детализированное представление с более подробной информацией о транзакции, которая включает задержку, пропускную способность, фрагмент трассировки (trace Sample) и т. д.

На приведенном выше скриншоте показана распределенная трассировка, на которой четко проиллюстрирована взаимосвязь микросервисов weather-front и weather-services. Кликнув по Trace Sample, вы перейдете к сведениям транзакции (transaction details).

Раскрывающийся список Actions в сведениях о транзакции предоставляет возможность просматривать логи для этой конкретной транзакции.

Что ж, на данный момент мы рассмотрели два столпа наблюдаемости из трех.

Наблюдаемость Столп третий Метрики

Для реализации третьего столпа, то есть метрик, мы можем использовать дашборд служб APM, где фиксируются задержка (Latency), пропускная способность (Throughput) и процент ошибок (Error rate).

Кроме того, мы можем использовать плагин Spring Boot Prometheus Actuator для сбора данных метрик. Для этого сначала установите Prometheus и Grafana, используя следующие простые команды:

Prometheus и Grafana:

helm repo add prometheus-community  https://prometheus-community.github.io/helm-chartshelm repo add grafana https://grafana.github.io/helm-chartshelm repo updatehelm install --name prometheus prometheus-community/prometheushelm install --name grafana grafana/grafana

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

template:   metadata:     labels:       app: weather-services     annotations:       prometheus.io/scrape: "true"       prometheus.io/port: "8888"       prometheus.io/path: /actuator/prometheus     containers:       - image: brainupgrade/weather-services:2.0.0         imagePullPolicy: Always         name: weather-services         volumeMounts:         - mountPath: /elastic/apm/agent           name: elastic-apm-agent                  env:           - name: management.endpoints.web.exposure.include             value: "*"           - name: spring.application.name             value: weather-services           - name: management.server.port             value: "8888"           - name: management.metrics.web.server.request.autotime.enabled             value: "true"           - name: management.metrics.tags.application             value: weather-services

После повторного развертывания микросервисов откройте Grafana, импортируйте дашборд с id 12685 и выберите микросервис, метрики которого вы хотите увидеть. На скриншоте ниже приведен weather-front:

И чтобы увидеть метрики всего кластера, импортируйте дашборд Grafana с id 6417, и вы увидите что-то вроде:


Узнать подробнее о курсе "Microservice Architecture".

Смотреть открытый вебинар по теме Распределенные очереди сообщений на примере кафки.

Подробнее..

Переход на микросервисную архитектуру

19.09.2020 00:21:00 | Автор: admin


Вместо введения


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

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

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

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

С чего все начиналось


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

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



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

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

  1. выносим в микросервисы то, что (как мы думали) вынести проще всего;
  2. выносим в микросервисы то, чей перевод на микросервисы решает больше всего проблем как для бизнеса, так и для ИТ.

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

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

Первые трудности


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



Лучше всего архитектуру наших отдельных систем иллюстрирует вот эта картинка, взятая из статьи Стефана Тилкова Dont start with a monolith. Как мы видим, функциональные блоки в монолите крайне сильно связаны друг с другом. Это является серьезным препятствием для процесса выноса отдельного функционала в микросервис.

Для справки: возраст наших монолитов около 13 лет, а размер кодовой базы среднего монолита примерно 1,2 млн строк.

Другими словами, команда раз за разом сталкивалась со следующими проблемами:

  • крайне трудоемкий процесс аналитики существующего функционала;
  • часто недостаточное понимание того, что именно мы выносим в микросервис;
  • сложности интеграции монолита с новым микросервисом.

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

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

Первые успехи и новые трудности




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

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

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

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

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

Что ж

Карантин, трудовые подвиги и наконец успех


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

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

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

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



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


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

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

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

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

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

Как итог


Вместо заключения хотелось бы остановиться на выводах, которые мы для себя сделали

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

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

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

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

Внести массовые изменения в микросервисы, автоматизировать код-ревью и сберечь нервы команде

11.12.2020 14:05:39 | Автор: admin
Представьте ситуацию ваше задание на работе изменить формат логирования. Сначала всё кажется просто. Ровно до того момента, пока все эти изменения не нужно вносить в 80+ микросервисах И так легкая на первый взгляд задача превращается в длинную и рутинную. Что можно с этим делать?

Или вот еще задачка какими фичами можно обеспечить скорость, качество и удобство code review?

Обо всём этом рассказывают Java-разработчики ЮMoney в своих докладах. Добавляйте в закладки или смотрите прямо сейчас. Видео с таймкодами уже ждут под катом.





Automate it! Внесение типовых изменений в микросервисы


Вита Комарова, старший Java-разработчик
Эксперт рассказывает, как запустить массовые изменения, поддерживать стандарты и сберечь нервы всей команды

1:03 О микросервисной архитектуре в ЮMoney и не только
2:17 Задача изменить формат логирования. Что нужно сделать?
3:00 Разделяем работу по командам: плюсы и минусы
4:02 Примеры массовых изменений
4:34 Решение автоматизация
4:47 Шаги раскатки изменений
6:05 Реализация автоматизации: о роботе Modernizer
8:09 Что такое Flow? Различные сценарии патчинга
8:58 Что умеет Modernizer? Техническая реализация
10:26 Результаты работы
10:57 Контроль патча
12:34 Путь задачи после merge
13:15 Давайте автоматизируем тестирование
14:40 Про Automerge и автоматизация релиза
16:13 История глазами разработчика
17:42 Итоги: жизнь до и после Modernizer
20:18 В чем секрет нашего успеха?
21:42 Наши выводы и советы команды ЮMoney




Автоматизация код-ревью. Два года спустя


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

1:31 О бэкенде в ЮMoney, наши инструменты
3:29 О чем пойдет речь в докладе
5:12 О code review и зачем его улучшать
7:25 Код-ревью на словах и на деле. Личный опыт
10:07 Система и функциональность код-ревью. Фичи ЮMoney
10:30 Скорость
14:42 Качество
18:47 Удобство
24:22 Топ фичей в код-ревью
25:07 План доработок




Все доклады с большой ИТ-конференции ЮMoneyDay. На подходе материалы про SQL, DevOps, фронтенд, PM, тестирование и мобильную разработку.

Подробнее..

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

19.02.2021 16:11:01 | Автор: admin

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

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

Не используйте для разработки ERP-систему

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

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

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

То есть, грубо говоря, система управления заказами (OMS) сама маршрутизирует потоки (подборы товаров, идентификация позиций товаров по конкретным поставщикам и т.д.). Должны быть автоматизированы все процессы системы: управление каталогом, программы лояльности, витрина и т.д.

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

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

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

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

И в конечном итоге компания жалуется на результат, потому что ожидания не совпадают с реальностью. Ждали резкого взлета в продажах, а получили не более 10% от общего оборота. Все это довольно грустно. Но выход есть.

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

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

Суть микросервисной архитектуры состоит в том, что каждая отдельная функция (набор функций) выделяется в самостоятельную систему. То есть OMS (управление заказами), PIM (управление товарным каталогом), система биллинга, транспортная система, личный кабинет, программа лояльности, склад и т.д. - все это отдельные системы в единой архитектуре.

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

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

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

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

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

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

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

Как начать работу с проектом по запуску маркетплейса

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

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

  • формирование ключевых систем автоматизации маркетплейса в формате To be;

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

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

  • формирование ключевых требований к инфраструктуре.

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

Подробнее..

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

25.03.2021 22:22:00 | Автор: admin

В преддверии старта курса "Microservice Architecture" подготовили для вас традиционный перевод материала.


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

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

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

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

Бессерверные функции

Бессерверные функции (Serverless Functions, также известные как FaaS, функция как сервис) - это блоки определенной логики, которые создаются и выполняются в ответ на заданные события, такие как HTTP-запросы или сообщения, полученные в топике Kafka. По завершении своего выполнения такие функции исчезают, по крайней мере, логически, и их стоимость возвращается к нулю.

FAAS реагирует на HTTP-запросы: множественное параллельное выполнение и модель pay per useFAAS реагирует на HTTP-запросы: множественное параллельное выполнение и модель pay per use

Все крупные общедоступные облака имеют FAAS предложения (AWS Lambda, Azure Functions, Google Functions, Oracle Cloud Functions). Кроме того FAAS также могут быть доступны в локальных вариациях с помощью таких фреймворков, как Apache OpenWhisk. У них есть некоторые ограничения с точки зрения ресурсов (например, для AWS максимум 10 ГБ памяти и 15 минут времени выполнения), но они могут покрыть многие варианты использования современных приложений.

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

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

Преимущества FaaS

Когда бессерверные функции простаивают, они ничего вам не стоят (модель Pay per use). Если бессерверная функция вызывается 10 клиентами одновременно, 10 ее инстансов запускаются почти одновременно (по крайней мере, в большинстве случаев). Полное предоставление инфраструктуры, управление, высокая доступность (по крайней мере, до определенного уровня) и масштабирование (от 0 до лимитов, определенных клиентом) полностью предоставляются командами специалистов, работающих за кулисами.

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

Таким образом, FaaS подразумевает два больших преимущества.

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

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

Эластичность и затраты

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

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

Когда мы хотим запустить новый сервис, модель FaaS, вероятно, будет лучшим выбором. Бессерверные функции можно быстро настроить и минимизировать затраты на инфраструктуру. Их модель pay per use подразумевает отсутствие стартовых вложений. Их возможности масштабирования обеспечивают стабильное время отклика при различных уровнях нагрузки.

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

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

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

Бессерверные функции могут СЭКОНОМИТЬ ВАМ МНОГО ДЕНЕГ, ровно также как и могут СТОИТЬ ВАМ БОЛЬШИХ ДЕНЕГ

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

Пример приложения. Рассмотрим приложение, которое получает 3.000.000 запросов в месяц. Обработка каждого запроса с помощью Lambda с 4 ГБ памяти занимает 500 мс (ЦП назначается автоматически в зависимости от памяти).

FaaS имеет модель pay per use, поэтому, независимо от кривой нагрузки (будь то пиковая или фиксированная), стоимость в месяц является фиксированной: 100,60 долларов США.

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

Сценарий с пиками нагрузки. Если для нагрузки характерны пиковые моменты, и мы хотим гарантировать постоянное хорошее время отклика для наших клиентов, нам необходимо определить размер инфраструктуры, чтобы выдерживать пиковую нагрузку. Если на пике у нас есть 10 одновременных запросов в секунду (что вполне возможно, если 3.000.000 запросов сосредоточены в определенные часы дня или в определенные дни, например, в конце месяца), вполне возможно, что нам понадобится виртуальная машина (AWS EC2) с 8 процессорами и 32 ГБ памяти, чтобы обеспечить ту же производительность, что и Lambda. В этом случае ежемесячная стоимость подскочит до 197,22 долларов США (можно сэкономить при заключении многолетнего контракта, но это снижает финансовую гибкость). Затраты увеличились почти вдвое. Эту разницу можно уменьшить путем динамического включения и выключения экземпляров EC2 в зависимости от нагрузки, но для этого требуется, чтобы нагрузка была предсказуемой, что увеличивает сложность и стоимость решения.

Сценарий с равномерной нагрузкой. Если нагрузка в основном равномерная, то дела обстоят совсем по другому. Если нет пиков, то мы можем легко выдержать нагрузку с помощью гораздо более дешевой машины. Вероятно, будет достаточно виртуальной машины с 2 процессорами и 8 МБ памяти, а ежемесячные затраты в этом случае составят 31,73 доллара США, что меньше трети стоимости Lambda.

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

Тут возникает вопрос: как мы можем достичь такой гибкости? Насколько это будет сложно?

Анатомия кодовой базы современного приложения

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

  • Логика приложения. Код (обычно написанный на таких языках, как Java, TypeScript или Go), который реализует то, что должно делать наше приложение

  • DevSecOps (CI/CD). Обычно это скрипты и файлы конфигурации, которые автоматизируют сборку, тестирование, проверки безопасности и развертывание приложения.

Логика приложения

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

  • Бизнес-логика. Код, который реализует поведение службы, выраженное в форме логических API (методов или функций), которые обычно ожидают некоторые данные, например, в формате JSON, в качестве входных и возвращают некоторые данные в качестве выходных. Этот код не зависит от технических механизмов, связанных с реальной средой, в которой он выполняется, будь то контейнер, бессерверная функция или сервер приложения. Находясь в контейнере, эти логические API могут быть вызваны чем-нибудь наподобие Spring Boot (если языком является Java), Express (с Node) или Gorilla (с Go). При вызове в бессерверной функции он будет использовать конкретный механизм FaaS, реализованный конкретным облачным провайдером.

  • Код, связанный с развертыванием. Код, который касается механики среды выполнения. Если необходимо поддерживать более одной модели развертывания, должны быть разные реализации этой части (но только этой части). В случае развертывания в контейнерах это та часть, где сосредоточены зависимости от аналогов Spring Boot, Express или Gorilla. В случае FaaS эта часть будет содержать код, реализующий механизмы, определенные конкретным облачным провайдером (функции AWS Lambda, Azure или Google Cloud, которые имеют собственные проприетарные библиотеки для вызова бизнес-логики).

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

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

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

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

Следуя этим двум простым правилам, мы максимизируем объем кода (бизнес-логики), пригодного для использования всеми моделями развертывания, и, следовательно, минимизируем стоимость перехода от одной модели к другой.

Невозможно абстрактно оценить относительные размеры частей бизнес-логики и кода, связанного с развертыванием. Но на примере, анализируя одну простую интерактивную игру, развертываемую как на AWS Lambda, так и на Google Application Engine, выясняется, что код, связанный с развертыванием, составляет 6% от кодовой базы (всего около 7 200 строк кода). Таким образом, 94% кодовой базы одинаковы, независимо от того, работает ли служба в Lambda или в контейнере.

DevSecOps (CI/CD)

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

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

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

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

Стремитесь изолировать то, что не зависит от модели развертывания, и максимизировать это

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

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

Заключение

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

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

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

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


Узнать подробнее о курсе "Microservice Architecture".

Подробнее..

Content Services Platform новая реинкарнация систем электронного документооборота

06.04.2021 10:06:21 | Автор: admin

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

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

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

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

Говорим СЭД, подразумеваем ECM и наоборот


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

Исторически повелось, что все средства автоматизации офисной бюрократии у нас называют СЭД системы электронного документооборота, и этот рынок существует уже тридцать лет. За этот период сменилось несколько поколений систем, и для каждого на Западе придумывали новые термины сначала были RM-системы (Records Management), потом EDMS (Electronic Document Management System) и, наконец, ECM (Enterprise Content Management).

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

ECM приказал долго жить? Отнюдь


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

И вдруг внезапно в 2017 году Gartner заявляет, что ECM умер. И говорит, что отныне это будет рынок CSP Content Services Platforms. Что стоит за этим заявлением и что такое CSP, мы поговорим чуть ниже, а пока специально для спокойствия вашего финдиректора нужно сказать, что речь не идет о том, чтобы взять и выбросить все ECM и купить вместо них CSP. Это эволюционный процесс. Более того, по оценке Mordor Intelligence, глобальный рынок ECM к 2025 году достигнет более 93 миллиардов долларов, то есть за пять лет его стоимость удвоится.

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

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

Источник

Предпосылки появления CSP


Так откуда эти CSP взялись? Конечно, есть соблазн списать все на происки аналитиков, которые выдумывают новые сочетания из трех букв, чтобы продать побольше своих отчетов. Но это было бы слишком просто.

На самом деле накопился пул проблем, которые в рамках ECM не находят решения, и это вызывает фрустрацию у заказчиков. С другой стороны, в ИТ возникли новые глобальные тренды, и на их фоне подход ECM выглядит весьма олдскульным. В общем, назрела революционная ситуация поставщики не могут удовлетворить клиентов, пользователи не хотят страдать от неудобных продуктов. Вот тут и выходит на сцену CSP, который по сути наследует функциональность ECM, однако реализует ее на основе современных архитектурных паттернов и с большим вниманием к пользовательскому опыту (UX).

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

Впрочем, давайте обо всем по порядку.

Почему ECM разонравился клиентам


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

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

Сегодня концепция поменялась вещи должны удовлетворять сиюминутные потребности клиентов и появляться на рынке быстро. Параметр Time-to-Market стал одним из главных при оценке проектов, внедрение изменений в системе должно происходить не за 2-3 года, как раньше, а за 2-3 месяца.

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

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

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

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

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

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

Микросервисы наше все


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

Итак, по определению Gartner, Content Services Platforms это набор служб и микросервисов в виде интегрированного набора продуктов или в виде отдельных приложений, которые используют общие API и репозитории. Они обслуживают отдельные виды контента для различных бизнес-задач организации.

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

По материалам конференции Микросервисная архитектура в управлении корпоративным контентом, 23 апреля 2020. Подробнее

Однако благодаря новой архитектуре CSP существенно отличается от ECM.

  • Web-scale масштабируемость. Больше, чем самая крупная корпорация. CSP должны уметь работать с миллиардами документов и сотнями миллионов пользователей.
  • Cloud-Native. Пусть прямо сегодня клиенты еще поглядывают на облака с подозрением, однако лед уже тронулся, и доля облачных сервисов в корпоративном ИТ-ландшафте будет прирастать, в том числе и за счет сервисов контента.
  • Low-code. Это свойство обеспечивает скорость разработки, тот самый time-to-market. Если вести разработку по старинке, то в нынешние сроки не уложишься.
  • Способность к интеграции. Это нечто большее, чем наличие API. Это свойство должно быть присуще CSP на генетическом уровне, ибо каждый отдельный микросервис сам по себе бесполезен, все компоненты должны взаимодействовать между собой и с любыми внешними источниками данных или функциональными блоками.
  • Всеядность относительно типов контента.CSP должна принимать любой контент, а не только офисные файлы и PDF. Причем не просто хранить и снабжать метаданными, но и уметь заглядывать внутрь, работать с содержащейся в документе информацией.
  • Обучаемый ИИ. Искусственный интеллект (ИИ) становится все более и более распространенным в нашей повседневной жизни. Логично ожидать, что интеллектуальные сервисы будут встроены в CSP изначально и будут применяться для широкого круга задач, а не только для автоматического заполнения регистрационных карточек.

User Experience: все для блага человека


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

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

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

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

Джон Манчини, президент и главный евангелист AIIM, красочно сравнивает эту ситуацию с покупкой напитков отдельными порциями или целыми галлонами (это почти 4 литра). Ну действительно, иногда нам достаточно и пинты (1/8 галлона, если кто забыл). Аналогично, зачем человеку пробираться через множество экранов, когда ему всего-то нужно согласовать документ?

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

Open Source спешит на помощь


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

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

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

Кроме BPM есть построители отчетов, мессенджеры, поисковые движки, средства просмотра документов, встроенные редакторы, планировщики, брокеры сообщений и огромное количество самых разнообразных библиотек. На базе СПО можно собрать практически любую корпоративную систему, не только CSP.

Электронный архив абонентских договоров для Tele2


Системами CSP уже активно интересуются телеком-компании. А именно они, как мы помним, самые прогрессивные в выборе ИТ-решений. Так, компания Tele2 создала электронный архив на CSP-платформе (платформа DocsHouse, разработка ЛАНИТ). Оператор выбирал из порядка десяти решений для управления корпоративным контентом от разных поставщиков и в итоге принял решение в пользу именно такой архитектуры: она, по его мнению, наиболее технологична.

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

Проект в Tele2 и другие проекты внедрения CSP в российских организациях будут представлены на онлайн-конференции ЛАНИТ, которая пройдет 27 апреля https://docshouse.ru/conference2021.

Статья написана в соавторстве с d_levinsky и stas_makarov
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru