Làm thế nào để bạn quản lý khả năng mở rộng trong các hệ thống nhiều khách thuê của bạn?


13

Bây giờ tôi đã có một vài sản phẩm nhiều khách thuê dựa trên web lớn, và tôi sẽ sớm thấy rằng sẽ có rất nhiều tùy chỉnh dành riêng cho người thuê.

Một trường bổ sung ở đây hoặc ở đó, có thể là một trang bổ sung hoặc một số logic bổ sung ở giữa quy trình công việc - đó là một thứ.

Một số tùy chỉnh này có thể được đưa vào sản phẩm cốt lõi, và điều đó thật tuyệt. Một số trong số chúng rất đặc biệt và sẽ cản trở mọi người khác.

Tôi có một vài ý tưởng trong việc quản lý việc này, nhưng không ai trong số họ dường như có quy mô tốt. Giải pháp rõ ràng là giới thiệu một tấn cài đặt cấp độ máy khách, cho phép các 'tính năng' khác nhau được bật trên cơ sở mỗi khách hàng. Nhược điểm với điều đó, tất nhiên, là sự phức tạp và lộn xộn lớn. Bạn có thể giới thiệu một số lượng lớn các cài đặt thực sự và theo thời gian, các loại logic (trình bày, kinh doanh) có thể vượt khỏi tầm kiểm soát. Sau đó, có vấn đề về các trường dành riêng cho khách hàng, yêu cầu một cái gì đó sạch hơn là chỉ thêm một loạt các trường không thể vào các bảng hiện có.

Vậy mọi người đang làm gì để quản lý việc này? Force.com dường như là bậc thầy về khả năng mở rộng; rõ ràng là họ đã tạo ra một nền tảng từ đầu đến mức siêu mở rộng. Bạn có thể thêm vào hầu hết mọi thứ với giao diện người dùng dựa trên web của họ. FogBugz đã làm một cái gì đó tương tự khi họ tạo ra một mô hình plugin mạnh mẽ, khi nghĩ về nó, có thể thực sự được truyền cảm hứng từ Force. Tôi biết họ đã dành rất nhiều thời gian và tiền bạc cho nó và nếu tôi không nhầm thì ý định thực sự là sử dụng nó trong nội bộ để phát triển sản phẩm trong tương lai.

Âm thanh giống như thứ mà tôi có thể bị cám dỗ để xây dựng nhưng có lẽ không nên. :)

Là một sự đầu tư lớn vào kiến ​​trúc cắm được là cách duy nhất để đi? Làm thế nào bạn quản lý những vấn đề này, và bạn đang thấy loại kết quả nào?

EDIT: Có vẻ như FogBugz đã xử lý vấn đề bằng cách xây dựng một nền tảng khá mạnh mẽ và sau đó sử dụng nó để kết hợp màn hình của họ. Để mở rộng nó, bạn tạo một DLL chứa các lớp thực hiện các giao diện như ISearchScreenGridColumn và trở thành một mô-đun. Tôi chắc chắn rằng nó rất tốn kém để xây dựng vì họ có rất nhiều nhà phát triển và họ đã làm việc với nó trong nhiều tháng, cộng với diện tích bề mặt của họ có lẽ là 5% kích thước ứng dụng của tôi.

Ngay bây giờ tôi thực sự tự hỏi liệu Force.com có ​​phải là cách đúng đắn để xử lý việc này không. Và tôi là một anh chàng ASP.Net cốt lõi, vì vậy đây là một vị trí kỳ lạ để thấy mình trong.


3
Tôi đoán đây là câu hỏi SO, làm cho bài này giống nhau. Đừng làm điều đó, hoặc yêu cầu câu hỏi SO được di chuyển ở đây hoặc nếu bạn đang tìm kiếm câu trả lời khác nhau, hãy cho chúng tôi biết chính xác lý do tại sao câu trả lời cho câu hỏi SO không thỏa mãn.
yannis

