Что такое микросервисы

Микросервисы Архитектура сервер API

1. Введение в микросервисы

1. Что такое микросервисы

Внедряя микросервисы, мы должны сначала понять, что такое микросервисы.Как следует из названия, микросервисы следует понимать с двух сторон: что такое «микро» и что такое «сервис», и в узком смысле он маленький и известный». «Команда 2 пиццы» очень хорошо объясняет это (команда 2 пиццы была впервые предложена генеральным директором Amazon Безосом, что означает, что дизайн одного сервиса, все участники от проектирования, разработки, тестирования, эксплуатации и обслуживания в сумме составляют только один 2 пиццы достаточно). Так называемую службу необходимо отличать от системы, обслуживающей одну или группу относительно небольших и независимых функциональных единиц, что представляет собой наименьший функциональный набор, который могут воспринимать пользователи.

2. Происхождение Micro-Service

Микросервисы были впервые предложены Мартином Фаулером и Джеймсом Льюисом в 2014 году. Архитектурный стиль микросервисов — это способ разработки одного приложения с использованием набора небольших сервисов, каждый из которых работает в своем собственном процессе и использует легкие механизмы для связи, обычно HTTP API, эти сервисы основаны на бизнес-возможностях и могут быть развернуты независимо с помощью автоматизированных механизмов развертывания, эти сервисы реализованы с использованием разных языков программирования и различных технологий хранения данных и обеспечивают минимальное централизованное управление.

3. Зачем вам микросервисы?

В традиционной ИТ-индустрии большая часть программного обеспечения представляет собой стек различных независимых систем, проблемы которых можно охарактеризовать как плохую масштабируемость, низкую надежность и высокие затраты на обслуживание. Позже была введена служба SOA, однако, поскольку в первые дни SOA использовала режим шины, этот режим шины сильно привязан к определенному стеку технологий, например J2EE. Это затрудняет подключение устаревших систем многих предприятий, время переключения слишком велико, стоимость слишком высока, а конвергенция стабильности новой системы также требует некоторого времени. В конце концов SOA выглядела красиво, но превратилась в роскошь корпоративного уровня, отпугивающую малые и средние компании.

3.1 Проблемы, вызванные новейшей монолитной архитектурой

Монолитная архитектура хорошо работает, когда масштаб относительно небольшой, но по мере расширения масштаба системы она выявляет все больше и больше проблем, в основном в следующих моментах:

1. Возрастающая сложность

Например, в некоторых проектах сотни тысяч строк кода, различие между модулями расплывчато, логика запутана, чем больше кода, тем выше сложность и тем сложнее решать возникающие проблемы.

2. Технический долг растет

Течение кадров в компании - нормальное явление.Перед уходом из компании некоторые сотрудники пренебрегали контролем качества кода, в результате чего возникало множество подводных камней.Из-за огромного количества кода в одном проекте ямки уходили трудно обнаружить., что приносит много хлопот новым сотрудникам.Чем больше поток кадров, тем больше остается ям, что является так называемым техническим долгом.

3. Скорость развертывания постепенно замедляется

Это очень хорошее понимание строительных блоков мономера очень велико, очень большое количество кода, что привело к тому времени, что нужно для развертывания все больше и больше проектов, некоторые проекты начали идти на десять-двадцать минут, что является ужасной точкой Для начала проекта несколько раз проходило время суток, оставив время разработчикам, чтобы развить очень меньше.

4. Препятствование технологическим инновациям

Например, предыдущий проект был написан с использованием struts2.Из-за неразрывных связей между различными модулями объем кода велик, а логика недостаточно ясна.Если вы хотите использовать spring mvc для рефакторинга этого проекта сейчас, он будет будет очень сложно Стоимость будет очень большой, поэтому чаще компаниям приходится стиснуть зубы и продолжать использовать старую архитектуру распорок, которая препятствует технологическим инновациям.

5. Не может масштабироваться по требованию

Например, модуль фильма представляет собой CPU-интенсивный модуль, а модуль заказа представляет собой IO-интенсивный модуль. Если мы хотим улучшить производительность модуля заказа, таких как увеличение памяти и увеличения жесткого диска, но потому что все Модули находятся под той же архитектурой, поэтому мы должны рассмотреть факторы других модулей при расширении производительности модуля заказа, потому что мы не можем расширить производительность одного модуля за счет выполнения других модулей, поэтому мы не можем масштабироваться как нужный.

3.2 Различия между микросервисами и монолитной архитектурой

Все модули монолитной архитектуры связаны между собой, объем кода большой, обслуживание сложное, каждый модуль микросервиса эквивалентен отдельному проекту, объем кода значительно уменьшен, а проблемы решаются относительно легко.

Все модули монолитной архитектуры совместно используют базу данных, а метод хранения относительно прост, каждый модуль микросервиса может использовать разные методы хранения (например, некоторые используют redis, некоторые используют mysql и т. д.), а база данных также является один модуль, соответствующий собственной базе данных.

В монолитной архитектуре все модули разрабатываются по одной технологии, каждый модуль микросервиса может использовать разные технологии разработки, а режим разработки более гибкий.

3.3 Различия между микросервисами и SOA

