Điều gì làm cho Erlang phù hợp cho các ứng dụng đám mây?

Chúng tôi đang bắt đầu một dự án mới và triển khai trên nền tảng đám mây openstack của tập đoàn chúng tôi (xem http://www.openstack.org/ ). Dự án là công cụ bảo mật cho tập đoàn của chúng tôi. Chúng tôi hiện đang điều hành hàng trăm máy chủ chuyên dụng cho các công cụ bảo mật và đang chuyển chúng sang tập đoàn của chúng tôi ngay lập tức về openstack.

Các dự án khác trong công ty của tôi hiện đang sử dụng erlang trong một số ứng dụng máy chủ phân tán và Q / A khác chỉ ra erlang được sử dụng trong một số dịch vụ đám mây phổ biến. Tôi đang cố gắng thuyết phục người khác xem xét nơi nào có thể áp dụng cho dự án của chúng tôi.

Thế mạnh của erlang cho lập trình đám mây là gì? Đâu là khu vực đặc biệt thích hợp để sử dụng erlang?

cloud-computing erlang

— Duncan
nguồn

Xác định "đám mây" và chúng tôi có thể cho bạn biết những gì bạn có thể muốn biết. Thuật ngữ "đám mây" là tiếp thị nói và có nghĩa là một cái gì đó khác nhau đối với mỗi người sử dụng nó.

Tôi nghĩ rằng nói đám mây openstack sẽ đủ định nghĩa về những gì chúng ta đang thực hiện. Xem openstack.org . Hay bạn đang yêu cầu thêm thông tin về dự án? Đó là công cụ bảo mật cho tập đoàn của chúng tôi. Chúng tôi hiện đang điều hành hàng trăm máy chủ chuyên dụng cho các công cụ bảo mật và đang chuyển chúng sang tập đoàn của chúng tôi ngay lập tức về openstack.

— Duncan

Tôi đã chỉnh sửa câu hỏi để hy vọng làm cho nó tốt hơn và loại bỏ mối quan tâm 'tiếp thị'. Vấn đề của tôi là chọn công cụ tốt nhất cho công việc. Tôi là một tân binh tại stackexchange vì vậy không hoàn toàn hiểu rõ về nó.

— Duncan

cụ thể, thuật ngữ "đám mây" là không rõ ràng và không có nghĩa cụ thể, đó là tiếp thị, bạn vẫn chưa xác định được điều gì thực sự đủ điều kiện là một ứng dụng đám mây . Cá nhân tôi biết những gì tôi biết những gì tôi nghĩ nó có nghĩa là gì, tôi chắc chắn đó không phải là những gì bạn nghĩ nó có nghĩa , đưa ra câu hỏi.

"Thuật ngữ" đám mây "là mơ hồ" - tốt! Nó có nghĩa là một cái gì đó ảo và bạn nên xác định xem "cái gì đó" là phần mềm, hệ điều hành, một máy đơn, đa máy và mạng hay cái gì khác.

— GlenPeterson

Câu trả lời:

Khác với thực tế là Erlang được phát triển đặc biệt để chạy trong các tình huống đồng thời / song song / phân tán, hai kỹ thuật chính mà nó sử dụng làm cho điều này có thể là:

Không có tác dụng phụ:

Điều này có nghĩa là, khi bạn cung cấp cho hàm một phần dữ liệu để thực thi, nó sẽ không ngoại trừ trong các trường hợp rất nghiêm ngặt ảnh hưởng đến bất kỳ điều gì khác trong quy trình / hệ thống đang chạy. Điều này có nghĩa là nếu bạn thực hiện đồng thời 300 lần một hàm, không ai trong số 300 lần thực thi của hàm đó sẽ ảnh hưởng đến bất kỳ hàm nào khác.

Kỹ thuật thực hiện để đảm bảo không có tác dụng phụ được gọi là "bất biến" có nghĩa là có thể không bị thay đổi (thay đổi). Điều này có nghĩa là ngay khi bạn tạo một biến, giá trị của biến đó có thể không được sửa đổi. Erlang thực hiện hành vi này với "chuyển nhượng đơn" vì vậy sau khi bạn gán giá trị cho một biến, bạn không thể gán lại giá trị cho nó.

X = 1.
X = 2. // This is not a valid operation

Điều này đảm bảo không có mã nào có thể vô tình thay đổi giá trị của X gây ra tình trạng chủng tộc, do đó, nó vốn đã an toàn cho luồng và việc sử dụng đồng thời trở nên tầm thường. Đây là một hành vi rất không phổ biến giữa các ngôn ngữ phần mềm và cách lớn nhất mà Erlang quản lý rất phù hợp để thực hiện đồng thời.

Người mẫu diễn viên:

Đây là một cách đặc biệt của mô hình hóa đã cho thấy việc thực hiện và quản lý xử lý đồng thời rất đơn giản cho các nhà phát triển. Trực tiếp từ wikipedia (http://en.wikipedia.org/wiki/Actor_model):

Mô hình diễn viên chấp nhận triết lý rằng mọi thứ đều là diễn viên. Điều này tương tự như mọi thứ là một triết lý đối tượng được sử dụng bởi một số ngôn ngữ lập trình hướng đối tượng, nhưng khác ở phần mềm hướng đối tượng đó thường được thực hiện tuần tự, trong khi mô hình Actor vốn dĩ đồng thời. Một tác nhân là một thực thể tính toán, để đáp lại một thông điệp mà nó nhận được, có thể đồng thời: gửi một số lượng tin nhắn hữu hạn cho các tác nhân khác; tạo ra một số lượng hữu hạn các diễn viên mới; chỉ định hành vi sẽ được sử dụng cho thông điệp tiếp theo mà nó nhận được. Không có trình tự giả định cho các hành động trên và chúng có thể được thực hiện song song. Việc tách người gửi khỏi các liên lạc được gửi là một tiến bộ cơ bản của mô hình Actor cho phép các cấu trúc điều khiển và giao tiếp không đồng bộ dưới dạng các mẫu của việc truyền tin nhắn.

— Jimmy Hoffa
nguồn

Về "Không có tác dụng phụ" bạn nói "Đây là một hành vi rất không phổ biến giữa các ngôn ngữ phần mềm" - tôi hơi ngạc nhiên về điều này. Java và C # không thể làm điều này ngày hôm nay? Những ngôn ngữ nào bạn biết rằng phải có tác dụng phụ khi gọi một chức năng?

— NoChance

@EmmadKareem Đây không phải là câu hỏi liệu bạn có thể viết chương trình mà không có tác dụng phụ hay không; như bạn đã lưu ý, bạn có thể làm điều này trong Java hoặc C #. Đó là liệu mặc định có hiệu ứng phụ hay không và có hỗ trợ trình biên dịch cho việc này hay không. Trong Java, bạn không thể, ví dụ, nói với trình biên dịch "phương pháp này không có tác dụng phụ". Đến lượt điều này có nghĩa là trình biên dịch không thể cảnh báo bạn khi bạn vi phạm các quy tắc!

— Andres F.

@EmmadKareem Tôi không nói rằng không thể viết C # hoặc java mà không có tác dụng phụ (mặc dù cực kỳ hiếm), nhưng tôi nói rằng rất ít ngôn ngữ lập trình có chính sách nghiêm ngặt được xây dựng thành ngôn ngữ tách biệt chức năng với các tác dụng phụ từ những thứ không có.

— Jimmy Hoffa

Sẽ thật tuyệt nếu Java có chú thích @NoSideEffects để đưa vào một phương thức để báo cho trình biên dịch thực thi các tác dụng phụ cho phương thức đó. Trong mã riêng của tôi, tôi muốn nghĩ rằng các phương thức không có tác dụng phụ là phổ biến. Chắc chắn, một số phương thức phải là trình biến đổi trong một ngôn ngữ như Java, nhưng nhiều phương thức thì không. Đặc biệt nếu bạn thích các đối tượng bất biến trong thiết kế của bạn.

— GlenPeterson

Jimmy Hoffa và @AndresF., Cảm ơn bạn đã làm rõ.

— NoChance

Erlang đặc biệt mạnh trong tính toán đồng thời / song song. Trong thực tế, nó được thiết kế ban đầu cho mục đích đó. Nó không liên quan gì đến đám mây, ngoại trừ các ứng dụng nặng tính toán được song song hóa và triển khai trong các trường hợp "đám mây" để giúp tăng / giảm công suất theo yêu cầu dễ dàng hơn.

Phần còn lại chỉ là tiếp thị nói.

— pap
nguồn

Erlang được thiết kế để tính toán chịu lỗi . Chỉ có điện toán phân tán là điều kiện tiên quyết cho điều đó (làm thế nào bạn có thể trả lại kết quả một cách đáng tin cậy nếu ai đó vô tình làm đổ cà phê qua máy đơn của bạn, bạn cần ít nhất hai máy) và điện toán song song và đồng thời chỉ là trường hợp đặc biệt của điện toán phân tán, vì vậy Erlang cũng xảy ra để được tốt ở những người. Nhưng đó không phải là những gì nó được thiết kế cho.

— Jörg W Mittag

@ JörgWMittag Miễn là chúng ta chia tóc ... vâng, mục đích của nó là đạt được khả năng chịu lỗi. Nó đạt được điều này thông qua song song hóa. Nó được thiết kế để thực hiện điều này trong tổng đài điện thoại kỹ thuật số AX mang hai ống tính toán song song bị cô lập với một ống làm việc ở chế độ chờ nóng.

— pap

Vâng, xin lỗi, tôi cần phải có được rõ ràng hơn: điện toán đám mây được phân phối khá nhiều theo định nghĩa, và nó thường (không phải lúc nào nhưng thường) được thực hiện bởi các cụm rẻ tiền và quan trọng hơn là không đáng tin cậy máy nhưng được thiết kế để cung cấp một dịch vụ đáng tin cậy. Đó là những gì làm cho Erlang rất phù hợp.

— Jörg W Mittag

Một khía cạnh của đám mây khác với triển khai phần cứng truyền thống là sự dễ dàng mà bạn có thể tạo ra các phiên bản mới khi cần. Khả năng giám sát các nút khác và xử lý trên các nút khác, giúp việc xây dựng các hệ thống rất năng động có thể thêm hoặc loại bỏ vms và quản lý chúng khi cần thiết tương đối đơn giản.

Điều này đặc biệt như vậy nếu bạn đang xây dựng hệ thống của mình bằng khung OTP (Open Telecom PL Platform) của erlang, cung cấp cả cấu trúc và cơ chế (cây giám sát) để hỗ trợ xây dựng một số thứ khá phức tạp với ít hiệu ứng hơn bạn tưởng tượng. Erlang xử lý tất cả các bit khó khăn để bạn không phải.

— Garry Hodgson
nguồn