Мы уже давно живем в микросервисной архитектуре. Статья рассказывает про наш опыт их систематизации и приведения к единым требованиям, в рамках статьи я не затрагивал переезд в микросервисную архитектуру из монолитной или любой другой
Тир-лист не отменяет текущих архитектурных практик, принятых в компании. Он направлен больше на повышение стабильности системы и предсказуемость отказов, снижение вероятности каскадных сбоев
Тиры были созданы чтобы определить важность сервиса с точки зрения именно бизнеса. Разные уровни тир требуют разные уровни инженерной зрелости сервиса. Помимо CI мы проводим DR-дрили, проводим ревью сервисов и архитектуры, а так же в первую очередь за состоянием сервисов в своем домене должна следить ответственная команда во главе с лидом
Тиры - лейблы для сервисов, показывающие важность для бизнеса. Они выставляют границы уровней зрелости (в статье таблица приведена)
Уровни зрелости в себе содержат набор правил, выдвигаемых к сервису.
За соответствием сервисов к уровню зрелости присвоенного сервису тира следит команда во главе с лидом и архитектурный совет
Так же добавлю, что API Gateway в Ситидрайве тоже Tier-1 сервис, на уровне с другими критическими сервисами, без него клиенты не смогут выполнить основной юзерфлоу
Уфф.. Наподобие, но у нас не обязательно сервисы друг с другом только через bus общаются. Можно сходить по grpc, если сервис того же tier или tier - N. Даже можно сходить по grpc в tier + N, но сервис должен ожидать, что tier + N может не ответить и это не должно поломать работу текущего сервиса
Кстати биллинг на этой схеме должен быть Tier-1 сервис, поездку необходимо рассчитать, необходимо дать клиенту оффер. Но именно списать за нее деньги спокойно может быть tier-2, главное, чтобы биллинг не забыл, что поездка не оплачена и допнул списание
Tier это именно система лейблов сервисов, она сквозная, лейбл накладывается не на домен, а на сервис
В том и дело что при создании Tier-листа мы ориентировались на бизнес-важность. Есть критический функционал (Tier-1) - это основное флоу наших клиентов, как, например начать или завершить аренду. Если такой функционал не доступен, компания теряет деньги.
Tier-2 это важный функционал, но не являющийся основным юзерфлоу. К примеру это списание денег с карты или радар.
При таком подходе становится понятно, что разные сервисы объединяют одну критическую функциональность, эти сервисы получают Tier-1 лейбл, к нему уже выставляются инженерные требования
Конечно бывает такое, что 90% работы сервиса это вспомогательный функционал, но 10% это критически важный. В таком случае архитектурный совет может принять решение о разделе сервиса на 2 новых или переносе этого критического функционала в другой, более подходящий, сервис
P.S: Если ориентироваться на важность сервиса с технической точки зрения мы как раз и получаем ситуацию при которой "все сервисы одинаково критичны", потому что без этих сервисов часть функционала не работает
Мы уже давно живем в микросервисной архитектуре. Статья рассказывает про наш опыт их систематизации и приведения к единым требованиям, в рамках статьи я не затрагивал переезд в микросервисную архитектуру из монолитной или любой другой
Тир-лист не отменяет текущих архитектурных практик, принятых в компании. Он направлен больше на повышение стабильности системы и предсказуемость отказов, снижение вероятности каскадных сбоев
Тиры были созданы чтобы определить важность сервиса с точки зрения именно бизнеса. Разные уровни тир требуют разные уровни инженерной зрелости сервиса. Помимо CI мы проводим DR-дрили, проводим ревью сервисов и архитектуры, а так же в первую очередь за состоянием сервисов в своем домене должна следить ответственная команда во главе с лидом
Тиры - лейблы для сервисов, показывающие важность для бизнеса. Они выставляют границы уровней зрелости (в статье таблица приведена)
Уровни зрелости в себе содержат набор правил, выдвигаемых к сервису.
За соответствием сервисов к уровню зрелости присвоенного сервису тира следит команда во главе с лидом и архитектурный совет
Так же добавлю, что API Gateway в Ситидрайве тоже Tier-1 сервис, на уровне с другими критическими сервисами, без него клиенты не смогут выполнить основной юзерфлоу
Уфф.. Наподобие, но у нас не обязательно сервисы друг с другом только через bus общаются. Можно сходить по grpc, если сервис того же tier или tier - N. Даже можно сходить по grpc в tier + N, но сервис должен ожидать, что tier + N может не ответить и это не должно поломать работу текущего сервиса
Кстати биллинг на этой схеме должен быть Tier-1 сервис, поездку необходимо рассчитать, необходимо дать клиенту оффер. Но именно списать за нее деньги спокойно может быть tier-2, главное, чтобы биллинг не забыл, что поездка не оплачена и допнул списание
Tier это именно система лейблов сервисов, она сквозная, лейбл накладывается не на домен, а на сервис
В том и дело что при создании Tier-листа мы ориентировались на бизнес-важность. Есть критический функционал (Tier-1) - это основное флоу наших клиентов, как, например начать или завершить аренду. Если такой функционал не доступен, компания теряет деньги.
Tier-2 это важный функционал, но не являющийся основным юзерфлоу. К примеру это списание денег с карты или радар.
При таком подходе становится понятно, что разные сервисы объединяют одну критическую функциональность, эти сервисы получают Tier-1 лейбл, к нему уже выставляются инженерные требования
Конечно бывает такое, что 90% работы сервиса это вспомогательный функционал, но 10% это критически важный. В таком случае архитектурный совет может принять решение о разделе сервиса на 2 новых или переносе этого критического функционала в другой, более подходящий, сервис
P.S: Если ориентироваться на важность сервиса с технической точки зрения мы как раз и получаем ситуацию при которой "все сервисы одинаково критичны", потому что без этих сервисов часть функционала не работает