Микросервисы, по сути, все еще являются архитектурами SOA. Но коннотация другая.Микросервисы не привязаны к какой-то специальной технологии.В микросервисной системе могут быть сервисы, написанные на Java, или сервисы, написанные на Python.Они объединены архитектурным стилем Restful в одну систематику. Поэтому сам микросервис не имеет ничего общего с конкретной технологической реализацией и обладает сильной масштабируемостью.

4. Природа микросервисов

Ключом к микросервисам являются не только сами микросервисы, но и система, обеспечивающая базовую архитектуру, которая позволяет независимо развертывать, запускать и обновлять микросервисы. Мало того, эта системная архитектура также позволяет использовать микросервисы и микросервисы. «слабо связаны» по структуре, но функционально представляют собой единое целое. Это так называемое «унифицированное целое» демонстрирует интерфейс в едином стиле, единое управление полномочиями, единую политику безопасности, унифицированный онлайн-процесс, унифицированный журнал и метод аудита, унифицированный метод планирования, унифицированную запись доступа и т. д. Подождите.

Цель услуги — эффективное микро-разделение приложений, гибкая разработка и развертывание.

Концепция, за которую ратуют микросервисы, должна обеспечивать взаимодействие, а не интеграцию между командами. Inter-operate — это определение границ и интерфейсов системы. Это полный стек внутри команды, позволяющий команде быть автономной. Причина в том, что, если команда сформирована таким образом, стоимость связи сохраняется в пределах система и каждая подсистема будут более внутренними.Когда они собираются вместе, взаимная зависимость и связь могут стать слабее, а стоимость связи в системе также может быть снижена.

5. Какие проекты подходят для микросервисов

Микросервисы можно разделить в соответствии с независимостью самой бизнес-функции.Если бизнес, предоставляемый системой, очень низкоуровневый, например: ядро ​​операционной системы, система хранения, сетевая система, система баз данных и т. д., такие системы все низкоуровневый, функциональный и функциональный.Между ними существуют тесные отношения сотрудничества.Если они принудительно разделены на более мелкие сервисные единицы, рабочая нагрузка интеграции резко возрастет, и это искусственное разделение не может обеспечить настоящую изоляцию бизнеса, поэтому его нельзя развертывать независимо и развернуто, работает, не подходит для микросервисов.

Можно делать микросервисы, это зависит от четырех факторов:

  • Небольшой: микросервисы маленькие, 2 пицца-команды.

  • Независимый: может быть развернут и работать независимо.

  • Легкий: используйте легкие механизмы и архитектуры связи.

  • Свободная связь: существует слабая связь между службами.

6. Оценка и дизайн микросервиса

Из-за унитарной структуры управления архитектурой микросервисов по-прежнему будет возникать проблема демаркации границ сервиса: например, у нас есть сервис для предоставления базовой пользовательской информации о пользователе, аватар пользователя и картинки должны быть отдельным подразделением для новый сервис более хороший или сервис должен быть заложен пользователем в нем? Если услуга имеет слишком грубую степень детализации, то вернуться к старому монолитному, если слишком мала, то накладные расходы на обслуживание номеров не будут игнорироваться, и сложность управления будет возрастать в геометрической прогрессии. Пока не существует стандартной услуги, которую можно назвать демаркацией границы, ее можно только корректировать в соответствии с различными бизнес-системами.

Общий принцип расщепления состоит в том, что, когда часть бизнеса не зависит или редко зависит от других услуг, имеет независимую бизнес-семантику и предоставляет данные для более чем 2 других услуг или клиентов, то он должен быть разделен на независимый сервисный модуль ,

6.1 Принципы проектирования микросервисов

  • Принцип единой ответственности

Это означает, что каждый микросервис должен реализовать только свою бизнес-логику, например модуль управления заказами, он должен обрабатывать только бизнес-логику заказа, а остальные не нужно учитывать.

  • Принцип сервисной автономии

Это означает, что каждый микросервис независим от разработки, тестирования, эксплуатации и сопровождения, включая базу данных хранилища, и имеет свой полный набор процессов, мы можем рассматривать его как проект. Нет необходимости зависеть от других модулей.

  • Легкие принципы связи

Во-первых, язык общения очень легкий. Во-вторых, метод общения должен быть кросс-языковым и кросс-платформенным. Причина кроссплатформенности и кросс-языка в том, чтобы сделать каждый микросервис достаточно независимым, чтобы быть свободным от ограничений. технологии.

  • Явный принцип интерфейса

Так как между микросервисами может быть вызывающая связь, во избежание корректировок других микросервисов из-за изменения интерфейса микросервиса в будущем следует учитывать все ситуации в начале проектирования, чтобы сделать интерфейс максимально общим ., более гибким, чтобы избежать внесения изменений другими модулями, насколько это возможно.

7. Преимущества и недостатки микросервиса

7.1 Особенности

  1. Каждый микросервис может работать независимо в своем собственном процессе;
  2. Ряд независимо работающих микросервисов работают вместе, чтобы построить всю систему;
  3. Каждый сервис разрабатывается для самостоятельного бизнеса, а микросервис, как правило, выполняет определенную функцию, например: управление заказами, управление пользователями и т. д.;
  4. Микросервисы взаимодействуют с помощью некоторых упрощенных механизмов связи, таких как вызовы через REST API или RPC.