Bạn đã đúng, câu hỏi tốt hơn đối với các lập trình viên, nhưng có vẻ như bạn vẫn nhận được một số câu trả lời khá hay. Tôi đã chỉnh sửa câu hỏi để tham khảo câu hỏi SO.
maple_shaft

Câu trả lời:


8

Tôi đã đối mặt với một vấn đề tương tự, và tôi sẽ cho bạn biết tôi đã giải quyết nó như thế nào.

  1. Thứ nhất, có một thư viện "lõi" hoặc động cơ. Điều này về cơ bản chạy chương trình, nhiều như bạn đã tìm ra. Nó xử lý những thứ phổ biến cho mọi hệ thống, từ biểu hiện động, quản lý tài khoản và người dùng, vai trò, bạn đặt tên cho nó, nó thực hiện nó.

  2. Mỗi phần của hệ thống được chứa trong một mô-đun. Một mô-đun có phụ thuộc (các mô-đun khác mà nó phụ thuộc vào). Ví dụ: hệ thống "lõi" có Bảo mật (người dùng, nhóm, vai trò, chính sách mật khẩu), Địa điểm, (bản dịch, quốc gia, văn hóa), Kho lưu trữ tệp, Email, v.v. Mỗi mô-đun tự xác định bằng tệp xml. Tệp xml về cơ bản chỉ định các lược đồ, bảng, lớp tính toán, định nghĩa màn hình vveteras. Chúng được đọc khi ứng dụng khởi động nếu ngày tệp đã thay đổi .

  3. Các mô-đun dành riêng cho khách hàng có các tệp xml riêng và DLL riêng. Tất cả cộng với và hoạt động tương ứng và minh bạch với phần còn lại của hệ thống. Phải xuống để thay thế các khung nhìn MVC hiện tại bằng các khung nhìn tùy chỉnh, với các mô hình khung nhìn tùy chỉnh và mã tùy chỉnh.

  4. Nếu khách hàng muốn mở rộng chức năng hiện có, xml / hệ thống cung cấp một phương thức trong đó tôi có thể "lấy" một mô-đun từ mô-đun khác. Mô-đun mới có tất cả các chức năng hiện có, nhưng với các yêu cầu cụ thể của khách hàng trong một DLL mới và với tệp XML mở rộng có thể thực hiện các sửa đổi. Caveat là, họ thực sự không thể loại bỏ các trường hiện có trong hệ thống này, nhưng chúng tôi có thể mở rộng nó và cung cấp các đối tượng và chức năng hoàn toàn mới.


+1: Âm thanh như thế mất một hoặc hai giờ. :)
Brian MacKay

1
@BrianMacKay, tốt, một khi công việc đã hoàn thành (và đó là một khẩu hiệu), khách hàng của chúng tôi rất hài lòng về tốc độ chúng tôi có thể xoay quanh các tùy chỉnh. Lưu ý rằng khung MVC (có nhiều lượt xem / trang được quan tâm) không cho vay rất tốt để trở thành đa dự án. Chúng tôi đã khắc phục điều này bằng cách sử dụng các tính năng thuộc tính của SVN và có các chế độ xem cốt lõi được đưa vào từ kho lưu trữ cốt lõi và sử dụng CSS / bố cục để tùy chỉnh nó. Nhưng năm, một vài giờ tốt: P
Moo-Juice

Chỉ tò mò, bạn nghĩ mất bao lâu để thực hiện kiến ​​trúc và bao nhiêu nhà phát triển đã tham gia?
Brian MacKay

1
@BrianMacKay, được 5 tháng. Một nhà phát triển giao diện người dùng để thực hiện tất cả các chế độ xem CSS / HTML / Một phần, javascript, v.v. và một nhà phát triển phụ trợ (bản thân tôi) để làm phần còn lại.
Moo-Juice

4

Có nhiều logic phiên bản và các lớp mã để quản lý không làm tăng giá trị cho ứng dụng / trang web của bạn. Nó cũng đòi hỏi nhiều năng lực não bộ hơn để hiểu những gì đang diễn ra và làm bạn mất tập trung vào cốt lõi của những gì bạn đang làm.

