Kiến trúc máy chủ Micro vs Monolithic

Chúng tôi hiện đang làm việc trên sản phẩm / dự án mới của chúng tôi, đây là một ứng dụng máy chủ-máy khách hướng đến một số doanh nghiệp công nghiệp / dịch vụ cụ thể. Chúng tôi đang xây dựng một máy chủ (Chỉ ngôn ngữ C và Linux) đang chạy một giao thức tùy chỉnh trên đầu TCP với giao diện người dùng Java. Chúng tôi có khoảng 20% ​​trong công việc mã hóa và phải đối mặt với một tình huống phải lựa chọn giữa Kiến trúc hạt nhân Micro hoặc Monolithic.

Tôi biết rằng Micro so với Monolithic thường liên quan đến kiến ​​trúc kernel, nhưng chúng tôi đặc biệt nói về các máy chủ.

Tại sao một máy chủ tùy chỉnh và không phải là một cái gì đó hiện có?

• Nhu cầu UI của chúng tôi rất quan trọng và rất năng động, do đó, các giải pháp dựa trên trình duyệt Web / Web là không phù hợp.
• Việc xử lý thống kê có ý nghĩa ở cuối máy khách và do đó, một lần nữa, các trình duyệt đã giúp ích rất ít. (Tất nhiên, chúng tôi có thể thực hiện xử lý ở cuối máy chủ và truyền dữ liệu đã xử lý cho máy khách nhưng điều đó sẽ ám chỉ rất nhiều tải trên máy chủ và gây lãng phí tài nguyên của máy khách).
• Ngoài ra, với ít nhất ba công nghệ (JS / HTML / CSS) để quản lý ngay cả một sự kiện duy nhất làm cho toàn bộ trải nghiệm như quét nhà giữa cơn bão sa mạc - bạn quét nó n lần, bụi tích tụ n + 1 lần.

Còn máy chủ Micro và Monolithic thì sao? Cậu đang nói gì thế?

Xem xét các yêu cầu khách hàng (giả định) sau đây:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Khi nhận được yêu cầu như vậy, thông thường, một máy chủ sẽ thực hiện (chúng tôi đang bỏ qua các kỹ thuật tương tranh như luồng và nhánh để đơn giản):

• Phân tích chuỗi yêu cầu
• Xác định hành động (Tìm nạp HistoricDataSets LIMIT Year (2010)trong trường hợp của chúng tôi)
• Tương tác với lớp kiên trì (Oracle, giả sử, trong ví dụ của chúng tôi) và lấy dữ liệu.

• Định dạng dữ liệu theo giao thức. Ví dụ:

  answer-id: 123
  thành công:
  phản hồi đúng văn bản: DataSets

• Trả lời khách hàng với dữ liệu được định dạng như vậy.

Đây là những gì chúng ta đang gọi là Máy chủ nguyên khối (gần giống với hạt nhân nguyên khối trong đó tất cả các hoạt động của hệ điều hành được thực hiện trong không gian hạt nhân).

Hãy xem xét lại cùng một yêu cầu, khi nhận, lần này máy chủ (chúng tôi chỉ giả sử bộ nhớ được chia sẻ là IPC, một lần nữa cho đơn giản):

• Đưa yêu cầu vào bộ nhớ dùng chung cho Parserquá trình
• Các Parserphân tích cú pháp chuỗi, xác định nhiệm vụ và chỉ đạo Executionerquá trình để thực hiện các nhiệm vụ.
• Sau Executionerđó chuyển dữ liệu để Fomatterxử lý, sau khi định dạng dữ liệu thành chuỗi giao thức, sẽ trả về máy chủ.
• Máy chủ gửi nó đến máy khách (phản hồi).

Tất nhiên, thay vì Parser, Executionervà Formatternó có thể là một quá trình đơn lẻ nhưng riêng biệt. Đây là những gì chúng ta đang gọi một Máy chủ Micro (gần giống với một hạt nhân siêu nhỏ chỉ cần tối thiểu là bắt buộc). Máy chủ thực sự chỉ lắng nghe và phản hồi trong khi tất cả các bước được xử lý bởi các quy trình khác nhau.

Chọn cái nào? Chúng tôi đang bối rối! Trong khi các máy chủ nguyên khối được thử và kiểm tra (hầu hết các Máy chủ HTTP-Web?) Và dễ lập trình hơn và có thể xử lý đồng thời khá tốt. Các máy chủ siêu nhỏ, prima facie, dường như nhanh chóng và phù hợp với nguyên tắc UNIX của một chương trình để thực hiện một nhiệm vụ, nhưng cũng rất phức tạp để phát triển, đặc biệt. giữ đồng thời trong tâm trí.

