Эволюция от автономного сервиса к распределенной архитектуре, без паники на собеседованиях!

Java
Эволюция от автономного сервиса к распределенной архитектуре, без паники на собеседованиях!

Из-за эпидемии мне здесь поручено не так много задач, поэтому у меня будет немного свободного времени.Обычно в это время я занимаюсь своими делами, такими как просмотр исходного кода, листание блога csdn, а затем ведение блога, Как раз когда я был зависим от исходного кода и не мог выбраться, директор внезапно подошел ко мне. Он должен был знать, что я был не очень занят в последнее время, и он тихо сказал мне: Недавно , задач у всех не так уж много, а свободного времени относительно немного, можете ли вы поделиться здесь техническими вопросами? Во-первых, вы можете связаться с чувствами между коллегами, а во-вторых, вы можете улучшить атмосферу обучения между коллегами. Что вы думаете ?

Когда я услышал это, я понял, что, возможно, я не смогу заниматься своими делами, ведь обмен технологиями также может улучшить отношения с моими коллегами, поэтому я согласился, но я волновался, чем я должен делиться? Если вы говорите о java-направлении, кроме java-коллег, другие коллеги прозвучат очень сложно, но когда дело доходит до других аспектов, я не знаю, что сказать. . . . . . . .

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

Монолитный сервис

Помню, когда практиковался, пользовался одним сервисом, на тот момент архитектура была очень простой, и не было разделения фронтенда и бэкенда, Jsp+java напрямую реализовывал набор проектов, весь процесс был довольно простой, и даже nginx не использовался. , давайте посмотрим, какой была архитектура в то время.

Представьте nginx

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

Это схема архитектуры после внедрения nginx.Поработав так некоторое время, вдруг однажды ко мне подошел руководитель и сказал: Есть ли проблема с кодом, который вы написали, почему обычный запрос занимает много времени ? Основные операции застряли насмерть, дайте вам неделю и быстро решите это для меня!

Ввести мономер redis

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

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

Ввести разделение чтения и записи mysql

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

Представляем серверные кластеры

Это окончательная архитектура нашего единого модуля.После завершения преобразования производительность действительно значительно улучшилась, потому что после кластеризации сервиса много запросов разбросаны.Например, максимальный параллелизм, который может поддерживать tomcat, составляет 200, а теперь три сервиса.Он может поддерживать параллелизм 600, а производительность улучшена в 3 раза.Я не знаю, сколько серверов будет расширено в итоге, потому что это делается эксплуатацией и обслуживанием. закончен, и он, наконец, может соответствовать требованиям лидера.Обновление набора, я не знаю, сколько ночей я не спал, и когда я увидел несколько волос, падающих рядом с компьютером, я удовлетворенно кивнул.
Следующие два месяца мы продолжали делать итеративные обновления, и версия запускалась почти каждую неделю.Через два месяца версия окончательно стабилизировалась, а обновлений было не так много, так что я пришел к простою программистов.Время, мои коллеги ходят на работу каждый день, занимаясь своими делами, некоторые учатся, некоторые делают покупки на Таобао, некоторые играют в игры, и даже более преувеличенно, есть коллега, которому нечего делать, чтобы дразнить Мисс Продукт, держать траву, это Хочу копать себе могилу?

Около недели мы простаивали, говорил наш технический директор, а сегодня в 3 часа дня все back-end разработчики собрались в конференц-зале, и когда я услышал новость, я понял, что есть над чем поработать, это новый проект?

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

Распределенная архитектура

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

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

Коллега А: Распределенная система — это программная система, построенная в сети. Именно благодаря характеристикам программного обеспечения распределенные системы обладают высокой связностью и прозрачностью. Следовательно, разница между сетью и распределенной системой больше в программном обеспечении высокого уровня (особенно в операционной системе), чем в аппаратном обеспечении.

Технический директор: Ну да, но это объяснение более официальное, есть более понятное объяснение?

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

Технический директор: О, да, этот коллега может добавить куриные голени на ночь, может кто-нибудь привести пример?

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

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

я: Я имею дело со всеми видами неудовлетворенности, поэтому я преподал техническому директору «урок», пожалуйста, посмотрите на картинку:

