Kiến trúc ứng dụng - ít hệ thống lớn hơn so với hệ thống nhỏ hơn


8

re: Architecture Architecture , nghĩa là " khoa học và nghệ thuật đảm bảo bộ ứng dụng đang được sử dụng bởi một tổ chức để tạo ra ứng dụng tổng hợp có thể mở rộng, đáng tin cậy, có sẵn và có thể quản lý được. "

Khi xem xét một loạt các ứng dụng trong một tổ chức, tôi có thể thấy nhiều lý do khác nhau để hợp nhất các ứng dụng lại với nhau, nhưng đôi khi cũng có những lý do tốt để giữ chúng tách biệt.

Nói chung , những ưu và nhược điểm của việc có ít hệ thống lớn hơn so với các hệ thống nhỏ hơn (lưu ý rằng nhiều hệ thống sẽ trao đổi thông tin).

Tôi đang nghĩ những điều như: ít hơn, ứng dụng lớn hơn có nghĩa là ít hệ thống ống nước hơn giữa các ứng dụng, nhưng ứng dụng nhỏ hơn có nghĩa là linh hoạt hơn cho từng bộ phận.

Có tài liệu nào về vấn đề này không, hoặc có ai có danh sách ưu và nhược điểm mà họ đã khám phá không?

chỉnh sửa: Trong kịch bản của tôi, rất nhiều ứng dụng có thể được tùy chỉnh ngoài ứng dụng thay vì phát triển nội bộ, nhưng hãy xem xét các tình huống chung hơn.


1
Lưu ý rằng các ứng dụng lớn hơn không có nghĩa là không có hệ thống ống nước, nó chỉ có nghĩa là hệ thống ống nước sẽ xảy ra trong ứng dụng.
deadalnix

@deadalnix: đồng ý. Tôi cho rằng việc liên kết dữ liệu trong một ứng dụng ít tốn công sức hơn so với liên kết dữ liệu giữa các ứng dụng.
codeulike

Câu trả lời:


3

Chỉ cần ra khỏi đầu của tôi

Hệ thống nhỏ hơn

  • Pro - Mở rộng quy mô trên phần cứng hàng hóa hoặc môi trường ảo hóa rẻ hơn.
  • Pro - Có thể triển khai theo tỷ lệ theo yêu cầu trong Đám mây.
  • Pro - Ít phụ thuộc trong hệ thống hơn, tức là. 1 dịch vụ cho mỗi máy chủ.
  • Pro - HA / DR (Tính sẵn sàng cao / Phục hồi thảm họa) thường dễ thực hiện hơn
  • Con - Phải có khả năng mở rộng theo chiều ngang
  • Con - Càng nhiều hệ thống, càng nhiều kết nối, quản lý càng phức tạp

Hệ thống lớn hơn

  • Pro - Ít kết nối hơn thường có nghĩa là nó ít phức tạp hơn
  • Pro - Đáp ứng nhanh hơn với mức sử dụng cao điểm nếu nó nằm trong dung sai.
  • Pro - Ít tài nguyên hơn để quản lý
  • Pro - Sử dụng tài nguyên hiệu quả hơn (giả sử sử dụng tương đối ổn định)
  • Con - Phụ thuộc nội bộ phức tạp hơn, tức là. N dịch vụ trên mỗi máy chủ
  • Con - HA / DR thường khó hơn / phức tạp hơn

Cảm ơn, đó là tuyệt vời. Làm thế nào để bạn thấy việc quản lý thay đổi phù hợp - có lẽ các thay đổi cục bộ dễ dàng hơn với các hệ thống nhỏ hơn, thay đổi toàn miền dễ dàng hơn với các hệ thống lớn hơn?
codeulike

Quản lý thay đổi có thể là thủ công trên ít hệ thống hơn, nhưng có thể nhanh chóng thoát khỏi tầm tay trên nhiều hệ thống và nên được tự động hóa.
dietbuddha

1

Trong một hệ thống lớn hơn, dễ dàng hơn nhiều để:

  • Chia sẻ tính năng và mã. Bạn sẽ phát minh lại bánh xe ít hơn một chút. Ví dụ: nếu bạn có mười ứng dụng phải có quyền truy cập vào cơ sở dữ liệu, bạn phải chỉ định chuỗi kết nối trong tất cả chúng , tức là mười lần. Hoặc bạn phải tạo một thư viện riêng và tham khảo lại mười lần nữa.

  • Hợp nhất các quy trình công việc , bao gồm cả quá trình triển khai.

  • Quản lý hệ thống: ít ứng dụng để quản lý thường dễ dàng hơn .

  • Thống nhất trải nghiệm người dùng . Khi một nhân viên phải đối phó với mười ứng dụng khác nhau, anh ta có thể dễ dàng bị mất: ứng dụng nào để chạy A? Trong ứng dụng nào có sẵn tùy chọn B? Nhưng đừng quá khích . Không ai sẽ đánh giá cao Word, PowerPoint, Outlook, Publisher, Visio, Project và Groove như một ứng dụng nguyên khối duy nhất.

