Это 23-й день моего участия в Gengwen Challenge.Подробности о мероприятии:Обновить вызов.
История микросервисов
До появления микросервисов основными недостатками монолитных приложений были:
- высокая сложность
- Плохая масштабируемость
- Высокая стоимость командной работы
- Неэффективность развертывания
- система с плохой высокой доступностью
Сложность выражается в: при непрерывной итерации бизнеса резко увеличивается объем кода проекта, а также увеличиваются модули проекта, и весь проект становится очень сложным.
Стоимость разработки высока, что выражается в том, что десятки человек в команде модифицируют код, а потом сливают в одну адресную ветку, упаковывают и деплоят, пока есть проблема с маленькой функцией на стадии тестирования , его необходимо перекомпилировать, упаковать, развернуть, повторно протестировать, при этом должны быть задействованы все соответствующие разработчики, что неэффективно и дорого в разработке.
Плохая масштабируемость, что выражается в: при добавлении новых функций в бизнес уровень кода будет считать написание кода не затрагивая существующий бизнес, что увеличивает сложность кода.
Низкая эффективность развертывания проявляется в следующем: когда в одном приложении появляется все больше и больше кода и от него зависит все больше и больше ресурсов, требуется все больше и больше времени для компиляции, упаковки, развертывания и тестирования приложения один раз, что приводит к низкому развертыванию. эффективность.
Разница в высокой доступности отражается в следующем: поскольку все бизнес-функции в конечном итоге развертываются в один и тот же файл, при возникновении проблемы с кодом или ресурсами, задействованными в функции, это повлияет на функцию развертывания всего пакета файлов. Чтобы привести особенно яркий пример: в 1980-х и 1990-х годах многие желтые страницы и более поздние веб-сайты были расширены, и многие страницы отображения и серверная часть для сбора данных были все в сервисном модуле. Это имеет очень плохой эффект: если изменить только очень небольшую часть отображения страницы или отображения изображения, необходимо упаковать и развернуть весь сервисный модуль, что приведет к серьезной трате времени и увеличению стоимости. Что еще хуже, это приносит пользователю очень плохой опыт, и пользователь не может понять, что простое изменение небольшой области отображения веб-сайта приводит к тому, что весь веб-сайт не может нормально посещать в этот момент. Конечно, возможно, при неразвитости интернета в то время, опыт людей такого рода уже является своего рода счастливым наслаждением.
Из-за указанных выше недостатков монолитных приложений родился новый термин и новая концепция: микросервисы.
Что такое микросервисы
Фактически, от одного приложения в первые годы до 2014 года, благодаря зрелости технологии контейнеризации, представленной Docker, и подъему культуры DevOps, идея службы в дальнейшем превратилась в микросервисы, с которыми мы знакомы сегодня. . . . Итак, что такое микросервисы?
Микросервис, английское название: микросервис, определяется в энциклопедии Baidu как вариант архитектуры SOA. Микросервисы (или микросервисная архитектура) — это способ структурирования приложения в виде набора плохо связанных сервисов.
Микросервисы имеют ряд отличительных особенностей:
- Одна функция
- Малая степень детализации обслуживания
- Сильная независимость между службами
- Слабые межсервисные зависимости
- Сервисное независимое техническое обслуживание
- Независимое от службы развертывание
Для каждого микросервиса функция, которую он предоставляет, должна быть единственной; его гранулярность очень мала; он предоставляет только соответствующие интерфейсы, задействованные в бизнес-функции. Такие как: система заказов, система оплаты, система продуктов и т. Д. В системе электронной коммерции каждая системная служба выполняет только независимую функцию системы и не включает функциональную логику, которая ей не принадлежит.
Зависимости между микрослужбами должны быть как можно более слабыми, что имеет то преимущество, что другие системы не могут нормально работать из-за простоя одной системной службы, что влияет на работу пользователя. Также возьмем в качестве примера систему электронной коммерции: после того, как пользователь добавляет товар в корзину, оформляет заказ, затем переходит к оплате и обнаруживает, что оплата не может быть произведена, в это время заказ может быть помещен в состояние ожидания платежа, тем самым предотвращая потерю заказа и недружественный пользовательский интерфейс. Если система заказов сильно зависит от платежной системы, система заказов всегда будет ждать ответа платежной системы, что приведет к тому, что пользовательский интерфейс всегда будет находиться в состоянии загрузки, что не позволит пользователю выполнять какие-либо операции.
Когда функцию микросервиса нужно обновить, или в функции нужно исправить ошибку, нужно только скомпилировать и развернуть текущий сервис, а не огромное количество сервисов, упаковывающих бизнес-функции всего продукта, независимых друг от друга. техническое обслуживание, автономное развертывание.
Описанные выше микросервисы на самом деле выделяют свои отличительные особенности:Высокая сплоченность, низкая связанность, тут возникает проблема. Что такое высокая сплоченность и низкая связанность? Так называемая высокая связность: то есть каждый сервис находится в одной сети или домене, и по отношению к внешней стороне целое представляет собой закрытый и безопасный ящик. Внешний интерфейс коробки неизменен, и интерфейс между модулями внутри коробки тоже неизменен, но содержимое внутри каждого модуля может быть изменено. Модули предоставляют только минимальные интерфейсы, чтобы избежать сильных зависимостей. Добавление или удаление модуля должно затрагивать только связанные модули с зависимостями, а несвязанные не должны затрагиваться.
Так называемая низкая связь: с небольшой точки зрения, это уменьшение связи между каждым классом Java, использование нескольких интерфейсов и использование инкапсуляции, наследования и полиморфизма идей объектно-ориентированного программирования Java для сокрытия деталей реализации. С точки зрения модулей, это должно уменьшить взаимосвязь между каждым модулем, уменьшить сложность избыточности, повторения и пересечения, а также как можно проще разделить функции модулей.
Революция и важность микросервисов
В предыдущем разделе было описано, что такое микросервисы, и отличительные черты микросервисов. Фактически, глядя на микросервисы из одного приложения, вы можете увидеть важность микросервисов.Он полностью реформирует инерцию приложений и появление его концепции дизайна: позволяя разработчикам значительно сократить затраты на разработку и ремонт;пользователь продукта имеет удобный опыт. Он решает многие сложные проблемы монолитных приложений и является более инновационным. Это позволяет нашим системам максимально быстро реагировать на изменения.
Микрослужба разделяет изначально связанный сложный бизнес на единую службу, избегая бесконечного накопления исходной сложности.Каждая микрослужба фокусируется на одной функции и четко выражает границы службы через четко определенные интерфейсы.
Поскольку микросервисы имеют независимые запущенные процессы, каждый микросервис можно развернуть независимо. Когда бизнес повторяется, необходимо выпустить только итерацию связанных сервисов, что снижает нагрузку на тестирование и снижает риск выпуска сервиса.
В микросервисной архитектуре при сбое компонента сбой локализуется в одной службе. Например, вред, причиняемый ошибками, можно уменьшить за счет ограничения тока и предохранителей, чтобы обеспечить нормальную работу основного бизнеса.