2014-11-11 25 views
24

Tôi nhầm lẫn về điểm mà tại đó ứng dụng web phân tách thành microservices - có phải ở cấp url hoặc cấp mô hình không? Ví dụ: Giả sử tôi có một ứng dụng nguyên khối phục vụ 3 trang. Giả sử mỗi trang phân phối một usecase riêng và tôi muốn quay lại eack của chúng với các dịch vụ nhỏ của riêng chúng. Bây giờ, cách nào trong số này là cách chính xác để triển khai kiến ​​trúc dựa trên microservice:Kiến trúc của ứng dụng web dựa trên microservice

  • Tôi tạo ba ứng dụng khác nhau (microservices), mỗi ứng dụng chứa (tuyến, bộ điều khiển, mô hình, mẫu) cho một trong các trang. Và sau đó dựa trên trang nào được yêu cầu, tôi định tuyến yêu cầu đến ứng dụng cụ thể đó. Điều này có nghĩa là toàn bộ trang từ cơ sở dữ liệu đến HTML được phục vụ bởi một ứng dụng riêng biệt. Về cơ bản, các trang khác nhau trong cùng một trang web đang được phục vụ hoàn toàn bởi các ứng dụng khác nhau trên chương trình phụ trợ.
  • 3 dịch vụ nhỏ không xử lý giao diện người dùng nhưng chỉ có dữ liệu cho các lần sử dụng của chúng (mô hình, bộ điều khiển, không có mẫu) và hiển thị nó trên api REST. Tôi có một ứng dụng phải đối mặt công khai. Ứng dụng này truy vấn ba ứng dụng khác nhau (microservices) chỉ dành cho dữ liệu và sau đó xây dựng các trang html sẽ được trả lại cho trình duyệt. Tất cả các trang trong một ứng dụng web trong trường hợp này đang được phục vụ bởi một ứng dụng duy nhất mà nội bộ sử dụng ba dịch vụ nhỏ khác nhau.

enter image description here

Trả lời

3

Như thường lệ trong Công Nghệ Phần Mềm, câu trả lời là nó phụ thuộc. Tôi không thể tưởng tượng một lý do ngay bây giờ nhưng tùy chọn 1 có thể hữu ích trong một số trường hợp cụ thể.

Tuy nhiên, xem xét định nghĩa chính thức về dịch vụ nhỏ, tùy chọn 2 minh họa tốt hơn. Một trong những ưu điểm chính của việc có microservices là có thể tái sử dụng nó. Các ứng dụng khác nhau có các yêu cầu và nhu cầu khác nhau về trình bày thông tin. Làm cho các dịch vụ nhỏ của bạn trả về biểu diễn JSON dữ liệu của bạn sẽ giúp bạn linh hoạt hơn về cách định dạng thông tin này.

+0

Phiên bản thông dụng của câu trả lời này có thể là: ** Thành phần ** và ** Nguyên tắc chịu trách nhiệm duy nhất ** (như MV *, không trộn dữ liệu với kết xuất). –

8

Bạn gặp sự cố khi mô hình hóa các dịch vụ nhỏ của bạn.

Về mặt dịch vụ nhỏ, cách tiếp cận thứ hai là thích hợp nhất, hiển thị logic của nó thông qua API.

Luôn khi bạn mô hình hóa các dịch vụ nhỏ của mình, hãy ghi nhớ các sự kiện tiếp theo.

  • Loose Coupling: Khi dịch vụ được lỏng lẻo, một sự thay đổi đến một dịch vụ không nên đòi hỏi một sự thay đổi khác. Toàn bộ vấn đề của Microservice này là có thể thay đổi một dịch vụ và triển khai nó, độc lập với nhu cầu thay đổi bất kỳ phần nào khác của hệ thống. Điều này thực sự khá quan trọng.

  • Gắn kết mạnh mẽ: Chúng tôi muốn hành vi liên quan để ngồi lại với nhau và hành vi không liên quan để ngồi ở nơi khác. Tại sao? Vâng, nếu chúng ta muốn thay đổi hành vi, chúng tôi muốn có thể thay đổi hành vi đó ở một nơi và giải phóng thay đổi đó càng sớm càng tốt.

+0

Hãy suy nghĩ về giao diện người dùng ui của bạn như một dịch vụ độc lập.Vì vậy, miễn là có một (các) dịch vụ phụ trợ đáp ứng các hợp đồng yêu cầu của nó, bạn có thể chỉ cần cắm nó vào và dịch vụ giao diện người dùng ui sẽ hoạt động – tiengtinh

2

Api cổng mô hình của Microservice apigateway là điểm đầu tiên từ nơi mà bạn có thể bắt đầu phân phối hoặc chuyển tiếp các cuộc gọi đến các dịch vụ khác nhau

Các vấn đề liên quan