Vào ngày 26 tháng XNUMX, chúng tôi đã tổ chức cuộc gặp gỡ Apache Ignite GreenSource, nơi những người đóng góp cho dự án nguồn mở phát biểu . Một sự kiện quan trọng trong đời sống của cộng đồng này là việc tái cơ cấu thành phần , cho phép bạn triển khai các vi dịch vụ tùy chỉnh trực tiếp vào cụm Ignite. Anh ấy đã nói về quá trình khó khăn này tại buổi gặp mặt , kỹ sư phần mềm và người đóng góp cho Apache Ignite trong hơn hai năm.
Hãy bắt đầu với Apache Ignite nói chung là gì. Đây là cơ sở dữ liệu là nơi lưu trữ Khóa/Giá trị phân tán có hỗ trợ SQL, giao dịch và bộ nhớ đệm. Ngoài ra, Ignite cho phép bạn triển khai các dịch vụ tùy chỉnh trực tiếp vào cụm Ignite. Nhà phát triển có quyền truy cập vào tất cả các công cụ mà Ignite cung cấp - cấu trúc dữ liệu phân tán, Nhắn tin, Truyền phát, Điện toán và Lưới dữ liệu. Ví dụ: khi sử dụng Lưới dữ liệu, vấn đề quản lý cơ sở hạ tầng riêng biệt để lưu trữ dữ liệu và do đó, chi phí chung phát sinh sẽ biến mất.
Bằng cách sử dụng API lưới dịch vụ, bạn có thể triển khai một dịch vụ bằng cách chỉ định sơ đồ triển khai và theo đó, chính dịch vụ đó trong cấu hình.
Thông thường, sơ đồ triển khai là dấu hiệu cho thấy số lượng phiên bản cần được triển khai trên các nút cụm. Có hai phương án triển khai điển hình. Đầu tiên là Cluster Singleton: tại bất kỳ thời điểm nào, một phiên bản của dịch vụ người dùng được đảm bảo có sẵn trong cụm. Thứ hai là Node Singleton: một phiên bản của dịch vụ được triển khai trên mỗi nút cụm.
Người dùng cũng có thể chỉ định số lượng phiên bản dịch vụ trong toàn bộ cụm và xác định vị từ để lọc các nút phù hợp. Trong kịch bản này, chính Service Grid sẽ tính toán phân phối tối ưu để triển khai dịch vụ.
Ngoài ra, còn có một tính năng như Dịch vụ mối quan hệ. Mối quan hệ là một hàm xác định mối quan hệ của các khóa với các phân vùng và mối quan hệ của các bên với các nút trong cấu trúc liên kết. Sử dụng khóa, bạn có thể xác định nút chính nơi dữ liệu được lưu trữ. Bằng cách này, bạn có thể liên kết dịch vụ của riêng mình với bộ đệm chức năng khóa và chức năng đồng dạng. Nếu chức năng ái lực thay đổi, việc triển khai lại tự động sẽ diễn ra. Bằng cách này, dịch vụ sẽ luôn được đặt gần dữ liệu mà nó cần thao tác và theo đó, giảm chi phí truy cập thông tin. Sơ đồ này có thể được gọi là một loại tính toán phối hợp.
Bây giờ chúng ta đã hiểu được vẻ đẹp của Service Grid là gì, hãy nói về lịch sử phát triển của nó.
Trước đây là gì
Việc triển khai Service Grid trước đây dựa trên bộ đệm hệ thống được sao chép giao dịch của Ignite. Từ "bộ đệm" trong Ignite dùng để chỉ bộ nhớ. Nghĩa là, đây không phải là điều gì đó tạm thời như bạn nghĩ. Mặc dù thực tế là bộ đệm được sao chép và mỗi nút chứa toàn bộ tập dữ liệu, nhưng bên trong bộ đệm, nó có một biểu diễn được phân vùng. Điều này là do tối ưu hóa lưu trữ.
Điều gì xảy ra khi người dùng muốn triển khai dịch vụ?
- Tất cả các nút trong cụm đã đăng ký cập nhật dữ liệu trong bộ lưu trữ bằng cơ chế Truy vấn liên tục được tích hợp sẵn.
- Nút khởi tạo, trong giao dịch cam kết đọc, đã tạo một bản ghi trong cơ sở dữ liệu chứa cấu hình dịch vụ, bao gồm cả phiên bản được tuần tự hóa.
- Khi được thông báo về mục mới, điều phối viên đã tính toán phân bổ dựa trên cấu hình. Đối tượng kết quả đã được ghi lại vào cơ sở dữ liệu.
- Nếu một nút là một phần của phân phối thì điều phối viên phải triển khai nó.
Điều gì không phù hợp với chúng tôi
Tại một thời điểm nào đó, chúng tôi đã đi đến kết luận: đây không phải là cách làm việc với các dịch vụ. Có một số lý do.
Nếu xảy ra lỗi nào đó trong quá trình triển khai thì lỗi đó chỉ có thể được phát hiện từ nhật ký của nút nơi mọi thứ xảy ra. Chỉ có triển khai không đồng bộ, vì vậy sau khi trả lại quyền kiểm soát cho người dùng từ phương thức triển khai, cần thêm thời gian để khởi động dịch vụ - và trong thời gian này, người dùng không thể kiểm soát bất cứ điều gì. Để phát triển Lưới dịch vụ hơn nữa, tạo ra các tính năng mới, thu hút người dùng mới và giúp cuộc sống của mọi người dễ dàng hơn, cần phải thay đổi một số điều.
Khi thiết kế Lưới dịch vụ mới, trước hết chúng tôi muốn đảm bảo triển khai đồng bộ: ngay khi người dùng trả lại quyền kiểm soát từ API, anh ta có thể sử dụng dịch vụ ngay lập tức. Tôi cũng muốn cung cấp cho người khởi xướng khả năng xử lý các lỗi triển khai.
Ngoài ra, tôi muốn đơn giản hóa việc thực hiện, cụ thể là thoát khỏi các giao dịch và tái cân bằng. Mặc dù thực tế là bộ đệm được sao chép và không có sự cân bằng, nhưng các vấn đề vẫn nảy sinh trong quá trình triển khai quy mô lớn với nhiều nút. Khi cấu trúc liên kết thay đổi, các nút cần trao đổi thông tin và với việc triển khai lớn, dữ liệu này có thể có trọng lượng rất lớn.
Khi cấu trúc liên kết không ổn định, điều phối viên cần tính toán lại việc phân phối dịch vụ. Và nói chung, khi bạn phải làm việc với các giao dịch trên cấu trúc liên kết không ổn định, điều này có thể dẫn đến những lỗi khó dự đoán.
Vấn đề
Những thay đổi toàn cầu mà không có vấn đề đi kèm là gì? Đầu tiên trong số này là một sự thay đổi trong cấu trúc liên kết. Bạn cần hiểu rằng tại bất kỳ thời điểm nào, kể cả thời điểm triển khai dịch vụ, một nút có thể vào hoặc rời khỏi cụm. Hơn nữa, nếu tại thời điểm triển khai, nút tham gia cụm, thì cần phải chuyển nhất quán tất cả thông tin về các dịch vụ sang nút mới. Và chúng ta đang nói không chỉ về những gì đã được triển khai mà còn về những triển khai hiện tại và tương lai.
Đây chỉ là một trong những vấn đề có thể được thu thập trong một danh sách riêng:
- Làm cách nào để triển khai các dịch vụ được cấu hình tĩnh khi khởi động nút?
- Rời khỏi một nút khỏi cụm - phải làm gì nếu nút đó lưu trữ các dịch vụ?
- Phải làm gì nếu điều phối viên đã thay đổi?
- Phải làm gì nếu máy khách kết nối lại với cụm?
- Các yêu cầu kích hoạt/hủy kích hoạt có cần được xử lý không và xử lý như thế nào?
- Điều gì sẽ xảy ra nếu họ kêu gọi hủy bộ nhớ đệm và chúng tôi có các dịch vụ liên quan gắn liền với nó?
Và đó không phải là tất cả.
phán quyết
Với mục tiêu, chúng tôi đã chọn phương pháp Hướng sự kiện với việc triển khai giao tiếp quy trình bằng tin nhắn. Ignite đã triển khai hai thành phần cho phép các nút chuyển tiếp tin nhắn với nhau - Communications-spi và Discovery-spi.
Communication-spi cho phép các nút giao tiếp trực tiếp và chuyển tiếp tin nhắn. Nó rất phù hợp để gửi một lượng lớn dữ liệu. Discovery-spi cho phép bạn gửi tin nhắn đến tất cả các nút trong cụm. Trong triển khai tiêu chuẩn, việc này được thực hiện bằng cách sử dụng cấu trúc liên kết vòng. Ngoài ra còn có sự tích hợp với Zookeeper, trong trường hợp này cấu trúc liên kết sao được sử dụng. Một điểm quan trọng khác cần lưu ý là Discovery-spi đảm bảo rằng thông báo chắc chắn sẽ được gửi theo đúng thứ tự tới tất cả các nút.
Hãy nhìn vào giao thức triển khai. Tất cả các yêu cầu triển khai và hủy triển khai của người dùng đều được gửi qua Discovery-spi. Điều này mang lại những điều sau đây sự bảo đảm:
- Yêu cầu sẽ được nhận bởi tất cả các nút trong cụm. Điều này sẽ cho phép yêu cầu tiếp tục xử lý khi điều phối viên thay đổi. Điều này cũng có nghĩa là trong một thông báo, mỗi nút sẽ có tất cả siêu dữ liệu cần thiết, chẳng hạn như cấu hình dịch vụ và phiên bản được xê-ri hóa của nó.
- Thứ tự gửi tin nhắn nghiêm ngặt giúp giải quyết xung đột cấu hình và các yêu cầu cạnh tranh.
- Vì mục nhập của nút vào cấu trúc liên kết cũng được xử lý thông qua Discovery-spi nên nút mới sẽ nhận được tất cả dữ liệu cần thiết để làm việc với các dịch vụ.
Khi nhận được yêu cầu, các nút trong cụm sẽ xác thực yêu cầu đó và tạo các tác vụ xử lý. Các tác vụ này được xếp hàng đợi và sau đó được xử lý trong một luồng khác bởi một nhân viên riêng biệt. Nó được triển khai theo cách này vì việc triển khai có thể mất một lượng thời gian đáng kể và làm chậm quá trình khám phá tốn kém đến mức không thể chấp nhận được.
Tất cả các yêu cầu từ hàng đợi đều được người quản lý triển khai xử lý. Nó có một nhân viên đặc biệt lấy một tác vụ từ hàng đợi này và khởi tạo nó để bắt đầu triển khai. Sau đó, các hành động sau sẽ xảy ra:
- Mỗi nút tính toán phân phối độc lập nhờ chức năng gán xác định mới.
- Các nút tạo một thông báo về kết quả triển khai và gửi nó đến điều phối viên.
- Điều phối viên tổng hợp tất cả các thông báo và tạo ra kết quả của toàn bộ quá trình triển khai, được gửi qua Discovery-spi tới tất cả các nút trong cụm.
- Khi nhận được kết quả, quá trình triển khai kết thúc, sau đó tác vụ sẽ bị xóa khỏi hàng đợi.
Thiết kế hướng sự kiện mới: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Nếu xảy ra lỗi trong quá trình triển khai, nút sẽ ngay lập tức đưa lỗi này vào thông báo gửi đến điều phối viên. Sau khi tổng hợp tin nhắn, điều phối viên sẽ có thông tin về tất cả các lỗi trong quá trình triển khai và sẽ gửi tin nhắn này qua Discovery-spi. Thông tin lỗi sẽ có sẵn trên bất kỳ nút nào trong cụm.
Tất cả các sự kiện quan trọng trong Lưới dịch vụ đều được xử lý bằng thuật toán vận hành này. Ví dụ: việc thay đổi cấu trúc liên kết cũng là một thông báo qua Discovery-spi. Và nhìn chung, khi so sánh với những gì trước đây, giao thức này khá nhẹ và đáng tin cậy. Đủ để xử lý mọi tình huống trong quá trình triển khai.
Chuyện gì sẽ xảy ra tiếp theo
Bây giờ về các kế hoạch. Bất kỳ thay đổi lớn nào đối với dự án Ignite đều được hoàn thành dưới dạng sáng kiến cải tiến Ignite, được gọi là IEP. Thiết kế lại Lưới Dịch vụ cũng có IEP - với tiêu đề chế giễu “Thay dầu trong lưới dịch vụ”. Nhưng thực tế là chúng tôi không thay dầu máy mà thay toàn bộ động cơ.
Chúng tôi chia các nhiệm vụ trong IEP thành 2 giai đoạn. Đầu tiên là giai đoạn chính, bao gồm việc làm lại giao thức triển khai. Nó đã được bao gồm trong bản gốc, bạn có thể thử Lưới dịch vụ mới, sẽ xuất hiện trong phiên bản 2.8. Giai đoạn thứ hai bao gồm nhiều nhiệm vụ khác:
- Triển khai lại nóng
- Phiên bản dịch vụ
- Tăng khả năng chịu lỗi
- Khách hàng mỏng
- Công cụ theo dõi và tính toán các số liệu khác nhau
Cuối cùng, chúng tôi có thể tư vấn cho bạn về Service Grid để xây dựng các hệ thống có khả năng chịu lỗi cao, tính sẵn sàng cao. Chúng tôi cũng mời bạn đến thăm chúng tôi tại и Chia sẻ kinh nghiệm của bạn. Kinh nghiệm của bạn thực sự quan trọng đối với cộng đồng; nó sẽ giúp bạn hiểu nơi cần đi tiếp, cách phát triển thành phần trong tương lai.
Nguồn: www.habr.com