Пожалуйста, указывайте первоисточник при перепечатке, спасибо!
В нынешнюю эпоху Интернета, под влиянием высокого параллелизма, также необходимо обеспечить, чтобыСервис высокой доступности, если служба не является высокодоступной, это означает:
- Система не предоставляет услуги 7 * 24 часа, поэтому пользовательский опыт особенно плох, и пользователь может не иметь возможности удержать пользователя в следующий раз.
- Когда система недоступна, это влияет на имидж компании, а BAT и подобные технологии носят символический характер.
- Самое главное, когда система недоступна, немедленная потеря денег! ! ! В основном теряется в секундах, я смутно помню28 мая 2015 г. паралич Ctrip.comСогласно данным, опубликованным в финансовом отчете Ctrip за первый квартал, потери от простоя Ctrip составляют в среднем 1,0648 млн долларов США в час.
Высокая доступность очень сложна, и ее собственный уровень ограничен, и он не может охватывать так много, можно лишь сказать, что это некое осмысление и понимание высокой доступности.
Итак, как сделать систему высокодоступной?
Мы не можем допустить, чтобы сервер не зависал и чтобы не зависала служба, так как же сделать так, чтобы в этой ситуации сбоя не было проблем, то есть он может зависнуть, а служба может быть нарушена, так как же может система еще оказывать услуги?
Во-первых, если много машин и много сервисов, даже если некоторые из них сломаны, проблемы нет, и ситуация неминуемого поражения будет решена. Ниже приводится пошаговый анализ.Если в машине хранится определенное значение, его нельзя расширить.Это должна быть машина, которая зависла.Тогда это невозможно.Проблему с машиной легко решить,и та же замена конфигурации несложная.тогда служба приложений аналогично служба приложений не хранит значения связанные с состоянием ни в какой машине и не хранит в себе какие-то специфические данные характеристик.если есть то нет возможности легко расширить , только когда каждый основной компонент такой же, Нет никакой разницы, мы можем его заменить, и его легко расширить, поэтому это называетсяУслуги без гражданства.
Если текущая служба не имеет состояния, как система может динамически определить, что служба не работает? Иначе запрос все равно уходит обратно на зависшую машину, как перенести на новую машину? тогда может понадобитьсяСлужба обнаружена и зарегистрирована.
Если вышеописанная ситуация достигнута, в принципе достаточно разобраться с общей ситуацией, но интернет сложный, а проблема в том, что машина сломана и служба сломана только что упоминалась, то что делать, если сеть временно заблокировали из-за этого?
Таким образом, должно бытьобнаружение сердцебиения,Регулярно приезжайте, чтобы узнать, доступен ли он (машина сломана, сервис не работает, сеть заблокирована), он все равно недоступен. Эту ситуацию можно решить с помощью регистрации и обнаружения службы, но иногда сеть отключается, так что в этой конкретной ситуации? Например, сервис а только что отправил запрос сервису б, а сервис б получил запрос, потом вдруг сеть в это время отключается, но сервис б завершил логическую обработку, а сервис а отвечает, что ответа нет , стойка регистрации. Если время ожидания истекло, запустите его снова, а затем, если служба b снова выполнит предыдущую логику, есть ли проблема? Например, если вы уже заплатили 200 юаней, хотите ли вы заплатить еще 200 юаней? Здесь нужно упомянуть об одномидемпотентностьПринцип проектирования идемпотент, как он идемпотент, то есть результат многократного выполнения один и тот же, если есть идемпотентный дизайн, то бояться этой ситуации нечего, если нет обратной связиПовторить попыткуМожно, проблем не будет.
Чтобы достичь вышеизложенного, нужно справиться с ситуацией, когда машина сломана, служба зависла, сеть заблокирована или флэш-память отключена и т. Д. В основном нет серьезных проблем, поэтому Интернет в настоящее время имеет высокий параллелизм, затем в случае высокого параллелизма, как улучшить систему, способную?
Как и в случае с перемещением вещей, один человек работает медленно, а другие люди могут помочь с чем-то.Поскольку в приведенной выше архитектуре можно добавлять машины и службы, легко думать о дополнительных машинах и службах. Тогда это должно быть быстрее, чем меньше машин.Например, машин 5, столько запросов приходит, какая стратегия используется для их распределения по разным машинам? Через оборудование, через какие-то программные уровни, но должна быть регистрация сервисов обнаружения, иначе нет возможности динамически узнать, а есть контроль какой-то информации, черные и белые списки, частота доступа и т.д.Во многих случаях добавление машины может показаться относительно небольшим, но иногда это более эффективно, но вы не можете добавить машину вслепую.В некоторых случаях добавление машины не может быть решено.
Больше машин действительно быстрее.Если в сервисе есть метод блокировки, то он бесполезен даже если сервисов много, поэтому надо обращать внимание напроблема тайм-аута службы,Так как сервис идемпотентный, не имеет значения, даже если он выполняется, и тайм-аут не повлияет на последующие сервисы в течение длительного времени (нисходящие сервисы не работают, потоки заблокированы, нижестоящие сервисы заняты и т. д.).
Что касается некоторых шаблонов проектирования синхронизации и асинхронности, синхронизация должна использоваться в некоторых бизнес-сценариях, которые должны выполняться последовательно. через много шагов), поэтому из общего времени одного запроса синхронизация не обязательно будет быстрее, но с макро точки зрения запрос на улучшение параллелизма будет намного больше). Давайте кратко поговорим об асинхронности. Внутри службы асинхронность должна упоминать многопоточность. Многие многопоточности могут улучшить использование ЦП и производительность системы, но стоимость реализации намного выше. Так как же разные службы могут быть напрямую асинхронными? (промежуточное программное обеспечение сообщений сложно, первое, что нужно убедиться, этодействительно асинхронный,Вторая необходимость обеспечитьНе тяжелый и не протекает, эти два пункта действительно сложны, особенно в случае больших данных), особенно сетевой ввод-вывод должен быть ориентирован на асинхронную модель, но Netty очень хорошо ее инкапсулирует.
Поскольку у каждой машины или службы есть верхний предел, если вы измеряете флуд и это не его способность справиться с ним, как его решить?
Эту проблему можно увидеть везде в жизни.Это просто после Национального дня пойти домой и пойти поиграть, и это можно увидеть везде.Например, проходя проверку безопасности, охранник возьмет специальный знак чтобы увидеть людей.Не так много, чтобы проверить, пусть люди сзади делают это, а затем ждать его. , а если есть высокоуровневые, или машина вот-вот уедет, вообще пусть проезжают первыми, в архитектуре софта она должна называтьсяОграничение тока, ухудшение обслуживания,Обычно есть две стратегии управления (1, отклонить некоторые запросы, 2, закрыть некоторые службы). Возможно, раньше упоминалось закрытие некоторых служб, но сейчас это не рекомендуется (Ведь это еще и воплощение технической мощи компании), текущий акцент делается на отклонении части запроса, где добавить контроль над этой частью? Это часть, которую нужно контролировать, и ее следует добавлять к каждому слою.
Я смутно припоминаю, что в индустрии есть поговорка,Три волшебных оружия для обеспечения высокого параллелизма и высокой доступности: ограничение тока, переход на более раннюю версию и кэширование., Что касается кэша, вы должны связаться с большинством.Интернет-бизнес характеризуется большим количеством чтения и меньшим количеством записей, поэтому очень удобно использовать кэш.
Поскольку запрос находится в одной службе, расширение по-прежнему непросто расширить, и некоторые вызовы в объединенной службе очень велики, а некоторые вызовы относительно малы, потому что продолжают делить и продолжать демонтировать, так что параллелизм все еще может снова улучшиться.
микросервисы,Концепций микросервисов много.Первая из упомянутых - это вертикальное разделение, которое легко понять.После этого может быть много вертикальных бизнесов, и нужно продолжать горизонтальное разделение.Чем глубже, тем лучше).
Благодаря вышеизложенному, проблемы, связанные с зависанием службы, поломкой машины, блокировкой или перепрошивкой сети, были решены, а параллелизм можно улучшить, и можно приложить все усилия, чтобы сделать службу высокодоступной. .Ну, так как это вызывает много проблем,Следовательно, необходимо решить проблемы, вызванные этими модификациями:
- Раньше в сервисе было легко контролировать транзакции. Затем, после микросервисов, контроль транзакций стал особенно важен. Много раз мы не могли обеспечить строгую согласованность, но мы можем это сделать.окончательная согласованностьЭто возможно.
- Мониторинг цепочки вызовов особенно важен, наряду с ранним предупреждением.
- Распределенное ведение журналов также особенно важно.
- Расширенные возможности jstack и Btrack особенно важны в реальных условиях.
На сегодня все.Надеюсь всем будет полезно.Я тоже учусь и думаю.Надеюсь всем будет уделено больше внимания,поддержки и лайков и лайков,спасибо! ! !
Проверьте больше истории, добро пожаловать, чтобы обратить внимание на личный публичный аккаунт! ! !