Почему нужно использовать распределённую систему:

1. Отдельное обслуживание, без взаимного влияния. При запуске можно запускать только часть системы, нет необходимости запускать всё сразу.
2. Увеличение пропускной способности: когда несколько сервисов вызывают один сервис, например, модуль пользователя, происходит балансировка нагрузки между сервисами.
3. Максимальное использование ресурсов: позволяет максимально эффективно использовать ресурсы для вычислений основных сервисов.
4. Отказоустойчивость: неважные модули (GG) не влияют на основные модули.

Выбор модели ввода-вывода (IO): Существует множество моделей IO, включая синхронное блокирующее, синхронное неблокирующее и асинхронное неблокирующее. Многоканальный мультиплексный ввод-вывод также влияет на пропускную способность. В большинстве случаев используется синхронный ввод-вывод. На стороне сервера применяется главный-подчиненный режим, то есть после установления соединения с клиентом, многопоточность в сочетании с пулом потоков обрабатывает реальные бизнес-операции. Сетевой протокол: TCP TCP, UDP, HTTP: В основном используются TCP, не слышал об UDP. Как синхронный неблокирующий метод, он имеет механизм подтверждения, который является предпочтительным. HTTP также может использоваться как RPC, но пропускная способность снижается, поскольку серверы обычно выполняют балансировку нагрузки, например, через Nginx и обратные прокси-серверы, что предотвращает прямой доступ к сервисам. Вместо этого доступ осуществляется через Nginx, а затем к сервису, так что это 1+1.

2017-8-14: Всё работает, но есть ещё много проблем. Сериализация пока отложена.

2017-8-18: Внезапно обнаружил проблему. Если это длительное соединение, как выполнить балансировку нагрузки? Если есть 5 провайдеров, нужно ли создавать 5 длительных соединений? Затем сервис выполняет балансировку нагрузки? Кажется, в архитектуре есть проблема.

2017-8-31: Внезапно возникла ещё одна проблема. Предположим, a, b, c вызываются одновременно, и c может замедлить a и b. Что делать? Сначала я думал о наличии слоя localservice, который вызывает a, b и c отдельно. Но это тоже неправильно, потому что localservice будет заблокирован, и это приводит к новым вопросам: управление версиями сервисов, плавное и полуплавное завершение работы (ограничение потока), обработка тайм-аутов.

2017-9-14: Мониторинг. Посмотрел на открытый исходный код Yikxin. Он кажется обычным. Их продукт — это промежуточное ПО, которое не вмешивается в код, а перехватывает запросы. Это похоже на загрузку пользовательского класса перед Tomcat. Лично я считаю, что риск слишком высок, потому что мониторинг может помешать основному процессу. Лучше использовать ZK для мониторинга. Кроме того, существует множество открытых программных решений для мониторинга серверов, таких как Zabbix. Нет необходимости разрабатывать собственное решение, это требует времени и усилий. Springboot кажется немного сложным, трудно найти реальные проекты.