Это лишь одна из многих точек зрения на микросервисы, которые я сделал, чтобы наше воображение оставалось свежим, потому что единственным ограничением человека является его разум. И говорю вам, что большинство технологий, которыми мы пользуемся, основаны и тесно связаны с нашей природой и всей вселенной. Прежде чем приступить к нашему мысленному эксперименту, нам нужно понять самые основные компоненты построения микросервисов. Здесь мы разделяем его на 3 уровня структуры: инфраструктура, серверная часть и внешний интерфейс. Эти 3 слоя связаны друг с другом, поэтому всякий раз, когда на одном уровне возникает проблема, за ней последуют и другие. Чтобы понять почему, нам нужно взглянуть, что на самом деле делают эти 3 слоя.
- Инфраструктура (Большой взрыв)
Уровень инфраструктуры — это, по сути, отправная точка создания вашего приложения, чтобы оно могло работать. Сюда входят серверы/облака, базы данных, сети, nginx, очереди сообщений, такие как kafka или nsq, и многое другое. Вы не создадите приложение, не поработав над некоторыми из них. Но в микросервисах вы думаете об огромной, долгосрочной, эффективной и масштабируемой инфраструктуре для поддержки всех ваших сервисов, чтобы они могли работать безупречно с крошечной частотой отказов. . - Внутренние службы (время)
Почему мы должны рассматривать внутренние службы как временные рамки вселенной микрослужб? Работа серверной службы в основном сосредоточена на записи непрерывного потока данных. Это также содержит бизнес-логику, логику хранения данных и доставку на внешнюю сторону. Таким образом, суть заключается в непрерывном, постоянном увеличении данных. Самый простой пример для того, чтобы дать вам четкое представление о бэк-энде (времени), — это цифровое видео, в нем есть данные, которые он хранит в сжатом формате, включая изображение и звук на определенной временной шкале. - Внешняя служба (дело)
В интерфейсе каждое взаимодействие имеет значение, потому что этот уровень является самой близкой частью удовлетворенности пользователя и помогает показать, насколько полезным, значимым и простым является использовать ваш продукт. Именно в этой части вашего продукта постоянно происходит переход от старой к новой части, поскольку он всегда пытается отрегулировать удовлетворенность пользователей, чтобы получить максимально возможную ценность. И, конечно же, изменение всегда содержит в себе смысл и волнение, которые могут помочь повысить удовлетворенность пользователей.
У вас может возникнуть вопрос, зачем нам нужна другая точка зрения, которая кажется не связанной с микросервисом? Эта теория — лишь один из многих способов описать поведение микросервиса и его природу. Основываясь на этих трех принципах, кажется, что инфраструктура является ядром всего, и да, это так. Но другие слои не будут использоваться для описания того, как вы должны рассматривать микросервис с астрономической точки зрения. Вместо этого мы собираемся использовать лучшую силу во Вселенной, Гравитацию. Чем более критичен или сильно зависит от других сервисов, тем больше у него серьезности. давайте посмотрим на пример изображения ниже:
Как видите, здесь мы описываем Sun как инфраструктуру, поскольку она является ядром сервисов. Но мы не используем термины Back-end или Front-end, чтобы определить, как мы должны видеть микросервис, поскольку оба они важны и связаны друг с другом как единое целое. В этом примере мы видим общие термины, которые представляют собой услуги перед продажей, описанные как огромные планеты, поскольку они несут огромные зависимости, которые будут использоваться другими службами. И послепродажные или не связанные с продажей сервисы, которые также важны, но имеют меньше зависимостей, которые будут использоваться другими сервисами.
Давайте поместим эту перспективу в сценарий. Скажем, у нас есть сервис, который обрабатывает пользовательский опыт при покупке продукта. Поскольку это старая архитектура, сервис охватывает добавление в корзину, управление заказами, оплату и управление доставкой. Через год ваш стартап станет хитом с трафиком на 300% больше, чем в прошлом году. Но вместо того, чтобы сосредотачиваться на старой архитектуре, вы больше сосредотачиваетесь на новых функциях. И этот сервис имеет большие зависимости, которые используются другим сервисом.
С этой точки зрения это становится огромной планетой с массивной гравитацией. давайте опишем эту службу как Юпитер нашей планетарной системы микрослужб. Только представьте или поищите в интернете, что было бы, если бы Юпитер моментально удалился? В реальной планетарной системе это не будет страшно в человеческой временной перспективе, так как потребуется довольно много времени, чтобы достичь настоящей катастрофы на Земле, но не во вселенской временной перспективе. И что может случиться с вашим микросервисом, если ваш огромный сервис мгновенно исчезнет? Это мгновенно становится настоящей катастрофой для вашего пользователя и влияет на другие службы.
Чем больше зависимостей сервиса используется другим сервисом, тем сложнее система и код. И, конечно же, большая тяжесть неудач. Независимо от того, что нет службы, которая может работать идеально без сбоев, «все, что может пойти не так, может пойти не так». Чтобы достичь крошечного уровня отказов, нам нужен новый взгляд с той же точки зрения. Давайте расширим наш микросервис не только как солнечную систему, но и за ее пределы. Взгляните на картинку ниже:
В этом сценарии у вас есть центр галактики или галактический центр, где находится сверхмассивная черная дыра в Стрельце A*. Поэтому у вас есть инфраструктура, которая объединяет все ваши микросервисы, чтобы оставаться стабильной. Но с этой точки зрения вы не увидите никакого массивного сервиса с его огромной гравитацией зависимостей. Потому что они более распределены и разнообразны. Если вы имеете сбалансированно распределенные микрослужбы и не создаете еще одну черную дыру в своей системе, вы можете получить микрослужбу с небольшой частотой сбоев для поддержки стабильности вашего приложения.
Вывод
- Распределяйте риски сбалансированно
анализируйте, насколько велик риск сбоев каждого микросервиса, используя хорошие исторические данные системы мониторинга. Никогда не заключайте что-либо без данных, потому что это может привести к ненужным усилиям по диверсификации рисков вашего микросервиса. Но также всегда помните об этом. - Всегда имейте планы и видения
«Все, что может пойти не так, пойдет не так», поэтому важно иметь сценарии и техническое планирование. Создайте свою архитектуру и свою систему, хорошо спланировав, проанализировав и записав сценарии вместе со своими командами. Помимо того, что это помогает командам критически мыслить, это может помочь наладить общение и повысить осведомленность вашей команды о важности микросервиса. Никогда не прекращайте обновлять свой сервис, нет кода сервиса, у которого нет технического долга. - Перспектива имеет значение
Перспектива — это то, как мы обрабатываем данные внутри нашего мозга. Но, имея слишком много или меньше информации для обработки, мы не сможем принять правильное решение. Если вы изолируете свое представление, чтобы увидеть общую ситуацию, вы не сможете создать по-настоящему микросервис, который поддерживает сервисы друг друга, чтобы обеспечить крошечную частоту сбоев и стабильность вашего приложения и продуктов. Поскольку для этого не существует чудес, чудеса — это иллюзии, вызванные недостаточным наблюдением и пониманием. Итак, всегда открывайте свое представление, начинайте спрашивать, насколько хорош ваш микросервис, и проводите свое исследование.
