Giao tiếp liên tục giữa các ứng dụng cục bộ là một ý tưởng hay?

Question

Tôi tự hỏi có nên cho phép các ứng dụng cục bộ (trong cùng một máy chủ) giao tiếp với nhau hoàn toàn thông qua API Restful không?

Tôi biết điều này không phải là điều không phổ biến, vì chúng tôi đã có các ứng dụng như CouchDB đang sử dụng HTTP REST để giao tiếp, ngay cả với các ứng dụng cục bộ.

Nhưng tôi muốn đưa nó lên cấp cao hơn bằng cách tạo ứng dụng hoạt động như mô-đun cho ứng dụng lớn hơn, cũng có thể là mô-đun cho ứng dụng khác, v.v. Nói cách khác, sẽ có rất nhiều ứng dụng/mô-đun địa phương đang giao tiếp với API Restful.

Bằng cách này, các ứng dụng/mô-đun này có thể bằng bất kỳ ngôn ngữ nào và chúng có thể giao tiếp qua dây giữa các máy chủ.

Nhưng tôi có một số câu hỏi:

• Đây có phải là một ý tưởng tốt?
• Việc chuyển dữ liệu giữa chúng có chậm không?
• Nếu tôi làm điều này, thì mỗi ứng dụng/mô-đun phải là máy chủ HTTP phải không? Vì vậy, nếu ứng dụng của tôi sử dụng 100 ứng dụng/mô-đun thì mỗi một trong số này phải là một máy chủ web HTTP cục bộ, mỗi máy chủ chạy trên một cổng khác (http: // localhost: 81, http://localhost:82, http://localhost:83 và vv) phải không?
• Bất kỳ thực tiễn tốt nhất/gotchas mà tôi nên biết?

Answer 1

• Đây có phải là một ý tưởng hay không?

Chắc chắn, có thể.

• Dữ liệu chuyển dữ liệu giữa chúng có bị chậm không?

Yup! Nhưng so với cái gì? So với các cuộc gọi nội bộ, nội bộ, tuyệt đối - nó sẽ là băng giá. So với một số API mạng khác, eh, không nhất thiết phải chậm hơn.

• Nếu tôi làm điều này, thì mỗi ứng dụng/mô-đun phải là máy chủ HTTP phải không?Vì vậy, nếu ứng dụng của tôi sử dụng 100 ứng dụng/modules tôi phải có 100 máy chủ HTTP web địa phương lên và chạy mỗi cổng khác (http: // localhost: 81, http://localhost:82, http://localhost:83 và vân vân)?

Không, không có lý do gì để phân bổ cổng cho mỗi mô-đun. Tất cả các loại cách để làm điều này.

• Bất kỳ thực tiễn tốt nhất/gotchas nào mà tôi nên biết?

Cách duy nhất để thành công là nếu các dịch vụ bạn đang nói đến là đủ thô. Đây phải là những loại dịch vụ lớn, màu đen, làm cho chi phí gọi chúng là đáng giá. Bạn sẽ phải chịu chi phí kết nối, chi phí chuyển dữ liệu và chi phí cố định dữ liệu trên mỗi giao dịch. Vì vậy, bạn muốn những giao dịch đó càng hiếm càng tốt và bạn muốn tải trọng càng lớn càng tốt để có được lợi ích tốt nhất.

Bạn đang nói thực sự sử dụng kiến ​​trúc REST hay chỉ gửi công cụ qua lại qua HTTP? (Đây là những thứ khác nhau) REST phải gánh chịu chi phí riêng của mình, bao gồm các liên kết được nhúng, các loại dữ liệu phổ biến và phổ biến, v.v.

Cuối cùng, bạn có thể không cần thực hiện việc này. Nó có thể được "kinda mát mẻ", một "tốt đẹp để có", "có vẻ tốt trên bảng trắng", nhưng nếu, thực sự, không cần nó, sau đó không làm điều đó. Chỉ cần làm theo các phương pháp tốt để cô lập các dịch vụ nội bộ của bạn để bạn quyết định sau đó thực hiện một cái gì đó như thế này, bạn chỉ cần chèn lớp keo cần thiết để quản lý thông tin liên lạc,… Thêm phân phối từ xa sẽ tăng nguy cơ, độ phức tạp và hiệu suất thấp hơn ! = hiệu suất) do đó, nên có một lý do tốt để làm điều đó cả.

Điều đó, được cho là, là "thực hành tốt nhất" của tất cả chúng.

Edit - Đáp lại bình luận:

Vì vậy, bạn có nghĩa là tôi chạy một máy chủ web mà xử lý tất cả các yêu cầu đến? Nhưng sau đó các mô-đun sẽ không độc lập ứng dụng, sẽ đánh bại toàn bộ mục đích . Tôi muốn mỗi một trong các mô-đun để có thể tự chạy.

Không, nó không đánh bại mục đích.

Đây là giao dịch.

Giả sử bạn có 3 dịch vụ.

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

Trong nháy mắt, nó sẽ là công bằng khi nói rằng đây là ba dịch vụ khác nhau, trên 3 máy khác nhau, chạy trong 3 máy chủ web khác nhau.

Nhưng sự thật là tất cả những điều này đều có thể chạy trên máy tính CÙNG, trên máy chủ web SAME, thậm chí xuống (để đưa điều này đến cùng cực) chạy cùng một logic.

HTTP cho phép bạn ánh xạ tất cả mọi thứ. Bản thân HTTP là cơ chế trừu tượng hóa.

Là khách hàng, tất cả những gì bạn quan tâm là URL để sử dụng và tải trọng để gửi. Những gì máy nó kết thúc lên nói chuyện với, hoặc những gì mã thực tế nó thực hiện nó không phải là vấn đề của khách hàng.

Ở cấp kiến ​​trúc, bạn đã đạt được cách thức trừu tượng hóa và mô đun hóa. Các URL cho phép bạn tổ chức hệ thống của bạn là bất kỳ bố cục LOGICAL nào bạn muốn. Triển khai thực hiện khác biệt với chế độ xem logic.

3 dịch vụ đó có thể chạy trên một máy tính được phục vụ bởi một quy trình duy nhất. Mặt khác, chúng có thể đại diện cho 1000 máy. Bạn cho rằng có bao nhiêu máy móc phản hồi "www.google.com"?

Bạn có thể dễ dàng lưu trữ tất cả 3 dịch vụ trên một máy, mà không cần chia sẻ bất kỳ mã nào lưu chính máy chủ web. Làm cho nó dễ dàng để di chuyển một dịch vụ từ máy ban đầu của nó đến một số máy khác.

Tên máy chủ lưu trữ là cách đơn giản nhất để ánh xạ dịch vụ tới máy. Bất kỳ máy chủ web hiện đại nào cũng có thể phục vụ bất kỳ số lượng máy chủ khác nhau nào. Mỗi "máy chủ ảo" có thể phục vụ bất kỳ số điểm cuối dịch vụ riêng lẻ nào trong không gian tên của máy chủ lưu trữ đó. Ở mức "máy chủ" cấp tầm thường của nó để di chuyển mã từ máy này sang máy khác nếu và khi bạn phải.

Bạn nên khám phá thêm các khả năng của máy chủ web hiện đại để hướng các yêu cầu tùy ý đến logic thực tế trên máy chủ. Bạn sẽ thấy chúng rất linh hoạt.

Answer 2

Khi sử dụng các giải pháp an toàn để tích hợp ứng dụng, tôi tin rằng đây là một ý tưởng hay và công bố các lượt xem tương tự tại một câu hỏi khác.

• How to share data across an organization

Answer 3

Để được thẳng thắn Tôi không nghĩ rằng bạn cần 100 máy chủ cho 100 ứng dụng, có thể chỉ cần sử dụng 100 cổng trên cùng một máy chủ.

và cũng có thể, giao diện RESTful sẽ cung cấp cho bạn sự linh hoạt để mở rộng các máy chủ và cho phép cân bằng tải nếu bạn muốn có khả năng mở rộng quy mô lớn.

Answer 4

Đây có phải là một ý tưởng hay không?

Có. Nó được thực hiện tất cả các thời gian. Đó là cách tất cả các máy chủ cơ sở dữ liệu làm việc, ví dụ. Linux được đóng gói đầy đủ các ứng dụng khách/máy chủ giao tiếp thông qua TCP/IP.

Truyền dữ liệu giữa chúng có bị chậm không?

Không. TCP/IP sử dụng localhost như một đoạn ngắn để lưu làm mạng I/O thực tế.

Giao thức HTTP không phải là điều tốt nhất cho các kết nối chuyên dụng, nhưng nó đơn giản và được hỗ trợ tốt.

Nếu tôi làm điều này, thì mỗi ứng dụng/mô-đun phải là máy chủ HTTP phải không?

Không nhất thiết. Một số mô-đun có thể là khách hàng và không có máy chủ.

Vì vậy, nếu ứng dụng của tôi sử dụng 100 ứng dụng/modules sau đó mỗi một trong những thiết phải là một máy chủ HTTP web địa phương từng chạy trên một cổng khác (http: // localhost: 81, http://localhost:82, http://localhost:83 và vân vân) đúng?

Có. Đó là cách nó hoạt động.

Thực tiễn tốt nhất/những điều mà tôi nên biết?

Không có số cổng "mã cứng".

Không sử dụng số cổng "đặc quyền" (dưới 1024).

Sử dụng thư viện WSGI và bạn sẽ hạnh phúc nhất làm tất cả các mô-đun của mình thành các ứng dụng WSGI. Sau đó, bạn có thể sử dụng một máy chủ HTTP 2 dòng nhỏ để bọc mô-đun của mình.

Đọc nội dung này. http://docs.python.org/library/wsgiref.html#examples

Answer 5

Không - đó không phải là ý tưởng hay nếu bạn không có lý do chính đáng. Đó là một ý tưởng tốt để lớp mã của ứng dụng của bạn để nó có thể được "nghỉ ngơi" ở giai đoạn sau nếu bạn cần nó. (Hoặc bất kỳ cải tiến hiệu suất nào được coi là cần thiết.) Sự phức tạp triển khai tăng của "các lớp dựa trên máy chủ" là một lý do chính đáng để không làm điều đó. Tôi sẽ đề xuất:

• Viết một ứng dụng có cấu trúc tốt với mã sạch, tốt.
• thử nghiệm nó với vô sản xuất dự kiến ​​
• nếu cần thiết - cấu trúc lại thành các lớp có máy chủ - nhưng .....

Một cách tiếp cận tốt hơn là để cân bằng tải toàn bộ ứng dụng. Nếu bạn đang làm một cái gì đó như đường ray không có nhà nước trong máy chủ ứng dụng nó sẽ không có vấn đề để chạy một số trường hợp song song.

Nếu bạn đang tìm kiếm sự phức tạp - hãy bỏ qua câu trả lời của tôi. :-)