Node.js có phù hợp để xử lý nền không?


10

Tôi đang dần học hỏi node.jsvà có một dự án nhỏ mà tôi muốn bắt đầu. Dự án sẽ có rất nhiều quy trình nền (tải xuống dữ liệu từ các trang bên ngoài, phân tích tệp CSV, v.v.).

Một "chiến thắng" lớn đối với tôi và nút là thực tế nó sử dụng JavaScript cho cả máy khách và máy chủ. Tôi viết mã bằng Java và JavaScript trong công việc hàng ngày của mình nhưng tôi cũng khá giỏi về Ruby.

Nhưng, như tôi đã nói, có vẻ hấp dẫn khi sử dụng một ngôn ngữ ở mọi nơi và JS dường như phù hợp với dự luật đó.

Tuy nhiên, tôi chưa có nhiều kinh nghiệm trong việc sử dụng JS để chạy các công việc nền. Ruby dường như nổi trội về điều này. Và tôi không phản đối việc sử dụng nó. Vì vậy, suy nghĩ của bạn về việc đi 100% JS cho việc này là gì? Tôi nhận ra các dự án rất lớn đòi hỏi các giải pháp tùy chỉnh. Tôi chỉ tự hỏi nếu nó đáng giá nỗ lực. Hoặc, tôi có nên gắn bó với Ruby trên những công việc đó không?

Ý kiến ​​đánh giá cao.

Cảm ơn


Bạn cũng có thể muốn xem vert.x như là một thay thế cho nút.
Mike

Câu trả lời:


13

Nó đặc biệt mạnh khi xử lý hàng tấn tệp I / O và tôi hy vọng nó cũng sẽ xử lý tốt cả tấn giao tiếp mạng. Nó có vẻ đặc biệt phổ biến cho các ứng dụng điều khiển ổ cắm. Điều quan trọng cần lưu ý là nếu nhu cầu của bạn không được đáp ứng bởi các thư viện hiện có (có rất nhiều), bạn có thể cần phải đi sâu vào một số C có thể bị ràng buộc với các lệnh JS. Bạn cũng có thể sinh ra các quy trình Node bổ sung nhưng tôi nghi ngờ việc thực hiện nhiều quy trình có thể bị đánh thuế (tôi cho rằng - có thể sai - có một phiên bản V8 được sinh ra cho mỗi một trong số đó).

JS là một luồng đơn và chặn, có nghĩa là không có gì khác có thể thực thi cho đến khi một lệnh gọi hàm hoàn thành. Đây là một tính năng mong muốn của JS, về cơ bản lấy tất cả các mối quan tâm phân luồng và xếp hàng ra khỏi tay bạn. JS không ngăn các công cụ C / C ++ chạy theo kiểu đa luồng hơn dưới mui xe, vì vậy vai trò của JS thực sự là kiến ​​trúc / trình nhắn tin nhiều hơn. Nếu bạn đang xử lý hình ảnh, bạn sẽ không muốn xử lý điều đó bằng các lệnh JavaScript đồng bộ vì mọi thứ khác trên ứng dụng hoặc máy chủ của bạn sẽ bị chặn cho đến khi hoàn thành. Ý tưởng là bạn gọi cho một hình ảnh được xử lý bằng chức năng C / C ++ bị ràng buộc, và sau đó trả lời sự kiện 'xong' khi hình ảnh được xử lý xong.

Điều này đòi hỏi rằng JS trong bất kỳ ứng dụng Node.js nào phải chịu nhiều sự kiện và điều khiển gọi lại hoặc nó có thể sẽ hoạt động rất kém. Vì vậy, bạn sẽ không thấy nhiều cuộc gọi phương thức trong Node mà không được trao một hàm để sử dụng sau này. Một điều trở nên rất rõ ràng rất nhanh trong Node là bạn đang ở trong một thế giới xấu xí nếu bạn không tìm cách xử lý kim tự tháp gọi lại. ví dụ

//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
    e.fileObj.find('some snippet', function(e){
        someFinalCallBackHandler( e.snippetLocations );
    } );
} );

May mắn thay, có rất nhiều công cụ và ví dụ ngoài kia để xử lý việc này tốt hơn. Hầu hết có xu hướng xoay quanh các cơ chế hứa hẹn và chỉ đơn giản là xâu chuỗi một loạt các chức năng nhằm đáp ứng các trạng thái gọi lại của nhau trong một mảng thực hiện công cụ kim tự tháp xấu xí cho bạn dưới mui xe.