Зачем использовать распределенную архитектуру

Технический директор: Да, рисунок хороший, но знаете, почему мы сделали рефакторинг монолитного сервиса для распространения? Ответ - куриные бедра.

Коллега С:

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

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

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

Коллега Д:

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

Распределенные базовые компоненты

Технический директор: Раз все так хорошо знакомы с распределёнными, то больше говорить не буду. Давайте поговорим непосредственно о выборе распределённых компонентов. Вы можете выдвигать любые мнения. Кто придёт первым? Что такое распределённые компоненты? Пожалуйста, начните свое шоу.

Коллега Э: Тогда добро пожаловать. Поскольку мы все знакомы с springcloud, теперь он стал более популярным, поэтому позвольте мне представить основные компоненты облака.

  • Spring Cloud Config: набор инструментов для управления конфигурацией, который позволяет размещать конфигурацию на удаленном сервере и централизованно управлять конфигурацией кластера.В настоящее время он поддерживает локальное хранилище, Git и Subversion.
  • Spring Cloud Bus: Событие, шина сообщений для распространения изменений состояния в кластере (например, событий изменения конфигурации), могут быть объединены с Spring Cloud Config для горячего развертывания.
  • Eureka: Обнаружение облачных служб, служба на основе REST для поиска служб для обнаружения облачных служб среднего уровня и аварийного переключения.
  • Hystrix: Circuit breaker, отказоустойчивый инструмент управления, предназначенный для управления узлами служб и сторонних библиотек через механизм прерывателя цепи, тем самым обеспечивая более высокую отказоустойчивость при задержках и сбоях.
  • Zuul: Zuul — это платформа для обеспечения динамической маршрутизации, мониторинга, эластичности, безопасности и других пограничных сервисов на облачных платформах. Zuul эквивалентен входной двери для всех запросов к устройству и серверной части веб-сайта потокового приложения Netflix.
  • Archaius: API управления конфигурацией, включая серию API управления конфигурацией, предоставляющих такие функции, как динамические типизированные свойства, потокобезопасные операции настройки, структура опроса и механизм обратного вызова.
  • Consul: Инкапсулирует операции консула. Консул - это инструмент обнаружения и конфигурации услуг, который можно легко интегрировать с контейнерами Docker.
  • Spring Cloud для Cloud Foundry: привяжите сервисы к CloudFoundry через протокол Oauth 2. CloudFoundry — это облачная платформа PaaS с открытым исходным кодом, запущенная VMware.
  • Spring Cloud Sleuth: Набор инструментов для сбора журналов, который инкапсулирует трассировку на основе Dapper и журналов, а также операции Zipkin и HTrace, реализует решение для распределенной трассировки для приложений Spring Cloud.
  • Spring Cloud Data Flow: Инструмент для работы с большими данными, альтернатива Spring XD, представляет собой гибридную модель вычислений, сочетающую потоковую передачу данных и пакетную обработку данных.
  • Spring Cloud Security: Spring инструментарий безопасности, основанный на безопасности, для добавления элементов управления безопасностью в ваше приложение.
  • Spring Cloud Zookeeper: набор инструментов для работы с Zookeeper для обнаружения служб и управления конфигурацией с использованием метода zookeeper.
  • Spring Cloud Stream: Комплект разработки операций с потоками данных, пакет передачи сообщений и Redis, Rabbit, Kafka.
  • Spring Cloud CLI: на основе Spring Boot CLI вы можете быстро создать облачный компонент в командной строке.
  • Ribbon: Обеспечивает балансировку нагрузки в облаке с различными стратегиями балансировки нагрузки на выбор, которые можно использовать с обнаружением служб и автоматическими выключателями.
  • Turbine: Turbine — это инструмент, с помощью которого сервер агрегации отправляет данные потока событий для мониторинга метрик hystrix в рамках кластера.
  • Feign: Feign — это декларативный шаблонный HTTP-клиент.
  • Spring Cloud Task: Обеспечивает управление задачами облачного плана и планирование задач.
  • Spring Cloud Connectors: облачным приложениям удобно подключаться к серверной части на различных платформах PaaS, таких как службы баз данных и брокеров сообщений.
  • Spring Cloud Cluster: Обеспечить выборы лидеров, таких как: ZooKeeper, Redis, Hazelcast, Consul и т. д. Абстракция и реализация.
  • Spring Cloud Starters: Стартап-проекты в стиле Spring Boot, обеспечивающие управление зависимостями из коробки для Spring Cloud.