Tôi khuyên khác nhau. Tôi khuyên để giữ cho mọi thứ đơn giản hơn phức tạp.

Duy trì một cơ sở mã duy nhất giống nhau cho tất cả mọi người. Mỗi tính năng bạn thêm là một tính năng cho tất cả. Chỉ giới hạn số lượng vật phẩm hoặc lưu trữ hoặc một số thứ có thể định lượng, không phải tính năng. Lý do là định lượng những thứ như lưu trữ, số lượng mục nhập dữ liệu, v.v ... rất đơn giản để lập trình và nó có thể được áp dụng cho một số ít những thứ thực sự hạn chế người dùng không sử dụng ứng dụng của bạn. Nó chỉ cần được lập trình khi thêm các mục thay vì thực hiện một số tính năng logic. Điều gì nếu các tính năng được gắn vào các tính năng khác? Nó trở nên rất phức tạp để mã cho điều này.

Để đủ điều kiện trả lời, tôi đã xây dựng một khung thương mại điện tử mà tôi có cho nhiều khách hàng và đã học được cách khó khăn để cố gắng duy trì tất cả các đặc điểm riêng của họ. Cuối cùng tôi đã phá vỡ chuỗi và tạo ra một trang web quản trị duy nhất có nhiều xu hướng cho thương mại điện tử. Sau đó tôi có các trang web lấy dữ liệu từ các cuộc gọi dịch vụ web. Điều này cho phép các nhóm khác nhau trong các công nghệ khác nhau triển khai các tính năng cụ thể cho các trang web thương mại điện tử trong khi tôi tiếp tục được trả tiền mỗi tháng trên cùng một cơ sở hạ tầng và tôi không quan tâm họ đang làm gì. Tôi chỉ giới hạn việc sử dụng bằng số, không phải tính năng. Cách của nó dễ dàng hơn. Khách hàng có thể chọn nhà cung cấp của riêng họ để xây dựng trang web của họ và tôi không tham gia vào các quyết định đó nữa.

Tôi cũng có một dịch vụ đăng ký để quản lý nội dung SAAS. Điều này cũng hoạt động bằng cách sử dụng các tầng và khách hàng có thể thêm các plugin của riêng họ nếu họ muốn trong khi nhóm của tôi thêm nhiều tính năng hơn cho tất cả.

Đây chỉ là kinh nghiệm của tôi từ việc đập đầu vào tường sau một thời gian dài, sau đó vấp phải thứ gì đó đơn giản hơn.

Nếu một cái gì đó luôn luôn là cụ thể cho từng khách hàng, đừng tạo một khuôn khổ cho nó. Chia nó thành các phần đơn giản nhất để phần khung làm việc cho tất cả và sau đó cắt phần còn lại để bạn có thể mở rộng nó cho từng cá nhân.


+1 để chia sẻ kinh nghiệm của bạn. Rất nhiều điều tôi dường như đang nghe là "đây là một vấn đề rất khó khăn". Thực tế tôi đang giải quyết là hệ thống này sẽ có vô số tùy chỉnh và chúng không phù hợp với tất cả mọi người ... Có vẻ như bạn đang nói rằng bạn đã thực hiện phương pháp phơi bày một lớp dịch vụ và sau đó cho phép mọi người tiêu thụ tuy nhiên họ muốn - ít nhất tôi có lợi thế là chúng tôi viết tất cả các phần mở rộng trong nội bộ. Nhưng nó vẫn là một mớ hỗn độn để quản lý (cntd)
Brian MacKay

Kết luận mà tôi sắp đưa ra là bạn sẽ phải viết một nền tảng hỗ trợ khái niệm thành phần UI và thành phần động của chính nó, sau đó xây dựng toàn bộ ứng dụng bằng nền tảng đó. Và vì vậy tôi bắt đầu nghĩ rằng sẽ thật thông minh khi chỉ viết toàn bộ nội dung trong trang Force.com, bởi vì đó là thế lực.com!
Brian MacKay

Brian, FYI kitgui.com và hubsoft.com nếu bạn tò mò.
Jason Sebring

