Dịch vụ REST như một máy chủ ứng dụng cho hơn 2000 máy khách. Nó là một ý tưởng tốt?


11

Chúng tôi sẽ xây dựng một hệ thống với UI trong javaFx sẽ được triển khai tới hơn 2000 máy (tối thiểu là 2000, nhưng sẽ nhiều hơn - có thể đạt 5000 máy).

Vì những lý do / hạn chế khác, nó phải được cài đặt trên máy, vì vậy chúng tôi không thể thực hiện với giao diện trình duyệt web.

Các máy 2000+ sẽ nằm trong các nhóm vị trí địa lý khác nhau. Nói chung, kết nối là tốt, nhưng có thể không tốt trên các địa điểm xa hơn.

Thay vì truy cập trực tiếp vào cơ sở dữ liệu, tôi nghĩ đến việc xây dựng một cụm dịch vụ REST với Spring + Spring Boot + Spring Data (java).

Dịch vụ REST sẽ chấp nhận và trả về Json.

Tôi nghĩ rằng đó là một ý tưởng tốt bởi vì:

  • Dịch vụ này sẽ hoạt động như một nhóm kết nối cơ sở dữ liệu (Tôi nghĩ rằng hơn 2000 kết nối trên cơ sở dữ liệu sẽ gây ra sự cố);
  • Có thể có một cơ sở dữ liệu với nhật ký vận chuyển đến cơ sở dữ liệu chỉ đọc khác để phục vụ một số truy vấn;
  • Nó sẽ mở rộng tốt hơn khi chúng ta có thể thêm nhiều máy hơn để chạy các dịch vụ REST;
  • Có thể sử dụng HTTPS với nén vì lý do bảo mật và tiết kiệm băng thông;
  • Có thể thực hiện một số thay đổi tập trung trên các thực thể kinh doanh mà không cần triển khai lại hơn 2000 máy;
  • Nó tích hợp tốt hơn với các hệ thống khác (chỉ cần trỏ đến dịch vụ REST).

Nó thực sự là một ý tưởng tốt?

Bạn có thể chia sẻ một số kinh nghiệm tích cực hoặc tiêu cực?

Cảm ơn bạn.


1
Tôi nghĩ rằng đó là một ý tưởng hợp lý, đặc biệt là vì REST được thiết kế với bộ nhớ đệm. Bạn có thể cân nhắc sử dụng websockets để giảm tải từ các kết nối máy khách không liên tục, nhưng điều này phụ thuộc vào mô hình sử dụng API của bạn. WebSocket bắt đầu thể hiện thế mạnh của mình khi có thể ghép một số lượng lớn các giao dịch req / res nhỏ vào các kết nối liên tục. Điều đó nói rằng, có thể đơn giản hơn khi chỉ mở rộng ra ...
blz

8
Cơ sở dữ liệu không bao giờ có thể truy cập được từ internet công cộng và luôn ở phía sau tường lửa - do đó, che chắn chúng thông qua API REST hoặc tương tự là quy trình chuẩn. Điều này cũng cho phép bạn thêm các tính năng bảo mật khác dễ dàng hơn, ví dụ: ngăn người dùng chỉnh sửa các mục nhập dữ liệu mà họ không được phép xem hoặc chỉnh sửa.
amon

Câu trả lời:


3

Đây là một câu hỏi kết thúc mở với rất nhiều câu trả lời có thể phụ thuộc vào những gì bạn đang cố gắng làm. Tuy nhiên, tôi sẽ thêm một vài điều như một câu trả lời, vì một nhận xét sẽ không đủ lớn.

Dịch vụ này sẽ hoạt động như một nhóm kết nối cơ sở dữ liệu (Tôi nghĩ rằng hơn 2000 kết nối trên cơ sở dữ liệu sẽ gây ra sự cố);

Vâng đó là một ý tưởng tốt. Bạn giữ một số lượng nhỏ hơn các kết nối được mở và bạn sử dụng lại chúng khi yêu cầu đến dịch vụ. Nhưng bạn cần biết các yêu cầu sẽ được phục vụ nhanh như thế nào và mỗi yêu cầu sử dụng cơ sở dữ liệu bao nhiêu, nếu không một nhóm nhỏ có thể dễ dàng cạn kiệt và các yêu cầu khác sẽ bị chặn trong khi chờ kết nối cơ sở dữ liệu được phát hành.

Bộ nhớ đệm có thể giúp ở đó, để trả về dữ liệu đã tìm nạp (như tôi đã nói, tùy thuộc vào những gì bạn đang cố gắng thực hiện - nếu các truy vấn là duy nhất bạn không thể lưu trữ nhiều bộ đệm).

