Web uygulaması için ayrı API ve UI sunucuları kullanmanın avantajları

İşte, 2 yıla yakın bir süredir geliştirme aşamasında olan büyük bir şirket içi uygulamamız var; Kısa bir süre önce projeye katıldım ve mimariden bazıları beni biraz şaşırttı, bu yüzden mimarlardan birine aynı soruları sormadan önce birisinin tavsiyelerde bulunabileceğini umuyorum (böylece onlarla bilinçli bir tartışma yapabilirim) ).

Benim özür dilerim aşağıda biraz uzunsa, sadece soruyu sormadan önce sistemin ne olduğunu iyi bir resim çizmek istiyorum :)

• Sistemin kurulum şekli, çoğunlukla diğer çeşitli hizmetlerden veri toplayan bir ana web uygulamamız (asp.net, AngularJS) olmasıdır. Temelde bir AngularJS uygulaması için bir ana bilgisayar; kelimenin tam anlamıyla istemci tarafını önyükleyen bir MVC denetleyicisi vardır ve daha sonra diğer her denetleyici bir WebAPI denetleyicisidir.

• İstemci tarafından yapılan çağrılar, her zaman Web Uygulamasını barındıran hiçbir şey yapmayan kutulara dağıtılan bu denetleyiciler tarafından gerçekleştirilir. Şu anda böyle 4 kutumuz var.

• Bununla birlikte, aramalar sonuçta başka bir WebAPI uygulaması grubuna yönlendirilir (genellikle bunlar güvenlik, müşteri verileri, ürün verileri vb. Gibi iş alanları başına yapılır). Bu WebAPI'lerin tümü, özel kutulara da dağıtılır; Ayrıca bu kutulardan 4 tane var.

• Tek bir istisna dışında, bu WebAPI'ler kuruluşumuzun başka hiçbir bölümü tarafından kullanılmaz.

• Son olarak, bu WebAPI'ler, tipik olarak eski ERMX veya WCF hizmetleri olan çeşitli ERP sistemleri ve Veri depolarının (üzerinde kontrolümüzün olmadığı) üzerine tokatlanan "arka uç" hizmetlerine bir başka çağrı yapar.

• Uygulamamızın iş mantığının çoğu, eski verilerin dönüştürülmesi, toplanması, iş kurallarının yürütülmesi, olağan şey türü gibi bu WebApis'lerde bulunmaktadır.

Beni şaşırtan şey, WebApplication ve ona hizmet eden WebAPI'ler arasında böyle bir ayrımın olması olası ne yararıdır. Başka kimse bunları kullanmadığından, herhangi bir ölçeklenebilirlik avantajı görmüyorum (yani, artan yükü işlemek için başka bir 4 API kutusu koymanın bir anlamı yok, çünkü API sunucularındaki artan yük Web sunucularında artan yük olduğu anlamına gelmelidir - bu nedenle Web sunucusunun Api sunucusuna 1: 1 oranı olmalıdır)

• Ben de ekstra bir HTTP arama yapmak zorunda hiçbir fayda görmüyorum Tarayıcı => HTTP => WebApp => HTTP => WebAPI => HTTP => Arka uç hizmetleri. (WebApp ve WebAPI arasındaki HTTP çağrısı benim sorunum)

• Şu anda, mevcut WebAPI'lerin ayrı çözümlerden, WebApplication çözümündeki sadece ayrı projelere taşınması, aralarında basit proje referansları ve tek bir dağıtım modeli ile taşınması için uğraşmak istiyorum. Sonuçta onlar sadece sınıf kütüphaneleri olacaklardı.

• Dağıtım açısından bu, 4 + 4'ün aksine 8 "tam yığın" web kutularımız olacağı anlamına gelir.

Yeni yaklaşımdan gördüğüm faydalar

• Web uygulaması ve WebAPI sunucuları arasında daha az serileştirme / serileştirme döngüsü olduğundan performans artışı
• Web Uygulamasının ve WebApi sunucularının giden ve gelen sınırlarında sırasıyla DTO'lar ve eşleyiciler açısından silinebilen (yani sürdürmeye / test etmeye gerek yok) tonlarca kod.
• Anlamlı otomatikleştirilmiş Entegrasyon Testleri oluşturmak için daha iyi yetenek, çünkü basitçe arka uç hizmetleri ile alay edebilir ve orta düzey HTTP sıçramalarının etrafındaki dağınıklığı önleyebilirim.

Yani soru şu: yanlış mıyım? WebApplication ve WebAPI kutularını ayırmanın bazı temel "büyüsünü" kaçırdım mı?