Mặt khác, trong một loạt các hệ thống nhỏ, bạn sẽ thấy rằng:

  • Bạn có thể từ bỏ toàn bộ hệ thống nếu bạn không cần nó nữa. Hoặc bắt đầu lại từ đầu nếu codebase trở nên không sử dụng được theo thời gian. Điều này tất nhiên chỉ đúng nếu các hệ thống khác không dựa vào hệ thống này hoặc nếu giao diện đủ nhẹ để dễ dàng viết lại trong phiên bản mới.

  • Bạn có thể thành lập một nhóm các nhà phát triển mới và mong muốn họ hiểu được cơ sở mã hiện tại trong thời gian ngắn hơn . Nếu đó là một phần của một dự án lớn, rất có thể họ sẽ cần nhiều thời gian hơn, trừ khi toàn bộ cơ sở mã lớn được thực hiện cực kỳ chuyên nghiệp và được tái cấu trúc rất tốt (tôi chưa từng thấy những cơ sở mã hóa như vậy trong đời).

  • Các quản trị viên hệ thống sẽ có thể di chuyển các ứng dụng dễ dàng hơn . Mặt khác, hệ thống lớn hơn có thể mở rộng tốt trên nhiều máy chủ hoặc không.

  • Các nhà phát triển có thể di chuyển codebase sang các tiêu chuẩn mới dễ dàng hơn . Di chuyển một codebase lớn luôn luôn đáng sợ. Thay vào đó, khi bạn phải đối phó với một codebase nhỏ, sau đó là cái khác, rồi cái khác, v.v., nó trở nên ít đáng sợ hơn.

Điều này đang được nói, so sánh như vậy chỉ hoạt động trong các trường hợp chung, nhưng quyết định của bạn phải được lấy không phải từ nhóm, mà từ tài sản công ty của bạn. Nó được tổ chức như thế nào? Có nhiều nhóm phát triển nhỏ hoặc một vài nhóm lớn? Có hướng dẫn nghiêm ngặt về phong cách mã hóa và những thứ tương tự?

Nó cũng phụ thuộc vào chính ứng dụng. Ví dụ: sẽ vô lý khi gửi tất cả các ứng dụng Microsoft Office dưới dạng một ứng dụng. Nhưng nó cũng sẽ ảnh hưởng đến năng suất, ví dụ, tách Adobe Photoshop trong một ứng dụng để vẽ và một ứng dụng khác để chỉnh sửa ảnh. IMO, quyết định hợp nhất hoặc tách sản phẩm phải là quyết định kinh doanh, không phải là quyết định thuần túy về mặt kỹ thuật.

Cuối cùng, tôi cũng muốn trả lời bình luận thứ hai của câu hỏi ban đầu:

Tôi cho rằng việc liên kết dữ liệu trong một ứng dụng ít tốn công sức hơn so với liên kết dữ liệu giữa các ứng dụng

Điều đó không phải lúc nào cũng đúng. Nếu bạn đang xử lý ví dụ với .NET, sẽ không có gì lạ khi gửi một ứng dụng duy nhất nơi các thành phần khác nhau đang trao đổi thông qua WCF. Trong trường hợp này, điều này có thể so sánh với một tập hợp các ứng dụng riêng biệt giao tiếp qua WCF.

Tất nhiên, khi bạn phải xử lý nhiều ứng dụng, bạn phải thiết lập một số cách để chúng giao tiếp, trong khi việc có một ứng dụng nguyên khối duy nhất không buộc bạn phải làm điều đó. Nhưng bạn có thực sự có thể viết một ứng dụng nguyên khối lớn không?


0

Đọc này. Đó là triết lý "nhiều chương trình nhỏ" của Unix. Linux cũng sử dụng nó. Sức chịu đựng to lớn của triết lý này (từ cuối những năm 1960 đến nay) cho thấy rằng đó là điều đúng đắn.

http://en.wikipedia.org/wiki/Unix_philatics#Eric_Raymond

http://en.wikipedia.org/wiki/Unix_philatics#Mike_Gancarz:_The_UNIX_Phil Triết

http://159.93.17.14/usoft/WWW/LJ/Articles/unixtenets.html

http://www.linuxjournal.com/article/2877


OK, để nó hoạt động cho một tập hợp các thành phần trong một hệ điều hành, nhưng nó có hoạt động cho một tập hợp các ứng dụng cơ sở dữ liệu trong một tổ chức không? Đó là một kịch bản hoàn toàn khác.
codeulike

Không phải là một kịch bản khác nhau. Bạn có thể cung cấp một số khác biệt cụ thể?
S.Lott

@codeulike: đây có phải là câu hỏi của bạn không? "Có tài liệu nào về điều này không," Nếu vậy, đây là văn học. Tôi không nhận được bình luận của bạn trong bối cảnh câu hỏi của bạn.
S.Lott
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.