7.2 Особенности

  • Простота разработки и обслуживания

Поскольку один модуль микросервиса эквивалентен проекту, нам нужно заботиться только о логике этого модуля, чтобы разработать этот модуль, и объем кода и сложность логики будут уменьшены, что упростит разработку и поддержку.

  • начать быстрее

Это относительно одного микросервиса, по сравнению с запуском всего проекта с одной архитектурой скорость запуска модуля, очевидно, намного выше.

  • Локальные модификации легко развернуть

При разработке была обнаружена проблема.Если это монолитная архитектура, то нам нужно перевыпустить и запустить весь проект, что очень трудоемко, но микросервисы разные.В каком модуле есть ошибка, нам нужно только решить ошибка этого модуля.Теперь, после устранения ошибки, нам нужно только перезапустить службу этого модуля.Развертывание относительно простое, и нет необходимости перезапускать весь проект, что значительно экономит время.

  • Неограниченный стек технологий

Например, сервисы заказов и микросервисы микрофильмов изначально написаны на java, и теперь мы хотим изменить технологию микросервисов фильмов nodeJs, что вполне возможно, и потому что фильм касался только только логики, и, следовательно, стоимости технологии замены было бы намного меньше.

  • Масштаб по запросу

Выше мы упоминали, что когда одиночная архитектура хочет увеличить производительность определенного модуля, она должна учитывать, не повлияет ли это на производительность других модулей.Для наших микросервисов это вообще не проблема. movie, чтобы каким-либо образом улучшить производительность.Рассмотрите случай с другими модулями.

7.3 недостатки

  • Требования к эксплуатации и техническому обслуживанию высоки

Для монолитной архитектуры нам нужно поддерживать только этот один проект, но для микросервисной архитектуры, поскольку проект состоит из нескольких микросервисов, проблемы с каждым модулем приведут к неправильной работе всего проекта. модуль вызвал проблему, потому что мы не можем отследить его шаг за шагом с помощью отладки, что предъявляет высокие требования к эксплуатационному и обслуживающему персоналу.

  • Распределенная сложность

Для монолитной архитектуры мы не можем использовать распределённую, но для микросервисной архитектуры распределённая технология почти неизбежна.Из-за сложности самого дистрибутива усложняется и микросервисная архитектура.

  • Стоимость настройки интерфейса высока

Например, пользовательский микросервис вызывается микросервисом заказа и микросервисом фильма.Раз интерфейс пользовательского микросервиса сильно меняется, все микросервисы, которые от него зависят, должны быть соответствующим образом скорректированы, потому что микросервисов может быть много, тогда стоимость настройка интерфейса значительно увеличится.

  • повторяющаяся работа

Для монолитной архитектуры, если определенный бизнес используется несколькими модулями, мы можем абстрагировать его в класс инструмента и вызвать его напрямую всеми модулями, но микросервис не может этого сделать, потому что класс инструмента этого микросервиса не может быть вызван. непосредственно другими микросервисами, поэтому нам приходится создавать такой класс инструментов для каждого микросервиса, что приводит к дублированию кода.

8. Среда разработки микросервисов

В настоящее время наиболее часто используемыми платформами разработки для микросервисов являются следующие четыре:

  1. Весеннее облако:Projects.spring.IO/spring - уродливые...

  2. Дуббо: http://dubbo.io

  3. Мастер сброса:www.dropwizard.io(Фокус на разработке отдельных микросервисов)

  4. Консул и т. Д. (Модули для микросервисов)

9. Разница между облаком Sprint и загрузкой Sprint

Spring Boot:

Он предназначен для упрощения создания приложений и сервисов Spring производственного уровня, упрощения файлов конфигурации, использования встроенных веб-серверов и содержит множество готовых функций микросервиса, которые можно развернуть вместе с Spring Cloud.

Весеннее облако:

Набор инструментов для микросервисов предоставляет разработчикам такие инструменты разработки, как управление конфигурацией, обнаружение сервисов, автоматические выключатели, интеллектуальная маршрутизация, микроагенты и шины управления в распределенных системах.

2. Пророк микросервисной практики

1. Как клиенты получают доступ к этим услугам? (API-шлюз)

В традиционном методе разработки все сервисы локальны, и пользовательский интерфейс может вызываться напрямую, теперь же он разделен на независимые сервисы по функциям и запускается в независимых Java-процессах, которые обычно находятся на независимых виртуальных машинах. Как клиентский пользовательский интерфейс получает доступ к своему? В фоновом режиме работает N служб, и служба приема и размещения должна помнить об управлении службами N. Если служба отключается/обновляется/обновляется, стойку регистрации необходимо перераспределить. Это, очевидно, не соответствует нашей концепции разделения, особенно когда стойка регистрации представляет собой мобильное приложение. Часто темпы изменений в бизнесе выше. Кроме того, вызов N небольших сервисов также приводит к значительным сетевым издержкам. Внутри системы также есть общие микросервисы, которые обычно не имеют состояния.Лучше всего иметь единое место для информации для входа пользователя и управления разрешениями (OAuth).