Câu hỏi
- (Có thể là gì) có thể là ưu và nhược điểm của từng phương pháp?
- Khi nào sử dụng? (Nó cũng có thể được hiểu là một câu hỏi chung: Khi nào nên sử dụng IPC?)
- Nếu Micro kernel được chọn, thì những chức năng nào cần phải là một phần của máy chủ lõi và những gì không?

Câu hỏi tương tự / liên quan

• Nguy hiểm của ứng dụng nguyên khối khổng lồ
• Trình duyệt nhúng ngoài Vs (Tiếp tuyến)
• Lời khuyên cho việc chuyển đổi ứng dụng nguyên khối thành đa luồng (Tiếp tuyến)

• Khách hàng tiềm năng của chúng tôi có thể được chia thành hai loại:
  • Lớn: Khoảng 1.700 - 2.000 yêu cầu mỗi phút
  • Nhỏ: Khoảng 650 - 700 yêu cầu mỗi phút
• Khối lượng dữ liệu trên mỗi chu kỳ yêu cầu (yêu cầu và phản hồi tiếp theo) có thể được giả định là được phân phối bình thường với giá trị trung bình ~ 1,20 MB và trường hợp xấu hơn khoảng 250-300 MB.
• Khái niệm sản phẩm tương đối mới nhưng có khả năng tác động đến các hoạt động cốt lõi, do đó chúng tôi hy vọng ngân sách của khách hàng sẽ linh hoạt chỉ đăng một độ trễ nhất định (9-12 tháng), điều này giới hạn số lượng phần cứng mà khách hàng sẽ sẵn sàng để cam kết đặc biệt. Những cái nhỏ.
• Mỗi khách hàng sẽ có ngăn xếp máy khách-máy chủ của riêng mình. Máy chủ sẽ chạy trên phần cứng của khách hàng được quản lý bởi nhóm của khách hàng, trong khi khách hàng sẽ được triển khai trên máy của các nhân viên chức năng
• Cập nhật từ xa cho cả ứng dụng khách và máy chủ là bắt buộc
• Các PUSHdịch vụ thời gian thực của máy chủ có thể 'rất mong muốn' nếu sản phẩm nhấp!

Kinh tế đôi khi chi phối câu trả lời quan trọng hơn nhiều so với lý thuyết cốt lõi đằng sau các lựa chọn. Điều quan trọng nhất là nếu bạn đang xem xét một thứ gì đó 'rộng lớn' trong trường hợp của bạn, nơi ứng dụng của bạn cần triển khai thực sự khó khăn - số lượng bánh xe bạn tự phát minh ra càng ít thì càng tốt. Nếu nó hoạt động, tôi sẽ không quan tâm nếu nó là nguyên khối hoặc vi mô; nếu nó không tôi cũng không quan tâm

Có thể đúng là các ứng dụng dựa trên trang web thông thường có thể không dành cho bạn - nhưng bạn cần nhìn rộng hơn một chút và thấy bạn có thể sử dụng những thứ sẵn sàng để đi và sau đó phát triển để xem liệu bạn có thể thay thế yếu tố đó bằng thứ gì đó không tốt hơn. Bằng cách đó, không chỉ bạn sẽ tiết kiệm thời gian cho việc đầu tiên - mà bạn cũng sẽ cải thiện sự hiểu biết của bạn về những gì thực sự quan trọng trong cuộc sống thực. Dưới đây là một số gợi ý bạn có thể xem xét.

1. Nếu bạn thực sự cần khả năng mở rộng rất cao, hãy xem xét cách các máy chủ của bạn sẽ phân chia nhiệm vụ thay vì khuấy các số nhanh nhất có thể. Cuối cùng, bạn sẽ có một tải mà một máy chủ không thể thực sự chiếm được ngay cả khi intel tạo bộ xử lý nhanh nhất trên trái đất và khách hàng sẵn sàng trả tiền! Vì vậy, yêu cầu định tuyến và cân bằng tải quan trọng hơn hiệu quả của chính giao thức.

2. HTTP vẫn là tốt nhất - nếu bạn cần mở rộng quy mô. (Bạn cũng có thể dễ dàng mua bộ cân bằng tải nếu bạn sử dụng nó). Giao thức tùy chỉnh yêu cầu sắp xếp tùy chỉnh.

3. HTTP không có nghĩa là bạn cần phải sử dụng HTML, java script. Thậm chí không có nghĩa là bạn cần phải có máy chủ apache và trình duyệt web thông thường. Bạn có thể sử dụng HTTP giữa hai máy khách tùy chỉnh và các thành phần như máy chủ AOL hoặc lighthttpd có thể được sử dụng làm thư viện nếu giao tiếp không phải là truyền dữ liệu lớn. Bạn cũng có thể sử dụng SOAP trên cả hai mặt với bộ công cụ như gSOAP .

