Lunex’te tasarım yaptığınız çalışma alanı ile entegrasyon mesajlarını işleyen runtime farklı sorumluluklar taşır. Bu ayrım; proje planlamasını, CPU/RAM ayarlarını, erişim kararlarını ve sorun gidermeyi doğrudan etkiler.
Projenin içindeki grafiği ve düğmeleri öğrenmek için Architecture ekranı, Git’teki bir sürümün nasıl çalışır hâle geldiği için geliştirmeden üretime rehberini açın.
Platformun parçaları
| Parça | Sorumluluk |
|---|---|
| Lunex çalışma alanı | Projeleri, dosyaları, API tasarımını ve çalışma/izleme işlemlerini yönetir. Tarayıcıdan kullanılır. |
| Git deposu | Commit edilmiş kaynakları ve dağıtım ayarlarını sürümler. Çalışma alanında kaydedilmiş bir taslak henüz Git’te olmayabilir. |
| Derleme işi (builder) | Kaynağı Git’ten alır, çalıştırılabilir imajı üretir ve yapılandırılan build betiğini yürütür. Varsayılan Kubernetes betiği dağıtımı da uygular. |
| İmaj deposu (registry) | Üretilen container imajlarını etiketleriyle saklar. |
| Proje runtime’ı | Projedeki route’ları, bean’leri ve bağlantıları çalıştırır. Geliştirme runtime’ı ile paketlenmiş uygulama farklı yaşam döngülerine sahiptir. |
| API giriş katmanı | Yayınlanan HTTP/HTTPS yollarını ilgili projeye yönlendirir ve seçilen API erişim politikasını uygular. |
| Kimlik servisi | Kullanıcı girişini ve platform rollerini sağlar. Kurumsal kimlik sağlayıcısıyla bağlantı burada kurulur. |
| İzleme deposu | Mesaj ve çalıştırma metadata’sını; izin verilen kayıt seviyesinde geçmiş ve içerik kanıtlarını saklar. |
| Artemis | Kullanılan entegrasyonlarda mesajları kuyrukta tutar ve tüketicilere teslim eder. Her route’un broker kullanması gerekmez. |
Proje neyi bir araya getirir?
Proje, birlikte geliştirdiğiniz ve dağıttığınız bir entegrasyonun dosyalarını kapsar. Bir projede birden fazla route, API operation’ı, yardımcı Java sınıfı, Kamelet ve kaynak dosyası bulunabilir. Projenin runtime’ında bu route’lar aynı uygulama sürecinin kaynaklarını paylaşır.
Örneğin sipariş API’si ve siparişi işleyen route aynı projede olabilir. Bağımsız ölçeklemek veya dağıtmak istediğiniz bir raporlama entegrasyonunu ayrı projeye koyabilirsiniz. Proje ayırmak, dış sistemlerdeki veri erişim yetkilerini kendiliğinden ayırmaz.
İzolasyon nerede başlar, nerede biter?
| Sınır | Anlamı | Tasarımınız için sonuç |
|---|---|---|
| Route | Mesaj işleme akışıdır. Aynı projedeki route’lar ortak runtime’da çalışır. | Bir route için bağımsız CPU/RAM bütçesi verilmez. |
| Proje runtime’ı | Ayrı çalışan container/pod uygulamasıdır. | Ayrı dağıtım ve kaynak bütçesi oluşturabilirsiniz. |
| Çalışma alanı | Projelerin ve platform rollerinin ortak yönetildiği alandır. | Proje adına dayanarak kullanıcıya özel tenant izolasyonu varsaymayın. Roller çalışma alanı genelindedir. |
| Kubernetes namespace | Kurulumun kaynaklarının yerleştirildiği altyapı kapsamıdır. | Proje oluşturmak otomatik olarak ayrı namespace, ağ politikası veya müşteri güvenlik alanı oluşturmaz. |
| Dış sistem hesabı | Veritabanı, API veya broker erişimini belirler. | İzinleri dış sistemin hesabı, Secret’ı ve ağ politikasıyla sınırlandırın. |
| Kuyruk | Broker içindeki ayrı mesaj birikimidir. | Queue adı tek başına erişim sınırı değildir; broker yetkileri ayrıca tanımlanır. |
Farklı müşterilerin veya güvenlik alanlarının kesin ayrılması gerekiyorsa çalışma alanı, namespace, kimlik, Secret, Git, broker ve veri saklama gereksinimlerini platform yöneticinizle birlikte belirleyin. Kimlik ve yetkiler, kurulum ve kaynaklar bu kararın uygulama adımlarını açıklar.
Bir API çağrısı nasıl ilerler?
- Çağıran sistem, yayın adresine HTTP/HTTPS isteği gönderir.
- API giriş katmanı, seçilen erişim politikasını uygulayıp isteği projenin etkin runtime’ına yönlendirir.
- OpenAPI sözleşmesindeki operation,
operationIdile eşleşendirect:route’una bağlanır. - Route mesajı doğrular, dönüştürür ve hedef sisteme veya kuyruğa iletir.
- Sonuç HTTP yanıtı olarak döner. Mesajın izleme kaydı, uygulanan kayıt ve saklama politikasına göre tutulur.
Tasarım ekranındaki Mock testi çalışan route’u çağırmaz. Running project testi geliştirme runtime’ını çağırır; yayın adresinin güvenlik politikasını ayrıca dış URL üzerinden doğrulayın. Ayrıntılar yayınlama ve test sayfasındadır.
Mesajlaşma nasıl farklılaşır?
Senkron çağrıda gönderen, işlenen isteğin yanıtını bekler. Kuyruk kullanımında mesaj broker’a teslim edilir; bir tüketici uygun olduğunda alır. Bu, geçici hedef kesintileri ve hız farkları için bekleme alanı sağlar. Başarı ölçütünüzü açık seçin: “kuyruğa kabul edildi” ile “hedef sistemde işlem tamamlandı” farklı sonuçlardır.
Aynı runtime içindeki direct: çağrısı veya seda: belleği, dayanıklı bir broker kuyruğuyla aynı değildir. Kalıcı teslimat gereksiniminiz varsa mesajlaşma ve hata yönetimi rehberlerini birlikte okuyun.
Hangi kaynak nerede kalır?
| Veri | Sahibi ve yaşam döngüsü |
|---|---|
| Kaydedilmiş çalışma dosyası | Lunex çalışma alanı; kaydetme durumunu editörde doğrulayın. |
| Commit edilmiş kaynak | Git; Build bu sürümlenmiş kaynağı kullanır. |
| Çalıştırılabilir paket | Registry’deki container imajı ve dağıtım tanımları. |
| Bekleyen iş mesajı | Kullanılıyorsa broker; proje kaynak dosyası değildir. |
| İşlenmiş mesajın kanıtı | İzleme deposu; kayıt seviyesi ve saklama süresiyle sınırlıdır. |
| Parola ve erişim anahtarı | Ortamın Secret/kimlik yönetimi; örnek route veya Git dosyasına düz metin yazılmamalıdır. |
Projeyi dışa aktarmak, kuyruk mesajlarını veya izleme geçmişini yedeklemek anlamına gelmez. İşletim planınız Git’i, uygulama verisini, broker verisini ve kimlik/yapılandırmayı ayrı sorumluluklar olarak ele almalıdır.