Trong công việc, chúng tôi có một ứng dụng nội bộ lớn đã được phát triển gần 2 năm nay; Tôi mới tham gia dự án và một số kiến trúc khiến tôi hơi bối rối, vì vậy tôi hy vọng ai đó ở đây có thể cung cấp một số lời khuyên trước khi tôi ra ngoài để hỏi các kiến trúc sư những câu hỏi tương tự (vì vậy tôi có thể thảo luận với họ ).
Tôi xin lỗi nếu phần dưới đây hơi dài, tôi chỉ muốn thử vẽ một bức tranh đẹp về hệ thống là gì trước khi tôi đặt câu hỏi của mình :)
Cách hệ thống được thiết lập là chúng tôi có một ứng dụng web chính (asp.net, AngularJS), chủ yếu chỉ tổng hợp dữ liệu từ nhiều dịch vụ khác. Vì vậy, về cơ bản nó là một máy chủ cho một ứng dụng AngularJS; đúng là có một bộ điều khiển MVC khởi động phía máy khách, và sau đó mọi bộ điều khiển khác là bộ điều khiển WebAPI.
Các cuộc gọi từ phía máy khách được xử lý bởi các bộ điều khiển này, chúng luôn được triển khai đến các hộp không làm gì khác ngoài việc lưu trữ Ứng dụng Web. Chúng tôi hiện có 4 hộp như vậy.
Tuy nhiên, các cuộc gọi sau đó cuối cùng được chuyển qua một bộ ứng dụng WebAPI khác (thường là các khu vực kinh doanh, như bảo mật, dữ liệu khách hàng, dữ liệu sản phẩm, v.v.). Tất cả các WebAPI này cũng được triển khai cùng với các hộp chuyên dụng; chúng tôi cũng có 4 hộp này
Với một ngoại lệ duy nhất, các WebAPI này không được sử dụng bởi bất kỳ bộ phận nào khác trong tổ chức của chúng tôi.
Cuối cùng, các WebAPI này thực hiện một nhóm các cuộc gọi khác đến các dịch vụ "back end", thường là các dịch vụ asmx hoặc wcf kế thừa được đặt trên các hệ thống ERP và kho lưu trữ dữ liệu khác nhau (mà chúng tôi không kiểm soát được).
Hầu hết logic kinh doanh của ứng dụng của chúng tôi nằm trong các WebApis này, chẳng hạn như chuyển đổi dữ liệu kế thừa, tổng hợp nó, thực thi các quy tắc kinh doanh, loại điều thông thường.
Điều khiến tôi bối rối là lợi ích có thể có là gì khi có sự tách biệt như vậy giữa Ứng dụng web và WebAPI phục vụ nó. Vì không ai khác đang sử dụng chúng, tôi không thấy bất kỳ lợi ích về khả năng mở rộng nào (nghĩa là không có việc đưa vào 4 hộp API khác để xử lý tải tăng, vì tải tăng lên trên các máy chủ API phải có nghĩa là có tải tăng trên máy chủ Web - do đó phải có tỷ lệ 1: 1 của máy chủ Web so với máy chủ Api)
Tôi cũng không thấy bất kỳ lợi ích nào khi phải thực hiện thêm một cuộc gọi HTTP Trình duyệt => HTTP => WebApp => HTTP => WebAPI => HTTP => Dịch vụ cuối cùng. (cuộc gọi HTTP giữa WebApp và WebAPI là vấn đề của tôi)
Vì vậy, tôi hiện đang tìm cách thúc đẩy để các WebAPI hiện tại được chuyển từ các giải pháp riêng biệt, sang chỉ các dự án riêng biệt trong giải pháp WebApplication, với các tham chiếu dự án đơn giản ở giữa và một mô hình triển khai duy nhất. Vì vậy, cuối cùng họ sẽ trở thành thư viện lớp.
Triển khai khôn ngoan, điều này có nghĩa là chúng tôi sẽ có 8 hộp web "đầy đủ", trái ngược với 4 + 4.
Những lợi ích tôi thấy của phương pháp mới là
- Tăng hiệu suất vì có ít hơn một chu kỳ tuần tự hóa / giải tuần tự giữa ứng dụng Web và máy chủ WebAPI
- Hàng tấn mã có thể bị xóa (nghĩa là không cần phải duy trì / kiểm tra) về mặt DTO và trình ánh xạ tại các ranh giới đi và đến của các máy chủ Ứng dụng Web và WebApi tương ứng.
- Khả năng tốt hơn để tạo các Thử nghiệm tích hợp tự động có ý nghĩa, bởi vì tôi có thể đơn giản chế giễu các dịch vụ back-end và tránh sự lộn xộn xung quanh các bước nhảy HTTP trung cấp.
Vì vậy, câu hỏi là: tôi sai? Tôi đã bỏ lỡ một số "ma thuật" cơ bản của việc tách các hộp WebApplication và WebAPI chưa?
Tôi đã nghiên cứu một số tài liệu kiến trúc N-Tier nhưng dường như không thể tìm thấy bất cứ thứ gì trong chúng có thể mang lại lợi ích cụ thể cho tình huống của chúng tôi (vì khả năng mở rộng không phải là vấn đề theo như tôi có thể nói, và đây là một ứng dụng nội bộ bảo mật về các ứng dụng WebAPI không phải là vấn đề.)
Ngoài ra, tôi sẽ mất gì về mặt lợi ích nếu tôi tổ chức lại hệ thống theo thiết lập đề xuất của mình?