Привет, меня зовут Диана, я системный аналитик, но биолога и препода так просто из себя не вытравить. Поэтому вернулась к вам с ещё одной статьёй. И это будет большая статья-размышление, так что морально подготовьтесь). Все мои профессии – и бывшие, и нынешняя – предполагают постоянную необходимость учиться и разбираться в чём-то новом (по крайней мере, для себя).
Я не буду сейчас подробно останавливаться на методах и способах познания (дайте знать, если интересно – возможно, это станет темой отдельной статьи), а хочу познакомить вас с одной аналогией, которая в своё время помогла мне усвоить, как же работает микросервисная архитектура.
Скрытый текст
Напомню, аналогия (др.-греч. ἀναλογία, от ana - по образцу, и logos - рассудок) – это:
а) сходство предметов, явлений, процессов, величин и т. п. в каких-либо свойствах;
б) познание путем сравнения;
в) метод умозаключения, по которому, на основании сходства между предметами в одном отношении, заключают о сходстве их и в других отношениях.
Делать строгие умозаключения мы здесь не будем. Это не исследование и уж точно не введение в биоинформатику. Скорее, хочется показать вам приём – способ понять, усвоить и запомнить тему. Потому что наш мозг так устроен: ему проще запоминать новое, если есть за что зацепиться из уже знакомого.
На самом деле биология регулярно помогает мне разбираться в самых разных областях: кибербезопасность и иммунная система, нейросети и нервная система, разработка и эволюция, программный код и код генетический. Если такие аналогии вам тоже по душе, к ним можно будет вернуться позже. А в этой статье мы всё-таки сосредоточимся на микросервисной архитектуре и клеточном строении организма.
Разберемся, чем микросервисы похожи на клетки, поднимемся на уровень модулей и органов, а потом посмотрим на продукт как на организм. Поехали?
Микросервисы vs клетки
Как вы уже, наверное, заметили, я страстно люблю определения. Потому что, только в тот момент, когда ты можешь дать определение, можно честно сказать, что ты понимаешь, что это такое.
На самом деле давать определения довольно просто:
Сначала обозначаешь, что это вообще за объект – процесс, явление, система, сущность.
Потом описываешь его ключевые свойства и характеристики – биологический, информационный, физический и так далее.
И, при необходимости, указываешь, какие функции он выполняет – что обеспечивает, что позволяет, что делает.
Именно по этой схеме давайте и посмотрим, что такое микросервис и что такое клетка. Можете даже провести небольшое мысленное упражнение и попробовать сформулировать эти определения самостоятельно. А если не хочется – держите мои.
Но перед этим сделаю два небольших, но важных допущения.
в рамках этой статьи буду рассматривать микросервис не как архитектурный паттерн, а как отдельную сущность, структуру, компонент системы.
здесь мы говори�� о клетках многоклеточных организмов. Одноклеточные организмы оставим за скобками: они не имеют специализированных клеток, делают всё сами, полностью автономны и обеспечивают все процессы в одиночку. В общем, ведут себя подозрительно похоже на монолиты.
Теперь к определениям.
Относительная автономность и функционал
И микросервисы, и клетки многоклеточных организмов – это относительно автономные единицы более сложной системы. Каждая из них выполняет определённую функцию и взаимодействует с другими компонентами системы.
И те, и другие получают на вход информацию и ресурсы:
клетка – сигналы, энергию и вещества;
микросервис – запросы, данные и вычислительные ресурсы.
На основе этого входа единица поддерживает свою «жизнедеятельность» и выполняет функцию. Например, мышечная клетка сокращается, а микросервис для работы с клиентами обрабатывает запрос и возвращает ответ.
Разница, конечно, тоже есть. Микросервисы не самовоспроизводятся (хотя поднять новый инстанс обычно не так уж сложно) и, в отличие от живых систем, не склонны к спонтанным мутациям и самостоятельной эволюции. Все изменения мы в них вносим осознанно – руками разработчиков.
Функция определяет структуру
И в биологии, и в микросервисной архитектуре функция определяет строение. Да, чтобы всё работало, нужны базовы�� вещи:
для микросервиса – зависимости, библиотеки, описание классов, функций, контрактов;
для клетки – минимальный набор органелл: ядро для хранения информации, митохондрии для получения энергии, рибосомы для синтеза белка и так далее.
Но именно функция, ради которой всё затевается, определяет специфику строения. Передача ли нервного импульса у нейрона, секреция ли у железистой клетки или создание нового пользователя у микросервиса регистрации – всё это требует разной внутренней организации.
Попытка заставить одну клетку или один микросервис «уметь всё» обычно заканчивается плохо: в биологии – потерей специализации, а то и неконтролируемым ростом/размножением и канцерогенозом (процесс образования опухоли), в архитектуре – антипаттернами и болью.
Взаимодействие как основа работы системы
Ни клетки, ни микросервисы не существуют сами по себе. Они работают только во взаимодействии с внешней средой и с другими компонентами системы.
Посмотрим на два очень упрощенных примера: рефлекторная дуга коленного рефлекса и бизнес-процесс получения информации о состоянии заказа.
И там, и там есть входящий сигнал, цепочка обработки и результат. И там, и там важны скорость передачи сигнала, корректность обработки и устойчивость всей цепочки. Разница лишь в том, что в одном случае мы говорим о миллисекундах реакции организма, а в другом – о latency и SLA.
Разумеется, это сильное упрощение. Ни нервная система, ни реальные бизнес-процессы не выглядят так линейно. Но как модель для понимания работает.
Масштабирование и изменение функциональности
Как клетки, так и микросервисы можно масштабировать. Если системе нужно выполнять больше однотипных операций, она просто увеличивает количество соответствующих элементов:
организм – за счёт деления клеток,
система – за счёт увеличения числа ин��тансов микросервиса.
Например, если есть необходимость, можно масштабировать только те микросервисы, на которые приходится наибольшая нагрузка. А организм может резко увеличить количество лимфатических клеток при инфекции, а потом вернуться к норме.
Если же меняется функциональность, возможны и изменения на уровне самих элементов. В определенных пределах клетка может менять свою функцию – например, если достать картофель на свет, его клетки, которые вообще-то выполняют запасающую функцию, начинают вырабатывать хлорофилл и фотосинтезировать.
В микросервисной архитектуре это выглядит куда прозаичнее: если бизнес говорит, что теперь мы не только получаем данные о пользователе, но и можем их редактировать – мы просто добавляем новый метод, например PUT (на самом деле не так и просто, но вы поняли). Или идем обсуждать необходимость разработки нового микросервиса.
Однако, пределы таких изменений не безграничны: сложно заставить эпителиальную клетку синтезировать гормоны, а добавление принципиально нового функционала хоть и можно реализовать в имеющемся сервисе, но лучше не надо. В целом, чем выше специализация – тем выше эффективность отдельного компонента. Но и зависимость от всей системы в целом – тоже выше.
Микросервисы и клетки удивительно похожи: это автономные, специализированные единицы, существующие не сами по себе, а в составе более сложной системы. Их структура определяется функцией, масштабирование достигается за счёт увеличения количества однотипных элементов, а взаимодействие с другими компонентами критично для работы всей системы.
Разница лишь в том, что в биологии за ошибки отвечает эволюция, а в архитектуре – мы сами.
Модули vs органы
И в биологии, и в архитектуре за специализацию приходится платить связанностью. Чем более узкую и чётко определённую функцию выполняет компонент, тем сильнее он зависит от других. В отрыве от окружающих элементов ему становится сложно, а иногда и бессмысленно, выполнять свой функционал. Отдельная клетка вне организма долго не живёт, как и отдельно взятый микросервис вне системы редко имеет практическую ценность. Поэтому и в живых системах, и в программных архитектурах возникает следующий уровень организации.
Клетки с одинаковым функционалом объединяются в ткани. Инстансы микросервисов обычно специально в «ткани» не группируют, хотя кластеры, пулы и поды в контейнерных платформах отдаленно напоминают такой тип организации. Поэтому давайте для продолжения нашей биологической аналогии рассмотрим уровень модулей и органов. Вот и определения созрели.
Общая задача и кооперация
Как правило, и микросервисы внутри одного модуля и клетки внутри одного органа, хотя и выполняют свои собственные функции, но работают на одну глобальную задачу: желудок переваривает пищу, сердце снабжает кровью весь организм, а модуль “Клиенты” обеспечивает работу с этими самыми клиентами – их создание, поиск и изменение персональных данных (и что там еще требует бизнес-логика). При этом связь между компонентами в рамках одного модуля/органа довольно тесная. Как это проявляется?
Отказоустойчивость и деградация
Если перестает работать часть клеток одного типа или один инстанс микросервиса, то орган или модуль худо-бедно продолжат свою работу, хоть и с падением производительности. Но когда какой-то тип клеток/микросервисов откажет полностью, то работа всего органа/модуля или будет серьезно нарушена, или полностью остановится. Конечно, уровень критичности работоспособности отдельных клеток/микросервисов для всего организма/продукта может существенно отличаться.
Если у человека выпадут все зубы, то он продолжит свое существование и функционирование (просто значительно ухудшится качество жизни, а в перспективе и само существование сократится), а вот если откажут кардиомиоциты, то тут уже не до шуток.
Так и для продукта, если приляжет микросервис, отвечающий за регистрацию новых клиентов, то уже зарегистрированные пользователи могут это даже не заметить. А вот если у какого-то маркетплейса рухнет платежный модуль, то в принципе весь сервис теряет свой смысл. Ну разве что вы, как и я, заходите туда просто посмотреть на красивых рыбов. В целом, на этом уровне, в отличие от уровня микросервисов и клеток, отказ целой структуры не проходит без последствий.
Давайте рассмотрим конкретный пример – желудок и воображаемый модуль “Клиенты”. На схемах, напоминающих компонентную диаграмму, можно увидеть, что и органы, и модули состоят из разных клеток/микросервисов, которые выполняют свои функции (часто несколько на один микросервис). При этом я не стала ни отображать внутренние связи между клетками/микросервисами, ни добавлять другие модули/органы на схемы, чтобы ее не усложнять и не перегружать (чем больше деталей, тем хуже работает аналогия😆). Но в целом, думаю, понятно, почему мне так нравится этот подход: если заменить клетки/ткани на микросервисы, а орган – на модуль, логика организации системы остается той же.
Внутренние взаимодействия
Как системный аналитик, я, конечно, не могу пройти мимо интеграции. А значит, не могу не отметить, что интеграция между компонентами одного функционала упрощена, как правило, по сравнению со взаимодействием с другими частями той же системы.
Клетки одного органа, как правило, могут делиться некоторой информацией и ресурсами напрямую без использования посредников в виде нервной и кровеносной системы. А микросервисы в рамках одного модуля тоже могут интегрироваться без лишних сложностей (зависит от ситуации, конечно):
- синхронные REST-запросы;
- упрощенные схемы аутентификации (в разумных пределах, например, basic auth) и т.д.
А вот для взаимодействия с другими органами/модулями/системами уже нужно что-то посложнее. В организме это будет кровеносная и/или нервная система, шины, в IT – брокеры сообщений, API-gateway, асинхронные очереди, иногда даже отдельные интеграционные контуры.
Конечно, у всего есть своя цена: упрощая взаимодействие внутри модуля или органа, мы одновременно повышаем связанность. Это делает систему быстрее и удобнее локально, но усложняет изменения, рефакторинг и изоляцию компонентов. Биология с этим живёт давно. Не грех у нее поучится, как с этим жить.
Итак, органы и модули – это уровень, на котором система перестает быть просто набором автономных элементов и начинает работать как целостный механизм. Здесь важны не только функции отдельных компонентов, но и их согласованность, связанность и способность совместно выполнять бизнес- или жизненно важные задачи. Именно на этом уровне архитектурные ошибки становятся особенно болезненными и особенно заметными.
Продукт vs организм
А теперь давайте перейдем на уровень выше и рассмотрим аналогию продукт/организм. Хотелось бы отметить, что чем сложнее уровень организации, тем больше накапливается отличий, тем больше допущений и упрощений приходится применять для аналогии (уверена, в комментариях мне подробно объяснят, где и как я не права и я только за, без иронии), но пока она все еще хорошо прослеживается.
И снова мои любимые определения:
В обоих случаях мы имеем дело со сложной системой из различных компонентов, которые работают согласованно для обеспечения ключевой функциональности. Только с IT-продуктом это будет какая-то бизнес-задача, а в случае организма – размножение и поддержание своего существования.
Но поскольку и организм, и IT-продукт обладают свойством эмерджентности (когда совокупность частей больше, чем их просто сложение отдельных свойств этих частей), то хотелось бы несколько продолжить эту аналогию и поискать схожие черты в таких разных системах.
Принятие решений
Отдельный модуль, как и отдельный организм, может работать безупречно, но только тогда это имеет смысл, когда все подчиняется общей задаче. А для этого должны быть какие-то общие правила, которым подчиняется вся система, а для достаточно сложных систем – единый центр принятия решений. Для продукта определять правила игры будут бизнес-логика и бизнес-правила, для живого организма – физиологические и эволюционные ограничения. Но это на глобальном уровне, а вот за принятие каких-то конкретных решений, за поведение системы в определенных условиях отвечает сама система, и иногда для этого выделяется специальный компонент или орган.
Так, в качестве центра принятия решений у живых организмов выступает центральная нервная система (например, наш замечательный во всех отношениях мозг), в IT-продуктах часто реализуется что-то подобное через паттерн оркестрации, возможно, сервис решений или отдается на откуп человеку. Важно понимать, что мозг не выполняет работу других органов (не обеспечивает переваривание пищи или движение тела в пространстве). Но он собирает сигналы, обрабатывает их, принимает решение и выдает уже свои собственные сигналы, координируя работу остальных органов. Как и сервис-оркестратор ��е выполняет работу других сервисов, а объединяет усилия. Можете посмотреть, кстати, на все те же схемы с рефлекторной дугой и простейшим бизнес-процессом, только с осознанием, что тут мы переходим на другой уровень сложности.
На этом, пожалуй, аналогию с мозгом и управляющим микросервисом можно сворачивать, поскольку для микросервисной архитектуры God service является антипаттерном, а еще чуть-чуть – и мы к этому скатимся.
Согласованность действий и связанность
С принятием решений мы вроде бы разобрались, но мало решение принять, надо еще обеспечить сбор сигналов от внешней среды и внутренних компонентов, а также передачу решения конечному компоненту, который выполнит итоговое действие. Для этого необходимо обеспечить связь между всеми компонентами и передачу информации.
У живых организмов это кровеносная система и периферическая нервная система. Первая не только обеспечивает транспорт питательных веществ, газообмен, но и передает очень важные сигналы. Например, уровень концентрации сахара или гормонов. А нервная система с одной стороны собирает информацию от внешней среды и внутренних органов, а с другой – передает сигналы от центральной нервной системы к рабочим компонентам. То есть первая – это что-то медленное, но постоянно работающее, а второе – что-то, что позволяет реагировать уже гораздо быстрее и точечно. И кажется, это самое место, чтобы провести аналогию с асинхронной и синхронной интеграцией соответственно. Так, Kafka вполне может стать эдакой кровеносной системой IT-продукта, а шинные интеграции или point-to-point интеграции – аналогом нервной системы (в упрощенном виде, конечно).
Внутренний мониторинг
Для сложной системы важно контролировать, все ли ее компоненты функционируют нормально (согласитесь, все мы испытываем довольно неприятные ощущения при онемении конечностей, в первую очередь потому что не можем ими полноценно управлять в таком состоянии и не понимаем, все ли хорошо с ногой, которую не чувствуем). В организме имеется целый ряд рецепторов, который отслеживает целую кучу различных параметров. Более того, организм не просто следит, все ли хорошо – в случае, когда становится нехорошо, принимаются активные действия, чтобы восстановить функционал. Это называется поддержанием гомеостаза.
До поддержания постоянства внутренней среды IT-продуктам, на мой взгляд, еще далековато, но тем не менее в любом более-менее сложном продукте внедряются системы мониторинга. Это может быть проверка работоспособности сервисов (health-check, alerts), внедрение автотестов, создание различных метрик и отображение их на дашбордах. В любом случае, чем раньше мы узнаем, что “что-то пошло не так”, тем лучше. Только если живая система получая, внутренний сигнал о сбое сама восстанавливает гомеостаз, то для IT-продукта в большинстве случаев все-таки требуется внешнее вмешательство.
Безопасность и иммунная система
Еще один важный аспект для любой системы – безопасность. Если сложная система (не важно IT-продукт или организм) существует в идеальных условиях без контакта с враждебной средой, то тратить ресурсы на всевозможные проверки и борьбу с внешними факторами нет смысла. Но и в природе, и в современном мире продуктов такое бывает редко. Всегда найдется желающий воспользоваться вашими ресурсами – будь то паразиты в живой природе или киберпреступники в мире IT. А значит, надо позаботиться о безопасности (особенно при контакте с внешними системами, но и внутренние компоненты должны предоставлять доказательство, что это именно они и не сошли с ума).
У многоклеточных организмов для этого есть иммунная система, которая состоит из большого числа самых разнообразных органов, работает на органном, клеточном и молекулярном уровне и выполняет самые различные функции, но с одной целью – защита организма. У IT-продуктов за безопасность тоже отвечает целый ряд технологий, обеспечивающих проверку прав, целостность данных и конфиденциальность: TLS-протокол, OAuth 2.0 и т.д.
Итак, что можно выделить в этих аналогиях общего:
- распознавание «свой/чужой»: у организмов для этого служат молекулярные маркеры и механизмы распознавания, у IT-продуктов – способы аутентификации, например токены;
- распределенность и централизованность: в иммунной системе можно выделить лимфоузлы, которые будут контролировать работу иммунных клеток. В IT в качестве такого примера можно привести Keycloak (минутка саморекламы – если интересно, как работает Keycloak, то можно почитать мою статью), но и в первом, и во втором случае это всего лишь узел, а не единая точка контроля;
Ниже показана схема, которая иллюстрирует один и тот же принцип в биологии и в IT: доступ к ресурсам возможен только после проверки идентичности субъекта. В живых системах эту роль выполняют молекулярные маркеры и иммунная система, в IT – токены и сервисы аутентификации.
Сразу подчеркну, где возникают отличия.
Во-первых, иммунная система, в отличие от Identity Provider, не выдает никаких маркеров, сертификатов или токенов. У клетки они уже есть: как правило, это белки, липопептиды, полисахариды и другие сложные соединения на поверхности клетки, которые являются строго специфичными. В случае взаимодействия клиент-сервис маркер идентичности, напротив, выдается явно в виде токена или сертификата.
Во-вторых, клетка, в отличие от микросервиса или внешней системы, не запрашивает у иммунной системы допуск специально. Все эти процессы идут параллельно, распределенно и часто вероятностно, тогда как в IT они предельно последовательны, формализованы и инициируются клиентом.
Казалось бы, иммунная система требует массу ресурсов, не влияет напрямую на жизнедеятельность, также и система безопасности значительно усложняет разработку (требует тех же ресурсов), не выполняет собственно бизнес-логику. Однако без иммунитета организм долго не протянет, а небезопасный IT-продукт просто никому не нужен.
Сложность – это цена, а не цель
Все, что я описала выше – характерно для сложных многоклеточных организмов и сложных IT-продуктов с развитой структурой, но всегда ли нужна эта сложность?
Разумеется, нет! И в мире живой природы, и в мире IT целая тьма примеров, которые подтверждают, что сложно не равно успешное. В конце концов, одноклеточные организмы существуют миллиарды лет и не собираются никуда исчезать. А эндогенные паразиты дадут фору любому в эффективности размножения, но при этом у них не то что нет особо сложных структур, а даже редуцирована часть органов, которая была у их предков. И точно так же, если вы делаете продукт, рассчитанный на очень узкую аудиторию, нет смысла закладывать ресурсы, чтобы им могли пользоваться одновременно все жители планеты. Полно стартапов, которые разрабатывались как монолит и отлично функционируют годами.
Надо помнить, что чем сложнее система, тем проще ее вывести из строя. Это одинаково актуально и для организмов, и для продуктов. Поэтому в живой природе вы вряд ли найдете создание, у которого будут:
- лишние органы (ну просто на всякий случай);
- усложнение ради усложнения (у всего есть цель, ну или по крайней мере когда-то была, но в ходе эволюции немножко потерялась);
- в экстремальных условиях жизнь есть – но очень просто устроенная, часто одноклеточная и безъядерная, потому что любое усложнение – это дорого.
Поэтому всегда стоит задумываться, а действительно вам нужны:
- микросервисная архитектура;
- брокеры сообщений;
- оркестрация.
Если попытаться подвести итог этой аналогии, то становится видно: сложные IT-продукты и сложные живые организмы удивительно похожи не устройством отдельных компонентов, а принципами организации.
И там, и там:
нет универсального «органа», который делает всё;
жизнеспособность системы обеспечивается согласованной работой множества специализированных компонентов;
для выживания критичны коммуникации, безопасность и контроль внутреннего состояния.
Центр принятия решений в виде мозга или оркестрации не выполняет работу за остальные компоненты, а лишь координирует их. Кровеносная и нервная системы не существуют ради себя – они обеспечивают связность и своевременную доставку сигналов. Иммунная система и системы безопасности напрямую не создают ценность, но без них система оказывается нежизнеспособной.
При этом важно помнить: аналогия – это инструмент мышления, а не доказательство. Живой организм эволюционирует миллионами лет, IT-продукт – спринтами. Организм умеет поддерживать гомеостаз, продукт пока в основном лишь сигнализирует о проблемах. Где-то сходство почти буквальное, а где-то лишь полезная метафора.
Но именно в этом и заключается ценность таких сравнений: они позволяют увидеть архитектуру не как набор технологий и паттернов, а как целостную систему, в которой любое усложнение имеет цену, а любая структура должна быть оправдана средой, задачами и контекстом.
И, пожалуй, главный вывод здесь прост: сложность – это не признак зрелости, а форма адаптации. И как в биологии, так и в архитектуре, она имеет смысл только тогда, когда действительно помогает выживать.
Выводы. Почему вообще эта аналогия работает
Мы могли бы продолжать такие биологические аналогии до бесконечности: эволюция vs разработка, популяция vs группа продуктов, заболевания vs антипаттерны архитектуры… Но боюсь вас утомить, так что думаю, куда полезнее будет сосредоточиться на некоторых общих выводах и где лучше остановиться.
Биологические организмы, и IT-продукты являются сложными системами, а значит для них будут работать общие принципы: специализация, связность, коммуникации, безопасность и контроль состояния – всё это возникает не как модный тренд, а как ответ на усложнение среды и задач.
Однако чем выше уровень абстракции, тем важнее помнить: аналогия – это не доказательство и не инструкция к применению. Она полезна ровно до тех пор, пока помогает мыслить точнее, а не подменяет собой анализ.
Давайте пробежимся по основным концептуальным моментам, где сходство между организмом и IT-продуктом заканчивается:
1. Цель системы
Организм существует ради поддержания собственной жизни.
IT-продукт – ради внешней цели: бизнеса, пользователя, регулятора.
2. Эволюция и изменения
Организмы эволюционируют медленно, без плана и без архитектора. Из поколения в поколение, а не на базе одного организма, адаптивный потенциал которого хоть широк, но не бесконечен (микробиологи, молчать! Мы тут про многоклеточных).
IT-продукты меняются быстро, осознанно (хотелось бы верить) и по инициативе человека. Так что это скорее селекция, только и правила, и материал мы создаем сами (да-да, трудно быть богом).
3. Саморегуляция
Живые системы обладают встроенным гомеостазом и способны самостоятельно восстанавливаться и тут, конечно, дают фору IT-продуктам, которые пока просто сигнализируют о проблеме (если вы не забудете это настроить) и лишь частично автоматизируют ответ (например, могут откатить неудачный релиз). До полноценного «гомеостаза» пока далеко.
4. Буквальность переноса
Иммунитет – не OAuth, мозг – не оркестратор, а клетка – не микросервис.
Это не эквиваленты, а смысловые рифмы. Отличий все еще слишком много)
Зачем тогда всё это было нужно?
Несмотря на ограничения, аналогия остаётся полезной, потому что:
она помогает осмыслить архитектуру как систему, а не набор технологий;
заставляет задуматься о цене усложнения;
и напоминает, что не всякая система обязана быть сложной, чтобы быть успешной.
Ну и конечно, помогает нам узнавать новое через уже знакомое: если вы биолог – то понять что же это за зверь микросервисная архитектура, а если айтишник – то возможно, вы будете чуть лучше понимать, что и как работает в вашем собственном организме.
Словарь аналогий:
Биология (клетка) | Микросервисная архитектура | Пояснение |
Клетка | Микросервис | Минимальная автономная единица системы, выполняющая ограниченный набор функций |
Многоклеточный организм | Продукт / IT-система | Целостная система, состоящая из взаимодействующих компонентов |
Специализация клеток (нейрон, мышечная, железистая) | Специализация микросервисов (платежи, пользователи, уведомления) | Функция определяет структуру и внутреннюю реализацию |
Клеточная мембрана | API / контракт сервиса | Определяет, как и с кем компонент может взаимодействовать |
Рецепторы на мембране | Входные эндпоинты | Точки входа для сигналов / запросов |
Сигнальные молекулы | HTTP-запросы, события, сообщения | Механизм передачи информации между компонентами |
Обмен веществ | Обмен данными | Поддержание «жизнедеятельности» компонента |
Органеллы (ядро, митохондрии, рибосомы) | Внутренние модули, библиотеки, БД | Внутренняя реализация, скрытая от внешнего мира |
Ядро клетки (ДНК) | Код микросервиса / конфигурация | Хранение «инструкций» и логики работы |
Деление клеток | Масштабирование инстансов | Увеличение пропускной способности за счёт количества |
Апоптоз (запрограммированная гибель клетки) | Деактивация / вывод сервиса из эксплуатации | Контролируемое удаление компонента без ущерба для системы |
Дифференцировка клеток | Изменение функциональности сервиса | Адаптация под новые требования в допустимых пределах |
Рефлекторная дуга | Бизнес-процесс / цепочка вызовов | Последовательная обработка сигнала / запроса |
Гомеостаз | Наблюдаемость, алертинг, auto-healing | Поддержание стабильности системы |
Орган | Модуль | Функциональное объединение элементов, решающее целостную задачу |
Кровеносная система | Асинхронные интеграции / брокер сообщений | Фоновая передача данных и сигналов между компонентами |
Нервная система | Синхронные вызовы | Быстрая и адресная передача управляющих сигналов |
Организм | IT-продукт | Целостная система, состоящая из взаимосвязанных компонентов, работающих ради общей цели |
Центральная нервная система | Оркестрация / управляющая логика | Координация работы компонентов без выполнения их функций |
Рефлексы | Автоматические сценарии | Быстрые реакции на типовые события без сложной логики |
Иммунная система | Система безопасности | Защита от внешних и внутренних угроз |
Распознавание «свой / чужой» | Аутентификация | Проверка подлинности субъекта взаимодействия |
Иммунный ответ | Авторизация / политики доступа | Определение допустимых действий |
Гомеостаз | Мониторинг и self-healing | Поддержание стабильности системы |
Сенсорные рецепторы | Метрики и алерты | Сбор информации о состоянии системы |
Эволюция | Развитие продукта | Постепенное изменение структуры под требования среды |
Смерть организма | Вывод продукта из эксплуатации | Прекращение жизненного цикла системы |
Источники и материалы:
Микросервисная архитектура
Базовое определение, история возникновения, ключевые свойства и критика архитектуры.
https://ru.wikipedia.org/wiki/Микросервисная_архитектураWhat are microservices? – Atlassian
Обзор преимуществ и недостатков микросервисной архитектуры, проблемы масштабирования и эксплуатации.
https://www.atlassian.com/microservicesMicroservices (Martin Fowler)
Классическая статья о микросервисах, их характеристиках и архитектурных компромиссах.
https://martinfowler.com/articles/microservices.htmlMonolith First – Martin Fowler
Почему микросервисы – не универсальное решение и когда монолит оказывается лучшим выбором.
https://martinfowler.com/bliki/MonolithFirst.htmlExplaining Microservices: A Visual Analogy
Если вы далеки от биологии, то тут неплохая аналогия с университетским кампусом.
https://medium.com/%40isaackleimmanngraper/explaining-microservices-a-visual-analogy-1a9c4685ee9bOAuth 2.0 Authorization Framework (RFC 6749)
Формальное описание протокола авторизации, лежащего в основе современных систем безопасности.
https://datatracker.ietf.org/doc/html/rfc6749OpenID Connect Core 1.0
Стандарт аутентификации поверх OAuth 2.0.
https://openid.net/specs/openid-connect-core-1_0.htmlKeycloak Documentation
Официальная документация Keycloak: архитектура, роли, токены, реалмы.
https://www.keycloak.org/documentationИммунная система человека
Обзор принципов работы иммунной системы, уровней защиты и механизмов распознавания «свой/чужой».
https://ru.wikipedia.org/wiki/Иммунная_системаThe Immune System as a Distributed System
Научно-популярный взгляд на иммунную систему как распределённую, отказоустойчивую систему.
https://arxiv.org/abs/1011.4199Emergence
Понятие эмерджентности и его применение к сложным системам.
https://en.wikipedia.org/wiki/EmergenceМикросервисы: ошибки, грабли и разочарования
Подборка практических статей и кейсов от разработчиков.
https://habr.com/ru/hubs/microservices/articles/
