Введение Практически каждый второй человек, впервые столкнувшийся с MSA (Micro Service Architecture), сначала восклицает: «Да, я видел эти микросервисы… двенадцать лет назад».
Они отчасти правы.
А я тоже был из этой самой половины и не понимал, почему столько шума? 
Действительно! В конце концов, MSA занимается также разработкой программного обеспечения.
Какие революции здесь могут быть? Все методы знакомы.
Где-то вы даже можете удивиться: «А разве может быть по-другомуЭ» Фанаты Agile и DevOps тоже скажут, что это всё наше, дорогой.
Но я все же прошу вас набраться терпения и продолжить чтение.
Что такое микросервисная архитектура (MSA)
Перефразируя Википедию, определение микросервисной архитектуры может быть таким:М.С.
А.
принципиальный организация распределенного системы на основе микросервисов и их взаимодействия друг с другом и со средой в сети, а также на принципах, определяющих дизайн архитектура, ее создание и эволюция.
Что такое микросервис (МС)
С архитектурой разобрались быстро.Давайте подробнее рассмотрим микросервисы.
Самый простой способ понять суть микросервиса — сравнить или даже противопоставить его большому приложению — монолиту.И далее мы рассмотрим каждый из них более подробно.В отличие от MSA, я не буду давать определение микросервису, а перечислю его наиболее важные характеристики.
Я определил восемь свойств микросервиса:
- Он не большой.
- Он независим.
- Он построен вокруг потребностей бизнеса и использует ограниченный контекст. (Ограниченный контекст) .
- Он взаимодействует с другими микросервисами по сети на основе шаблона.
Умные конечные точки и тупые каналы.
- Его распределенная сущность обязывает нас использовать подход Проектирование на провал .
- Централизация ограничена сверху до минимума.
- Процессы его разработки и поддержки требуют автоматизации.
- Его разработка итеративна.
Лично я на этом этапе стал сомневающимся.
Маленький
Что такое «маленький»? Какая неинформативная формулировка! На самом деле, иначе и не скажешь.Каждый должен определить свой размер.
Лучшая практика.
В качестве ориентировочных оценок можно опираться на рекомендации экспертов.
Размер микросервера должен быть таким, чтобы выполнялось одно из следующих условий:
- Один сервис может разрабатывать одна команда численностью не более десятка человек.
- Команда из полдюжины человек может разработать полдюжины сервисов.
- Контекст (не только бизнеса, но и развития) одного сервиса помещается в голову одного человека.
- Один сервис может быть полностью переписан одной командой за одну итерацию Agile.
Независимый
Микросервисная архитектура — это воплощение шаблонов высокой сплоченности и низкой связанности.Все, что противоречит этому, беспощадно отвергается.
В противном случае команду ждут большие проблемы.
Поэтому микросервис должен быть независимым компонентом.
Здесь я прошу не затевать холивар о том, что такое «компонент».
Давайте в рамках данной статьи согласимся, что
Компонент — это часть программного обеспечения, код которой можно самостоятельно заменять или обновлять.Конечно, любая более-менее серьезная программа пишется разделенной на компоненты, которые, естественно, основаны на одних и тех же принципах.
Но в монолите общая кодовая база открывает возможность нарушения низкой связанности.
А при плохой дисциплине рано или поздно кодекс превращается в спагетти.
Сторонние библиотеки также подходят для этой формулировки компонентов.
Здесь сложнее с нарушением границ произвольными связями, но ненамного.
В то же время методология разделения на отдельные микросервисы вынуждает их придерживаться строгого разделения, поскольку они должны соответствовать более строгим критериям независимости.
Таким образом, каждый микросервис работает в своем собственном процессе и поэтому должен явно указывать свой API. Учитывая, что другие компоненты могут использовать только этот API и что он удален, минимизация связанности становится жизненно важной.
Такое разделение дает явное преимущество с точки зрения независимой разработки различных компонентов.
И с учетом этого в различных языках вводятся конструкции, позволяющие явно создавать независимые компоненты (например, модули в Java 9), и это уже не является прерогативой микросервисного подхода.
Я не хочу создать впечатление, что микросервисная архитектура запрещает использование библиотек.
Их использование нежеланный , так как это так или иначе приводит к зависимостям между микросервисами, но всё же допустимый .
Обычно это предположение распространяется на такие функции инфраструктуры, как ведение журналов, удаленные вызовы API, обработка ошибок и тому подобное.
Независимость микросервисов позволяет организовать независимый жизненный цикл разработки, создавать отдельные сборки, тестировать и развертывать.
Поскольку размер микросервисов невелик, очевидно, что в больших системах их будет много.
Управлять ими вручную будет сложно.
Поэтому команда должна иметь приемлемый уровень автоматизации согласно Непрерывная интеграция И Непрерывная доставка.
Где находится микросервис (потребность бизнеса)
Итак, вы решили разработать новый микросервис.Определение его границ является наиболее важным шагом.
От этого будет зависеть вся дальнейшая жизнь микросервиса, а это серьёзно повлияет на жизнь ответственной за него команды.
Главный принцип определения зоны ответственности микросервиса — сформировать ее вокруг определенной бизнес-потребности.
И чем он компактнее, чем более формализованы его связи с другими областями, тем проще создать новый микросервис.
В общем, довольно стандартное сообщение.
На его основе основано создание любых других компонентов.
Вопрос только в том, чтобы продолжать сохранять эту зону ответственности, о которой мы говорили в предыдущем пункте.
После того как границы микросервиса определены и он выделен в отдельную базу кода, защитить эти границы от внешнего влияния не составит труда.
Далее они создают внутри микросервиса свой микромир, основанный на паттерне «ограниченный контекст».
В микросервисе любой объект, любое действие могут иметь свою интерпретацию, отличную от других контекстов.
Но что, если границы окажутся неправильными? В этом случае изменение функциональности нового микросервиса приводит к изменению функциональности других микросервисов.
В результате интерфейсы всех зависимых микросервисов «поплывут», после чего пройдут интеграционные тесты.
И все превращается в снежный ком.
А если эти микросервисы еще и принадлежат разным командам, то начинаются межкомандные встречи, согласования и тому подобное.
Таким образом, правильные границы микросервисов являются основой здоровой микросервисной архитектуры.
Чтобы минимизировать ошибки при определении границ, нужно их предварительно продумать.
Поэтому оправдан подход Monolith First, когда сначала система разрабатывается в традиционной парадигме, а при появлении устоявшихся областей они разделяются на микросервисы.
Но все течет и меняется.
И границы тоже могут меняться.
Главное, чтобы выгода от разделения превышала трудности пересмотра этих границ.
Этот подход к постепенному созданию набора микросервисов аналогичен итеративной разработке, используемой в Agile, также называемой «эволюционным проектированием».
(Эволюционный дизайн) .
Есть еще одно интересное последствие создания микросервисов, соответствующее закону Конвея.
Если организация использует монолитное приложение, это нарушает согласованность структуры и коммуникации внутри организации.
А команды разработчиков строятся вокруг архитектурных слоев монолита: пользовательского интерфейса, серверной логики, базы данных.
С точки зрения Конвея, микросервисная архитектура приводит ИТ и бизнес в гармонию.
Поскольку микросервисы формируются вокруг бизнес-потребностей конкретных бизнес-подразделений, архитектура предприятия начинает копировать организационную структуру и каналы социальной и деловой коммуникации.
И команды становятся кросс-функциональными и формируются вокруг этих бизнес-потребностей/бизнес-единиц.
Поскольку разные микросервисы независимы не только логически, но и технологически, и создавать их могут разные команды, ничто не мешает подобрать для каждого случая подходящие языки программирования, фреймворки и даже операционные системы.
Интеграция.
Умные конечные точки и тупые каналы Интеграция микросервисов не требует ESB в качестве центрального посредника.
Сообщество, вероятно, уже пострадало от неудачной реализации этого подхода.
То, что были успешные, не учитывается.
Однако ЕСБ также противоречит таким критериям, как децентрализация и независимость.
Таким образом, сложность интеграции распределяется от центрального звена в виде ESB непосредственно к интегрируемым компонентам: «умным конечным точкам».
Для интеграции, как правило, используются простые текстовые протоколы на базе HTTP, чтобы нивелировать возможные технологические различия между микросервисами.
REST-подобные протоколы являются практически стандартом.
В качестве исключения можно использовать двоичные протоколы, такие как Java RMI или .
NET Remoting. Здесь есть дилемма.
Конечно, бинарные протоколы гораздо эффективнее.
Но, во-первых, появляются технологические ограничения.
Во-вторых, сложнее реализовать паттерн Tolerant Reader на бинарных протоколах, сохранив при этом эффективность.
В-третьих, снова появляется зависимость провайдера и потребителей, поскольку они оперируют одними и теми же объектами и методами, то есть связаны кодовой базой.
Еще одна отличительная особенность взаимодействия микросервисов — нежелательность синхронных вызовов.
Рекомендуется использовать один синхронный вызов для каждого запроса пользователя или вообще избегать синхронных вызовов.
И еще пара комментариев.
- Основная трудность разбиения монолита на микросервисы — не определение их границ.
Они уже должны быть сформированы и утверждены.
Проблема в том, что местные звонки становятся удаленными.
И это влияет не только на организацию звонков, но и на стиль взаимодействия, поскольку частые звонки уже не подходят. Скорее всего, придется пересмотреть сам API, сделать его крупнее и, как следствие, пересмотреть логику работы компонентов.
- Поскольку асинхронное взаимодействие на основе событий является практически стандартом в микросервисной архитектуре, необходимо понимать, как создать архитектуру, управляемую событиями, а сами микросервисы должны соответствовать требованиям Reactive.
Проектирование на провал для распределенной системы
Одним из наиболее важных аспектов микросервисной архитектуры является необходимость разработки кода для распределенной системы, составные элементы которой взаимодействуют по сети.А сеть ненадежна по своей природе.
Сеть может просто выйти из строя, работать плохо или внезапно перестать пропускать какой-то тип сообщений из-за того, что изменились настройки брандмауэра.
Десятки причин и видов недоступности.
Поэтому микросервисы могут внезапно перестать отвечать на запросы или начать отвечать медленнее, чем обычно.
И каждый удаленный звонок должен это учитывать.
Должен правильно обрабатывать разные варианты отказа, уметь ждать и уметь вернуться к нормальной работе при восстановлении контрагента.
Дополнительный уровень сложности вносит архитектура событий.
И сложно даже представить себе отладку такой системы — не одного микросервиса, а системы, где много потоков разнонаправленных, неупорядоченных событий.
И даже если каждый из микросервисов безупречен с точки зрения бизнес-логики, этого недостаточно.
По аналогии со спортом, «звезды» не гарантируют звездную команду, потому что в команде важнее не «звезды», а слаженность всех ее игроков.
А поскольку сложность таких систем очень высока, проблема решается таким образом.
- Они не приводят систему в состояние «без сбоев».
Это очень дорого.
Конечно, это не означает, что система рухнет при первом же дуновении.
Он просто отвечает необходимым нефункциональным требованиям.
Но он может содержать ошибки, незначительно влияющие на его стабильность и производительность.
- С другой стороны, они инвестируют в инфраструктуру, которая помогает быстрее устранять чрезвычайные ситуации.
Модульный код должен быть полностью покрыт модульными тестами, интеграционными тестами и тестами производительности.
Должен быть интеллектуальный мониторинг, который не только мгновенно показывает неработающие участки, но и сигнализирует об ухудшении состояния системы и прогнозирует возможные сбои.
Должно быть расширенное распределенное журналирование, позволяющее проводить быстрые расследования.
И часто по результатам исправляются скрытые ошибки.
Децентрализация данных
Еще один из наиболее важных элементов парадигмы микросервисов.
Каждый микросервис имеет свою базу данных!Лозунг популиста на выборах.
Фактически даже в монолите можно бороться за изоляцию компонентов, например, на уровне серверного кода.
Если изоляция время от времени протекает, современные инструменты предлагают передовые инструменты рефакторинга.
Используй это.
Хотя, как правило, на это есть время только тогда, когда дела уже совсем плохи.
Теперь давайте спустимся на уровень базы данных.
Почему-то здесь меньше внимания уделяют изоляции.
В результате через пару лет активного развития в базе монолита образуется если не хаос, то энтропия продвинутого уровня.
Чтобы его преодолеть, одной строчки в отставании недостаточно.
Требуются месяцы кропотливой и долгой работы.
В микросервисной архитектуре это решается гильотиной.
Просто нет общей базы данных.
Помимо изоляции, есть и побочные преимущества.
Например, проще реализовать Полиглот Настойчивость , когда база выбирается для конкретных целей.
Ничто не мешает вам сделать это без микросервисов, и это часто делается.
Но все же в одном случае это закон, в другом – исключение.
У этой медали есть обратная сторона.
Много основ, много контекстов, как их все примирить? Старая техника распределенных транзакций сложна и медленна.
Возможно, иногда это можно преодолеть.
Но потребность в синхронном взаимодействии нескольких микросервисов не может быть удовлетворена и преодолена.
Проблема решается нетрадиционным для монолита способом: отказом от постоянной консистентности данных.
Добро пожаловать в мир Окончательная согласованность .
Поначалу это вызывает волну «справедливого» гнева.
Но если разобраться, везде ли необходима немедленная согласованность данных в конце транзакции? При более внимательном рассмотрении значительную часть дел можно отбросить.
Там, где это возможно, замените одну распределенную транзакцию серией локальных с механизмами компенсации.
Где-то смирились с временным несоответствием.
А возможные ошибки обрабатываются либо посредством более сложной архитектуры, либо благодаря данным мониторинга.
Если ничего не помогает, то в особо крайних случаях все равно используются распределенные транзакции.
Но это, с моей точки зрения, является нарушением принципов MSA. 
Монолит против микросервисов
Микросервисный подход сопряжен с довольно большим количеством проблем.Их нетрудно найти, и каждый может попрактиковаться.
Например, организационные вопросы.
Как поддерживать сотни микросервисов в состоянии с согласованием версий, которые к тому же постоянно и непредсказуемо перераспределяются.
Имеет ли каждый инженер в каждой команде доступ к среде? Какая команда будет писать интеграционные тесты? А если кто-то согласен, то попробуйте написать им еще раз для такой запутанной конфигурации.
А если возникнет ошибка, то чья она? Только та команда, которая сломалась? Как можно не узнать вечером в пятницу, что используемая вами API-версия N-го сервиса внезапно стала устаревшей? Да, это действительно проблемы.
Но команды, практикующие Agile и DevOps, уже знают решение.
Поэтому начинать путь к микросервисной архитектуре стоит с внедрения этих практик.
Помимо организационных, есть и чисто архитектурные.
Как перейти от монолита, где все синхронно, согласованно и унифицировано, к распределенной событийной архитектуре, основанной на множестве мелких элементов, в которой необходимо учитывать возможную несогласованность данных? Одного этого достаточно, чтобы задуматься: стоит ли игра свеч? На этом фоне, например, падение скорости обработки одного запроса кажется мелочью.
По крайней мере, это работает! 
Почему? Если у вас нет проблем с вашим «монолитом», то и искать их не нужно.
Но если есть проблемы, то посмотрите на преимущества MSA, возможно, это вас спасет. Разделение на независимые компоненты дает безусловные и неоспоримые преимущества: простое понимание контекста, гибкость разработки, управления и масштабирования.
Независимость и небольшой размер также дают неожиданные преимущества с точки зрения инфраструктуры.
Вам больше не нужна машина-монстр за 100 500 долларов.
Микросервисы можно устанавливать на обычные дешевые машины.
И получается, что даже все они вместе будут стоить на порядок меньше, но работать будут эффективнее, чем та самая супермашина, на которую ваша организация наверняка молится и сдувает с нее пыль.
Здесь уместен еще один лозунг от популиста.
Хотя, как и предыдущий, вполне серьезный.
У каждого микросервиса есть свой сервер!Давайте продолжим выступать за микросервисы.
Давайте посмотрим на лидеров IT-индустрии: Amazon, Netflix, Google и другие показывают впечатляющие результаты.
Их гибкость и скорость внедрения новых продуктов поразительны.
Поэтому игра определенно стоит свеч! Здесь уместно вспомнить, что в упомянутых организациях нет одной и двух команд «божественного уровня».
Они вполне способны справиться со сложностями микросервисной архитектуры.
А если вы предложите создать монолит, то сделают так, чтобы он сверкал как путеводная звезда.
И, например, Amazon неплохо поработал на монолите, уже будучи гигантом и имея миллиардные обороты.
Веб-сайт газеты Guardian по-прежнему, а возможно, и навсегда, основан на микросервисах вокруг монолита.
Это говорит о том, что значительную часть проблем можно успешно, а зачастую и проще, решить без использования микросервисов.
Тем не менее, это не означает, что микросервисы не для вас.
Не боги обжигают горшки.
Но и в бассейн с головой бросаться не стоит. Для микросервисной архитектуры команда должна быть достаточно зрелой.
Один из главных критериев: использует ли он Agile и DevOps? Команда должна быть компетентной.
Это сложно формализовать, но все же постарайтесь трезво оценить возможности.
Например, насколько продвинута команда в области реактивной и событийно-ориентированной архитектуры? Кроме того, команда должна иметь подготовленную инфраструктуру для поддержки микросервисной системы.
Однако этого достаточно.
Просто попробуйте.
Надеюсь, это сработает и вам понравится.
Теги: #архитектура #Высокая производительность #Микросервисы #Системный анализ и проектирование #проектирование и рефакторинг #микросервисная архитектура #raiffeisenbank #raiffeisen
-
Jsoc: Как Готовить Инциденты
19 Oct, 24 -
Обложки Для Rpw™: Как Это Было
19 Oct, 24 -
Однопейджеры И Seo. Секреты Оптимизации
19 Oct, 24
