Переход на Cloud-Native
Облачные вычисления принесли много методологий и методов, которые произвели революцию как в деловом, так и в техническом мире. Среди предложенных терминов были облачные. Чтобы оправдать и оправдать эти ожидания во вселенной Java, появилась Jakarta EE. Цель этого поста — рассказать о концепции облачного натива и запустить приложение с этой концепцией, используя последнюю версию Jakarta EE NoSQL .
Вам также может понравиться: От javax. * До Джакарта. *: Простое доказательство концепции
Что облачного?
Как и в любой новой концепции, есть несколько концепций с одинаковыми именами; Если вы читаете книги или статьи о облачных носителях, вы можете не найти единого мнения по этому поводу. Например:
«Cloud-native — это подход к созданию и запуску приложений, использующий преимущества модели облачных вычислений».
— Pivotal
«Облачная среда — это другой способ мышления и рассуждения о программных системах. Он воплощает в себе следующие концепции: питание от одноразовой инфраструктуры, составленной из ограниченной, масштабируемой по всему миру, охватывающей одноразовую архитектуру».
— Архитектура облачных собственных приложений: разработка высокопроизводительных и экономичных приложений для облака
«В общем случае« облачный »- это подход к созданию и запуску приложений, использующий преимущества модели доставки облачных вычислений.« Облачный »- это способ создания и развертывания приложений, а не где».
— Инфомир
Во взаимном согласии вокруг определений из нескольких статей мы можем сказать, что облачный натив — это термин, используемый для описания сред на основе контейнеров. Таким образом, облачная среда не связана с конкретными языками программирования или средами или даже с компанией-поставщиком облачных вычислений, а связана с контейнерами .
Каковы облачные лучшие практики?
Когда мы начинаем изучать новую концепцию, мы обычно читаем о лучших практиках, чтобы избежать ошибок и запаха кода . Благодаря объектно-ориентированному программированию ( ООП ) у нас есть шаблоны проектирования от группы из четырех, в Java у нас есть эффективная Java , а когда речь идет об архитектуре, у нас есть как чистый код, так и чистая архитектура . Вопрос в том, каковы лучшие практики для облачных нативов?
Насколько нам известно, нет лучших практик, связанных конкретно с облачным. Поскольку облако близко к методологии Agile, есть несколько методов, которые мы можем использовать для создания здорового, безболезненного приложения:
- Манифест для гибкой разработки программного обеспечения .
- Непрерывная интеграция.
- Непрерывная доставка.
- Домен-управляемый дизайн.
Наиболее известные практики, относящиеся к любому приложению, которое включает в себя облачные вычисления, основаны на паттернах Мартина Фаулера « Архитектура корпоративных приложений и рефакторинг» .
Приложение с двенадцатью факторами
- Codebase : Один кодовые отслеживается контроль версий, многие разворачивают.
- Зависимости : явно объявлять и изолировать зависимости.
- Конфиг : Хранить конфиг в среде.
- Службы поддержки: относитесь к службам поддержки как к прикрепленным ресурсам.
- Сборка, выпуск, запуск : строго разделить этапы сборки и запуска.
- Процессы : Запустите приложение как один или несколько процессов без сохранения состояния.
- Привязка порта : экспорт услуг через привязку порта.
- Параллельность : масштабирование через модель процесса.
- Доступность : Максимальная надежность благодаря быстрому запуску и плавному отключению.
- Соотношение между разработчиками и разработчиками: старайтесь, чтобы разработка, подготовка и производство были максимально схожими.
- Журналы : обрабатывать журналы как потоки событий.
- Процессы администратора : запуск задач администратора / управления как одноразовых процессов.
Таким образом, пока нет конкретных рекомендаций для нативных облачных сред, но есть полезные шаблоны от Agile, микросервисов и приложений из двенадцати факторов.
Вернуться к коду
Во введении мы подробно объяснили, что такое облачный натив, а теперь давайте вернемся к нашему приложению и преобразуем его как нативное облачное приложение. В первом посте мы объяснили модель, сущность и принципы работы Jakarta NoSQL. Итак, мы возьмем его отсюда и воспользуемся самым простым способом обработки запросов с NoSQL и MongoDB с репозиторием.
Джава
1
import jakarta.nosql.mapping.Column;
2
import jakarta.nosql.mapping.Entity;
3
import jakarta.nosql.mapping.Id;
4
import javax.json.bind.annotation.JsonbVisibility;
6
import java.io.Serializable;
7
import java.util.Objects;
8
import java.util.Set;
9
11
(FieldPropertyVisibilityStrategy.class)
12
public class Hero implements Serializable {
13
15
private String name;
16
18
private Integer age;
19
21
private Set<String> powers;
22
}
24
import jakarta.nosql.mapping.Page;
27
import jakarta.nosql.mapping.Pagination;
28
import jakarta.nosql.mapping.Repository;
29
import java.util.stream.Stream;
31
public interface HeroRepository extends Repository<Hero, String> {
33
Stream<Hero> findAll();
35
Page<Hero> findAll(Pagination pagination);
37
Stream<Hero> findByPowersIn(String powers);
39
Stream<Hero> findByAgeGreaterThan(Integer age);
41
Stream<Hero> findByAgeLessThan(Integer age);
43
}
44
Чтобы сделать эти сервисы доступными, мы создадим приложение отдыха с JAX-RS в качестве класса ресурсов.
xxxxxxxxxx
1
import javax.enterprise.context.ApplicationScoped;
3
import javax.inject.Inject;
4
import javax.ws.rs.Consumes;
5
import javax.ws.rs.DELETE;
6
import javax.ws.rs.GET;
7
import javax.ws.rs.POST;
8
import javax.ws.rs.PUT;
9
import javax.ws.rs.Path;
10
import javax.ws.rs.PathParam;
11
import javax.ws.rs.Produces;
12
import javax.ws.rs.WebApplicationException;
13
import javax.ws.rs.core.MediaType;
14
import javax.ws.rs.core.Response;
15
import java.util.List;
16
import java.util.function.Supplier;
17
import static java.util.stream.Collectors.toList;
19
21
("heroes")
22
(MediaType.APPLICATION_JSON)
23
(MediaType.APPLICATION_JSON)
24
public class HeroResource {
25
private static final Supplier<WebApplicationException> NOT_FOUND =
27
() -> new WebApplicationException(Response.Status.NOT_FOUND);
28
30
private HeroRepository repository;
31
33
public List<Hero> findAll() {
34
return repository.findAll()
35
.collect(toList());
36
}
37
39
("/{id}")
40
public Hero findById(("id") String id) {
41
return repository.findById(id).orElseThrow(NOT_FOUND);
42
}
43
45
("seniors/{age}")
46
public List<Hero> findByOlder(("age") Integer age) {
47
return repository.findByAgeGreaterThan(age)
48
.collect(toList());
49
}
50
52
("youngs/{age}")
53
public List<Hero> findByYounger(("age") Integer age) {
54
return repository.findByAgeLessThan(age)
55
.collect(toList());
56
}
57
59
public void save(Hero hero) {
60
repository.save(hero);
61
}
62
64
("/{id}")
65
public void update(("id") String id, Hero hero) {
66
repository.save(hero);
67
}
68
("/{id}")
70
71
public void delete(("id") String name) {
72
repository.deleteById(name);
73
}
74
}
Приложение готово; последний шаг, который мы создадим, это класс конфигурации, который разрешает соединение с MongoDB. Это просто, мы будем использовать конфигурацию Eclipse MicroProfile, которая имеет тесные возможности интеграции с Eclipse JNoSQL, эталонной реализацией Jakarta NoSQL. Eclipse MicroProfile Config - это решение для экстернализации конфигурации из приложений Java, которое позволяет легко следовать третьему фактору .
Джава
xxxxxxxxxx
1
import jakarta.nosql.document.DocumentCollectionManager;
2
import org.eclipse.microprofile.config.inject.ConfigProperty;
3
import javax.enterprise.context.ApplicationScoped;
5
import javax.enterprise.inject.Disposes;
6
import javax.enterprise.inject.Produces;
7
import javax.inject.Inject;
8
10
class DocumentManagerProducer {
11
13
(name = "document")
14
private DocumentCollectionManager manager;
15
17
public DocumentCollectionManager getManager() {
18
return manager;
19
}
20
public void destroy( DocumentCollectionManager manager) {
22
manager.close();
23
}
24
}
25
Текущая конфигурация приложения может быть доступна через ConfigProvider # getConfig ().
Config состоит из информации, собранной из зарегистрированных org.eclipse.microprofile.config.spi.ConfigSource s. Эти ConfigSource s сортируются в соответствии с их порядковым номером. Таким образом, мы можем перезаписать конфигурацию с меньшей важностью извне.
По умолчанию есть три ConfigSources:
- System.getProperties () (ordinal = 400).
- System.getenv () (порядковый номер = 300).
- все файлы META-INF / microprofile-config.properties в ClassPath. (порядковый номер по умолчанию = 100, настраивается отдельно через свойство config_ordinal внутри каждого файла).
Поэтому значения по умолчанию могут быть указаны в вышеуказанных файлах, поставляемых вместе с приложением, и это значение может быть перезаписано позже для каждого развертывания. Более высокий порядковый номер имеет приоритет над более низким числом.
Это подразумевает, что у нас может быть конфигурация для локальной среды в виде файла, которую можно также протестировать как файл, и, наконец, мы можем переопределить всю эту информацию, когда переместим ее в облако.
xxxxxxxxxx
1
document=document
2
document.database=conferences
3
document.settings.jakarta.nosql.host=localhost:27017
4
document.provider=org.eclipse.jnosql.diana.mongodb.document.MongoDBDocumentConfiguration
5
Теперь у нас есть локальная конфигурация, поэтому давайте перенесем наше приложение с Jakarta EE на основе облачного подхода. Чтобы упростить процесс, мы будем использовать платформу как услугу (PaaS), потому что вы можете перемещать стиль приложения на основе контейнера в облаке через инфраструктуру как код (IaC).
Инфраструктура как код или программируемая инфраструктура означает написание кода, который может быть выполнен с использованием языка высокого уровня или любого описательного языка для управления конфигурациями и автоматизации предоставления инфраструктуры в дополнение к развертываниям.
Структура Platform.sh
Приложение Java готово к работе! Следующим шагом является установка файлов Platform.sh, необходимых для управления и развертывания приложения. В нашей первой статье о Java мы подробно рассмотрели каждый из этих трех файлов:
- Один маршрутизатор (.platform / rout.yaml). Platform.sh позволяет вам определять маршруты.
- Ноль или более служебных контейнеров (.platform / services.yaml). Platform.sh позволяет вам полностью определить и настроить топологию и сервисы, которые вы хотите использовать в своем проекте.
- Один или несколько контейнеров приложений (.platform.app.yaml). Вы управляете своим приложением и тем, как оно будет построено и развернуто на Platform.sh через один файл конфигурации.
Файл, который изменится в этом сообщении, является служебным файлом, позволяющим определить базу данных, поисковую систему, кэш и т. Д. Для этого проекта мы установим MongoDB вместо MySQL.
xxxxxxxxxx
1
mongodb
2
typemongodb3.6
3
disk1024
Для чтения конфигурации среды Platform.sh поддерживает программу чтения конфигурации, которая позволяет легко интегрировать. Platform.sh также поддерживает массивы каркасов и языков, включая Java. В этом посте мы переопределим конфигурацию MongoDB с помощью свойств Java, которые добавят прозрачность приложению - благодаря конфигурации Eclipse MicroProfile. С этими файлами, готовыми и переданными мастеру, Platform.sh создаст набор контейнеров в кластере.
YAML
xxxxxxxxxx
1
# in the same project.
2
#
3
# See https://docs.platform.sh/user_guide/reference/platform-app-yaml.html
4
# The name of this app. Must be unique within a project.
6
nameapp
7
# The runtime the application uses.
9
type"java:8"
10
disk800
12
# The hooks executed at various points in the lifecycle of the application.
14
hooks
15
build
16
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
17
mv jq-linux64 jq
18
chmod +x jq
19
mvn -U -DskipTests clean package payara-micro:bundle
20
# The relationships of the application with services or other applications.
22
#
23
# The left-hand side is the name of the relationship as it will be exposed
24
# to the application in the PLATFORM_RELATIONSHIPS variable. The right-hand
25
# side is in the form `<service name>:<endpoint name>`.
26
relationships
27
mongodb'mongodb:mongodb'
28
# The configuration of app when it is exposed to the web.
30
web
31
commands
32
start
33
export MONGO_PORT=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|./jq -r ".mongodb[0].port"`
34
export MONGO_HOST=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|./jq -r ".mongodb[0].host"`
35
export MONGO_ADDRESS="${MONGO_HOST}:${MONGO_PORT}"
36
export MONGO_PASSWORD=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|./jq -r ".mongodb[0].password"`
37
export MONGO_USER=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|./jq -r ".mongodb[0].username"`
38
export MONGO_DATABASE=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|./jq -r ".mongodb[0].path"`
39
java -jar -Xmx1024m -Ddocument.settings.jakarta.nosql.host=$MONGO_ADDRESS \
40
-Ddocument.database=$MONGO_DATABASE -Ddocument.settings.jakarta.nosql.user=$MONGO_USER \
41
-Ddocument.settings.jakarta.nosql.password=$MONGO_PASSWORD \
42
-Ddocument.settings.mongodb.authentication.source=$MONGO_DATABASE \
43
target/heroes-microbundle.jar --port $PORT
Приложение готово, поэтому пришло время переместить его в облако с помощью Platform.sh, выполнив следующие действия :
- Создайте новый бесплатный пробный аккаунт .
- Зарегистрируйтесь с новым именем пользователя и паролем или войдите в систему, используя текущую учетную запись GitHub, Bitbucket или Google. Если вы используете стороннюю учетную запись, вы сможете установить пароль для своей учетной записи Platform.sh позже.
- Выберите регион мира, в котором должен жить ваш сайт.
- Выберите пустой шаблон.
После этого мастера Platform.sh предоставит вам всю инфраструктуру и предложит вашему проекту удаленный Git-репозиторий. Инфраструктура Platform.sh, основанная на Git, означает, что она будет автоматически управлять всем, что нужно вашему приложению, чтобы отправить его в главный удаленный репозиторий. После настройки ключей SSH вам нужно только написать свой код, включая несколько файлов YAML, в которых указана желаемая инфраструктура, а затем передать его в Git и нажать.
Оболочка
xxxxxxxxxx
1
git remote add platform <p>
2
git commit -m "Initial project"
3
git push -u platform master
4
В этой статье мы поговорили о принципах и лучших практиках, связанных с облачной средой , которая все еще нуждается в улучшении, когда мы говорим о новой методике разработки программного обеспечения. Облако облегчает разработку программного обеспечения, и мы можем видеть приложение, работающее довольно просто через Platform.sh и интегрированное с Jakarta EE. В общем, это отличное время (счастливого нового года!), Чтобы перенести ваш проект в зрелое облачное PaaS, такое как Platform.s.