Могу ли я проксировать сервер Golang, встроенный в WAR?

У моих клиентов очень строгие требования о том, как они могут развернуть веб-приложение. Они требуют, чтобы он был доступен для развертывания как WAR на сервере Java, таком как Tomcat. Однако наше приложение написано в golang и компилируется на исполняемый сервер.

Единственное решение, которое я мог бы придумать, было бы, чтобы начать долговременный процесс golang в фоновом режиме, который слушает нестандартный порт, например 8080, а затем помещает какой-то прокси-сервер в java, который прозрачно проксирует все HTTP-запросы и ответы на этот процесс.

Как мне это сделать? Я не совсем знаком с Java Servlets и выполняю длинные процессы, подобные этому в фоновом режиме.

Моя основная забота - если что-то подобное стандартное,

  • Это повлияет на использование памяти JVM и т.д.
  • Будет ли сервер разрешать мой процесс golang распределять требуемые объем памяти?
  • Может ли JVM отслеживать использование процессора?

Есть ли лучший способ сделать это, может быть? Как какой-то механизм взаимодействия между процессами?

Ответ 1

Если HTTP - это единственный API, предоставляемый вашим приложением Go, вы остаетесь только с возможностью просто отправлять HTTP-запрос Go. Да, вы можете запустить исполняемый файл Go как дочерний процесс из JVM с помощью ProcessBuilder. Но это не по-настоящему встраивание идет в вашу ВОЙНУ. Вы можете использовать JNI (Go bindings называются GoJVM), чтобы вызывать собственные подпрограммы в Go из Java, но тогда вам нужно внести множество изменений в код Go также.

То, что вы ищете, вероятно, является обратным прокси. Это не часто делается в сервлетах/серверах приложений, поскольку это обычно выполняется в балансировщиках нагрузки. Обычно это будет NGINX или httpd с mod_rewrite. Для серверов приложений вы можете использовать сервлет-прокси.

Примеры:

Объем памяти, как правило, не плохой, потому что вы по существу только соединяете потоки. JVM сможет отслеживать использование процессора и памяти - если он будет реализован правильно, а исполняемый файл Go будет работать на одном сервере. Очевидно, что специфическая статистика Java больше не имеет смысла, поскольку вы используете только свой сервер Java в качестве сквозного прохода.

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

Ответ 2

Если они хотят войны, дайте им войну!

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

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

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

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