Таким образом, обычно существует прокси-сервер или API-шлюз между службами N в фоновом режиме и пользовательским интерфейсом. Его функции включают в себя:

  • Предоставить единый вход в службу для прозрачности микросервисов

  • Агрегируйте фоновые сервисы для экономии трафика и повышения производительности

  • Обеспечить функции управления API, такие как безопасность, фильтрация и управление потоком

Я понимаю, что этот API-шлюз может иметь множество обобщенных методов реализации, которые могут быть жесткой коробкой, простой инфраструктурой MVC или даже сервером Node.js. Их наиболее важная роль заключается в обеспечении агрегации фоновой службы для службы приема и размещения (обычно мобильных приложений), обеспечении унифицированного экспорта службы для уменьшения связи между ними, но шлюз API также может стать единой точкой или узким местом в производительности.

2. Как службы взаимодействуют? (сервисный звонок)

Поскольку все микросервисы представляют собой независимые процессы Java, работающие на независимых виртуальных машинах, связь между службами осуществляется по принципу IPC (межпроцессное взаимодействие), и существует множество зрелых решений. В основном есть два наиболее распространенных метода. Все эти методы можно разложить в книгу, и все, как правило, знакомы с деталями, поэтому я не буду подробно о них рассказывать.

  • ОТДЫХ (JAX-RS, Spring Boot)

  • RPC (бережливость, даббо)

  • Асинхронные вызовы сообщений (Kafka, Notify)

в целомСинхронный вызовОн относительно прост и имеет строгую согласованность, но подвержен проблемам с вызовами, а производительность будет низкой, особенно при наличии большого количества уровней вызова. Сравнение RESTful и RPC тоже интересная тема. Как правило, REST основан на HTTP, который проще в реализации и более приемлем.Технология реализации на стороне сервера также более гибкая.Поддерживаются все языки.В то же время он может быть кросс-клиентским.Есть нет особых требований к клиенту.Его можно назвать,поэтому он относительно широко используется. У RPC также есть свои преимущества.Протокол передачи более эффективен, а безопасность более управляема.Особенно внутри компании, если есть единая спецификация разработки и единая структура обслуживания, его преимущество в эффективности разработки более очевидно. Это зависит от реальных условий их собственного накопления технологий и их собственного выбора.

иАсинхронное сообщениеЭтот метод широко используется в распределенных системах, он может не только уменьшить связь между вызывающими службами, но и служить буфером между вызовами, гарантируя, что невыполненные сообщения не перегрузят вызываемого, и в то же время он может обеспечить Услуги вызывающего абонента Опыт, продолжайте делать то, что вам нужно, и не замедляйтесь из-за фоновой производительности. Однако расплатой за это является ослабление непротиворечивости, и необходимо принять конечную согласованность данных, а фоновой службе, как правило, необходимо достичь идемпотентности, поскольку отправка сообщения обычно повторяется из соображений производительности (чтобы убедиться, что сообщение получено и Получение его только один раз является большим тестом на производительность); в конце концов, необходимо ввести независимого брокера.Если нет технического накопления внутри компании, это также является большой проблемой для распределенного управления брокером .

3. Как найти столько сервисов? (обнаружение службы)

В микросервисной архитектуре обычно каждый сервис имеет несколько копий для балансировки нагрузки. Служба может отключиться в любое время, а новые узлы службы могут быть добавлены в ответ на временное ограничение доступа. Как сервисы воспринимают друг друга? Как управляются услуги? Это проблема с обнаружением службы. Как правило, существует два типа подходов, каждый из которых имеет свои преимущества и недостатки. По сути, распределенное управление информацией о регистрации службы осуществляется с помощью zookeeper и других подобных технологий. Когда услуга подключается к сети, поставщик услуг регистрирует информацию о своей службе в ZK (или аналогичной структуре), поддерживает длинную ссылку через пульс и обновляет информацию о ссылке в режиме реального времени. Вызывающие службу могут найти службу с помощью адресации ZK в соответствии с настраиваемым алгоритмом, а также могут локально кэшировать информацию о службе для повышения производительности. Когда служба отключается, ZK отправит уведомление клиенту службы.

Клиенты делают: Преимущество в том, что архитектура проста, расширение гибкое и зависит только от регистратора сервиса. Недостатком является то, что клиенту необходимо поддерживать адреса всех вызывающих служб, что технически сложно.Как правило, крупные компании имеют развитую внутреннюю поддержку фреймворка, например Dubbo.

серверная часть: Это преимущество в том, что он прост, и все услуги прозрачны для переднего абонента. Как правило, небольшие компании разпускают больше приложений на облачных службах.

4. Что делать, если услуга приостановлена?

Распределенная самая большая особенность - сеть ненадежна. Сплит может уменьшить этот риск с помощью микросервисов, но если нет специальной защиты, результат определенно будет кошмарным. Мы только что столкнулись с линией разлома - это очень скромная функция подсчета SQL, когда трафик увеличивается, что приводит к высокой нагрузке на базу данных Biao, влияет на производительность хост-приложения, что влияет на все приложения, вызывающие приложения на стойке регистрации. Поэтому, когда наша система состоит из ряда цепочек сервисных вызовов, мы должны убедиться, что ни одна часть проблемы не повлияет на общую связь. Есть много подходящих средств:

  • механизм повторной попытки

  • Ограничение

  • автоматический выключатель

  • балансировки нагрузки

  • Даунгрейд (локальный кеш) Эти способы в основном очень понятные общие, подробно не описаны. Например, Hystrix от Netflix:Github.com/netflix/h и выше ...

