Выбор небольшого числа определенных технологий интерфейса помогает интегрировать новых потребителей. Лучше всего иметь один стандарт. Два — тоже неплохо. А вот наличие 20 различных стилей объединения уже никуда не годится. Это относится не только к выбору технологии и протокола. Если, к примеру, выбор пал на HTTP/REST, что вы будете использовать, глаголы или существительные? Как станете работать со страничной организацией ресурсов? Как будете справляться с управлением версиями конечных точек?
Мы не можем позволить, чтобы один плохо работающий сервис нарушил общую работу. Нужно убедиться в том, что наши сервисы сами себя защищают от вредных нисходящих вызовов. Чем больше окажется сервисов, неспособных правильно обработать потенциально сбойный характер нисходящих вызовов, тем более хрупкими будут наши системы. Это означает, что вам как минимум нужно будет выдвинуть требование, чтобы каждый нисходящий сервис получил собственный пул подключений, и вы даже можете дойти до того, чтобы сказать, что каждый из сервисов должен использовать предохранитель. Более подробно этот вопрос будет обсуждаться в главе 11 при рассмотрении микросервисов в более широком масштабе.
Игра по правилам важна и тогда, когда речь заходит о кодах. Если предохранители полагаются на HTTP-коды, а в отношении одного из сервисов принято решение о возврате для ошибок кодов вида 2XX или коды 4XX перепутаны с кодами 5XX, то все меры безопасности окажутся тщетными. Те же опасения возникнут, даже если вы не используете HTTP. Знание того, в чем заключается разница между подходящим и корректно обработанным запросом, плохим запросом, при котором сервис удерживается от каких-либо действий по отношению к нему, и запросом, который может быть в порядке, но точно этого сказать нельзя, поскольку сервер не работал, является ключом уверенности в возможности быстрого отказа и отслеживания возникших проблем. Если наши сервисы будут пренебрегать этими правилами, система получится более уязвимой.
Хорошо бы собраться вместе и согласовать, как именно все нужно сделать. Но тратить время на то, чтобы убедиться, что люди следуют руководящим установкам, менее привлекательно, чем выдвигать разработчикам требования реализовать все стандарты, следование которым ожидается от каждого сервиса. Но я твердо верю в то, что именно такой подход упрощает создание нужных вещей. Насколько я заметил, хорошо срабатывает использование экземпляров и предоставление шаблонов сервисов.
Написание документации — дело полезное. Я прекрасно это осознаю, ведь в конце концов я же написал эту книгу. И разработчикам нравится код, ведь они могут его запустить и исследовать. Если у вас есть предпочтительные стандарты или передовой опыт, то будет полезно иметь демонстрационные экземпляры. Замысел заключается в том, что, подражая некоторым наиболее удачным частям вашей системы, люди не смогут слишком сильно свернуть с верного пути.
В идеале для обеспечения правильного восприятия это должны быть реальные, имеющиеся у вас в наличии сервисы, а не изолированные сервисы, реализованные просто в качестве совершенных примеров. Уверяя в активном использовании своих экземпляров, вы гарантируете, что используемые вами принципы имеют смысл.
Как по-вашему, хорошо было бы иметь возможность действительно упростить разработчикам задачу следования большинству ваших указаний, затратив совсем немного усилий? Неужели не было бы замечательно предоставить в распоряжение разработчиков основную часть кода для реализации ключевых свойств, столь необходимых каждому сервису?
Есть два микроконтейнера с открытым кодом на основе JVM-машины — Dropwizard и Karyon. Они делают схожую работу, составляя набор библиотек для обеспечения таких свойств, как проверка работоспособности, обслуживание HTTP-протокола или экспортирование метрик. То есть вы получаете готовый сервис, укомплектованный встроенным сервлет-контейнером, который можно запустить из командной строки. Великолепный способ, чтобы пуститься в путь, почему бы им не воспользоваться? Раз уж все это имеется, почему бы не взять что-нибудь вроде Dropwizard или Karyon и не добавить дополнительные свойства, чтобы добиться соответствия вашему контексту?
Например, вам может потребоваться предписать использование предохранителей. В таком случае можно будет интегрировать такую библиотеку предохранителей, как Hystrix. Или у вас может практиковаться обязательная отправка всех метрик на центральный Graphite-сервер, поэтому нужно будет, наверное, ввести в действие такую библиотеку с открытым кодом, как Metrics из состава Dropwizard, и настроить ее таким образом, чтобы ее средствами показатели времени отклика и частоты появления ошибок автоматически помещались в известное место.