W pracy mamy dużą aplikację wewnętrzną, która jest rozwijana od prawie 2 lat; Niedawno dołączyłem do projektu i trochę architektury mnie nieco zakłopotało, więc mam nadzieję, że ktoś tu udzieli porady, zanim pójdę zadać architektom te same pytania (dzięki czemu mogę z nimi przeprowadzić świadomą dyskusję) ).
Przepraszam, jeśli poniżej jest trochę za długo, po prostu chcę namalować dobry obraz tego, czym jest system, zanim zadam moje pytanie :)
System jest skonfigurowany w taki sposób, że mamy jedną główną aplikację internetową (asp.net, AngularJS), która głównie gromadzi dane z różnych innych usług. Zasadniczo jest to host aplikacji AngularJS; istnieje dosłownie jeden kontroler MVC, który ładuje się po stronie klienta, a następnie każdy inny kontroler jest kontrolerem WebAPI.
Połączenia ze strony klienta są obsługiwane przez te kontrolery, które są zawsze wdrażane w skrzynkach, które nie wykonują nic poza hostowaniem aplikacji sieci Web. Obecnie mamy 4 takie skrzynki.
Jednak połączenia są następnie przekierowywane do jeszcze jednego zestawu aplikacji WebAPI (zazwyczaj są to obszary biznesowe, takie jak bezpieczeństwo, dane klientów, dane produktów itp.). Wszystkie te WebAPI są również wdrażane razem w dedykowanych urządzeniach; mamy również 4 z tych pól.
Z jednym wyjątkiem te interfejsy WebAPI nie są używane przez żadne inne części naszej organizacji.
Wreszcie te WebAPI wykonują kolejny zestaw wywołań do usług „zaplecza”, które są zwykle starszymi usługami asmx lub wcf umieszczanymi na różnych systemach ERP i magazynach danych (nad którymi nie mamy kontroli).
Większość logiki biznesowej naszej aplikacji znajduje się w tych WebApis, takich jak przekształcanie starszych danych, agregowanie ich, wykonywanie reguł biznesowych, zwykły rodzaj rzeczy.
To, co mnie pomyliło, to jaka jest potencjalna korzyść z takiego oddzielenia aplikacji sieci Web od obsługujących ją interfejsów WebAPI. Ponieważ nikt inny ich nie używa, nie widzę żadnej korzyści ze skalowalności (tj. Nie ma sensu umieszczać kolejnych 4 skrzynek API do obsługi zwiększonego obciążenia, ponieważ zwiększone obciążenie serwerów API musi oznaczać zwiększone obciążenie serwerów WWW - dlatego musi istnieć stosunek 1: 1 serwera WWW do serwera Api)
Nie widzę też żadnej korzyści z konieczności wykonywania dodatkowego połączenia HTTP. Przeglądarka => HTTP => WebApp => HTTP => WebAPI => HTTP => Usługi zaplecza. (moim problemem jest połączenie HTTP między WebApp a WebAPI)
Tak więc obecnie staram się przenieść obecne interfejsy WebAPI z oddzielnych rozwiązań, do oddzielnych projektów w ramach rozwiązania WebApplication, z prostymi odniesieniami do projektów pomiędzy nimi i jednym modelem wdrażania. Więc ostatecznie staną się bibliotekami klas.
Jeśli chodzi o wdrażanie, oznacza to, że mielibyśmy 8 „pełnych stosów” skrzynek internetowych, w przeciwieństwie do 4 + 4.
Korzyści, jakie widzę z nowego podejścia, to
- Wzrost wydajności, ponieważ istnieje jeden mniejszy cykl serializacji / deserializacji między aplikacją sieci Web a serwerami WebAPI
- Mnóstwo kodu, który można usunąć (tj. Nie trzeba utrzymywać / testować) pod względem DTO i maperów na wychodzących i przychodzących granicach odpowiednio aplikacji sieci Web i serwerów WebApi.
- Lepsza zdolność do tworzenia znaczących automatycznych testów integracji, ponieważ mogę po prostu kpić z usług zaplecza i unikać bałaganu wokół skoków HTTP w środkowej warstwie.
Pytanie brzmi: czy się mylę? Czy przegapiłem podstawową „magię” oddzielenia skrzynek WebApplication i WebAPI?
Przeszukałem niektóre materiały architektury N-Tier, ale nie mogę znaleźć w nich niczego, co mogłoby dać konkretną korzyść dla naszej sytuacji (ponieważ skalowalność nie jest problemem, o ile wiem, a jest to aplikacja wewnętrzna, więc bezpieczeństwo w zakresie aplikacji WebAPI nie stanowi problemu).
A także, co straciłbym pod względem korzyści, gdybym przeorganizował system do proponowanej konfiguracji?
źródło
Odpowiedzi:
Jednym z powodów jest bezpieczeństwo - jeśli (haha! Kiedy ) haker uzyska dostęp do twojego serwera front-end, uzyska dostęp do wszystkiego, do czego ma dostęp. Jeśli umieściłeś swoją środkową warstwę na serwerze internetowym, ma on dostęp do wszystkiego, co ma - tj. Do Twojej bazy danych, a następnie wiesz, że po prostu uruchomił „wybierz * od użytkowników” na swojej bazie danych i zabrał ją z trybu offline łamanie hasła.
Innym powodem jest skalowanie - warstwa internetowa, w której strony są konstruowane, zniekształcane i przetwarzane XML, a wszystko to zajmuje znacznie więcej zasobów niż warstwa środkowa, która często jest wydajną metodą przenoszenia danych z bazy danych do warstwy internetowej. Nie wspominając o przesyłaniu wszystkich danych statycznych, które znajdują się (lub są buforowane) na serwerze WWW. Dodanie większej liczby serwerów WWW jest prostym zadaniem po przejściu 1. Nie powinno być stosunku 1: 1 między poziomami sieci i logiki - wcześniej widziałem 8: 1 (i stosunek 4: 1 między logiką poziom i DB). Zależy to jednak od tego, co robią Twoje poziomy i ile buforowania się w nich dzieje.
Strony internetowe tak naprawdę nie dbają o wydajność pojedynczego użytkownika, ponieważ są zbudowane z myślą o skalowaniu, nie ma znaczenia, że istnieje dodatkowe połączenie, które nieco spowalnia, jeśli oznacza to, że możesz obsłużyć więcej użytkowników.
Innym powodem, dla którego warto mieć te warstwy, jest wymuszenie większej dyscypliny podczas opracowywania interfejsu API (i łatwego testowania, ponieważ jest samodzielny), a następnie interfejsu użytkownika opracowanego w celu jego wykorzystania. Pracowałem w miejscu, które to zrobiło - różne zespoły opracowały różne warstwy i działało to dobrze, ponieważ mieli specjalistów dla każdego poziomu, którzy potrafili szybko wprowadzać zmiany, ponieważ nie musieli się martwić o inne poziomy - tj. może dodać nową sekcję do witryny, po prostu konsumując nową usługę internetową opracowaną przez kogoś innego.
źródło
Myślę, że nie ma tutaj dobrej / złej odpowiedzi. Czy zapytałeś swoich kolegów o cel tej architektury?
Z tego, jak rozumiem twoje opisy, „ WebAPI ” w twojej architekturze służy jako swego rodzaju oprogramowanie pośrednie. Teraz możesz zbadać, jakie korzyści ma zastosowanie oprogramowania pośredniego. Zasadniczo Twoja aplikacja internetowa nigdy nie będzie musiała zostać adoptowana, jeśli zmienisz system backoffice (o ile interfejs WebAPI pozostanie taki sam).
Aby przejść dalej: Wyobraź sobie, że masz bazę danych klientów (usługa zaplecza) i masz 5 aplikacji internetowych komunikujących się z tą bazą danych. Jeśli zastąpisz system bazy danych klientów nowym systemem (np. Od innego dostawcy i nie możesz wpływać na interfejsy usługi sieciowej), najprawdopodobniej będziesz musiał zmienić warstwę komunikacyjną wszystkich 5 aplikacji internetowych. Jeśli komunikujesz się za pośrednictwem interfejsu WebAPI , wystarczy zmienić warstwę komunikacyjną interfejsu WebAPI .
Zasadniczo architektura warstw jest obecnie uważana zarówno za: wzorzec, jak i anty-wzorek. (Patrz: kod Lasagna ) Jeśli masz tylko 1 system bez planów dalszego rozszerzania go w ciągu najbliższych kilku lat, wolałbym uznać to za anty-wzór. Ale to nie będzie nierealistyczny sędzia, ponieważ nie znam dokładnych okoliczności / sytuacji :)
źródło