Наши часто используемые компоненты: Spring Cloud Config, Spring Cloud Bus, Hystrix, Zuul, Ribbon, Feign.

технический директор:

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

Eureka

Eureka является одним из компонентов Spring Cloud Netflix. Он в основном отвечает за регистрацию и обнаружение сервисов. Что такое регистрация и обнаружение? В дистрибутиве, который мы только что проанализировали, есть проблема, то есть сервис заказов и сервис пользователей независимы, так как же они взаимодействуют? Например, чтобы получить основную информацию о пользователях в сервисе заказов, что нам нужно сделать в это время? Если вы будете следовать приведенной выше схеме архитектуры, вы можете перейти непосредственно к базе данных, чтобы получить ее, потому что, хотя служба независима, база данных по-прежнему является общей, поэтому вы можете получить результаты, напрямую запросив базу данных.Что, если мы разделим базу данных ? Что нам делать в это время? Некоторые люди думали, для сервисных вызовов, сервисных вызовов нужен ip и порт, тогда вопрос, для заказа сервиса, как мне узнать IP и порт пользовательского сервиса? Это жестко закодировано в сервисе заказов? Что делать, если порт пользовательского сервиса изменится? В это время выходит Эврика.Это должно решить проблему связи служб.Каждая служба может регистрировать свою собственную информацию в Эврике, такую ​​как ip, порт, имя службы и другую информацию.В это время, если служба заказа хочет получить информацию об услугах пользователя, просто перейдите на Eureka, чтобы получить ее, см. рисунок ниже:

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

Код:springcloud (a) реестр эврика

Spring Cloud Config

Spring Cloud Config обеспечивает поддержку сервера и клиента для внешней конфигурации в распределенных системах. С помощью Config Server вы можете управлять внешними свойствами вашего приложения во всех средах. Отображение понятий на клиенте и сервере — это та же абстракция, что и Spring Environment и PropertySource, поэтому они хорошо подходят для приложений Spring, но могут использоваться с любым приложением, работающим на любом языке. По мере того, как приложение проходит процесс развертывания от разработчика к тестированию и производству, вы можете управлять конфигурацией между этими средами и быть уверенными, что у приложения есть все необходимое для запуска при миграции. Реализация бэкэнда серверного хранилища по умолчанию использует git, поэтому он легко поддерживает среды конфигурации с версиями с вкладками, а также доступ к различным инструментам для управления контентом. Альтернативные реализации можно легко добавить и подключить с помощью конфигурации Spring.

Проще говоря, централизованно управлять файлом конфигурации каждой службы и отделить файл конфигурации от службы. Чтобы дать простой каштан, в нашем файле конфигурации обязательно будет информация о подключении к базе данных и информация о подключении Redis.Наша среда разнообразна, включая среду разработки, тестовую среду, предварительную среду, производственную среду и соответствующее соединение для каждой среды. Информация должна быть разной, нужно ли каждый раз при публикации изменять файл конфигурации в сервисе? Могу ли я централизованно управлять этими конфигурациями с большими изменениями, а менеджеры в разных средах могут модифицировать их по отдельности, поэтому нет необходимости вносить изменения в сервис, а Config может это сделать.

Это общая структура config.Все файлы конфигурации централизованы и управляются config.Как управлять этими файлами конфигурации с помощью config? Вы можете хранить файлы конфигурации каждой среды в другом месте, таком как Lgitlab, svn, local и т. д. config будет считывать файлы конфигурации в соответствии с расположением, которое вы установили для управления, а затем переходить непосредственно в центр конфигурации конфигурации, когда другие службы Соответствующего конфигурационного файла достаточно, так что разработчикам нужно обращать внимание только на конфигурационный файл -dev, а тестировщикам только на конфигурационный файл -test.Он полностью отвязан от сервиса, и вы заслуживаете Это.

Код:Конфигурация центра конфигурации springcloud (два)

Netflix Zuul (Gateway)

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

