Lợi ích của việc sử dụng các máy chủ API và UI riêng cho ứng dụng Web


16

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?


Nếu tất cả 8 hộp thực sự nằm trong tầm kiểm soát của bạn, tôi không thể nghĩ ra bất kỳ lý do chính đáng nào cho việc chia tách. Bạn có biết nếu họ có quyền sở hữu riêng trong quá khứ?
Ixrec

@Ixrec - có tất cả 8 hộp thuộc về tổ chức và ứng dụng chỉ là nội bộ 100%. Tôi nghi ngờ rằng sự tách biệt ban đầu được thiết kế một phần vì một nhóm nội bộ khác sở hữu cơ sở hạ tầng (rất nhiều chính trị) và một phần vì ai đó đã nói "N-Tier" và mọi người chỉ đi theo nó.
Stephen Byrne

Câu trả lời:


24

Một lý do là bảo mật - nếu (haha! Khi ) một hacker có quyền truy cập vào máy chủ web mặt trước của bạn, anh ta có quyền truy cập vào mọi thứ mà nó có quyền truy cập. Nếu bạn đã đặt tầng giữa của mình trong máy chủ web, thì anh ta có quyền truy cập vào mọi thứ mà nó có - tức là DB của bạn và điều tiếp theo bạn biết, anh ta chỉ cần chạy "select * from users" trên DB của mình và lấy nó ra khỏi ngoại tuyến bẻ khóa mật khẩu.

Một lý do khác là mở rộng - tầng web nơi các trang được xây dựng và xử lý và XML được xử lý và tất cả những thứ đó chiếm nhiều tài nguyên hơn tầng giữa thường là một phương pháp hiệu quả để lấy dữ liệu từ DB sang tầng web. Không đề cập đến việc chuyển tất cả dữ liệu tĩnh cư trú (hoặc được lưu trong bộ nhớ cache) trên máy chủ web. Thêm nhiều máy chủ web là một nhiệm vụ đơn giản khi bạn đã vượt qua 1. Không nên có tỷ lệ 1: 1 giữa các tầng logic và logic - Tôi đã thấy 8: 1 trước đây (và tỷ lệ 4: 1 giữa logic lớp và DB). Nó phụ thuộc vào những gì các tầng của bạn làm tuy nhiên và bao nhiêu bộ nhớ đệm diễn ra trong đó.

Các trang web không thực sự quan tâm đến hiệu suất của một người dùng khi chúng được xây dựng theo tỷ lệ, không có vấn đề gì khi có thêm một cuộc gọi làm chậm mọi thứ nếu điều đó có nghĩa là bạn có thể phục vụ nhiều người dùng hơn.

Một lý do khác có thể có các lớp này là tốt vì nó buộc phải có kỷ luật hơn trong phát triển nơi API được phát triển (và dễ dàng được kiểm tra vì nó là độc lập) và sau đó UI được phát triển để tiêu thụ nó. Tôi đã làm việc tại một nơi đã làm điều này - các nhóm khác nhau đã phát triển các lớp khác nhau và nó hoạt động tốt vì họ có các chuyên gia cho từng tầng có thể tạo ra các thay đổi thực sự nhanh chóng vì họ không phải lo lắng về các tầng khác - tức là một nhà phát triển javscript UI có thể thêm một phần mới vào trang web bằng cách tiêu thụ một dịch vụ web mới mà người khác đã phát triển.


cảm ơn vì quan điểm Tôi đã không xem xét công việc bổ sung đang được thực hiện bằng cách xây dựng trang, v.v. Tuy nhiên, do có nghĩa là có một chế độ xem dao cạo trong ứng dụng và mọi thứ một khi đã khởi động là AngularJs, tôi không chắc đó là vấn đề trong trường hợp này. Ngoài ra, vì ứng dụng chỉ là nội bộ, tôi không nghĩ rằng vấn đề bảo mật là vấn đề quá lớn - lưu ý rằng các dịch vụ back-end là nơi lưu trữ tất cả dữ liệu, sẽ luôn nằm trong các hộp riêng biệt phía sau các dịch vụ wcf, với hàng tấn bảo mật trên chúng vì chúng được sử dụng bởi toàn bộ tổ chức.
Stephen Byrne

