Какой из них будет устранен, Spring Cloud или Dubbo?

Java Spring Cloud

Сегодня увидел такой вопрос на Жиху: Какой из Spring Cloud и Dubbo будет устранен? Прочитав несколько ответов, чувствую, что не по делу, поэтому просто пишу небольшую статью и рассказываю об этом.

Просто личное мнение

Я думаю, что эти два фреймворка, скорее всего, будут существовать еще долгое время.

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

Что означает для Dubbo бесшовная интеграция экосистемы Spring Cloud? Есть два основных аспекта:

  1. Если вы раньше были пользователем Dubbo, теперь вы можете использовать Spring Cloud. Легко и удобно интегрируйте центр конфигурации Spring Cloud, реестр и полезные периферийные продукты, такие как распределенная трассировка, для управления кластерами распределенных служб, и наслаждайтесь теми же экологическими преимуществами, что и другие пользователи Spring Cloud Netflix.
  2. Если вы раньше не пользовались Dubbo, но ваш сценарий кажется неэффективным и экономичным при использовании HTTP-вызовов, вы можете рассмотреть возможность внедрения Dubbo для повышения производительности RPC при вызовах с сокращением обслуживания.

В этот момент некоторые официальные лица могут сказать, что вы говорите с точки зрения интеграции, мне просто не нравится подход Dubbo, зависящий от интерфейса, и я решительно защищаю исходную экологию Spring Cloud!

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

Однако я не думаю, что настойчивость пользователей Spring Cloud в отношении этого решения повлияет на упадок экосистемы Dubbo. Два основных момента:

  1. Исходная пользовательская база Dubbo огромна. До проповеди Spring Cloud у Dubbo была огромная пользовательская база. Теперь, когда есть хороший план интеграции, соображения интеграции должны быть более безопасными, чем соображения реконструкции.
  2. Есть много пользователей, которые будут сомневаться в проектах Alibaba с открытым исходным кодом, которые легко быть евнухами.Как долго Dubbo может поддерживаться на этот раз? На самом деле, на этот раз не нужно слишком беспокоиться об этом, потому что текущий Dubbo был передан Apache Foundation, поскольку у Apache высокие требования к оценке проектов с открытым исходным кодом для долгосрочного обслуживания (активность, коэффициент вклада и т. д.), проект, который может вырасти из Apache, если не будет чего-то, что может превзойти его во всех аспектах, будет существовать и применяться еще долго.

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