2

Sản phẩm phần mềm mà tôi làm việc có thêm các trường cho khả năng mở rộng của người dùng. Mỗi mục dữ liệu cho các trường này có thể được khóa vào một hàng hiện có trong các bảng chính trong ứng dụng. Ví dụ: nếu phần mềm của bạn chứa khách hàng và mỗi khách hàng một danh sách các đơn hàng, thì bảng dữ liệu có thể tùy chỉnh sẽ có một cột cho các khóa ngoại cho bảng khách hàng và bảng đơn hàng, chỉ một trong số đó sẽ không có giá trị. Một trong hai bảng có các trường tùy chỉnh cho một bảng.

Đây là một cách đơn giản và hiệu quả để lưu trữ dữ liệu bổ sung cho người dùng. Thông tin bổ sung sẽ cần được lưu trữ về tên và loại của các trường này.

Điều đó bao gồm các lĩnh vực tùy chỉnh cho một khách hàng. Đối với hành vi tùy chỉnh, API dịch vụ web sẽ cho phép mở rộng.


1

1) Chạy mã của người khác trên các hộp bạn sở hữu là một vấn đề khá khó khăn. Hoặc bạn có thể tin tưởng họ hoặc bạn có thể trì hoãn trách nhiệm một cách hợp lý, bạn sẽ phải sử dụng mã của họ rất nhiều và có sự cống hiến cao hơn mức trung bình cho bảo mật. Khi hệ thống plugin của bạn cho phép nhiều chức năng hơn, khó khăn trong việc làm cho nó an toàn tăng lên. Những thứ như từ chối dịch vụ (plugin tiêu tốn quá nhiều tài nguyên), rò rỉ thông tin (plugin có thể truy cập dữ liệu của người thuê nhà khác), v.v. có thể rất thật và rắc rối, tôi sẽ không tham gia vào điều này trừ khi tôi có thể làm quen với mọi người những vấn đề này hoặc những người rất có khả năng có nhiều thời gian để làm cho đúng.

2) Có, tính mô-đun và khả năng tùy biến là khó khăn. Những thứ như mẫu Chiến lược có thể giúp (một tên ưa thích cho các con trỏ hàm; trong Java, nó thường được triển khai bằng cách khai báo một Giao diện mà người dùng của lớp có thể triển khai để tùy chỉnh hành vi của mã của bạn), nhưng bạn sẽ muốn tách biệt và tách rời mã cho việc này để làm việc.

3) Dữ liệu khôn ngoan, đây có thể là một trong những ví dụ về lưu trữ schemaless hữu ích. Nếu bạn có một mô hình dữ liệu quan hệ, việc có các bảng có nhiều cột cho các khách hàng khác nhau là vấn đề (vâng, bạn kết thúc với rất nhiều cột không thể, điều này rất tệ ; một lý do là khó hoặc không thể đặt các ràng buộc chính xác [nghĩa là các ràng buộc không cho phép kết hợp null không hợp lệ xuất hiện]). Thêm bảng khách hàng cụ thể (ví dụ usersfoo_users, với userstổ chức các lĩnh vực có giá trị cho tất cả khách hàng và foo_userscó fileds cụ Foo) là tốt hơn; bạn có thể có các ràng buộc chính xác một cách dễ dàng, nhưng RDBMS của bạn có thể không xử lý nó một cách duyên dáng (do sự bùng nổ tham gia, giới hạn về số lượng bảng, v.v.) và có thể sẽ trông xấu trong mã của bạn.

Cuối cùng, bạn có thể triển khai một kho lưu trữ khóa-giá trị trong RDBMS, điều này làm cho mô hình dữ liệu của bạn ít quan hệ hơn và sẽ gây khó chịu (tức là cơ sở dữ liệu quan hệ hoạt động tốt nhất với các mô hình quan hệ-ish). Tôi không chắc chắn liệu một giải pháp NoQuery có phù hợp với tổng thể vấn đề hay không, nhưng tính đa dạng của hầu hết các triển khai có thể là một lợi thế.

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.