При создании программного обеспечения лучше всего знать о болевых точках разработки систем масштаба предприятия, чтобы можно было поддерживать стабильность на всех масштабах. Зная об этих проблемных областях, унция предосторожности может спасти кого-то от серьезных головных болей в будущем. Это основной тезис первой части книги Майкла Т. Найгарда Выпуск!: Проектирование и развертывание готового программного обеспечения. Далее он предлагает таксономию антипаттернов и предлагает шаблоны для решения этих антипаттернов. Я хотел бы перечислить и обобщить те из них, которые показались мне наиболее полезными, чтобы дать себе и будущим читателям краткий обзор некоторых идей, содержащихся в этой книге.
Антипаттерны стабильности
Точки интеграции.Точки интеграции являются проблемой стабильности при любом масштабе программного обеспечения, и чем больше система, тем больше точек интеграции может стать проблемой. Будь то внутренний или внешний код, проблемы обязательно возникнут при связывании любых двух частей функциональности вместе. Вот почему настолько важна развязка, насколько это возможно, она сводит к минимуму точки интеграции и снижает вероятность сбоя. Найгард указывает определенные точки интеграции, о которых следует помнить, например, протоколы HTTP, библиотеки поставщиков и блокирующие потоки. Следует быть осторожным, когда они имеют дело с точками интеграции, чтобы максимально изолировать угрозу.
«Каждый пользователь потребляет больше памяти». -Майкл Найгард
Пользователи. Хотя это может показаться очевидным утверждением, его эффект никогда не бывает одинаково очевидным. Ответить на вопрос, как система должна реагировать на чрезмерный спрос, непросто. Технически существует столько же различных типов пользователей, сколько и самих пользователей: обычные обычные пользователи, непредсказуемые пользователи, злонамеренные пользователи, и этот список можно продолжить. Но важно продумать и минимизировать влияние каждого типа пользователей, особенно злонамеренных. Это бесконечная битва, в которой нужно сражаться.
Эффекты масштабирования. Существует ряд вариантов дизайна, которые ставят под угрозу стабильность при масштабировании системы. Связь точка-точка, когда каждый экземпляр системы должен общаться напрямую с каждым другим экземпляром, может быстро вырасти до неуправляемых масштабов. Каждый новый добавленный экземпляр заставляет каждый предыдущий экземпляр взаимодействовать с этим новым экземпляром. Этот рост O(n^2) может быстро выйти из-под контроля. Общие ресурсы также следует рассматривать как угрозу стабильности по мере масштабирования системы. Когда мы добавляем экземпляры приложения, пытающегося получить доступ к общему ресурсу, оно становится узким местом. Следует рассмотреть возможность добавления избыточных общих ресурсов.
Шаблоны стабильности
Тайм-ауты.Тайм-аут — это механизм, используемый для прекращения ожидания ответа, когда вы понимаете, что ответ не будет получен. Это отличный способ изящно обрабатывать ошибки в других системах. Это полезно для точек интеграции, блокирующих потоков или любого процесса, который может зависнуть или медленно реагировать. Использование тайм-аутов позволяет вам реагировать любым удобным для вас образом или восстанавливаться после неожиданного сбоя.
Автоматический выключатель — это полезный шаблон, который может гарантировать, что ошибки не будут распространяться из одной части вашей системы в другую. Автоматический выключатель действует как обычно до тех пор, пока отказ или накопление отказов не «разомкнет» цепь. Это признак того, что что-то не так, и эта часть системы должна перестать работать как обычно и закрыться. По прошествии некоторого времени автоматический выключатель «полуоткрывается» и снова пытается функционировать. Если все в порядке, он возвращается в нормальное состояние, в противном случае он возвращается в «открытое» состояние. Это отличное решение для антипаттерна Integration Points. Как говорит Найгард: «Когда возникают трудности с точками интеграции, перестаньте звонить!»
Переборки. Разделение системы может предотвратить сбой в одной части системы от выхода из строя другой. Это пример того, что Найгард называет переборками, названными в честь металлических перегородок на лодках, которые препятствуют переходу воды из одной секции в другую. Физическая избыточность является обычной реализацией этого шаблона и делает систему более отказоустойчивой, позволяя продолжать работу, даже если часть системы была скомпрометирована. Это невероятно полезно при масштабировании с помощью общих ресурсов, поскольку позволяет обслуживать больше запросов, имея более одного места для доступа к ресурсам.
Это всего лишь пример паттернов стабильности и антипаттернов, которые я нашел особенно полезными или наводящими на размышления, читая книгу Найгарда. Я хотел создать краткий справочник по паттернам и антипаттернам, к которым, как мне казалось, я, скорее всего, вернусь в будущем.
