Но верно и то, что возникают некоторые осложнения из-за наличия все большего количества движущихся частей, и эта проблема также будет повсеместно исследоваться в данной книге. Как только вы научитесь справляться с подобными сложностями, можно будет направить свои силы на создание все меньших и меньших сервисов.
Наш микросервис является самостоятельным образованием, которое может быть развернуто в качестве обособленного сервиса на платформе, предоставляемой в качестве услуги, — Platform as a Service (PAAS), или может быть процессом своей собственной операционной системы. Мы стараемся не заполнять несколькими сервисами одну и ту же машину, хотя определение машины в современном мире весьма размыто! Чуть позже мы разберемся в том, что, несмотря на издержки, которые могут быть вызваны обособленностью, получаемая в результате использования такого сервиса простота существенно облегчает рассуждения о распределенной системе, а самые последние технологии позволяют смягчить множество проблем, связанных с этой формой развертывания.
Обмен данными между самими сервисами ведется через сетевые вызовы, чтобы упрочить обособленность сервисов и избежать рисков, сопряженных с тесными связями.
Этим сервисам необходимо иметь возможность изменяться независимо друг от друга и развертываться, не требуя никаких изменений от потребителей. Нам нужно подумать о том, что именно наши сервисы будут показывать и что им можно будет скрывать. Если объем совместно используемого будет слишком велик, потребляемые сервисы станут завязываться на внутренние представления. Это снизит автономность, поскольку при внесении изменений потребует дополнительного согласования с потребителями.
Наши сервисы выставляют напоказ программный интерфейс приложения — Application Programming Interface (API), и работающие на нас сервисы связываются с нами через эти API. Нужно также подумать о технологии, позволяющей не привязывать сами интерфейсы к потребителям. Это может означать выбор API, нейтральных по отношению к тем или иным технологиям, чтобы гарантировать отсутствие ограничений в выборе технологий. На страницах этой книги мы еще не раз вернемся к вопросу о важности качественных, ни к чему не привязанных API.
Без отсутствия привязки наша работа теряет всякий смысл. Можете ли вы внести изменения в сервис и провести полностью самостоятельное его развертывание, не внося каких-либо изменений во что-нибудь еще? Если нет, то реализовать множество обсуждаемых в этой книге преимуществ будет крайне сложно.
Чтобы добиться качественной обособленности, нужно правильно смоделировать свои сервисы и получить на выходе подходящие API. На эту тему еще предстоит множество разговоров.
Микросервисы обладают множеством разнообразных преимуществ. Многие из них могут быть присущи любой распределенной системе. Но микросервисы нацелены на достижение вершин этих преимуществ, что обусловливается в первую очередь тем, насколько глубоко ими принимаются концепции, положенные в основу распределенных систем и сервис-ориентированной архитектуры.
Имея систему, составленную из нескольких совместно работающих сервисов, можно прийти к решению использовать внутри каждого из них различные технологии. Это позволит выбрать для каждого задания наиболее подходящий инструментарий, не выискивая какой-либо стандартный подход на все случаи жизни, зачастую заканчивающийся выбором наименьшего общего знаменателя.
Если какой-то части системы требуется более высокая производительность, можно принять решение по использованию иного набора технологий, более подходящего для достижения требуемого уровня производительности. Можно также принять решение об изменении способа хранения данных для разных частей нашей системы. Например, пользовательский обмен сообщениями в социальной сети можно хранить в графоориентированной базе данных, отражая тем самым присущую социальному графу высокую степень взаимосвязанности, а записи в блоге, создаваемые пользователями, можно хранить в документоориентированном хранилище данных, давая тем самым повод для использования разнородной архитектуры, похожей на ту, что показана на рис. 1.1.
Микросервисы также позволяют быстрее внедрять технологии и разбираться в том, чем именно нововведения могут нам помочь. Одним из величайших барьеров на пути принятия новой технологии является риск, связанный с ее использованием. Если при работе с монолитным приложением мне захочется попробовать новые язык программирования, базу данных или структуру, то влияние распространится на существенную часть моей системы. Когда система состоит из нескольких сервисов, у меня появляются несколько новых мест, где можно проверить работу новой части технологии. Я могу выбрать такой сервис, с которым риск будет наименьшим, и воспользоваться предлагаемой им технологией, зная, что могу ограничить любое потенциально отрицательное воздействие. Возможность более быстрого внедрения новых технологий рассматривается многими организациями как существенное преимущество.