Thế giới không đứng yên. Tiến bộ tạo ra những thách thức công nghệ mới. Để phù hợp với những yêu cầu thay đổi, kiến trúc của hệ thống thông tin phải phát triển. Hôm nay chúng ta sẽ nói về kiến trúc hướng sự kiện, tính đồng thời, tính đồng thời, tính không đồng bộ và cách bạn có thể chung sống hòa bình với tất cả những điều này trong Erlang.
Giới thiệu
Tùy thuộc vào quy mô của hệ thống được thiết kế và các yêu cầu đối với nó, chúng tôi, những nhà phát triển, chọn phương thức trao đổi thông tin trong hệ thống. Trong hầu hết các trường hợp, để tổ chức tương tác giữa các dịch vụ, một tùy chọn hoạt động có thể là một chương trình với nhà môi giới, chẳng hạn như dựa trên RabbitMQ hoặc kafka. Nhưng đôi khi luồng sự kiện, SLA và mức độ kiểm soát hệ thống khiến tin nhắn tạo sẵn không phù hợp với chúng tôi. Tất nhiên, bạn có thể làm phức tạp hệ thống một chút bằng cách chịu trách nhiệm về việc hình thành lớp vận chuyển và cụm, chẳng hạn như sử dụng ZeroMQ hoặc nanomsg. Nhưng nếu hệ thống có đủ thông lượng và khả năng của cụm Erlang tiêu chuẩn thì vấn đề giới thiệu một thực thể bổ sung đòi hỏi phải có nghiên cứu chi tiết và biện minh kinh tế.
Chủ đề về các ứng dụng phân tán phản ứng khá rộng. Để giữ đúng định dạng của bài viết, chủ đề thảo luận hôm nay sẽ chỉ là các môi trường đồng nhất được xây dựng trên Erlang/Elixir. Hệ sinh thái Erlang/OTP cho phép bạn triển khai kiến trúc phản ứng với ít nỗ lực nhất. Nhưng trong mọi trường hợp, chúng ta sẽ cần một lớp nhắn tin.
Cơ sở lý thuyết
Thiết kế bắt đầu bằng việc xác định mục tiêu và ràng buộc. Mục tiêu chính không nằm ở lĩnh vực phát triển vì mục đích phát triển. Chúng ta cần có được một công cụ an toàn và có thể mở rộng, trên cơ sở đó chúng ta có thể tạo và quan trọng nhất là phát triển các ứng dụng hiện đại ở nhiều cấp độ khác nhau: bắt đầu từ các ứng dụng một máy chủ phục vụ một lượng nhỏ đối tượng, sau này có thể phát triển thành cụm lên tới 50 -60 nút, kết thúc bằng liên kết cụm. Vì vậy, mục tiêu chính là tối đa hóa lợi nhuận bằng cách giảm chi phí phát triển và quyền sở hữu hệ thống cuối cùng.
Chúng ta hãy nêu bật 4 yêu cầu chính cho hệ thống cuối cùng:
- Сhướng sự kiện.
Hệ thống luôn sẵn sàng vượt qua luồng sự kiện và thực hiện các hành động cần thiết; - Мkhả năng mở rộng.
Các khối riêng lẻ có thể được thu nhỏ theo cả chiều dọc và chiều ngang. Toàn bộ hệ thống phải có khả năng phát triển theo chiều ngang vô hạn; - Оkhả năng chịu lỗi.
Tất cả các cấp độ và tất cả các dịch vụ sẽ có thể tự động phục hồi sau các lỗi; - Гđảm bảo thời gian đáp ứng.
Thời gian rất quý giá và người dùng không nên chờ đợi quá lâu.
Bạn còn nhớ câu chuyện cổ tích về “Chiếc động cơ nhỏ có thể” không? Để hệ thống được thiết kế có thể thoát khỏi giai đoạn nguyên mẫu thành công và tiến bộ, nền tảng của nó phải đáp ứng các yêu cầu tối thiểu KHÓI BỤI.
Một điểm nữa được thêm vào tính năng nhắn tin như một công cụ cơ sở hạ tầng và nền tảng cho tất cả các dịch vụ: tính dễ sử dụng cho các lập trình viên.
Định hướng sự kiện
Để ứng dụng phát triển từ một máy chủ thành một cụm, kiến trúc của nó phải hỗ trợ khớp nối lỏng lẻo. Mô hình không đồng bộ đáp ứng yêu cầu này. Trong đó, người gửi và người nhận quan tâm đến việc tải thông tin của tin nhắn và không lo lắng về việc truyền tải và định tuyến trong hệ thống.
Khả năng mở rộng
Khả năng mở rộng và hiệu quả hệ thống nằm cạnh nhau. Các thành phần ứng dụng phải có khả năng sử dụng tất cả các tài nguyên có sẵn. Chúng ta có thể sử dụng năng lực càng hiệu quả và các phương pháp xử lý càng tối ưu thì chúng ta càng chi ít tiền hơn cho thiết bị.
Trong một chiếc máy duy nhất, Erlang tạo ra một môi trường có tính cạnh tranh cao. Sự cân bằng giữa tính đồng thời và song song có thể được thiết lập bằng cách chọn số lượng luồng hệ điều hành có sẵn cho máy ảo Erlang và số lượng bộ lập lịch sử dụng các luồng này.
Các quy trình Erlang không chia sẻ trạng thái và hoạt động ở chế độ không chặn. Điều này mang lại độ trễ tương đối thấp và thông lượng cao hơn so với các ứng dụng dựa trên tính năng chặn truyền thống. Bộ lập lịch của Erlang đảm bảo phân bổ CPU và IO hợp lý, đồng thời việc không bị chặn cho phép ứng dụng phản hồi ngay cả khi tải hoặc lỗi cao điểm.
Ở cấp độ cụm, vấn đề xử lý cũng tồn tại. Điều quan trọng là tất cả các máy trong cụm đều được tải đồng đều và mạng không bị quá tải. Hãy tưởng tượng một tình huống: lưu lượng truy cập của người dùng đến các bộ cân bằng đến (haproxy, nginx, v.v.), họ phân phối các yêu cầu xử lý đồng đều nhất có thể giữa tập hợp các chương trình phụ trợ có sẵn. Trong cơ sở hạ tầng ứng dụng, dịch vụ triển khai giao diện được yêu cầu chỉ mới ở chặng cuối và sẽ cần yêu cầu một số dịch vụ khác để đáp ứng yêu cầu ban đầu. Các yêu cầu nội bộ cũng yêu cầu định tuyến và cân bằng.
Để quản lý hiệu quả các luồng dữ liệu, tính năng nhắn tin phải cung cấp cho nhà phát triển một giao diện để quản lý việc định tuyến và cân bằng tải. Nhờ đó, các nhà phát triển sẽ có thể sử dụng các mẫu microservice (tập hợp, proxy, chuỗi, chi nhánh, v.v.) để giải quyết cả các vấn đề tiêu chuẩn và những vấn đề hiếm khi phát sinh.
Từ quan điểm kinh doanh, khả năng mở rộng là một trong những công cụ quản lý rủi ro. Điều chính là đáp ứng yêu cầu của khách hàng bằng cách sử dụng thiết bị một cách tối ưu:
- Khi sức mạnh của thiết bị tăng lên do sự tiến bộ. Nó sẽ không ở trạng thái nhàn rỗi do phần mềm không hoàn hảo. Erlang có quy mô hoàn hảo theo chiều dọc và sẽ luôn có thể sử dụng tất cả các lõi CPU và bộ nhớ khả dụng;
- Trong môi trường đám mây, chúng tôi có thể quản lý số lượng thiết bị tùy thuộc vào tải hiện tại hoặc dự đoán và đảm bảo SLA.
khả năng chịu lỗi
Hãy xem xét hai tiên đề: “Thất bại là không thể chấp nhận được” và “Sẽ luôn có những thất bại”. Đối với một doanh nghiệp, lỗi phần mềm có nghĩa là mất tiền và tệ hơn là mất danh tiếng. Cân bằng giữa những tổn thất có thể xảy ra và chi phí phát triển phần mềm có khả năng chịu lỗi, thường có thể tìm thấy một sự thỏa hiệp.
Trong ngắn hạn, một kiến trúc kết hợp khả năng chịu lỗi sẽ tiết kiệm tiền khi mua các giải pháp phân cụm có sẵn. Chúng đắt tiền và chúng cũng có lỗi.
Về lâu dài, một kiến trúc có khả năng chịu lỗi sẽ tự mang lại lợi ích gấp nhiều lần ở tất cả các giai đoạn phát triển.
Nhắn tin trong cơ sở mã cho phép bạn tìm hiểu chi tiết về sự tương tác của các thành phần trong hệ thống ở giai đoạn phát triển. Điều này giúp đơn giản hóa nhiệm vụ ứng phó và quản lý lỗi, vì tất cả các thành phần quan trọng đều xử lý lỗi và hệ thống kết quả biết cách tự động trở lại bình thường sau lỗi do thiết kế.
Khả năng đáp ứng
Bất kể lỗi xảy ra, ứng dụng phải đáp ứng các yêu cầu và đáp ứng SLA. Thực tế là người dân không muốn chờ đợi nên doanh nghiệp phải thích ứng cho phù hợp. Ngày càng có nhiều ứng dụng được kỳ vọng sẽ có khả năng phản hồi cao.
Các ứng dụng đáp ứng hoạt động gần như theo thời gian thực. Erlang VM hoạt động ở chế độ thời gian thực mềm. Đối với một số lĩnh vực, chẳng hạn như giao dịch chứng khoán, y học và kiểm soát thiết bị công nghiệp, chế độ thời gian thực cứng rất quan trọng.
Hệ thống đáp ứng cải thiện UX và mang lại lợi ích cho doanh nghiệp.
Tóm tắt sơ bộ
Khi lập kế hoạch cho bài viết này, tôi muốn chia sẻ kinh nghiệm của mình trong việc tạo một nhà môi giới nhắn tin và xây dựng các hệ thống phức tạp dựa trên nó. Nhưng phần lý thuyết và động lực hóa ra lại khá rộng rãi.
Trong phần thứ hai của bài viết, tôi sẽ nói về các sắc thái của việc triển khai điểm trao đổi, mô hình nhắn tin và ứng dụng của chúng.
Trong phần thứ ba chúng ta sẽ xem xét các vấn đề chung về tổ chức dịch vụ, định tuyến và cân bằng. Hãy nói về khía cạnh thực tế của khả năng mở rộng và khả năng chịu lỗi của hệ thống.
Hết phần thứ nhất.
Hình ảnh .
Nguồn: www.habr.com