Когда работаешь с изящными небольшими примерами форматом с книжную страницу, все кажется простым. Но реальный мир намного сложнее. Что будет, когда наши архитектуры микросервисов станут расширяться и превращаться из простых и скромных в нечто более сложное? Что будет, когда нам придется справляться со сбоями нескольких отдельных сервисов или управлять сотнями сервисов? Какие схемы нужно будет скопировать, когда микросервисов у вас станет больше, чем людей? Давайте все это выясним.
Мы понимаем, что нештатных ситуаций не избежать. Может отказать жесткий диск. Может дать сбой наша программа. И все, кто читал об ошибках, происходящих при распределенном вычислении, могут сказать о том, что знают о ненадежности сети. Мы можем приложить максимум усилий, пытаясь ограничить число сбоев, но при определенном масштабе сбои становятся неизбежными. Жесткие диски, к примеру, сейчас надежнее, чем когда-либо прежде, но временами и они выходят из строя. Чем больше у вас жестких дисков, тем выше вероятность отказа для отдельной стойки; при расширении масштаба отказ становится статистически неизбежен.
Даже тем из нас, кто не собирается слишком сильно расширять свою систему, все же стоит учитывать возможность сбоев. Если мы, к примеру, можем изящно обрабатывать сбои сервиса, то у нас получится и обновлять службу на месте, поскольку иметь дело с запланированными отключениями намного проще, чем с незапланированными.
Мы также сможем тратить немного меньше времени на попытки остановить неизбежное и уделять немного больше времени на то, чтобы справиться с ними как можно изящнее. Меня удивляет, что немалое количество организаций тратят силы и средства в первую очередь на попытки предотвращения сбоев и значительно меньше усилий направляют на упрощение восстановления после них.
Предположение о том, что все может дать сбой и неизбежно его даст, заставит изменить представление о том, как решать проблемы.
Я видел пример такого мышления, когда много лет назад был в кампусе Google. В приемной одного из зданий в Маунтин-вью в качестве своего рода экспозиции стояла старая стойка с машинами. И там я кое-что заприметил. Эти серверы были без кожухов — голые материнские платы, вставленные в стойку. Но мне бросилось в глаза то, что жесткие диски были смонтированы на липучках. Я спросил одного из сотрудников Google о том, почему так сделано. Он ответил, что жесткие диски настолько часто выходят из строя, что им не захотелось их прикручивать. Их просто вытаскивали, бросали в мусорное ведро и крепили на липучке новый диск.
Итак, позвольте повторить: при расширении, даже если будут приобретены самый лучший комплект, самое дорогое оборудование, избежать того, что что-то может дать сбой и сделает это, просто невозможно. Поэтому нужно предполагать, что сбой может произойти. Если это обстоятельство учитывать во всем, что вы создаете, и планировать сбои, можно будет пойти на различные компромиссы. Если известно, что система сможет справиться с тем фактом, что сервер может дать сбой и даст его, то зачем беспокоиться и сильно тратиться на все это? Почему бы не воспользоваться простой материнской платой с самыми дешевыми компонентами (и какими-нибудь липучками), как это было сделано в Google, не слишком переживая за стойкость отдельного узла?
Тема межфункциональных требований уже рассматривалась в главе 7. Представление о межфункциональных требованиях формируется из рассмотрения таких аспектов, как живучесть данных, доступность сервисов, пропускная способность и приемлемое время отклика сервисов. Многие технологии, упоминаемые в этой и других главах, имеют отношение к подходам, позволяющим реализовать эти требования, но о том, какими конкретно могут быть эти требования, знаете только вы.
Обладание автоматически масштабируемой системой, способной реагировать на возросшую нагрузку или отказ отдельных узлов, может быть фантастическим результатом, но окажется избыточным для системы создания отчетов, которую нужно запускать только дважды в месяц и для которой вполне приемлемо пару дней находиться в простое. Аналогично этому отработка способов сине-зеленых развертываний для ликвидации простоев сервиса может иметь смысл для системы электронной торговли, но для корпоративной базы знаний, доступной только во внутренней сети организации (в интранете), будет, наверное, излишней.
Задать количество приемлемых отказов или допустимую скорость системы можно на основе требований, предъявляемых пользователями данной системы. Это поможет вам понять, какие технологии разумнее всего будет применить. Тем не менее пользователи не всегда смогут сформулировать конкретные требования. Следовательно, чтобы получить правильную информацию и помочь им понять, каковы будут относительные затраты на предоставление различных уровней услуг, нужно задавать вопросы.
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии