ön plan
Monolitik bir platformdan daha Hizmet Odaklı Bir Mimariye geçiyoruz. Çok temel DDD ilkelerini uyguluyoruz ve alanımızı farklı sınırlı bağlamlara ayırıyoruz. Her alan adı dağıtılır ve bir web API (REST) aracılığıyla bir hizmet sunar.
İşimizin doğası gereği Rezervasyonlar , Hizmetler , Müşteriler , Ürünler vb.Gibi hizmetlerimiz var .
Ayrıca, asıl rolü aşağıdakileri yapmak için bir Kimlik Sunucusu (Thinktecture Identity Server 3 tabanlı) kurduk:
- Kimlik doğrulamayı merkezileştirin (belirteç verdiği kimlik bilgileri verildiğinde)
- Jetonlara talepleri ekleyin: müşterinin kapsamları (müşteriye göre talebi yapan uygulamayı kastediyorum), müşteri tanımlayıcısı (müşteriye göre uygulamayı kullanan kişiyi kastediyorum)
Ayrıca , hizmetlerimize harici erişimi merkezileştiren bir API Ağ Geçidi rolünü tanıttık . API Ağ Geçidi, aşağıdakiler gibi dahili alanlarla ilgili derin bilgi gerektirmeyen işlevler sağlar:
- Ters proxy: gelen istekleri uygun dahili hizmete yönlendirir
- Sürüm oluşturma: API Ağ Geçidi'nin bir sürümü, dahili hizmetlerin farklı sürümleriyle eşleşir
- Kimlik doğrulama: istemci istekleri arasında Kimlik Sunucusu tarafından verilen belirteç bulunur ve API Ağ Geçidi belirteci doğrular (kullanıcının söylediği kişi olduğundan emin olun)
- Kısma: istemci başına istek sayısını sınırlayın
yetki
Yetkilendirmeyle ilgili olarak, bu API Ağ Geçidi'nde değil, dahili hizmetlerin kendisinde yönetilir. Şu anda 2 ana tür yetkilendirme yapıyoruz:
- İstemci kapsamlarına dayalı yetkilendirme. Örnek: bir istemci (API'larımızı tüketen harici uygulama), Rezervasyonlar hizmet API'sı uç noktalarına erişmek için "rezervasyonlar" kapsamını gerektirir
- Müşteriye göre yetkilendirme. Örnek: Bir müşteri (uygulamasını kullanarak fiziksel kişi) uç nokta GET erişebileceği bir rezervasyon katılımcılarından yalnızca / dan rezervasyon Rezervasyonları hizmeti
Dahili hizmetlerde yetkilendirmeyi yapabilmek için, API Ağ Geçidi hem istemciyi (isteği yapan uygulama) hem de müşteriyi talep olarak (içinde) içeren jetonu (isteği dahili hizmete yönlendirirken) yönlendirir. bir kişinin istemci uygulamasında oturum açtığı durumlar).
Sorun Açıklaması
Hizmetlerarası iletişimi tanıtana kadar şu ana kadar iyi (bazı hizmetler veri elde etmek için diğer hizmetlerle iletişim kurabilir).
Soru
Hizmetler arası iletişimde yetkilendirmeye nasıl yaklaşmalıyız?
Dikkate alınan seçenekler
Farklı seçenekleri tartışmak için aşağıdaki örnek senaryoyu kullanacağım:
- API'mize erişen ExternalApp adlı harici bir uygulamamız var ( ExternalApp istemci olarak görülebilir)Rezervasyon akışını oluşturmak için )
- ExternalApp'ın Rezervasyonlar hizmetine erişmesi gerekiyor , bu nedenle ExternalApp'a "rezervasyonlar" kapsamını
- Dahili olarak (bu ExternalApp için tamamen şeffaf bir şeydir ) Rezervasyon hizmeti, Servisler servisine, uçuşlar, sigortalar veya araç kiralama gibi bir rezervasyonun varsayılan hizmetlerini almak için erişir
Bu sorunu dahili olarak tartışırken birkaç seçenek ortaya çıktı, ancak hangi seçeneğin en iyi olduğundan emin değiliz:
- Ne zaman Rezervasyonları ile iletişim hizmetleri , basitçe ileri o API Geçidi alınan belirteç orijinal olmalıdır (istemci olduğunu belirten ExternalApp )
- Çıkarımlar: ExternalApp'a verilmemesi gereken kapsamlar vermemiz gerekebilir . Örnek: ExternalApp'ın hem "rezervasyonlar" hem de "hizmetler" kapsamına sahip olması gerekebilir, ancak yalnızca "rezervasyonlar" kapsamı yeterli olabilir
- Tüm Sarı ile iletişim hizmetleri , bu ileriye doğru bir belirteç artık haline müşteri gösteren Sarı (yerine ExternalApp ) + o gösteren bir talebi ekler Ayırtabilirsiniz orijinal istemciyi temsil edilir ExternalApp
- Ayrıca, orijinal istemci olduğu bilgileri ekleyerek ExternalApp Hizmetleri hizmeti de böyle orijinal arayan bağlı bazı hizmetleri filtreleyerek mantığı yapabileceğini (örneğin, iç uygulamalar için sadece bazı dış uygulamalar için, bütün kavgalar dönmelidir)
- Hizmetler birbirleriyle iletişim kurmamalıdır (bu nedenle bu soru ile karşı karşıya kalmamalıyız)
Girişiniz için şimdiden teşekkür ederiz.