Cá nhân, tôi rất thích tình yêu rằng chúng tôi có được JS ở mức cao và C / C ++ gần với chrome hơn. Đó là sự kết hợp tuyệt vời và nó thôi thúc tôi bắt đầu học C. Và đừng để việc thiếu tiềm năng thư viện làm bạn hoảng sợ cho đến khi bạn thực hiện một số nghiên cứu. Các thư viện nút đang được sản xuất với tốc độ rất nhanh và đang trưởng thành rất nhanh. Nếu bạn không làm bất cứ điều gì tỷ lệ cược cao bất thường là tốt thì ai đó đã bảo hiểm.

Sự khác biệt lớn nhất từ ​​Rails, là JS không bao giờ có khả năng nằm trên đường ray như trước đây. Chúng tôi có xu hướng mã hóa để có thể có nó tuy nhiên bạn muốn nó rất nhanh vì vậy có một sợi dây để tự treo mình với yếu tố và kiến ​​trúc đã khá DIY trong JS cho đến những năm gần đây. Tôi gọi đó là sự tự do, nhưng tôi nhận ra rằng đó không phải là lý tưởng cho nhiều nhà phát triển.

Ngoài ra, bạn sẽ không bao giờ gặp sự cố "đá quý" trong Node.js vì bạn đã cố cài đặt trên một thứ khác ngoài máy Mac. Các nhà phát triển web phía khách hàng coi thường các vấn đề phụ thuộc và đó là nơi có rất nhiều cốt lõi của Node. Nếu nó không hoạt động trong vòng 5 phút hoặc ít hơn trên mọi nền tảng phổ biến, chúng tôi thường vò nó và ném nó. Tôi vẫn chưa chạy vào một mô-đun phổ biến yêu cầu tôi làm bất cứ điều gì đặc biệt để làm cho nó hoạt động. Hệ thống trọn gói, là tuyệt vời.

Nhưng để trả lời câu hỏi cốt lõi của bạn rõ ràng / ngắn gọn hơn: Nó có tốt với các quy trình nền không?

Có, về cơ bản, Node xử lý nền IS với phương tiện điều khiển ứng dụng thông qua các sự kiện và cuộc gọi lại.


1
Có rất nhiều thông tin chung ở đây, nhưng bạn chưa nói gì về khả năng của node.js để xử lý các yêu cầu không đồng bộ.
Robert Harvey

Điểm tốt. Tôi sẽ tập trung hơn vào đó.
Erik Reppen

Là một nhà phát triển Rails trước đây và một nhà phát triển Node.js bán kinh nghiệm, tôi hoàn toàn không đồng ý với việc so sánh hệ thống gói giữa thế giới Ruby / Rails và thế giới JS / Node.js do Erik thực hiện. Bất kỳ nhà phát triển Rails có kinh nghiệm (hoặc thậm chí không có kinh nghiệm) đều biết rằng "đá quý", theo nghĩa đen, giống như đá quý. Họ làm việc nỗ lực. Hầu hết trong số họ được thử nghiệm tốt, mạnh mẽ và ổn định. Tuy nhiên, hơn một nửa các mô-đun NPM được thiết kế kém, không được thử nghiệm và thậm chí không hoàn thành. Ví dụ, không ai có thể chỉ cho tôi thay thế JS của Devise hoặc Paperclip với chất lượng và tính năng phong phú chính xác như nhau. Không đời nào.
rùng rợn

Đó không phải là kinh nghiệm của tôi về bất cứ thứ gì khác ngoài máy Mac. Điều đó nói rằng, tôi ít ấn tượng với khả năng tương thích hệ điều hành chéo của mô-đun nút điển hình của bạn so với trước đây. Không chắc chắn liệu tôi có gặp phải nhiều trứng xấu hơn với kinh nghiệm hay cộng đồng đã phát triển để bao gồm rất nhiều nhà phát triển không thực hiện đa nền tảng nghiêm túc như họ nên làm. Nhưng chắc chắn có một số kẻ hợm hĩnh Linux ngoài kia.
Erik Reppen 04/07/2015

Câu trả lời này xứng đáng nhận được rất nhiều sự ủng hộ
Amin Mohamed Aeve

2

