Я хочу определить количество потоков для моего фиксированного пула потоков в моем весеннем приложении. Где я должен это сделать? Я запутался между файлами yaml и application.properties.
Это частично отвечает на мой вопрос, какая разница, если я определю количество в файлах yaml?
Вы должны определить количество потоков для вашего фиксированного пула потоков в файле application.properties file
. Это файл конфигурации по умолчанию для приложений Spring, и это рекомендуемое место для хранения параметров конфигурации. Вы можете указать количество потоков для вашего фиксированного пула потоков с помощью свойства spring.task.execution.pool.core-size
.
Например, если вы хотите определить фиксированный пул потоков с 10 потоками, вы должны добавить следующее в файл application.properties: spring.task.execution.pool.core-size=10
Согласно документу Spring boot:
Файлы YAML нельзя загрузить с помощью @PropertySource или Аннотации @TestPropertySource. Итак, в случае, если вам нужно загрузить таким образом, вам нужно использовать файл свойств.
Обратитесь к этим SO1 и SO2, чтобы узнать разницу между файлами yaml и application.properties.
Я вижу, что потоки выполняют одну и ту же задачу в разных модулях. Есть ли способ избежать этого и распространять потоки?
Spring имеет несколько способов установки свойств. Вы можете использовать более одного из этих механизмов, если это уместно. Здесь важно помнить, что переменная среды PROPERTY_NAME
предоставляет значение для свойства property.name
, а переменная среды переопределяет файл application.yml
.
Некоторые варианты:
Файл src/main/resources/application.properties
компилируется в ваш файл jar и образ контейнера. Это полезно для предоставления значений по умолчанию для вещей или для предоставления конфигурации слоям Spring, которые используют конфигурацию свойств. Тем не менее, избегайте размещения здесь настроек, специфичных для среды, таких как имена хостов; вы не хотите перестраивать приложение для каждой новой среды развертывания.
Файл Kubernetes deployment.yaml
может содержать переменные среды, а также значения свойств Spring.
env:
- name: PROPERTY_NAME # for @Value("property.name")
value: property value
Если вы используете инструмент развертывания Helm, вы также можете использовать его язык шаблонов здесь. Это позволит вам предоставить значение фактически во время развертывания.
# templates/deployment.yaml
env:
- name: OTHERSERVICE_URL # @Value("other-service.url")
value: {{ .Values.otherServiceUrl }}
# values.yaml
# otherServiceUrl provides the location of the other service.
otherServiceUrl: http://other-service
# at the command line
helm install my-service ./ \
--set otherServiceUrl=http://other-service.other-namespace
Вы можете использовать Kubernetes ConfigMaps и Secrets для предоставления отдельных битов конфигурации. Синтаксис для ссылки на значение ConfigMap или Secret несколько подробен.
env:
- name: SPRING_DATASOURCE_PASSWORD
valueFrom:
secretKeyRef:
name: database
key: password
Если вы уже используете Helm, я бы не стал пытаться помещать отдельные значения конфигурации в ConfigMaps, так как это слишком многословно и нет никакой практической пользы по сравнению с подходом с рендерингом шаблонов. Если нет, и вы регулярно обнаруживаете kubectl edit
значения конфигурации, и они совместно используются несколькими контейнерами, то, возможно, ConfigMap может быть разумным. Хранение учетных данных в секретах, а не в ConfigMaps, обычно считается хорошей практикой, хотя на практике секреты не являются такими уж секретными.
Наконец, можно предоставить всю конфигурацию Spring в ConfigMap. Это полезно в том случае, когда ключ значения содержит произвольную карту; например, установка тегов для вашей системы метрик. В этом случае сопоставление переменных среды может не работать. Этот подход может быть более понятным для чтения; это много настроек, но только один раз для каждого приложения; в контексте Helm вы также можете использовать шаблоны; но он не может ссылаться на секретные значения.
# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: spring-properties # typically a little more boilerplate in a Helm chart
data:
applicaton.yml: |
management:
metrics:
tags:
namespace: {{ .Release.Namespace}} {{/*- Helm syntax */}}
# templates/deployment.yaml
volumes:
- name: app-properties
configMap:
name: spring-properties
containers:
- name: application
volumeMounts:
- name: app-properties
mountPath: /app/properties
env:
- name: SPRING_CONFIG_ADDITIONALLOCATION
value: file:///app/properties
Любая идея, как распределить поток по разным модулям? Я вижу, что одна и та же задача выполняется потоком во всех модулях.
Поток по своей сути является локальным для данного процесса. Вы можете посмотреть на поддержку Spring для систем обмена сообщениями, таких как RabbitMQ, чтобы вставить рабочую очередь в вашу обработку.