Это 24-й день моего участия в августовском испытании обновлений. Узнайте подробности события:Испытание августовского обновления

🌈 Обзор прошлых выпусков

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

• 💖Познакомьтесь с RocketMQ за 10 минут! Если хочешь зайти на али, то даже этого сделать нельзя? 2️⃣💖
• 💖Познакомьтесь с RocketMQ за 10 минут! Если хочешь зайти на али, то даже этого сделать нельзя? 1️⃣💖
• 💖5 минут, чтобы настроить образ и установить программное обеспечение 💖Вводное руководство по серии Docker

1. Микросервисы

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

    In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.-----[С официального сайта] В двух словах, архитектурный стиль микросервисов — это подход к разработке одного приложения как «набора небольших сервисов», каждый из которых «работает в своем собственном API) для связи. Эти услуги «построены вокруг бизнес-функций» и «развертываются независимо» с помощью полностью автоматизированного механизма развертывания. «Эти сервисы имеют минимальное централизованное управление», могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.

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

1.2 Почему микросервисы

1.2.1.Монолитное приложение

Когда бизнес-объем системы очень мал, все коды помещаются впунктПросто отлично, а затем проект развертывается на сервере. Все услуги для всего проекта предоставляются этим сервером. Это автономная структура.

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

Его недостатки также очевидны:

1. Приложение Со временем все больше и больше функций в конечном итоге станут огромными, и проект, скорее всего, будет утомительным пакетом JAR между миллионами строк.
2. Со временем эффективность разработки снижается, а обслуживание кода становится затруднительным.
3. Если вы хотите использовать новую технологию, новый фреймворк или новый язык для всего приложения, это невозможно.
4. Уязвимости или ошибки в любом модуле повлияют на приложение и снизят надежность системы.

1.2.2 Распределенный

Поскольку вся система должна использовать Tomcat и MySQL, вычислительная мощность одного сервера ограничена, и для использования Tomcat и MySQL необходимо выделить 2 ГБ памяти.По мере того, как бизнес становится все более сложным, появляется все больше и больше Запросы. Памяти становится все меньше и меньше, поэтому в это время нам нужно провести распределенное развертывание.

Мы делаем запрос на комментарий, этот запрос зависит отраспределенныйКомпоненты [Tomat и MySQL] на двух разных серверах могут быть сделаны .. Так называется распределенной системой.

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

1.2.3 Кластер

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

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

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

1.3 Эволюция системной архитектуры

Эволюция архитектуры примерно такова: архитектура одного приложения===>Вертикальная архитектура приложений===>Распределенная сервисная архитектура===>Архитектура потоковых вычислений Микросервисная архитектура===>[неизвестный]

1.3.1 Архитектура единого приложения

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

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

Мы превратим их в веб-проект и развернем на сервере tomcat.

Его преимущества:

1. Структура проекта проста, а стоимость разработки для небольших проектов низкая.
2. Проект развернут на одном узле, а обслуживание простое.

Его недостатки также очевидны:

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

• Модули проекта тесно связаны, а единая точечная частота допуска откачки низкая.

• Целевая оптимизация и горизонтальное расширение не могут быть выполнены для разных модулей.

1.3.2 Вертикальная архитектура приложений

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

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

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

• Система электронной коммерции (управление пользователями, управление товарами, управление заказами)

• Фоновая система (управление пользователями, управление заказами, управление клиентами)

• Система CMS (управление рекламой, управление маркетингом)

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

Его преимущества:

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

недостаток:

1. Системы независимы друг от друга и не могут вызывать друг друга.
2. Системы независимы друг от друга, и задачи разработки будут повторяться.

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

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

преимущество:

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

недостаток:

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

1.3.4 Архитектура SOA

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

преимущество:

1. Использование реестра для решения автоматической настройки отношения вызова между службами

недостаток:

1. Между службами будут зависимости, и если связь выйдет из строя, это окажет большее влияние (сервисная лавина).
2. Вопросы обслуживания сложны, а эксплуатация, техническое обслуживание и тестовое развертывание сложны.