Một vấn đề cần lưu ý là điều gì xảy ra khi xử lý các tệp lớn trong môi trường không đồng bộ : nếu luồng đầu vào của bạn (tệp) nhanh hơn luồng đầu ra (db) thì bạn sẽ không thể xử lý nhanh các sự kiện dữ liệu đầu vào đủ. Điều này sẽ áp đảo một số phần của hệ thống của bạn (luồng đầu ra hoặc bộ nhớ) hoặc khiến bạn mất dữ liệu. Vì lý do này, xử lý dữ liệu không đồng bộ có thể hơi khó khăn. Nhưng như bài viết tôi liên kết để giải thích, khả năng tạm dừng luồng đầu vào giúp bạn có thể điều tiết theo cách phù hợp với tình huống của bạn.


1

Node.js vượt trội tại IO. Bạn rất khó có thể phát hiện ra một ngày nào đó quá trình của bạn bị kẹt vì hầu hết các luồng của bạn đang chặn trong các cuộc gọi SQL.

Tuy nhiên, node.js thực sự rất tệ trong công việc liên kết tính toán. Khi tôi nghe thấy "rất nhiều IO", tôi nghĩ "yeah! Go node!", Nhưng khi tôi nghe "phân tích cú pháp", tôi hơi do dự một chút. Tôi không chắc chắn liệu điều này có vì bất kỳ lý do nào ngoài việc mọi người không xử lý nút đa luồng một cách chính xác hay không, nhưng cho đến nay tất cả các công việc liên kết tính toán của sản phẩm của tôi đều xảy ra bên ngoài nút.

Đa luồng trong node.js rất khó để thiết lập đúng. Mọi thứ đều được phân luồng theo mặc định và hầu hết mã được viết theo giả định rằng nó sẽ chỉ chạy dưới một luồng. Bạn chắc chắn sẽ cần phải sử dụng các tên miền để ngăn lỗi trên một luồng làm giảm toàn bộ ứng dụng của bạn.

Cũng lưu ý rằng nút có thể yếu hơn một chút trong một số khả năng của doanh nghiệp. Chẳng hạn, các thư viện ghi nhật ký của nó không so sánh với Java. Hiện tại không có khung ghi nhật ký tốt nào thậm chí hỗ trợ và MDC, trong thực tế có nghĩa là bạn phải làm rất nhiều việc var logPrefix = userId + ": ".

Tôi cũng chưa bao giờ chạy repo npm riêng, bạn có thể cần một trong những thứ này tùy thuộc vào việc mã của bạn có thuộc sở hữu hay không.


1

Nếu các quá trình nền của bạn có thể chạy tuần tự, nó có thể khá tốt. Ở vị trí cuối cùng của tôi, tôi đã phải viết một số bộ xử lý trước, xuất khẩu và dịch vụ dịch thuật cho nhiều nguồn dữ liệu. Sử dụng NodeJS là một cách dễ dàng ở đây.

Nếu bạn không thực hiện nhiều xử lý ràng buộc tính toán, thao tác đơn giản các chuỗi ngắn và phân tích số nguyên không quá tệ, nếu bạn cần thao tác với hình ảnh, nó có thể không phải là công cụ tốt nhất (mặc dù có các trình bao bọc và mô-đun có thể gọi được có thể hoạt động tốt).

Tư vấn, bám vào các mô-đun sử dụng luồng. Điều này có thể làm cho việc xử lý các mô-đun của bạn thành các bước cụ thể dễ dàng hơn. Ví dụ, nếu bạn nhìn vào cách sử dụng luồng sự kiện trong gulp-jade cho công cụ xây dựng gulp , bạn có thể thấy khả năng của nó.

Đối với CSV, bạn có thể sử dụng nút-csv , điều này khá tốt trong việc thiết lập cơ sở cho các bản ghi đường ống đến luồng bộ xử lý.

Đối với XML có kích thước lớn, tại đó bạn muốn thực hiện một bản ghi tại một thời điểm, tôi sẽ xem xét một nửa nút nửa dòng đọc qua luồng XML của bạn bằng bộ xử lý SAX và tăng các sự kiện cho mỗi nút. Tôi sẽ gói nó thành một luồng đọc / ghi để bạn có thể nâng cao các trận đấu mong muốn của mình. Nhiều trình phân tích cú pháp đối tượng xml trong nút sẽ cố gắng đọc / phân tích toàn bộ xml cùng một lúc và giả sử 100mb xml trở nên rất lớn ... trong đó nửa dòng sẽ đọc dưới dạng luồng.

LƯU Ý: có các bộ xử lý khác như xml-stream sẽ sử dụng expat (thư viện C) bên dưới, có thể mang lại hiệu năng cao hơn, nhưng ít di động hơn mà không có môi trường xây dựng.

Nói chung, đó là một niềm vui thực sự để sử dụng ...

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.