5. Вопросы, которые следует учитывать при использовании микросервисов

Существует очень хороший вопрос, что сводная диаграмма, которую нужно считать архитектурой микросерверов, в том числе

  • API Gateway

  • Сервисный звонок

  • обнаружение службы

  • Отказоустойчивость сервиса

  • Развертывание службы

  • вызов данных

3. Важные компоненты микросервисов

1. Основные способности Micro Service

2. Реестр услуг

Между службами необходимо создать механизм обнаружения служб, чтобы помочь службам воспринимать существование друг друга. Когда служба запустится, она зарегистрирует свою собственную информацию о службе в реестре и подпишется на службы, которые ей необходимо использовать.

Реестр служб является ядром обнаружения служб. Он содержит сетевые адреса (IP-адрес и порт) каждого доступного экземпляра службы. Реестр службы должен иметь высокую доступность и обновляться в режиме реального времени. Упомянутая выше Netflix Eureka — это сервисный реестр. Он предоставляет REST API для регистрации службы и запроса информации о службе. Службы регистрируют свой собственный IP-адрес и порт с помощью запроса POST. Отправляйте запрос PUT каждые 30 секунд, чтобы обновить регистрационную информацию. Выйдите из службы с помощью запроса DELETE. Клиент получает доступную информацию об экземпляре службы через запрос GET. Высокая доступность Netflix (Netflix достигает высокой доступности) достигается за счет запуска нескольких экземпляров на Amazon EC2, каждый сервис Eureka имеет эластичный IP-адрес. При запуске службы Eureka происходит динамическое выделение DNS-серверов. Клиент Eureka получает сетевой адрес Eureka (IP-адрес и порт), запрашивая DNS. Как правило, он возвращает адрес сервера Eureka в той же зоне доступности, что и клиент. Другие, которые могут действовать как сервисные реестры:

  • etcd — Высокодоступный, распределенный, строго согласованный, ключ-значение, Kubernetes и Cloud Foundry — все используют etcd.

  • consul — Инструмент для обнаружения и настройки. Он предоставляет API-интерфейсы, которые позволяют клиентам регистрироваться и обнаруживать службы. Consul может выполнять проверки работоспособности служб, чтобы определить их доступность.

  • zookeeper — широко используемый в распределенных приложениях высокопроизводительный сервис координации. Apache Zookeeper начинался как подпроект Hadoop, но теперь является проектом верхнего уровня.

2.1 Регистрация и обнаружение службы зоопарка

Simply put, zookeeper can act as a service registry (Service Registry), allow multiple service providers to form a cluster, so that service consumers get access to a specific service address (ip + port) by a service registry to access a specific service provided От. Как показано ниже:

В частности, zookeeper — это распределенная файловая система.Каждый раз, когда поставщик услуг развертывается, он должен зарегистрировать свою собственную службу по определенному пути zookeeper: /{service}/{version}/{ip:port}, например, если наш HelloWorldService развернут на двух машинах, на zookeeper будут созданы два каталога: /HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888.

Zookeeper предоставляет функцию "обнаружения сердцебиения", которая будет периодически отправлять запрос каждому поставщику услуг (фактически устанавливается длинное сокетное соединение), если нет ответа в течение длительного времени, сервисный центр считает, что поставщик услуг "повесил трубку" и удалите его. Например, если машина 100.19.20.02 не работает, путь на zookeeper будет только /HelloWorldService/1.0.0/100.19.20.01:16888.

Потребитель сервиса будет прослушивать соответствующий путь (/HelloWorldService/1.0.0).Как только данные на пути изменятся (увеличится или уменьшится), zookeeper уведомит потребителя сервиса об изменении списка адресов поставщика услуг, чтобы обновить его.

Что еще более важно, присущие zookeeper отказоустойчивость и устойчивость к сбоям (например, выбор лидера) могут обеспечить высокую доступность реестра служб.

3. Балансировка нагрузки

Средство обеспечения высокой доступности служб. Чтобы обеспечить высокую доступность, каждая микрослужба должна развертывать несколько экземпляров службы для предоставления служб. В это время клиент выполняет балансировку нагрузки службы.

3.1 Общие стратегии балансировки нагрузки

3.1.1 Случайный выбор

Произвольно распределяйте запросы из сети на несколько серверов в доме.

3.1.2 Опрос

Каждый запрос из сети, в свою очередь, присваивается внутреннему серверу, от 1 до N, а затем начинается заново. Этот алгоритм балансировки нагрузки подходит для ситуации, когда все серверы в группе серверов имеют одинаковую конфигурацию, а средние запросы на обслуживание относительно сбалансированы.

3.1.3 Взвешенная круговая система