Bazı N-Tier mimari malzemelerini araştırdım, ancak durumumuz için somut bir fayda sağlayabilecek hiçbir şey bulamıyorum (ölçeklenebilirlik anlatabildiğim kadarıyla bir sorun değil ve bu dahili bir uygulama) WebAPI uygulamaları açısından güvenlik bir sorun oluşturmaz.)

Ayrıca, sistemi önerilen kurulumumda yeniden organize edersem faydalar açısından ne kaybederdim?

Bunun bir nedeni güvenliktir - eğer bir bilgisayar korsanı ön uç web sunucunuza erişirse (haha! Ne zaman ) erişimi olan her şeye erişir. Orta katmanınızı web sunucusuna yerleştirdiyseniz, sahip olduğu her şeye erişebilir - yani DB'niz ve bildiğiniz bir sonraki şey, DB'nizde "kullanıcılardan * seç" seçeneğini çalıştırır ve çevrimdışı durumdan uzaklaştırır şifre kırma.

Başka bir neden ölçekleme - sayfaların oluşturulduğu ve yönetildiği ve XML'nin işlendiği web katmanı ve bunların tümü DB'den web katmanına veri almak için etkili bir yöntem olan orta katmandan çok daha fazla kaynak alır. Web sunucusunda bulunan (veya önbelleğe alınan) tüm statik verilerin aktarılmasından bahsetmiyorum bile. 1 geçtikten sonra daha fazla web sunucusu eklemek basit bir iştir. Web ve mantık katmanları arasında 1: 1 oran olmamalıdır - Daha önce 8: 1 gördüm (ve mantık arasında 4: 1 oran) katman ve DB). Ancak, katmanlarınızın ne yaptığına ve bunlarda ne kadar önbellekleme yaptığına bağlıdır.

Web siteleri, ölçeklendirmek üzere oluşturuldukları için tek kullanıcılı performansı gerçekten umursamazlar, daha fazla kullanıcıya hizmet verebileceğiniz anlamına gelirse, işleri biraz yavaşlatan ekstra bir çağrı olması önemli değildir.

Bu katmanlara sahip olmanın iyi olmasının bir başka nedeni, bir API'nin geliştirildiği (ve bağımsız olduğu gibi kolayca test edildiği) ve daha sonra kullanıcı arayüzünün onu tüketmek için geliştirdiği daha fazla disiplini zorlamasıdır. Bunu yapan bir yerde çalıştım - farklı ekipler farklı katmanlar geliştirdi ve her katman için değişiklikleri gerçekten hızlı bir şekilde körükleyebilecek uzmanları olduğu için iyi çalıştı, çünkü diğer katmanlar hakkında endişelenmeleri gerekmiyordu - yani bir UI javscript geliştiricisi başka birinin geliştirdiği yeni bir web hizmetini tüketerek siteye yeni bir bölüm ekleyebilir.

Bence burada doğru / yanlış cevap yok. Meslektaşlarınıza bu mimarinin amacı hakkında soru sordunuz mu?

Tanımlarınızı nasıl anladığımdan, Mimarinizdeki " WebAPI " kendi kendine yapılan Middleware olarak hizmet eder. Şimdi bir Middleware kullanımında ne gibi avantajlar olduğunu araştırabilirsiniz. Temel olarak, backoffice sisteminizi değiştirirseniz ( WebAPI arabirimi aynı kaldığı sürece) Web Uygulamanızın hiçbir zaman benimsenmesi gerekmez .

Daha ileriye gitmek için: Bir müşteri veritabanınız (arka uç servisi) ve bu veritabanıyla iletişim kuran 5 web uygulamanız olduğunu düşünün. Müşteri veritabanı sistemini yeni bir sistemle değiştirirseniz (başka bir satıcıdan olduğu gibi ve web hizmeti arayüzlerini etkileyemezseniz) büyük olasılıkla 5 web uygulamasının tüm iletişim katmanını değiştirmeniz gerekecektir. Eğer üzerinden iletişim halinde WebAPI , sadece iletişim katmanını değiştirmek zorunda kalacak WebAPI .

Temel olarak, Katman Mimarisi günümüzde hem Desen hem de Anti-Desen olarak kabul edilmektedir . (Bkz: Lazanya-Kodu ) Önümüzdeki birkaç yıl içinde bunu daha da genişletmeyi planlamayan sadece 1 sisteminiz varsa, bunu anti-desen olarak görmeyi tercih ederim. Ama bu durumu tam olarak bilmediğim için gerçekçi olmayan bir taff yargıcı olacak :)