MicroProfile mikroskop altında, Bölüm 1: API Yapılandırması
Eclipse MicroProfile projesi, Enterprise Java ortamındaki mikro hizmetler için taşınabilir bir çözüm sağlamaya başladı. Yeni API’ler, Java EE standardı ile mikro hizmet mimarilerinin pratik gereksinimleri arasındaki boşluğu kapatmayı amaçlıyor.
Mikro hizmetler ve Java EE (aka EE4J)? Bu gerçekten uymuyor! En azından Java Enterprise Standard tabanlı mikro hizmet uygulamalarının uygulanması söz konusu olduğunda ortak görüş budur. JAX-RS, CDI, JPA ve JSON-P ile Java EE, RESTful mikro hizmetleri uygulamak için gereken her şeyi sunar. JMS, WebSocket ve Server-Sent Events (Java EE 8’den beri) sayesinde mesajlara veya olaylara dayalı eşzamansız hizmetler bile yalnızca birkaç satır kodla uygulanabilir. Öyleyse sorun nedir?
Mikro hizmet uygulamaları genel olarak, her biri kendi süreçlerinde çalışan çok sayıda hizmetin birbiriyle etkileşime girerek büyük bir küme oluşturması ile karakterize edilir. Bu hizmetlerin de kapsayıcılarda paketlenmesi ve bulutta konuşlandırılması alışılmadık bir durum değildir. Sonuç olarak, oldukça dinamik ve yüksek oranda dağıtılmış bir sistemle uğraşıyoruz.
Bu nedenle asıl zorluk, tek bir hizmetin (teknik) mantığını uygulamakta olduğundan daha az, tüm hizmetlerin bir bütün olarak sorunsuz etkileşimini gerçekleştirmektir. Java EE’nin sorunu veya zayıflığı tam olarak burada yatmaktadır. Çünkü Java EE, bireysel yapıtlar, bu durumda hizmetler, içeride olacak şekilde tasarlanmıştır. bir Uygulama sunucuları, yapılandırma, izleme, günlük kaydı, güvenlik vb. gibi tam hizmetleri (kesişen endişeler) üstlenebilecek şekilde uygulanır. Sunucu gittiyse veya her biri kendi mikro hizmetini yöneten birden çok bağımsız sunucu örneği varsa, koordinasyon kontrol merkezi eksiktir.
Bir dizi uygulama sunucusu satıcısı tam olarak bu boşluğu fark etti ve 2016’da MicroProfile.io girişimini başlattı. Artık Eclipse Foundation’ın bir parçası olan girişim, Java Enterprise Standard ile mikro hizmetlere dayalı mimarilerin pratik gereksinimleri arasındaki boşluğu doldurmaya başladı. Kendi ifadelerine göre, Java EE topluluğunun mevcut ivmesini kaldıraç olarak kullanmak ve bunu mikro hizmetler topluluğunun gereksinimleriyle organik olarak entegre etmek istiyorlar. Plan işe yarıyor gibi görünüyor. Yalnızca birkaç ay içinde, mikro hizmetlerle ilgili bir dizi kullanışlı API’yi mevcut Java EE 7/8 API’leri ile birleştirmek ve bunları düzenli MicroProfile sürümlerinde yayınlamak mümkün oldu. Durum denetimi, ölçümler, hata toleransı, JWT yayılımı, yapılandırma, izleme veya açık API’ler olsun, MicroProfile doğru yanıtlara, yani API’lere sahip gibi görünüyor.
Bu blog gönderisi, MicroProfile’ın mikro hizmete özgü API’lerini tartışan küçük bir dizinin ilk bölümüdür. Dolayısıyla, Java EE spesifikasyonunun parçası olmayan API’ler. İlki, 1.2 sürümü yalnızca birkaç gün önce piyasaya sürülen Config API’dir.
Yapılandırma API’sinin temelleri
Uygulama mantığını ve yapılandırmayı ayırma fikri gerçekten yeni değil. Haricileştirilmiş bir yapılandırmanın yardımıyla uygulama veya hizmet harici olarak ilgili çalıştırma ortamına uyarlanabilir. Örneğin, yerel test ortamı test kaynak kodunda belirtilen ayarları kullanırken, container runtime ortamı buluttaki bir container içindeki bir üretim ortamında yapılandırma için gereken değerleri ayarlar.
Basit görünen şeyler, pratikte beklenmedik zorluklara yol açabilir. Bir uygulamanın veya hizmetin yapılandırmasına ilişkin bireysel değerler genellikle sistem özellikleri, ortam değişkenleri, dosyalar, veritabanları veya özel yapılandırma kaynakları gibi birkaç kaynaktan gelir. Değerlerin depolandığı biçim de genellikle tekdüze değildir ve genellikle uygulama veya hizmet içinde yapılandırma değerlerinin kullanılacağı nesnenin biçimiyle eşleşmez. Statik yapılandırma değerlerinin başlangıçta bir kez yüklenmesi yeterli olmakla birlikte, dinamik değerlerin sürekli olarak kontrol edilerek güncellenmeleri ve gerektiğinde yeniden okunmaları gerekir. Ve elbette bir uygulama, bir yapılandırma bulunamasa bile iyi çalışmalıdır.
MicroProfile Yapılandırma API’si (bundan böyle Yapılandırma API’si olarak anılacaktır), tüm bu hususları ve daha fazlasını dikkate alır. Çok çeşitli yapılandırma kaynaklarına birleşik erişim sunar. Konfigürasyonların hedefli bir şekilde üzerine yazılabilmesi için bireysel kaynaklara öncelikler atanabilir. Yapılandırma API’sı, varsayılan olarak üç farklı kaynağı tanır:
- üzerinden sistem özellikleri System.getProperties() (sıra = 400 )
- Ortam değişkenleri uzakta System.getenv() (sıra = 300)
- aracılığıyla yerel yapılandırma dosyası META-INF/microprofile-config.properties (sıra = 100)
Ve aksiyon…
Config API, arka planda yönetilen yapılandırmalara erişmek için iki farklı yol sunar. Erişim bir yandan programlı, diğer yandan CDI enjeksiyonu yoluyla olabilir.
Programatik erişim, en basit durumda üzerinden erişilebilen Config sınıfının bir örneği aracılığıyla gerçekleştirilir. Yapılandırma Sağlayıcı üretebilir:
// get access to the Config instance via ConfigProvider
Config config = ConfigProvider.getConfig();
// access config properties via Config instance
String someStringValue = config.getValue("SOME_STRING_KEY", String.class);
Boolean someBooleanValue = config.getValue("SOME_BOOL_KEY", Boolean.class);
Yapılandırma örneğini oluştururken daha fazla etkiye sahip olmak istiyorsanız, Yapılandırma Sağlayıcı kimse Yapılandırma Oluşturucu temyize gitmek Oluşturucu, bir veya diğer özelleştirmeye izin verir. Yukarıda gösterilen kod bir kullanır Yapılandırma Oluşturucu Şuna benziyor:
// get access to the Config instance via ConfigBuilder
ConfigBuilder builder = ConfigProviderResolver.getBuilder();
builder.addDefaultSources();
Config config = builder.build();
// access config properties via Config instance
String someStringValue = config.getValue("SOME_STRING_KEY", String.class);
Boolean someBooleanValue = config.getValue("SOME_BOOL_KEY", Boolean.class);
Not: kullanırken Yapılandırma Sağlayıcı aradığınızda olur getConfig()-Yöntem, verimlilik için döndürülen yapılandırma örneğini otomatik olarak önbelleğe alır. Bu, Yapılandırma Oluşturucu sırasıyla Yapılandırma Sağlayıcı Çözümleyici konu bu değil.
Yukarıda gösterilen programatik erişimden çok daha kolay olan, CDI enjeksiyonudur:
@Inject @ConfigProperty("SOME_STRING_KEY")
String someStringValue;
@Inject @ConfigProperty("SOME_BOOL_KEY")
String someBooleanValue;
Ancak, aradığınız anahtar yapılandırma kaynaklarının hiçbirinde bulunamazsa ne olur? Yukarıdaki örnekte, bu otomatik olarak bir istisnaya yol açacaktır. İlk örnek olan programatik erişimde, bu bir NoSuchElementException çalışma zamanında. İkinci örnekte, bunun yerine, CDI enjeksiyonu durumunda, bir Dağıtım İstisnası başlatma sırasında başlatıldı.
İsteğe bağlı yapılandırma
Bir yapılandırmanın yalnızca isteğe bağlı olması gerekiyorsa, örneğin varsayılan değerleri yalnızca özel ortamlarda geçersiz kılmak ve diğerlerinde değil, bu, gösterilen her iki erişim mekanizması için de mümkündür. Programatik erişim durumunda, şöyle görünür:
// get access to the Config instance
Config config = ConfigProvider.getConfig();
// access optional string property
String someStringValue = config.getOptionalValue("SOME_KEY", String.class)
.orElse("someDefaultValue");
Öte yandan, CDI enjeksiyonunda, doğru türde varsayılan bir değer belirlemeniz yeterlidir:
// inject optional property
@Inject @ConfigProperty("SOME_KEY", defaultValue="someDefaultValue")
String someValue;
Tam zamanında yapılandırma
Mikro hizmet tabanlı uygulamalar, tek bir hizmetin yeniden başlatılmasından kolayca kurtulacak şekilde tasarlanmalıdır, ancak bir yapılandırma değeri değişti diye bir hizmeti her seferinde yeniden başlatmak kesinlikle mantıklı değildir. Bu nedenle Config API, konfigürasyon değerlerini kullanıldıkça dinamik olarak yüklemek için bir mekanizma sağlar.
Elbette, yapılandırma kaynağı WAR ile birlikte dağıtılan bir özellikler dosyasıysa bu çok az anlam ifade eder. Kaynak olarak bir veritabanı veya yapılandırma sunucusu bağlıysa durum farklıdır.
Enjeksiyon zamanındaki değeri değil, bir özelliğin kullanıldığı anda her zaman geçerli değerini almak için, ConfigProperty yerine bir sağlayıcı enjekte etmeniz gerekir. Tedarikçinin ve onun yardımıyla almak()yöntemiyle tam zamanında bir yapılandırma gerçekleşebilir.
// inject property provider
@Inject @ConfigProperty("SOME_KEY")
Provider<String> someValueProvider;
...
// get property value "just-in-time" via provider
String someValue = someValueProvider.get();
Ancak bu durumda, “tam zamanında” terimi göreceli terimlerle anlaşılmalıdır ve basitçe konfigürasyon kaynağında o anda saklanan değerin kullanıldığı anlamına gelir. Kaynak sırayla değerleri nasıl günceller ve yenilendiğinde belirtilmez ve dolayısıyla yazar Yapılandırma Kaynağı– sınıfı terk et. Örneğin, OpenLiberty uygulaması, bir sistem özelliği aracılığıyla bir güncelleme sıklığı belirtmenize izin verir. microprofile.config.refresh.rate yapılandırma kaynakları için. Varsayılan değer 500’dür (ms), dolayısıyla gerekirse yenileme her yarım saniyede bir yapılır.
dönüştürücü
İlk örnekte gösterildiği gibi, Config API yalnızca tür özelliklerini desteklemez sırım. Sözde dönüştürücüler sayesinde, yapılandırma kaynaklarında depolanan dize değerleri herhangi bir Java türüne dönüştürülebilir.
Bazı Java türleri için yerleşik dönüştürücüler zaten mevcuttur. Şimdiye kadar gösterilen türlere ek olarak sırım Ve mantıksal ayrıca olacak bu arada bütün sayı, Uzun, çiftler, yüzer nasıl süre, Yerel zaman, yerel tarih, LocalDateTime, hemen Ve URL’ler kutunun dışında desteklenir. Ve dizilerin kullanımı sürüm 1.2’den beri de mümkündür:
// injection list property via array converter
@Inject @ConfigProperty("SOME_LIST_KEY")
private List<String> someListValues;
...
// get access to the Config instance via ConfigProvider
Config config = ConfigProvider.getConfig();
// access config properties via Config instance
private String[] someArrayValues =
config.getValue("SOME_ARRAY_KEY", String[].class);
Ancak, yapılandırma API’sı aracılığıyla desteklenmeyen veya özel veri türlerinin ayarlanması gerekiyorsa ne olur? Bu durumda, belirli bir özel dönüştürücü dönüştürücü-Uygulanan arayüzü kullanın. Aşağıdaki örnek, adlandırılmış bir sınıf için basit bir dönüştürücüyü gösterir. e-posta:
@Priority(200)
public class EmailConverter implements Converter<Email> {
@Override
public Email convert(String email) throws IllegalArgumentException {
return new Email(email);
}
}
Dönüştürücünün çalışma zamanında otomatik olarak kullanılabilmesi için ayrıca kaydedilmesi gerekir. Bu, karşılık gelen bir dosyada dönüştürücü sınıfının tam adını belirterek Java ServiceLocator aracılığıyla yapılabilir. META-INF/services/org.Eclipse.microprofile.config.spi.Converter – olur veya alternatif olarak programlı olarak Yapılandırma Oluşturucu:
// get access to the Config instance via ConfigBuilder
ConfigBuilder builder = ConfigProviderResolver.getBuilder();
builder.addDefaultSources();
// add custom converter for Email class
Converter<Email> emailConverter = new EmailConverter();
builder.withConverters(emailConverter);
Config config = builder.build();
// read email property into email object
Optional<Email> emailOpt = config.getOptionalValue("ADMIN_EMAIL",
Email.class);
...
listesi gibi E-posta dönüştürücü gösterir, dönüştürücüler de önceliklendirilebilir. Aynı tür için birkaç dönüştürücü kaydedilmişse, daha yüksek öncelikli dönüştürücü, daha düşük öncelikli olanları geçersiz kılar. Varsayılan 100’dür.
Çözüm
Sonuç olarak, Config API’si çok yönlü bir izlenim bırakıyor ve API’nin kökenine daha yakından bakarsanız bu gerçekten şaşırtıcı değil:
API’yi denemek için küçük bir arzunuz varsa, bunu aşağıdaki uygulamalarla yapabilirsiniz:
Gelecek için daha fazla özellik planlanıyor. Temel hedef, dinamik yapılandırma değişikliklerini daha iyi desteklemek olacaktır. Meraklı olabilirsin.
()
Haberin Sonu