1.3.4, Микросервисная архитектура

Микросервисная архитектура в какой-то степени является сервис-ориентированной архитектурой, в которой делается упор на «полное разделение» сервисов.

преимущество:

1. Атомарное разделение сервисов, независимая упаковка, развертывание и обновление для обеспечения четкого разделения задач каждого микросервиса, что способствует расширению.
2. Микросервисы вызывают друг друга, используя облегченные протоколы Http, такие как RESTful.
3. У каждой службы есть свои отдельные обязанности, и службы слабо связаны, чтобы избежать сбоев службы из-за проблемы с модулем.

недостаток:

1. Технические затраты на разработку распределенной системы высоки (отказоустойчивость, распределенные транзакции и т. д.).
2. Управление услугами и мониторинг услуг имеют решающее значение.
3. Сложность мультисервисной эксплуатации и обслуживания, с увеличением количества услуг, нагрузка на эксплуатацию и техническое обслуживание также увеличивается.

1.4. Проблемы, которые должны решать микросервисы

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

    Часто задаваемые вопросы о микросервисной архитектуре

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

• Так много мелких сервисов, как ими управлять?

• С таким количеством небольших сервисов, как они общаются?

• Как клиенты могут получить к ним доступ при таком количестве небольших сервисов?

• При таком количестве мелких сервисов, если возникнет проблема, как мне с ней справиться?

• При таком количестве небольших сервисов, если возникает проблема, как мне ее устранить?

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

1.5 Общие концепции микросервисной архитектуры

1.5.1 Управление услугами

Управление службами — это автоматическое управление службами, ядром которого является регистрация и обнаружение служб.

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

1.5.2, сервисный вызов

В микросервисной архитектуре обычно требуется удаленный вызов между несколькими службами.В настоящее время основные технологии удаленного вызова включают интерфейс RESTFul на основе HTTP-запросов и протокол RPC на основе TCP.

• REST (передача репрезентативного состояния): это формат вызовов HTTP, который является более стандартным и общим и поддерживает протокол http независимо от языка.
• RPC (Remote Promote Call): метод межпроцессного взаимодействия. Позволяет вызывать удаленные службы так же, как если бы они вызывали локальные службы. Основная цель инфраструктуры RPC — сделать вызовы удаленных служб более простыми и прозрачными. Платформа RPC отвечает за защиту базовых методов передачи, методов сериализации и деталей связи. При его использовании разработчикам нужно только знать, кто и в каком месте предоставляет интерфейс удаленной службы, и им не нужно заботиться о базовых деталях связи и процессе вызова.

Разница между ними заключается в соединении:

сравнение	RESTFul	RPC
Протокол	HTTP	Обычно TCP
представление	немного ниже	выше
гибкость	высокий	Низкий
применение	Микросервисная архитектура	SOA-архитектура

1.5.3 Сервисный шлюз

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

1. Клиенту необходимо вызывать разные URL-адреса, что увеличивает сложность.
2. В некоторых сценариях возникает проблема междоменных запросов.
3. Каждая микрослужба требует индивидуальной аутентификации.

Для решения этих проблем и был создан API Gateway.

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

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

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

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

1. Не подвержен влиянию внешней среды.
2. Не перегружайтесь исходящими запросами.
3. Не увязайте в нисходящих ответах.

1.5.5 Отслеживание ссылок

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

1.6 Общие решения для микросервисов

1.6.1 Сервисная гребенка

Apache ServiceComb, ранее известный как облачный сервис CSE (Cloud Service Engine) механизма микросервисов HUAWEI CLOUD, является первым в мире микросервисным проектом Apache верхнего уровня. Он предоставляет универсальное решение с открытым исходным кодом для микросервисов и стремится помочь предприятиям, пользователям и разработчикам легко помещать микросервисные корпоративные приложения в облако и обеспечивать эффективное управление эксплуатацией и обслуживанием микросервисных приложений.

1.6.2, Весеннее облако

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

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

1.6.3, весеннее облако Али папа

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