Разумеется, мы могли бы воспользоваться необходимостью расширения масштаба для разбиения существующих микросервисов на части, чтобы успешнее справляться с нагрузкой. В качестве упрощенного примера представим, что наш сервис счетов позволяет создавать индивидуальные финансовые счета клиентов и управлять ими, а также выставляет API-интерфейс для запуска запросов с целью создания отчетов. Такая возможность запуска запросов существенно нагружает систему. Объем запросов считается некритическим и не требует сохранения поступающего за день потока запросов. Но возможность управления финансовыми записями является критической для наших пользователей, и мы не можем позволить, чтобы она функционировала со сбоями. Разделяя эти две возможности на отдельные сервисы, мы уменьшаем нагрузку на сервис важных счетов и вводим новый сервис отчета по счетам, спроектированный с учетом не только возможностей обработки запросов (возможно, с использованием технологий, рассмотренных в главе 4), но и того, что некритическую систему не обязательно развертывать в отказоустойчивом режиме, как того требует основной сервис счетов.
Один из способов масштабирования с целью повышения отказоустойчивости заключается в выдаче гарантий того, что все яйца не сложены в одну корзину. Простейшим примером может послужить обеспечение того, что вы не поместили на одном хосте сразу несколько сервисов, где сбой окажет влияние на работу сразу нескольких сервисов. Но рассмотрим значение такого понятия, как
Для внешних платформ виртуализации существует распространенная практика размещения корневого раздела виртуальной машины в одной сети хранения данных (SAN). Если SAN-сеть даст сбой, это может привести к сбою всех связанных с ее помощью виртуальных машин. SAN-сети отличаются масштабностью, дороговизной и проектированием в расчете на бессбойную работу. Я сталкивался со сбоями больших и дорогостоящих SAN-сетей как минимум дважды за последние десять лет, и каждый раз это имело довольно серьезные последствия.
Еще одной распространенной разновидностью сокращения вероятности сбоев является гарантия того, что не все ваши сервисы запускаются на одной и той же стойке дата-центра, или того, что сервисы распределены по более чем одному дата-центру. Если вы имеете дело с основным поставщиком услуг, то важно знать о предложении и планировании им соответствующего соглашения об уровне предоставления услуг (SLA). Если для вас допустимо не более четырех часов сбоев в квартал, а хостинг-провайдер может гарантировать всего лишь не более восьми часов, то вам придется либо пересмотреть SLA, либо придумать альтернативное решение.
AWS, к примеру, имеет региональную форму распределения, которую можно рассматривать как отдельные облака. Каждый регион, в свою очередь, разбит на две и более зоны доступности (AZ). Эти зоны в AWS являются эквивалентом дата-центра. Важно, чтобы сервисы были распределены по нескольким зонам доступности, поскольку инфраструктура AWS не дает гарантий доступности отдельно взятого узла или даже всей зоны доступности. Для своих вычислительных услуг эта инфраструктура предлагает только 99,95 % безотказной работы за заданный месячный период во всем регионе, поэтому внутри отдельно взятого региона рабочую нагрузку следует распределить по нескольким доступным зонам. Некоторых такие условия не устраивают, и вместо этого они запускают свои сервисы, также распределяя их по нескольким регионам.
Конечно же, нужно отметить, что провайдеры, давая вам