Коллега А: Мы можем открыть доменное имя второго уровня через обратный прокси nginx, а затем сопоставить доменное имя с микросервисом.

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

Коллега Б: Я думаю, что мы можем использовать шлюз, который может не только распределять и пересылать трафик, но и контролировать разрешения. Использование nginx + шлюз, я думаю, это лучшее решение. Далее следует введение шлюза zuul.

Маршрутизация является неотъемлемой частью архитектуры микросервисов. Например, / можно сопоставить с вашим веб-приложением, /api/users со службой пользователей, а /api/shop со службой магазина. Zuul — это маршрутизатор Netflix на базе JVM и балансировщик нагрузки на стороне сервера. Netflix использует Zuul для следующего:

  • Сертификация - Инсайты
  • испытание давлением
  • Канарский тест
  • динамическая маршрутизация
  • миграция службы
  • снижение нагрузки
  • Безопасность
  • Статическая обработка ответа
  • Активное/активное управление трафиком

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

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

Код:springcloud (три) шлюз zuul

Spring Cloud Bus

application.yml
spring:
  datasource:
    username: root
    password: 123456
    url: jdbc:mysql://localhost:3306/test
    driver-class-name: com.mysql.cj.jdbc.Driver

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

Коллега С: Мы можем решить эту проблему через облачную шину spring, которая связывает легковесные брокеры сообщений с узлами распределенных систем. Затем его можно использовать для передачи изменений состояния (например, изменений конфигурации) или других инструкций по управлению. Проект включает в себя реализации брокера AMQP и Kafka. Кроме того, любое связывание Spring Cloud Stream, найденное в пути к классам, может использоваться в качестве транспорта.

Это требует от нас небольшой основы mq, будь то rabbitmq или kafka, основной принцип шины таков: когда файл конфигурации изменяется, config выдает mq, чтобы сообщить службе, что файл конфигурации изменился, а также выдает изменить В настоящее время услуга должна быть изменена только в режиме реального времени в соответствии с информацией mq.Это очень простой принцип, и его нетрудно понять.Нарисуйте картинку, чтобы понять это.

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

Код:Springcloud (четыре) шина сообщений Bus

Feign

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

Коллега Д: Поскольку распределенная архитектура, о которой мы только что говорили, — это springcloud, рекомендуется использовать: Feign

Feign — это декларативный клиент веб-сервиса. Это упрощает для клиентов веб-сервиса написание интерфейса с помощью Feign и аннотирование его. Он имеет подключаемую поддержку аннотаций, включая аннотации Feign и аннотации JAX-RS. Feign также поддерживает подключаемые кодеры и декодеры. Spring Cloud добавляет поддержку аннотаций Spring MVC и использует HttpMessageConverters, используемые по умолчанию в Spring Web. Spring Cloud интегрирует Ribbon и Eureka, чтобы обеспечить балансировку нагрузки http-клиента при использовании Feign.

Feign основан на стиле rest, который прост и понятен, его нижний слой представляет собой слой инкапсуляции HttpClient, который очень удобен в использовании.

Технический директор: Да, а если проблема с вызовом сервиса? Например, когда истекает время ожидания вызова, как мы справляемся с ним по истечении этого времени?

Код:springcloud (5) удаленный вызов Feign (включая отслеживание исходного кода)

Нетфликс Хайстрикс (предохранитель)

Коллега Е: Это облако тоже рассматривалось для нас, осталось только ввести автоматические выключатели.

Hystrix поддерживает концепцию отката: путь кода по умолчанию для выполнения при разрыве цепи или возникновении ошибки. Чтобы включить откат для данного @FeignClient, задайте для свойства отката имя класса, который реализует откат.

Мы можем преобразовать структуру вызова прямо сейчас

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

Технический директор: Общая архитектура распределенной системы практически такая же.Есть еще некоторые компоненты, которые здесь не будут представлены.В них можно разобраться при использовании.Это не сложно.Чтобы сменить пароль,нужно отправить код подтверждения SMS, отправьте SMS на службу SMS и измените пароль на службу пользователя.В это время будет вызов службы, и мы знаем, что отправка текстового сообщения обычно вызывает сторонний интерфейс, например как у Али, поскольку вызов связан, будет много неопределенных факторов, таких как проблемы с сетью.Если пользователь нажимает, чтобы отправить код подтверждения SMS, служба пользователя вызовет службу SMS, но для выполнения требуется много времени API вызывает Ali в службе SMS. В это время это приведет к тому, что служба пользователя настроит службу SMS на тайм-аут, и он вернется к пользователю с ошибкой. Тем не менее, SMS, наконец, отправлено. Как решить эту проблему. проблема?