Cũng lưu ý rằng kích thước nhóm sẽ được nhân với số lượng dịch vụ bạn đặt tại chỗ. Một vài dịch vụ và bạn có thể sử dụng kích thước nhóm cơ sở dữ liệu lớn; Nhiều dịch vụ hơn và bạn cần giảm kích thước nhóm, để bạn có cùng số lượng kết nối được mở vào cơ sở dữ liệu.

Có thể có một cơ sở dữ liệu với nhật ký vận chuyển đến cơ sở dữ liệu chỉ đọc khác để phục vụ một số truy vấn;

Cơ sở dữ liệu có thể dễ dàng trở thành nút cổ chai của bạn. Quá nhiều kết nối và / hoặc quá nhiều truy vấn và bạn có thể phá vỡ nó. Tại thời điểm đó, không có vấn đề gì khi bạn có thể mở rộng quy mô dịch vụ của mình theo bất kỳ số nào. Tất cả các yêu cầu cuối cùng sẽ đạt được cùng một cơ sở dữ liệu.

Có nhiều cách khác nhau để bảo vệ nó: bộ nhớ đệm tôi đã đề cập (tùy thuộc vào trường hợp sử dụng của bạn), sao chép một số thông tin trên các máy chủ khác để phục vụ một số truy vấn như bạn đề cập, CQRS (tùy thuộc vào trường hợp sử dụng của bạn), sử dụng quan hệ so với không liên quan (tùy thuộc vào trường hợp sử dụng của bạn một lần nữa), v.v.

Lưu ý rằng khi bạn phân phối dữ liệu như vậy, định lý CAP bắt đầu được áp dụng. Hãy nhận ra điều đó vì bạn có thể cần phải thỏa hiệp giữa tính nhất quán và tính sẵn có.

Nó sẽ mở rộng tốt hơn khi chúng ta có thể thêm nhiều máy hơn để chạy các dịch vụ REST;

Có, dịch vụ REST sẽ mở rộng quy mô, nhưng như tôi đã đề cập ở trên, nếu bạn không bảo vệ cơ sở dữ liệu, điều đó có thể dễ dàng trở thành nút cổ chai.

Có thể sử dụng HTTPS với nén vì lý do bảo mật và tiết kiệm băng thông;

Vâng, cũng như những thứ khác ... có thể bạn muốn xác thực / ủy quyền sau này, v.v.

Có thể thực hiện một số thay đổi tập trung trên các thực thể kinh doanh mà không cần triển khai lại hơn 2000 máy;

Có, nhưng đến một mức độ nhất định và không phải tất cả các loại thay đổi. Nếu bạn thực hiện một thay đổi đột phá, bạn cũng sẽ cần phải cập nhật các khách hàng. Vì vậy, hãy suy nghĩ về một chiến lược để cập nhật các máy khách lên phiên bản mới nhất hoặc nếu bạn cho phép các máy khách cũ vẫn hoạt động và sử dụng ứng dụng.

Nó tích hợp tốt hơn với các hệ thống khác (chỉ cần trỏ đến dịch vụ REST).

Có, nhưng điều đó có nghĩa là khách hàng cho dịch vụ của bạn mà có lẽ bạn không thể kiểm soát.

Nếu bạn thực hiện một thay đổi đột phá và bạn có một chiến lược tốt để cập nhật hơn 2000 máy khách JavaFX thì không có vấn đề gì. Nhưng nếu các máy khách khác tồn tại và bạn không có quyền kiểm soát chúng, bạn có thể cần triển khai phiên bản trên dịch vụ REST và hỗ trợ nhiều hơn một phiên bản cho đến khi mọi người có thể cập nhật lên phiên bản mới nhất.

Như tôi đã nói, nó phụ thuộc vào những gì bạn đang cố gắng làm. Nhìn chung, bạn là một ý tưởng tốt. Nhưng hãy lưu ý rằng mọi thứ sẽ không miễn phí chỉ vì bạn dán dịch vụ REST trước cơ sở dữ liệu.

Chỉ 2 xu của tôi!


Tốt trả lời. Tôi chỉ muốn nhấn mạnh với Thiago rằng đáng để xem xét phiên bản trong API RESTful càng sớm càng tốt. Bạn có thể không cần phải làm điều đó khi bắt đầu nhưng bạn nên nhận thức được nó và được chuẩn bị.
Daniel Hollinrake
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.