У монолитных приложений есть проблемы!

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

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

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

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

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

проблема, с которой мы сталкиваемся

1. Проект слишком сложный

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

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

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

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

2. Развитие идет медленно

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

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

Не может быть быстро.

3. Нелегко расширять

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

4. Стек технологий нелегко расширить

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

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

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

прежнее преимущество

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

Простая разработка, одна IDE может быстро создать одно приложение
Простота тестирования
Развертывание простое, после установки Tomcat приложение можно закинуть.
Развертывание кластера также очень просто: несколько Tomcat + один Nginx могут создать кластерную среду за считанные минуты.

При таком большом количестве преимуществ есть еще и недостатки.

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

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

Использованная литература:

[1] Крис Ричардсон, Шаблоны проектирования микросервисной архитектуры [M], Пекин: Machinery Industry Press, 2019.

Обратите внимание на общедоступную учетную запись [Jiangnan A Little Rain], сосредоточьтесь на технологиях с полным стеком, таких как Spring Boot + микросервисы и разделение интерфейса и сервера, делитесь регулярными видеоуроками, отвечайте на Java после того, как уделите внимание, и получайте Сухие товары Java тщательно приготовлены Songge для вас!