Создание микросервисов

Обеспечение того, что команды владеют своими собственными сервисами, является важным шагом на данном пути, возлагающим на команды ответственность за вносимые изменения и в идеале даже за принятие решения о том, когда именно выпустить такие изменения. Чтобы обеспечить возможность внесения изменений в сервисы, находящиеся во владении других команд, воспользуйтесь семейственным открытым кодом, но при этом помните, что для его реализации нужно будет поработать. Подстраивайте команды под организацию, чтобы гарантировать, что закон Конвея работает на вас и помогает вашей команде приобрести специализацию в создаваемых ею сервисах, сконцентрированных на решении конкретных бизнес-задач. Если требуется какая-либо всеобъемлющая ориентация, попробуйте воспользоваться моделью общего руководства, при которой представители разных команд несут коллективную ответственность за развитие технической концепции системы.

Этот принцип применим и для архитектуры. Избегайте подходов вроде сервисных шин предприятия или оркестровых систем, которые могут привести к централизации бизнес-логики и появлению безмолвных сервисов. Чтобы гарантировать наличие соответствующей логики и данных на границах сервисов, которые помогают достигать нужного сцепления, отдавайте предпочтение хореографическому, а не оркестровому принципу и безмолвным промежуточным программным средствам с интеллектуальными конечными точками.

Независимое развертывание

Нужно всегда стремиться к тому, чтобы микросервисы могли развертываться и развертывались самостоятельно. Даже когда требуются изменения, нарушающие общий режим работы, нужно добиваться совместного существования конечных точек разных версий, позволяя потребителям со временем внести изменения. Тем самым мы сможем оптимизировать скорость выпуска новых свойств, а также повысить автономность работы команд, владеющих этими микросервисами, снимая с них обязанность постоянного согласования развертываний своих сервисов. Если используется интеграция на основе RPC, избегайте при создании заглушек тесной связанности между клиентом и сервером вроде той, что поддерживается технологией Java RMI.

Принимая модель «по одному сервису на каждом хосте», вы уменьшаете число побочных эффектов, которые могут при развертывании одного сервиса влиять на другой, не связанный с ним сервис. Чтобы отделить развертывание от выпуска, сократив тем самым риск неудачного выпуска, присмотритесь к использованию технологий сине-зеленого развертывания или канареечного выпуска. Чтобы отловить изменения, нарушающие работу системы, еще до того, как они на нее смогут повлиять, воспользуйтесь контрактами на основе запросов потребителей.

Запомните, что возможность внесения изменений в отдельно взятый сервис и его выпуска для работы в производственном режиме без необходимости развертывания других сервисов с приостановкой работы системы должна стать нормой, а не исключением. Ваши потребители должны сами решать, когда им нужно обновляться, а вам следует к этому приспособиться.

Изолирование сбоев

Архитектура микросервисов может быть более устойчивой, чем монолитная система, но только если мы разбираемся в ситуации и имеем план на случай сбоев в части нашей системы. Если возможность и неизбежность сбоев вызова нижестоящего сервиса в расчет не принимаются, наша система может испытать катастрофический каскадный сбой и мы останемся с системой, еще более хрупкой, чем прежняя.

При использовании сетевых вызовов не уподобляйте удаленные вызовы локальным, так как из-за этого будут скрываться разные виды отказов. Поэтому убедитесь, что при использовании клиентских библиотек не происходит чрезмерного применения удаленных вызовов.

Не нужно постоянно думать о том, что система должна быть устойчивой к сбоям, и при этом всегда и всюду ожидать сбоев. Обеспечьте соответствующую настройку лимитов времени. Разберитесь, когда и как для ограничения выхода из строя компонентов использовать перегородки и предохранители. Разберитесь в том, какое влияние окажет на клиента неправильная работа всего одной из частей системы. Узнайте, какими окажутся последствия разделения сети и будет ли правильно требовать в этой ситуации принести в жертву доступность или согласованность данных.

Всестороннее наблюдение