Chắc chắn, trường hợp của bạn là những gì trường hợp của bạn. Tôi tự hỏi nếu các dịch vụ đó có thể được sử dụng bởi một ứng dụng web khác trong tương lai (hoặc dự định) và đó là lý do tại sao nó được kiến ​​trúc như vậy. Một lần nữa, kiến ​​trúc sư cũ có thể đã nhìn xuống nó từ 10.000 feet!
gbjbaanb

1
Trong kịch bản của chúng tôi, chúng tôi đã quyết định phát triển ứng dụng Di động sau khi toàn bộ sản phẩm đã được sản xuất một thời gian. Chúng tôi rất vui khi tách máy chủ API khỏi máy chủ UI, vì ứng dụng Di động không liên quan gì đến ứng dụng Web. Chúng tôi có thể chia tỷ lệ các phần 'di động' và 'web' một cách riêng biệt. Một điều đáng chú ý: Ứng dụng web thực sự chỉ là một ứng dụng khách / khách hàng, điều đó có nghĩa là ứng dụng khách ứng dụng Web (trình duyệt) gọi máy chủ API để lấy dữ liệu (trong trường hợp của chúng tôi là có thể). Các cuộc gọi HTTP "dự phòng" giữa các máy chủ API và UI không đáng kể so với lưu lượng giữa trình duyệt / thiết bị di động và máy chủ API.
Bác sĩ Michal

2

Tôi nghĩ rằng không có câu trả lời đúng / sai ở đây. Bạn đã hỏi trường đại học của bạn về mục đích của kiến ​​trúc này?

Từ cách tôi hiểu các mô tả của bạn, " WebAPI " trong Kiến trúc của bạn đóng vai trò là một loại Middleware tự tạo. Bây giờ bạn có thể nghiên cứu những lợi thế trong việc sử dụng Middleware. Về cơ bản, ứng dụng Web của bạn sẽ không bao giờ cần phải được chấp nhận nếu bạn thay đổi hệ thống backoffice của mình (miễn là giao diện WebAPI giữ nguyên).

Để đi xa hơn: Hãy tưởng tượng bạn có cơ sở dữ liệu khách hàng (dịch vụ phụ trợ) và bạn có 5 ứng dụng web giao tiếp với cơ sở dữ liệu đó. Nếu bạn thay thế hệ thống cơ sở dữ liệu khách hàng bằng một hệ thống mới (như từ nhà cung cấp khác và bạn không thể ảnh hưởng đến giao diện dịch vụ web), rất có thể bạn sẽ cần thay đổi lớp giao tiếp của cả 5 ứng dụng web. Nếu bạn giao tiếp qua WebAPI , bạn sẽ phải thay đổi lớp giao tiếp của WebAPI .

Về cơ bản, Kiến trúc lớp ngày nay được coi là cả hai: Mẫu và Chống mẫu. (Xem: Lasagna-Code ) Nếu bạn chỉ có 1 hệ thống mà không có kế hoạch mở rộng thêm nữa trong vài năm tới, tôi sẽ coi đây là hệ thống chống mô hình. Nhưng điều này sẽ là một thẩm phán phi thực tế vì tôi không biết chính xác hoàn cảnh / tình huống :)


cảm ơn phản hồi, các dịch vụ back-end cuối cùng được sử dụng bởi toàn bộ tổ chức và có các hợp đồng dịch vụ WCF được xác định rõ (nếu đơn giản một chút) mà tổ chức sở hữu. Vì vậy, có rất nhiều quyết định nếu chúng ta cần thay đổi back-end (mà thực sự, chúng ta đang trong quá trình thực hiện, chuyển từ ERP này sang ERP khác). Nhưng vấn đề của tôi là với ứng dụng của chúng tôi cung cấp một bộ apis HTTP phần mềm trung gian riêng biệt chỉ được sử dụng bởi nó. Có vẻ như một tầng quá nhiều :)
Stephen Byrne
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.