В соответствии с различными возможностями обработки серверов каждому серверу присваиваются разные веса, чтобы он мог принимать запросы на обслуживание с соответствующими весами. Например, вес сервера A рассчитан равным 1, вес B равен 3, а вес C равен 6, тогда серверы A, B и C получат 10%, 30% и 60% обслуживания. запросов соответственно. Этот алгоритм балансировки может обеспечить более эффективное использование высокопроизводительных серверов и избежать перегрузки низкопроизводительных серверов.

3.1.4 IP Hash

Этот метод генерирует хеш-значение IP-адреса источника запроса и использует это хэш-значение для поиска правильного реального сервера. Это означает, что соответствующий сервер для одного и того же хоста всегда один и тот же. Таким образом, вам не нужно сохранять исходный IP-адрес. Однако следует отметить, что такой подход может привести к несбалансированной нагрузке на сервер.

3.1.5 Минимальное количество соединений

Время, затрачиваемое на сервер для каждого запроса от клиента, может сильно различаться.По мере увеличения рабочего времени, если используется простой циклический алгоритм или алгоритм случайной балансировки, процесс подключения на каждом сервере может генерировать огромное количество времени. , и не обеспечивает истинной балансировки нагрузки. Алгоритм балансировки наименьшего количества соединений имеет запись данных для каждого сервера, который необходимо загрузить внутренне, записывая количество соединений, которые в настоящее время обрабатываются сервером. сервер с наименьшим количеством подключений, сервер делает баланс более соответствующим реальной ситуации и более сбалансированной нагрузкой. Этот алгоритм балансировки подходит для долговременной обработки запросов сервисов, таких как FTP.

4. Отказоустойчивость

Отказоустойчивость, понимание этого слова, прямо означает, что к ошибкам можно относиться терпимо, нельзя допускать повторного разрастания, и влияние этой ошибки может быть в фиксированных границах.Пусть эта муравьиная колония не разрастается. Тогда наши общие понижения, ограничение тока, автоматические выключатели, повторная попытка тайм-аута и т. д. являются отказоустойчивыми методами.

При вызове сервисного кластера, если микросимально называемое ненормально, такое как время ожидания, ненормальность соединения, сетевая аномалия и т. Д. Служба неисправна в соответствии с неисправной стратегией. В настоящее время поддерживаемые стратегии допусков отказов обслуживания включают неудачную быструю и отказоуправление. Если это не удается несколько раз подряд, он будет прямо взорван и больше не звонит. Это позволяет избежать исключения службы от перетаскивания всех услуг, которые зависят от него.

4.1 Стратегия отказоустойчивости

4.1.1 Rapid-Fail

Сервис - это немедленно запустить ошибку подставки. Обычно используется в недемпотентной работе записи

4.1.2 Отказоустойчивость

Служба инициирует вызов, а при возникновении сбоя повторяет попытку других серверов. Обычно используется для операций чтения, но повторные попытки приводят к более длительным задержкам. Количество повторных попыток обычно может быть установлено

Потерпеть неудачу в безопасности 4.1.3

Отказоустойчивость, когда в сервисном вызове возникает исключение, оно напрямую игнорируется. Обычно используется для таких операций, как запись в журнал.

4.1.4 Автоматическое восстановление после сбоя

Когда в вызове службы возникает исключение, неудачный запрос записывается и регулярно передается повторно. Обычно используется для уведомлений о сообщениях.

4.1.5 forking Cluster

Вызывайте несколько серверов параллельно и возвращайтесь, пока один из них не увенчается успехом. Обычно используется для операций чтения в реальном времени. Максимальное количество параллелей может быть установлено forks=n.

4.1.6 Широковещательный вызов

Широковещательная рассылка вызывает всех провайдеров, одного за другим, и терпит неудачу, если какой-либо из них терпит неудачу. Обычно используется для уведомления всех провайдеров о необходимости обновления информации о локальных ресурсах, такой как кэши или журналы.

5. Фьюзинг

Можно сказать, что технология прерывателя цепи представляет собой "интеллектуальную отказоустойчивость". Когда вызов соответствует количеству сбоев, интенсивность отказов вызовет размыкание прерывателя цепи, и программа автоматически отключит текущий вызов RPC, чтобы предотвратить дальнейшие ошибки от расширения. При реализации предохранителя в основном рассматриваются три режима: закрытый, открытый и полуоткрытый. Переход каждого состояния показан на рисунке ниже.

При работе с исключениями мы должны выбрать метод обработки в соответствии с конкретной деловой ситуацией.Например, когда мы вызываем товарный интерфейс, другая сторона только временно понижает его, тогда как вызов шлюза нам нужно переключиться на альтернативный сервис выполнять или получать вспомогательные данные, давая удобные подсказки. Также необходимо различать типы исключений, например сбой зависимой службы, на устранение которого может уйти много времени. Это также может быть тайм-аут из-за временной высокой нагрузки на сервер. Как автоматический выключатель, он должен быть в состоянии идентифицировать этот тип исключения, чтобы скорректировать стратегию автоматического выключателя в соответствии с конкретным типом ошибки. Добавлены ручные настройки.В случае неопределенного времени восстановления сервиса администраторы могут вручную переключать состояние выключателя. Наконец, автоматические выключатели используются для вызова удаленных сервисных программ или общих ресурсов, которые могут выйти из строя. Если локальные частные ресурсы кэшируются локально, использование автоматических выключателей увеличит дополнительные накладные расходы системы. Также обратите внимание, что автоматические выключатели нельзя использовать в качестве замены обработки исключений для бизнес-логики в вашем приложении.

