Высокая доступность не является набором общих решений, а складывается из множества звеньев, одно звено - это другое звено, призрак знает, сколько карт я должен разобрать с этими связанными звеньями, чтобы окончательно сформировать высокую доступность всей системы план посадки.
Что такое высокая доступность
При определении того, что является высокой доступностью, вы можете сначала определить, что недоступно.Контент веб-сайта, наконец, представлен пользователям.Он должен пройти через несколько ссылок, и пока какая-либо ссылка не работает, это может привести к тому, что страница веб-сайта будет недоступна. недоступен Это То есть сайт недоступен.
Обратитесь к Википедии, чтобы узнать, как Вики определяет высокую доступность.
Способность системы выполнять свои функции без перерыва представляет собой степень доступности системы и является одним из критериев проектирования системы.
Эта трудность или основное внимание уделяется «без перерыва», чтобы обеспечить непрерывное предоставление услуг 7 x 24 часа без исключения.
Зачем нужна высокая доступность
Система, предоставляющая внешние услуги, требует комбинации аппаратного и программного обеспечения, но в нашем программном обеспечении будут ошибки, аппаратное обеспечение будет постепенно стареть, сеть всегда будет нестабильной, а программное обеспечение будет становиться все более и более сложным и огромным. не может быть достигнуто, и внешние условия также могут вызвать перебои в обслуживании, такие как перебои в подаче электроэнергии, землетрясения, пожары, обрывы оптоволокна экскаваторами, и степень этих эффектов может быть больше.
Широкие возможности оценки
Время Широта Метод оценки высокой доступности
В отрасли существует относительно хорошо известный набор показателей для оценки доступности веб-сайта. N 9 часто используются для количественной оценки доступности, которая может быть напрямую сопоставлена с процентом времени безотказной работы веб-сайта.
| описывать | N 9s | Уровень доступности | Ежегодный простой |
|---|---|---|---|
| в основном доступны | 2 9 с | 99% | 87,6 часов |
| высокая доступность | 3 девятки | 99% | 8,8 часов |
| Доступна возможность автоматического восстановления после сбоев | 4 девятки | 99.99% | 53 минуты |
| очень высокая доступность | 5 девяток | 99.999% | 5 минут |
Интернет-компания, в которой я работал раньше, также определяла доступность по этому показателю, но и у нее возникли некоторые проблемы в процессе внедрения, например, некоторые обновления сервисов или миграция данных, очевидно, могут быть остановлены или остановлены посреди ночи. , учитывая будущее В отчете показано, сколько девяток наша система достигла высокой доступности, и простое решение отказа от простоев, таких как время простоя в течение 2 часов, никогда не достигнет 4 девяток. Однако в некоторых ситуациях с высокой степенью параллелизма, таких как всплески или групповые драки, несмотря на то, что сервис останавливается на несколько минут, влияние на бизнес всей компании может быть очень значительным, а количество заказов, потерянных каждую минуту, может быть огромным. . Таким образом, N 9 для количественной оценки доступности фактически должны учитывать бизнес-ситуацию.
Средства проектирования высокой доступности микросервисов
Высокая доступность является относительно сложным предложением.По сути, высокая доступность участвует во всей обработке, а также во всех аспектах разработки решений высокой доступности.Детали, которые появятся в середине,различны, поэтому нам необходимо решение для микросервисов выполняет проектирование на высшем уровне, ориентируясь на высокую доступность сервисов, сначала проверьте, сколько карт у нас на руках.
резервирование услуг
Стратегия резервирования
Каждый доступ может состоять из нескольких служб, каждая машина и каждая служба могут иметь проблемы, поэтому первое соображение заключается в том, что каждая служба должна иметь более одной копии и может быть несколькими копиями, так называемые множественные согласованные службы. Это избыточность Служба, упомянутая здесь, обычно относится к службе машины, службе контейнера и службе самой микрослужбы.
На уровне обслуживания машин необходимо учитывать, является ли избыточность между каждой машиной изолированной и избыточной в физическом пространстве. Например, развернуты ли все машины в разных компьютерных залах, развернуты ли они в разных шкафах в одном и том же компьютерном зале и развернуты ли контейнеры докеров на разных физических машинах. Принятая стратегия на самом деле зависит от бизнеса службы, поэтому необходимо оценить и оценить службу, чтобы принять разные стратегии, разные стратегии имеют разные степени безопасности, и связанные с этим затраты также разные, и услуги с более высокие уровни безопасности могут быть более чем При рассмотрении разных компьютерных залов необходимо также учитывать район, в котором находится каждый компьютерный зал, например, два компьютерных зала не должны располагаться в одной сейсмоопасной зоне и т. д.
лица без гражданства
Избыточность службы потребует от нас расширения или сокращения службы в любое время.Возможно, что мы перейдем от машин 2 к машинам 3. Если мы хотим расширить или уменьшить службу в любое время и в любом месте, мы требуем, чтобы наша служба быть апатридом, так называемым апатридом, заключается в том, что содержимое службы и данные каждой службы согласованы.
Например, с точки зрения нашей микросервисной архитектуры мы разделили несколько уровней по горизонтали.Поскольку каждый уровень не имеет состояния, расширить эту горизонтальную архитектуру очень просто.
Предположим, нам нужно расширить шлюз, нам нужно только добавить сервисы, и нам не нужно учитывать, хранит ли шлюз дополнительные данные.
-
Шлюз не сохраняет какие-либо данные сеанса, не предоставляет услуги, обеспечивающие согласованность, хранит противоречивые данные несколькими способами и использует промежуточное ПО, которое лучше выполняет синхронизацию данных.
Это текущее основное решение.Сама служба предоставляет логические услуги в максимально возможной степени, чтобы обеспечить централизованную обработку согласованности данных, чтобы можно было извлечь «состояние», а шлюз мог поддерживать состояние «без сохранения состояния».
Это просто пример шлюза.В микросервисах только в основном все сервисы должны делаться таким образом.Если в сервисе есть состояние,то состояние должно извлекаться и обрабатываться компонентами,которые лучше умеют обрабатывать данные.Вместо компрометация состояния с данными в микросервисах.
Высокая доступность хранилища данных
Упомянутая выше избыточность сервисов может быть просто понята как высокая доступность вычислений.Высокая доступность вычислений должна быть только без сохранения состояния и может просто увеличиваться или уменьшаться, но для систем, которым необходимо хранить данные, сами данные имеют состояние.
По сравнению с хранением и вычислениями есть существенная разница:
Перемещение данных с одной машины на другую требует передачи по сети.
Сеть нестабильна, особенно сеть через машинный зал. Задержка пинга может составлять десятки сотен миллисекунд. Хотя миллисекунды для людей почти ничего, но для систем высокой доступности она принципиально другая. Это означает, что в какой-то момент в время в системе данные должны быть противоречивыми. Согласно формуле «данные + логика = бизнес», данные противоречивы, логика непротиворечива, и конечная эффективность бизнеса также будет противоречивой. Например
Будь то задержка передачи при нормальных обстоятельствах или прерывание передачи при нештатных обстоятельствах, данные системы будут несогласованными в определенный момент времени, и несогласованность данных вызовет проблемы в бизнесе, но если данные не являются избыточными , Высокая доступность системы не может быть гарантирована
Таким образом, сложность хранения высокой доступности заключается не в том, как сделать резервную копию данных, а в том, как уменьшить или избежать влияния несогласованности данных на бизнес.
В области распределенных вычислений существует известная CAP-теорема, которая теоретически демонстрирует сложность обеспечения высокой доступности хранилища, то есть высокая доступность хранилища не может одновременно удовлетворять «непротиворечивости, доступности и отказоустойчивости разделов» и может удовлетворять не более чем 2. Среди них отказоустойчивость разделов необходима при распределении, а это означает, что мы должны найти компромисс между согласованностью и доступностью в сочетании с бизнесом при проектировании архитектуры.
Суть решения высокой доступности хранилища заключается в копировании данных на несколько устройств хранения и достижении высокой доступности за счет избыточности данных.Сложность в основном отражается в несогласованности данных, вызванной задержкой или прерыванием репликации данных.Мы проектируем хранилище В архитектуре необходимо учитывать следующие аспекты:
- Как скопировать данные
- Каковы обязанности каждого узла в архитектуре
- Как бороться с задержками репликации данных
- Как обеспечить высокую доступность при ошибке узла в архитектуре
Репликация данных master-slave
Репликация master-slave — наиболее распространенное и простое решение для обеспечения высокой доступности хранилища, такое как Mysql, redis и т. д.
Преимущество его архитектуры в том, что она проста. Хост имитирует запись и чтение, а ведомый отвечает только за операции чтения. не удается, операция чтения также может обеспечить плавный ход операции чтения.
Недостатком является то, что клиент должен воспринимать наличие отношений master-slave и отправлять разные операции на разные машины для обработки, кроме того, в репликации master-slave за операцию чтения отвечает ведомая машина, что может привести к несогласованности данных. из-за большой задержки репликации master-slave.
Переключатель данных ведущий-ведомый
Я только что сказал, что есть две проблемы с переключателем master-slave: 1. Операция записи не может быть выполнена из-за отказа главной машины 2. Одна из подчиненных машин должна быть вручную обновлена до главной машины.
Чтобы решить эти две проблемы, мы можем разработать схему автоматического переключения ведущий-ведомый, которая предназначена для определения состояния главного устройства, решений о переключении, потери данных и конфликтов.
1. Определение статуса хоста
Необходимо несколько контрольных точек, чтобы определить, является ли хост-компьютер нормальным, существует ли процесс, есть ли тайм-аут, является ли операция записи невыполнимой, является ли операция чтения невыполнимой, суммировать их и передать их переключателю. решение.
2. Переключение решений
Определите время решения для переключения, при каких обстоятельствах ведомый должен быть обновлен до ведущего, если процесс не существует или если операция записи не разрешена, переключение будет выполнено после непрерывного обнаружения скольких сбоев. Какой подчиненный узел следует выбрать для обновления до главного узла, вообще говоря, для обновления следует выбрать подчиненный узел с наибольшим шагом синхронизации. Независимо от того, является ли переключатель автоматическим или полуавтоматическим, с помощью метода сигнализации, пусть руководство сделает подтверждение.
3. Потеря данных и конфликт данных Данные записываются на хост, и они зависают, прежде чем они будут скопированы на подчиненный хост.Как с этим бороться в это время, это также должно учитывать способ бизнеса, чтобы гарантировать, что CP или AP
Существует также проблема конфликта данных.Большая часть этой проблемы в mysql вызвана самоувеличивающимся первичным ключом.Даже если проблема конфликта данных, вызванного самоувеличивающимся первичным ключом, не рассматривается, на самом деле увеличение первичного ключа вызовет много проблем, которые здесь не описаны.Скажем, избегайте использования автоинкрементных первичных ключей.
разделение данных
Вышеупомянутая избыточность данных может быть решена путем репликации данных, но расширение данных должно быть решено путем сегментирования данных (если это сегментированная таблица в реляционной базе данных).
Режим сегментирования HDFS и mongoDB в основном основан на этом режиме сегментирования Основные моменты, которые мы учитываем при проектировании сегментирования:
- Делать шардинг данных, как сопоставлять данные с узлами
- Значение признака фрагментации данных, то есть по какому признаку (полю) в данных фрагментировать
- Управление метаданными осколков данных, как обеспечить высокую производительность и высокую доступность серверов метаданных и как обеспечить строгую согласованность, если это группа серверов.
Гибкость / Асинхронность
Асинхронный
В каждом вызове, чем больше время, тем больше риск тайм-аута, чем сложнее логика и чем больше шагов необходимо выполнить, тем выше риск отказа.Если бизнес позволяет, пользовательский вызов даст пользователю только необходимые результаты , вместо того, чтобы требовать синхронизации, результаты могут обрабатываться асинхронно в другом месте, что снижает риск тайм-аута и разделяет сложный бизнес для уменьшения сложности.
Конечно, у асинхронности есть много преимуществ, таких как развязка и развязка и т. д. Это только с точки зрения доступности.
Существует примерно три реализации асинхронности:
- После того, как сервер получает запрос, он создает новый поток для обработки бизнес-логики, и сервер сначала отвечает клиенту.
- После того, как сервер получает запрос, сервер сначала отвечает клиенту, а затем продолжает обработку бизнес-логики
- После того, как сервер получает запрос, сервер сохраняет информацию в очереди сообщений или базе данных и отвечает клиенту, а процесс бизнес-обработки сервера считывает информацию из очереди сообщений или базы данных для обработки бизнес-логики.
Гибкость
Что такое гибкость, представьте себе сценарий, наша система будет увеличивать баллы, соответствующие сумме заказа, для каждого пользователя, который размещает заказ.Когда пользователь завершает заказ, возникает проблема с услугой, которую мы ему даем, чтобы увеличить баллы , В настоящее время мы хотим отменить заказ или позволить ему пройти первым, а проблему с баллами следует решить путем повторного или тревожного оповещения?
Так называемая гибкость означает, что в условиях, которые позволяет наш бизнес, мы не можем предоставить пользователям 100% доступных услуг пользователям посредством понижения, вместо того, чтобы каждый раз передавать либо 100 баллов, либо 100 баллов. лист ответов.
То, как добиться гибкости, на самом деле больше связано с пониманием и оценкой бизнеса, а гибкость — это скорее своего рода мышление, которое требует глубокого понимания бизнес-сценариев.
В сценарии заказа электронной коммерции размещение заказа, вычет запасов и оплата — это все шаги, которые необходимо выполнить.Если это не удается, заказ не выполняется, но добавление баллов, доставка и послепродажное обслуживание могут выполняться гибко. Иди проверяй, не нужно терять доступность всего заказа за бонусные баллы
Итог / отказоустойчивость
Суть в том, что мы часто говорим о деградированном плане, и план должен быть реализован, но суть здесь может быть больше мысли и больше плана.В каждой операции могут быть ошибки, и мы также можем это принять .Совершайте ошибки, но у нас должен быть восходящий план для каждой ошибки.Этот итоговый план на самом деле является нашей отказоустойчивостью или мерами по максимальному предотвращению большего вреда.На самом деле это также процесс непрерывной деградации.
Например:
Например, мы запрашиваем интерфейс персонализированной рекомендации товаров пользователя на главной странице, если мы обнаружим, что система рекомендаций неверна, мы не должны расширяться (выбрасывать исключение непосредственно пользователю) или оставить ошибку вызова интерфейса. , но должен быть совместим с ошибкой вызывающего интерфейса, чтобы обеспечить большую гибкость. В настоящее время вы можете выбрать получение кэшированных данных, у которых ранее не было сбойного интерфейса. Если нет, вы можете получить общие продукты без персональных рекомендаций. Если нет, вы можете прочитать статический текст для отображения.
Поскольку наша архитектура является многоуровневой, она разделена на приложение, шлюз, уровень бизнес-логики, уровень доступа к данным и т. д., а организационная структура также разделена в соответствии с группой внешнего интерфейса, группой внутренней бизнес-логики и даже мидл-офисная группа. Поскольку существует иерархия кода и структуры персонала, каждый уровень должен иметь представление об устранении ошибок следующего уровня и обеспечении максимально возможного обслуживания для верхнего уровня.
Например:
Предполагается, что цена продажи товара в долларах США является ценой продажи/обменным курсом товара в юанях.В настоящее время ошибка возникает на нижнем уровне данных.Если верхний уровень разделен напрямую, он обязательно выдаст java.lang.ArithmeticException : / на 0. Принцип, согласно которому любой уровень вызывающих сервисов ненадежен, должен обрабатываться с отказоустойчивостью, и исключения не должны распространяться, и, что более важно, мы должны гарантировать, что наш уровень выполняет наилучшие возможные услуги для определения последнего время.
балансировки нагрузки
Я считаю, что тема балансировки нагрузки в основном проникла в сердца каждого разработчика или проектировщика микросервисов.Реализация балансировки нагрузки включает аппаратное и программное обеспечение, аппаратное обеспечение включает F5, A10 и другие машины, а программное обеспечение включает LVS, nginx, HAProxy. и т. д. Алгоритмы балансировки нагрузки случайные, RoundRobin, ConsistentHash и т. д.
Отказоустойчивость балансировки нагрузки Nginx
процесс передачи
Nginx планирует в соответствии с заданным алгоритмом балансировки нагрузки.Когда делается запрос к tomcat1, nginx обнаруживает, что у tomcat1 есть ошибка соединения (сбой узла), и nginx удалит tomcat1 из вызываемого списка загрузки согласно определенному механизму. следующий запрос, nginx не будет распространять запрос на проблемный tomcat1, передаст запрос другим tomcats.
Сбой узла
По умолчанию nginx оценивает сбой узла на основе отказа в соединении и тайм-аута.Когда сбои накапливаются на узле, когда сбои превышают max_fails, узел выходит из строя.
Восстановление узла
Когда количество сбоев узла больше, чем max_fails, но не превышает fail_timeout, nginx не обнаружит узел до тех пор, пока не истечет время сбоя или пока все узлы не выйдут из строя, nginx повторно обнаружит узел.
Отказоустойчивость балансировки нагрузки ZK
Когда ZK используется в качестве центра регистрации, обнаружение сбоев осуществляется Zk.Уровень бизнес-логики регистрируется в ZK через механизм контроля пульса, а шлюз подписывается на ZK, чтобы узнать, сколько списков можно вызвать. Когда уровень бизнес-логики перезапускается или закрывается, он прерывает пульсацию с помощью zk, и zk обновляет вызываемый список.
При использовании zk в качестве координатора балансировки нагрузки самая большая проблема заключается в том, доступен ли zk для сервисов, основанных на pingpong. Неизвестный. В настоящее время только шлюз может знать, доступна ли служба бизнес-логики.
Идемпотентный дизайн
Причина, по которой возникает проблема идемпотентного дизайна, в основном связана со стратегией аварийного переключения балансировки нагрузки, то есть сбойная служба будет повторена.Вообще говоря, если это служба операции чтения, проблем с повторением не будет. выполнение, но представьте себе на мгновение, если это операция по созданию заказа и сокращению запасов, первый вызов tomcat1 также истекает, а затем снова вызывается tomcat2. В настоящее время мы не можем подтвердить, вызывал ли tomcat1 по таймауту действительно вызывается.Это может вообще не быть успешным.Возможно, что вызов был успешным, но таймаут по какой-то причине возвращается, поэтому этот интерфейс будет вызываться дважды в значительной степени. Если мы не гарантируем идемпотентность, возможно, заказ приведет к сокращению запасов в 2 раза.
Так называемая идемпотентность гарантирует, что в одном и том же бизнесе интерфейс будет вызываться несколько раз, а результаты будут одинаковыми.
Предохранитель понижения предела рабочего тока
Во-первых, давайте поговорим о цели ограничения тока/слияния в микросервисах.После микросервисов система развертывается распределенным образом, и системы взаимодействуют через инфраструктуру rpc.Вероятность отказа всей системы увеличивается с ростом Масштаб системы.
Какая связь между текущим ограничением и высокой доступностью? Предположим, что наша система может выдерживать одновременный доступ максимум 500 человек, но внезапно увеличилась до 1000 человек за все время, и вся система была внезапно перегружена. Изначально было 500 человек. , Возможность пользоваться услугами нашей системы внезапно стала недоступной для всех.Вместо того, чтобы лишить 1000 человек возможности получить услугу, лучше позволить 500 людям получить услугу и отказаться от остальных 500 человек. Текущее регулирование — это изоляция доступа для обеспечения доступности пользователей в пределах диапазона системы отдела.
Какова связь между предохранителем и высокой доступностью? Как упоминалось выше, микросервисы представляют собой сложную цепочку вызовов. Предположим, что модуль A вызывает модуль B, модуль B вызывает модуль C, а модуль C вызывает модуль D. В это время модуль D выводит If в задаче серьезная задержка, в это время вся цепочка вызовов будет тянуться модулем D, A ждет B, B ждет C, C ждет D, а ресурсы ABCD заблокированы и не могут быть выпущен, если движение большое Это также может вызвать лавины. Слияние, активное отбрасывание вызовов модуля D и выполнение некоторых функциональных понижений может обеспечить надежность нашей системы. Фьюзинг — это изоляция модуля для обеспечения доступности максимальной функциональности.
Служба управления
Подразделение сервисных модулей
Существует неразрывная связь между сервисным модулем и сервисным модулем, но сервисный модуль имеет свой вес в бизнесе. Например, модуль заказа может быть главным приоритетом компании электронной коммерции. Если есть проблема, это напрямую повлияет на всю компанию.Выручка, и модуль обслуживания фоновых запросов также может быть важен, но его уровень важности определенно не так важен, как заказы. Следовательно, при управлении сервисом необходимо уточнить уровень важности каждого сервисного модуля, чтобы лучше отслеживать и распределять ресурсы. Это стандарт для каждой компании, например, в электронной коммерции компания может быть более склонна использовать количество запросов пользователей и выручку в качестве показателя для определения уровня обслуживания.
| Уровень обслуживания | сервисный модуль |
|---|---|
| первоклассный сервис | Платежная система Сервис заказа Товарный сервис Сервис для пользователей Издательская система... |
| вторичная служба | Система управления службами сообщений Система CRM Система баллов Система BI Система комментариев Система ... |
| третичное обслуживание | Система фонового журнала |
Реальное разделение может быть более сложным, чем это, и оно должно определяться в соответствии с конкретным бизнесом.Это можно оценить по трафику и трафику сервисного модуля.Часто более важные модули также предоставляют больше ресурсов, поэтому необходимо не только техническая архитектура хорошо известна, и необходимо наизусть понимать различные бизнес-формы компании.
Оценка службы не только играет важную роль в определении сбоя, но и определяет силу мониторинга службы.Мониторинг службы играет роль в обеспечении высокой доступности.Он может не только сохранять место сбоя службы для ожидания возобновления работы в будущем, но и многое другое. Самое главное, что он может играть роль пророка и судить заранее, во многих случаях он может предвидеть опасность и предотвратить ее до того, как она произойдет.
сервисный мониторинг
Мониторинг служб является важной частью управления микрослужбами. Совершенство системы мониторинга напрямую влияет на качество наших микрослужб. Существует ли полная система мониторинга, которая может оценить качество наших микрослужб, когда они работают в сети? Здоровье очень важно для надежность и стабильность всей системы, что является обязательным условием высокой доступности.
Мониторинг сервисов больше связан с прогнозированием рисков и заблаговременным обнаружением проблем до того, как они станут недоступными.Если система получит систему мониторинга и сигнализации и сможет сама исправить ошибку, то ошибка может быть устранена незаметно.Если система обнаружит, что сигнализация не может исправить сама по себе она может уведомлять персонал о раннем доступе.
Какие уровни должна включать относительно полная система мониторинга микросервисов Как показано на рисунке ниже, ее можно условно разделить на пять уровней мониторинга.
Мониторинг инфраструктуры
Например, низкоуровневые устройства, такие как сети, коммутаторы, маршрутизаторы и т. д., надежность и стабильность этих устройств напрямую влияют на стабильность сервисных приложений верхнего уровня, поэтому необходимо отслеживать сетевой трафик, потерю пакетов, ошибки пакетов. , количество подключений и т. д. основные показатели для мониторинга.
мониторинг системного уровня
Он охватывает физические машины, виртуальные машины и операционные системы, которые являются аспектами мониторинга на уровне системы.Он отслеживает несколько основных показателей, таких как использование процессора, использование памяти, дисковый ввод-вывод и пропускная способность сети.
Мониторинг прикладного уровня
Например, производительность доступа по URL-адресу, количество вызовов доступа, задержка доступа и мониторинг производительности предоставления услуг, частота ошибок службы и SQL также должны отслеживаться, чтобы увидеть, есть ли какой-либо медленный SQL. , необходимо отслеживать частоту попадания и производительность кеша монитора, время отклика и qps каждого сервиса и т. д.
мониторинг бизнеса
Например, веб-сайт электронной коммерции должен обращать внимание на статус входа пользователя, статус регистрации, статус заказа и статус платежа. Это напрямую влияет на фактические инициированные бизнес-транзакции. Этот мониторинг может быть предоставлен операционным и руководителям компании. обратить внимание на данные, которые могут напрямую повлиять на стратегию компании.
Мониторинг взаимодействия с конечным пользователем
Если пользователь обращается к нашему сервису через браузер и открывается клиент, то как пользовательский опыт на стороне пользователя, как производительность на стороне пользователя и есть ли ошибка, эту информацию также необходимо отслеживать и фиксировать. , если не Мониторинг, возможно, что пользовательский опыт очень плохой из-за некоторых ошибок или проблем с производительностью, но мы этого не воспринимаем.Это включает в себя мониторинг производительности пользовательского терминала, кода возврата и того, какие городские районы являются их Условия использования Аналогичным образом, есть также ситуация оператора, включая ситуацию с подключением пользователей телекоммуникаций и China Unicom. Нам нужно дополнительно знать, есть ли проблемы с тем, какие каналы и какие пользователи получают доступ, в том числе, что нам также необходимо знать версию браузера операционной системы, используемого клиентом.
Суммировать:
Разыгрывать столько карт - это всего лишь уловка. Реальный способ - успокоиться и посмотреть, в чем суть высокой доступности всего сервиса. По мере усложнения взаимного вызова микросервисной архитектуры ссылки будут только становиться все больше и больше Только установив четкую структуру и иерархию, мы можем прояснить гарантию высокой доступности в каждой ссылке и сохранить ее простой.
-
Высокая доступность с точки зрения средств: Основными техническими средствами являются резервное резервное копирование и аварийное переключение служб и данных.Набор служб или набор данных может проблема, вы можете переключаться с текущего сервиса на другие доступные сервисы, не влияя на доступность системы и не вызывая потери данных.
-
С точки зрения архитектуры, высокая доступность: сохраняйте архитектуру простой, большинство веб-сайтов в настоящее время используют относительно классическую многоуровневую архитектуру, уровень приложений, уровень служб и уровень данных. Уровень приложений обрабатывает некоторую бизнес-логику, уровень служб предоставляет некоторые службы, которые тесно связаны с данными и бизнесом, а уровень данных отвечает за чтение и запись данных Простая архитектура позволяет уровню приложений и уровню служб оставаться без состояния для горизонтальное расширение. Высокая доступность, по сравнению с вычислением высокой доступности, высокая доступность на уровне данных — это высокая доступность данных. По сравнению с вычислением высокой доступности, согласованность данных следует рассматривать как более сложную. В настоящее время теория CAP будет включена в Ключевая роль заключается в выборе AP или CP, что зависит от бизнес-модели.
-
С точки зрения аппаратного обеспечения, высокая доступность: Прежде всего, необходимо подтвердить, что аппаратное обеспечение всегда может выйти из строя, а сеть всегда нестабильна. Способ решения — добавить еще несколько серверов, если одного сервера недостаточно, несколько, если не хватает шкафа, и несколько, если не хватает машинного зала.
-
С точки зрения программного обеспечения, высокая доступность: разработка программного обеспечения не является строгой, а выпуск не стандартизирован, что также приводит к различной недоступности.Контролируя контроль качества процесса разработки программного обеспечения, тестирование, предварительный выпуск, выпуск в оттенках серого и другие средства также являются мерами по снижению недоступности.
-
С точки зрения управления, высокая доступность: система хорошо работает в сети, но мы не можем гарантировать, что она будет недоступна в следующую секунду Стандартизируйте услуги, сегментируйте услуги заранее и отслеживайте услуги Полезно, находите и решайте проблемы до того, как произойдет недоступность .
[Примечание: часть содержания статьи относится к «Изучение архитектуры с нуля» Ли Юньхуа и «Микросервисы» Ян Бо]