4. Ngay cả khi HTTP chắc chắn không phù hợp với dự luật, hãy xem xét một số thứ như BEEP , điều đó giúp bạn làm mọi thứ hiệu quả hơn. Ngoài ra, có nhiều cơ chế RPC, RMI đã được chứng minh tồn tại.

5. Hãy thử để thấy rằng bạn có thể thực hiện công việc tối đa nhiều hơn bằng cách xử lý song song trong back-end và máy chủ chỉ được truy vấn khi công việc được hoàn thành. Nếu điều này hoạt động - khác là các khung như MPI , hoặc có nhiều bộ công cụ máy tính phân tán khác có thể giúp đỡ.

6. Cuối cùng, mặc dù tôi có thể không ở vị trí để biết chính xác nhu cầu, nhưng bạn có thể cần phân phối nhiều dữ liệu hoặc tính toán nhiều, nếu bạn cần cả hai - vẫn còn một số sự thiếu hiệu quả về kiến ​​trúc cốt lõi.

Đối với tôi, việc tạo Giao thức mới và hơn là tạo khung máy chủ mới là một thử nghiệm kép mà bạn không nên làm cùng nhau. Nếu cổ phần của bạn quá cao, trước tiên bạn thực sự nên thử trải nghiệm với các công cụ hiện có để xem giới hạn của những gì đã được thực hiện cho đến nay - chỉ khi đó bạn mới biết những thách thức thực sự.

Nhiều thứ đã được hoàn thành trong nghiên cứu các hệ thống phân tán hơn là chỉ các ứng dụng web. Vì vậy, bạn nên nghiên cứu rằng.

Dipan.

Điều này có vẻ rất hàn lâm với tôi. Và thẳng thắn, tôi thấy cách tiếp cận thứ hai cũng giống như nguyên khối. Điều này là xa như bạn nên đi:

1. Phân tích yêu cầu
2. Xử lý yêu cầu

Trình xử lý yêu cầu được chọn dựa trên các tham số yêu cầu sẽ gói gọn tất cả các khía cạnh xử lý yêu cầu. Việc trình xử lý có thực sự thực hiện các truy vấn trên kho dữ liệu của bạn hay không và liệu nó có sử dụng định dạng chuẩn để trả về dữ liệu không liên quan từ lớp trên hay không. Trên thực tế, nó có thể sẽ làm điều đó, nhưng không có giá trị trong việc đưa ra các giả định về nó.

1. Hạt nhân nguyên khối cũ hơn nhiều so với Microkernel . Nó được sử dụng trong Unix. trong khi ý tưởng về hạt nhân xuất hiện vào cuối những năm 1980 .

2. ví dụ về os có các hạt nhân nguyên khối là UNIX, LINUX trong khi os có Microkernel là QNX, L4, HURD , ban đầu Mach (không phải mac os x) sau đó nó sẽ chuyển đổi thành kernel lai, thậm chí MINIX không phải là kernel thuần vì trình điều khiển thiết bị là được biên dịch như là một phần của kernel.

3. Hạt nhân nguyên khối nhanh hơn hạt nhân vi mô . trong khi Microkernel Mach đầu tiên chậm hơn 50% so với kernel Monolithic trong khi phiên bản sau như L4 chỉ chậm hơn 2% hoặc 4% so với kernel Monolithic .

4. Hạt nhân nguyên khối thường cồng kềnh . trong khi hạt nhân nguyên khối thuần túy phải có kích thước nhỏ, thậm chí vừa với s vào bộ đệm cấp bộ xử lý (vi nhân thế hệ thứ nhất).

5. trong trình điều khiển thiết bị kernel Monolithic nằm trong không gian kernel . trong khi Trình điều khiển thiết bị Microkernel nằm trong vùng người dùng .

6. do trình điều khiển thiết bị nằm trong không gian kernel, nó làm cho kernel nguyên khối kém an toàn hơn so với microkernel. (Lỗi trong trình điều khiển có thể dẫn đến sự cố) trong khi Microkernels an toàn hơn so với hạt nhân nguyên khối do đó được sử dụng trong một số thiết bị quân sự.

7. Hạt nhân nguyên khối sử dụng tín hiệu và ổ cắm để đảm bảo IPC trong khi phương pháp vi nhân sử dụng hàng đợi tin nhắn . 1 gen vi nhân IPC được triển khai kém nên chậm chuyển đổi ngữ cảnh.

8. thêm tính năng mới vào hệ thống nguyên khối có nghĩa là biên dịch lại toàn bộ kernel trong khi Bạn có thể thêm tính năng mới hoặc các bản vá mà không cần biên dịch lại .