Некоторые исключения являются стойкими, возникают внезапно, непредсказуемы, их трудно восстановить, а также они могут приводить к каскадным сбоям (например, предположим, что сервисный кластер находится под очень высокой нагрузкой, и если в это время часть кластера умрет, он все равно приходится большая часть ресурсов, может пострадать весь кластер). Если мы продолжим повторять попытки на этом этапе, большинство результатов не удастся. Поэтому в это время наше приложение должно немедленно войти в состояние сбоя (fast-fail) и принять соответствующие меры для восстановления.

Мы можем реализовать CircuitBreaker с помощью конечного автомата, который имеет следующие три состояния:

  • Замкнут ( Closed ): автоматический выключатель по умолчанию замкнут, что позволяет выполнять операции в это время. CircuitBreaker внутренне записывает количество недавних сбоев. Если соответствующая операция завершается сбоем, количество раз будет продолжаться. Если количество отказов (или частота отказов) достигает порогового значения в течение определенного периода времени, CircuitBreaker перейдет в открытое состояние. В открытом состоянии Circuit Breaker активирует таймер тайм-аута, цель которого — дать кластеру необходимое время для восстановления после сбоя. Когда таймер истечет, CircuitBreaker перейдет в полуоткрытое состояние.

  • Open (Открыть): В этом состоянии соответствующая операция будет выполнена немедленно и сразу же выдаст ошибку.

  • Полуботок (половина открытой): в этом состоянии автоматический выключатель позволяет определенному количеству выполненных операций. Если все операции прошли успешно, присматривается замыкание, неисправность была восстановлена, он переключится в состояние выключения и сбрасывает количество сбоев. Если какая-либо операция не удается, автоматический выключатель подумает, что проблема сохраняется, она будет преобразована в состояние в состоянии и запускает таймер (дайте ему некоторое время для восстановления от ошибки системы) снова

  1. дросселирование и даунгрейды Обеспечение стабильности основных служб. Чтобы обеспечить стабильность работы основных сервисов, поскольку количество посещений продолжает увеличиваться, необходимо установить предельный порог количества сервисов, которые может обработать система, а запросы, превышающие этот порог, напрямую отклоняются. В то же время, чтобы обеспечить доступность основных служб, некоторые неосновные службы можно понизить, ограничив максимальный доступ служб до ограничения текущего, и вручную понизить отдельные микрослужбы через консоль управления.

7. SLA

SLA: сокращение от Service-LevelAgreement, что означает соглашение об уровне обслуживания. Контракт между поставщиком услуг Интернета и клиентом, определяющий такие условия, как тип услуги, качество услуги и платеж клиента. Типичный SLA включает следующие пункты:

  • минимальная пропускная способность, выделенная клиенту;

  • ограничение пропускной способности клиента;

  • Количество клиентов, которые также могут обслуживаться одновременно;

  • Механизмы уведомления заблаговременно об изменениях в сети, которые могут повлиять на поведение пользователя;

  • Доступность коммутируемого доступа;

  • использовать статистику;

  • Минимальная производительность использования сети, поддерживаемая поставщиком услуг, например, 99,9% активного рабочего времени или максимум 1 минута простоя в день;

  • Приоритет трафика различных клиентов;

  • Техническая поддержка и услуги клиента;

  • Штрафные санкции, указанные для поставщиков услуг, не выполняющих требования SLA.

8. API Gateway

Здесь это означает шлюз API шлюза, а это означает, что все они сталкиваются с вызовами API единого доступа к уровню шлюза API, шлюзу единого доступа и выходному слою. Основные функции шлюза: унифицированный доступ, безопасность, адаптация протокола, управление потоком, поддержка длины канала, отказоустойчивость. Благодаря тому, что шлюзы After предоставляют различные команды службы API, они могут сосредоточиться на обработке своей бизнес-логики, а шлюзы API могут больше сосредоточиться на безопасности, трафике, маршрутизации и других вопросах.

9. Многоуровневый кеш

Самый простой кеш — это один раз запросить базу данных, а затем записать данные в кеш, такой как Redis, и установить время истечения срока действия. Из-за истечения срока нам нужно обратить внимание на скорость проникновения кеша.Формула расчета этой скорости проникновения, такая как метод запроса queryOrder (вызовы 1000/1s), имеет вложенный метод запроса БД queryProductFromDb (вызовы 300/s ), то скорость проникновения redis 300/1000.При таком способе использования кеша необходимо обращать внимание на скорость проникновения.Если скорость проникновения большая, эффект кеша нехороший. Еще один способ использования кеша — сохранить кеш, то есть без установки срока действия, это столкнется с проблемой обновления данных. Как правило, есть два способа. Один – использование меток времени. По умолчанию запрос основан на Redis. Каждый раз, когда вы устанавливаете данные, вы ставите метку времени, и каждый раз, когда вы читаете данные, используете текущее системное время и метку времени, которую вы ставил последний раз.Для сравнения, например, если превышает 5 минут, то снова проверяем базу. Это гарантирует, что в Redis всегда будут данные, что обычно является отказоустойчивым методом для БД. Другой способ — фактически использовать Redis в качестве БД. То есть, как показано на картинке, данные проталкиваются в кеш через гетерогенную систему данных через бинлог базы данных подписки, а кеш устанавливается многоуровневым. В качестве кеша первого уровня в приложении можно использовать jvmcache, как правило, он небольшого размера и имеет высокую частоту обращения, что больше подходит для данного метода jvmcache, в качестве удаленного кеша второго уровня используется набор redis , а самый внешний Redis третьего уровня используется в качестве постоянного кеша.