MQ (промежуточное ПО для сообщений)

Коллега Б: Мы можем добиться этого с помощью промежуточного программного обеспечения сообщений, используя асинхронную обратную связь с пользователем и разделение отправки SMS-сообщений.Пока пользователь нажимает, чтобы отправить SMS, он возвращает успех напрямую, а затем начинает отправлять код подтверждения, и повторно отправить его через 60 секунд, даже если он был отправлен. В случае неудачи у пользователя также есть возможность отправить его повторно.

Распределенная транзакция

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

Коллега С: У меня есть два решения: первое — обеспечить согласованность с помощью MQ, а второе — обеспечить согласованность с помощью распределенных транзакций.

Mq обеспечивает согласованность

Обслуживание кошелька: Шаг 1: Создайте таблицу заказов для записи статуса входящего и исходящего перевода. Шаг 2: Отправьте сообщение с подтверждением на mq. Шаг 3: Откройте локальную транзакцию, выполните операцию передачи и зафиксируйте транзакцию.

Сервис транзакционного кошелька: Получите сообщение mq и выполните операцию передачи (эта операция требует поддержки механизма подтверждения подтверждения).

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

Выше приведена общая идея mq для обеспечения распределенных транзакций, а не единственная, только для справки.

сиденья (распределенная транзакция)

Seata состоит из 3 основных компонентов:

  • Координатор транзакции (TC): поддержание глобальной транзакции и отраслей государственных дел, привод Глобальный коммит или откат.
  • Transaction Manager TM: определяет область действия глобальной транзакции: запускает глобальную транзакцию, фиксирует или откатывает глобальную транзакцию.
  • Диспетчер ресурсов (RM): управляет ресурсами, которые обрабатывает транзакция ветки, взаимодействует с TC, чтобы зарегистрировать транзакцию ветки, и сообщает о состоянии транзакции ветки, а также управляет фиксацией или откатом транзакции ветки.

Типичный жизненный цикл распределенной транзакции, управляемой Seata:

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

Полная распределенная архитектура

Это набор распределенной базовой архитектуры.Запрос отправляется из браузера, обратно проксируется nginx на шлюз zuul, шлюз проверяется на наличие разрешений, а затем перенаправляется в соответствующий сервис, каждый сервис имеет свою независимую базу данных, если вам нужно делать запросы между базами данных, вам нужно использовать распределенные удаленные вызовы (симулировать).Хотя я разделил службу здесь, следует отметить, что шлюз, который передает все запросы.Если запрос слишком большой, это произойдет. какие? Служба не работает, поэтому в целом шлюзы развертываются в кластерах. Не только шлюзы могут быть кластеризованы, но и другие службы, такие как реестр, Redis, MQ и т. д., тогда мы улучшим эту блок-схему. .
Сейчас эта архитектура представляет собой набор процедур сравнения.Будь то производительность или стабильность, все они левереджированы, и совещание по техническому отбору почти состоялось.Наконец, технический директор подвел итоги.

Суммировать

Монолитный сервис против распределенного сервиса

Когда использовать распределенный/кластерный

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

Использование распределенных соображений

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

Новости о компонентной подвеске

В настоящее время регистрационный центр Эврика, гейт зуул и фейк все остановлены один за другим.Остановка не означает, что им нельзя пользоваться, но он не может быть активно исправлен, за исключением багов.Поэтому в это время мы можем нужно выбрать другой компонент.Центр регистрации может использовать consul, Nacos, zookeeper, а gateway можно заменить на Gateway, а openFeign может заменить fiegn, так что не нужно беспокоиться о том, будет ли облако холодным, когда вы услышите новость что комплектующие будут остановлены.Будьте уверены, холода не будет, по крайней мере, в последние несколько лет.

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