10. Тайм-ауты и повторы

Механизм тайм-аута и повторных попыток также является методом отказоустойчивости.Везде, где происходят вызовы RPC, такие как чтение redis, db, mq и т. д., из-за сбоя сети или зависимого сбоя службы, если результат не может быть возвращен в течение длительного времени, это вызовет увеличение потока, увеличит нагрузку на процессор и даже вызовет лавину. Поэтому установите тайм-аут для каждого вызова RPC. Для случая сильной зависимости от ресурсов вызова RPC также есть механизм повторных попыток, но количество повторных попыток рекомендуется 1-2 раза, кроме того, если есть повторные попытки, время ожидания должно быть соответственно уменьшено, например , если есть 1 повторная попытка, то всего происходит 2 вызова. Если тайм-аут настроен на 2 секунды, клиент будет ждать 4 секунды перед возвратом. Поэтому в методе повтор + тайм-аут время тайм-аута должно быть уменьшено. Здесь давайте снова поговорим о времени, затрачиваемом на вызов PRC.Время, затраченное на обычную статистику вызовов, в основном включает: ① время выполнения RPC-инфраструктуры вызывающей стороны + ② время отправки по сети + ③ время выполнения сервера -Сторона RPC рамки + ④ служба Время бизнес-код терминала. У звонилки и сервера свой мониторинг производительности.Например tp99 звонилки 500мс, а tp99 сервера 100мс.Нашел коллегу в сетевой группе,подтвердить что проблем с сетью нет. Итак, где же потраченное время, две причины, вызывающий клиент, а другая — повторная передача TCP в сети. Так что обратите внимание на эти два момента.

11. Изоляция пула потоков

В случае по этой ссылке, когда сервлет3 асинхронно, есть упомянутая изоляция резьбы. Преимущество между изоляцией резьбы состоит в том, чтобы предотвратить каскадную или даже лавину. Когда шлюз вызывает n множество интерфейсных сервисов, мы должны поток каждого интерфейса. Например, у нас есть заказы, товары, пользователи. Затем порядок порядка не может повлиять на обработку запроса товаров и пользователей. Если вы не выполняете отказ от потоков, когда сбой сети обслуживания заказа вызывает сбой сети, резервные планы резьбы в конечном итоге приводят к всей нагрузке на обслуживание CPU. Это услуга, которую мы говорим, что она недоступна, и сколько машин будет заполнена запросом на данный момент. Затем существует изоляция потоков, которая делает наши ворота, чтобы гарантировать, что местные проблемы не повлияют на общую ситуацию.

12. Ограничитель потока и демотеции

В отрасли уже существуют зрелые методы понижения рейтинга и ограничения тока, такие как механизм FAILBACK, токен-ведро с методом ограничения тока, дырявое ведро, семафор и т. д. Давайте поговорим о нашем опыте здесь.Даунгрейд обычно реализуется переключателем даунгрейда единого центра конфигурации.Тогда когда есть много интерфейсов от одного и того же провайдера,система провайдера или сеть машинного зала,где находится машина возникла проблема У нас должен быть унифицированный переключатель перехода на более раннюю версию, или мы должны понижать версию одного интерфейса за другим. То есть иметь большой нож для вида бизнеса. Кроме того, не забудьте принудительно понизить версию. Что такое насильственное понижение? Например, если функция форума будет понижена, пользователь отобразит большую доску. Нам нужно кэшировать некоторые данные, то есть иметь резервные данные. Ограничение тока обычно делится на распределенное ограничение тока и автономное ограничение тока.Если реализовано распределенное ограничение тока, требуется общедоступная серверная служба хранения, такая как Redis, и lua используется для чтения информации о конфигурации Redis на большом узле nginx. . Наше текущее регулирование — это регулирование только для одной машины, и оно не реализует распределенное регулирование.

13. Мониторинг шлюза и статистика

Шлюз API — это последовательный вызов, поэтому исключение, возникающее на каждом шаге, должно фиксироваться и храниться в таком месте, как elasticserach, удобном для последующего анализа исключений вызова. Ввиду того, что докер-приложения компании все распределены равномерно, и до выделения на докере уже 3 агента, увеличение больше не допускается. Мы сами внедрили агентскую программу для сбора выходных данных журнала на сервере, отправки их в кластер kafka, использования в elasticserach и запроса через Интернет. Выполняемая в настоящее время функция отслеживания относительно проста, и эту часть необходимо доработать.

Категории