3

Triển khai môi giới tin nhắn cho trường hợp sử dụng IoT đưa ra một số thách thức mới đối với khả năng mở rộng của nhà môi giới. Bây giờ chúng ta đang nói về hàng ngàn kết nối, người tiêu dùng và điểm đến, điều này khiến chúng ta nghĩ về cách chúng ta cung cấp, định cấu hình và giám sát cơ sở hạ tầng nhắn tin của mình cẩn thận hơn nhiều. Trong bài viết này, tôi sẽ cố gắng tổng hợp một số kỹ thuật có thể được sử dụng với Apache ActiveMQ hiện tại để mở rộng quy mô tốt hơn cho việc triển khai IoT. Tôi cũng sẽ mô tả một số tính năng mới mà chúng tôi đã phát triển cho phiên bản 5.12.0 để làm cho nó phù hợp hơn trong thế giới mới này. Và cuối cùng tôi sẽ cố gắng giải thích chúng ta có thể đi đâu từ đây và chúng ta có thể làm việc gì trong tương lai.

Mở rộng theo chiều dọc ActiveMQ

Hai giao thức nhắn tin phổ biến nhất được sử dụng cho IoT là MQTT và AMQP và chúng tôi đã dành một nỗ lực đáng kể để làm cho chúng trở nên vững chắc trong các bản phát hành mới nhất. Nhưng các giao thức không phải là tất cả mọi thứ và mỗi khi ai đó bắt đầu chơi với nhà môi giới, cùng một câu hỏi được đặt ra: Làm thế nào tôi có thể có được khả năng mở rộng tối đa từ cá thể môi giới duy nhất? Vì vậy, đây là một số lời khuyên:

  • Luôn luôn bắt đầu với các kỹ thuật mở rộng quy mô môi giới nói chung . Điều đó về cơ bản có nghĩa là cố gắng sử dụng các luồng tối thiểu nhất có thể cho dù có bao nhiêu kết nối và đích mà nhà môi giới của bạn xử lý. Vì vậy, sử dụng truyền tải NIO và lần lượt thiết lập luồng trên mỗi đích.
  • Việc triển khai giao thức MQTT đầu tiên cho ActiveMQ cho rằng các thuê bao QoS1 và QoS2 được ánh xạ bên trong tới các thuê bao bền của JMS. Thuê bao bền của JMS có trạng thái nặng và không có quy mô rất tốt. Trong các phiên bản sau, bạn có thể chọn một triển khai khác sử dụng các chủ đề ảo thay thế và sẽ mở rộng tốt hơn nhiều.
    
    <transportConnectors>
      <transportConnector name="mqtt+nio"
        uri="mqtt+nio://0.0.0.0:1883&transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions"/>
    </transportConnector>

  • Thêm một lý do nữa để thử bản phát hành 5.12.0 mới là những cải tiến mới của kho thông báo KahaDB hiện có thể phân bổ các tệp nhật ký. Bạn có thể tìm thêm thông tin về điều này trong bài viết này , nhưng những điều chỉnh này trên một số hệ thống tệp có thể đạt được những cải tiến hiệu suất đáng kể

Tất cả các chỉnh sửa cấu hình nhỏ này được tóm tắt trong tệp cấu hình ví dụ mới, bạn có thể tìm thấy trong

examples/conf/activemq-mqtt.xml

tập tin trong bản phân phối 5.12.0 mới.

Theo chiều dọc, nhà môi giới chỉ là một phần của phương trình. Có một vài câu hỏi quan trọng hơn cần được đáp ứng để triển khai IoT thành công.

SSL

Nhiều thiết bị IoT phụ thuộc vào chứng chỉ SSL cho mục đích xác thực. Đây không phải là một cái gì đó mới và chúng tôi đã thấy rằng trong các thiết lập nhắn tin truyền thống cũng vậy (và hỗ trợ nó), nhưng sự khác biệt là, một lần nữa, ở quy mô. Thật dễ dàng để duy trì thủ công một kho khóa với một số chứng chỉ trong đó. Đó là câu chuyện hoàn toàn khác khi số lượng chứng chỉ bắt đầu tăng lên.

Trong 5.12.0, chúng tôi đã thêm một số tính năng mới để giúp mọi người giải quyết vấn đề này. Có một vài công cụ được chuẩn hóa để giải quyết các vấn đề này và được hỗ trợ trong JDK. Vì vậy, bây giờ, bạn có thể sử dụng Danh sách hủy bỏ chứng chỉ , cung cấp một cách dễ dàng để thu hồi các chứng chỉ không hợp lệ trong thời gian chạy.

Bạn cũng có thể sử dụng OCSP (Giao thức trạng thái chứng chỉ trực tuyến) cung cấp cách thức tự động hơn để liên lạc với cơ quan chứng nhận của bạn. Bạn có thể tìm thêm thông tin về các tính năng này ở đây .

Tôi nghĩ rằng chứng chỉ SSL cung là câu chuyện lớn hơn nhiều cho IOT triển khai (và những đám mây nói chung) và đã có một số dự án thú vị đang nổi lên giải quyết nó, như pki.io . Chúng tôi sẽ cố gắng hỗ trợ mọi người sử dụng trong không gian này và ngay bây giờ với sự hỗ trợ của CRL và OCSP, bạn có thể linh hoạt hơn một chút khi xử lý các chứng chỉ của mình.

Theo dõi căng thẳng

Một chủ đề tôi thường gặp khi nói về việc triển khai IoT là làm thế nào để giám sát nhà môi giới đang ở giới hạn của quy mô theo chiều dọc (bất kể họ là ai). Chúng tôi thường theo dõi hành vi môi giới bằng cách sử dụng JMX hoặc tin nhắn tư vấn. Mặc dù đây là những công cụ hoàn hảo khi nhà môi giới ở dưới giới hạn của nó, mọi thứ trở nên kém tối ưu hơn khi bạn ở bên lề.

Với số lượng lớn các điểm đến và kết nối đến và đi, việc đăng ký MBeans và thông điệp tư vấn bắn có thể trở nên rất tốn kém, đặc biệt là khi được thực hiện với khối lượng lớn. Nó có thể cản trở công việc thực tế mà người môi giới cần làm.

Những người muốn nhận được tối đa từ cá thể môi giới của họ thường chỉ cần tắt mọi thứ, như

<broker useJmx="false" advisorySupport="false" ...>

nhưng điều đó khiến chúng tôi không có cái nhìn sâu sắc trong trạng thái của nhà môi giới, ngoài việc đạt đến đỉnh cao vào nhật ký.

Một giải pháp chúng tôi đã đưa ra là làm cho đăng ký mbean trở nên chọn lọc hơn

Bắt đầu với 5.12.0, bạn có thể xác định tên mbean bạn muốn ngăn chặn đăng ký, bằng cách xác định chúng trên bối cảnh quản lý, như

<managementContext>
  <managementContext
    suppressMBean="endpoint=dynamicProducer,endpoint=Consumer,
                   connectionName=*,destinationName=ActiveMQ.Advisory.*"/>
</managementContext>

Sử dụng tính năng này, bạn có thể tùy chỉnh chế độ xem của nhà môi giới mà bạn cần và bằng cách ngăn chặn đăng ký / không đăng ký các mbeans phù du tần số cao, bạn có thể giúp nhà môi giới của mình xử lý tải. Vì vậy, ngay cả trong kịch bản quy mô / tải cao, bạn có thể lấy số liệu cơ bản của nhà môi giới. Có nhiều hơn nữa chúng ta có thể làm trong không gian này, bằng cách xác định chế độ xem tùy chỉnh và như vậy, vì vậy hãy theo dõi.

Di sản MQTT

Apache ActiveMQ triển khai đặc tả MQTT 3.1.1, nhưng MQTT không phải là một giao thức mới và đã có một lượng lớn thiết bị được triển khai sử dụng các máy khách cũ (3.1). Chúng tôi đã nỗ lực để cho phép các trường hợp sử dụng đã biết trong đó khách hàng lớn tuổi mong đợi hành vi khác với những gì trong đặc tả 3.1.1. Vì vậy, ví dụ, bạn có thể cho phép xuất bản lên các chủ đề đô la của Đức, và thấy sự khác biệt trong hành vi đối với các nỗ lực đăng ký không thành công. Chúng tôi sẽ cố gắng bao gồm tất cả các trường hợp góc này và cung cấp hỗ trợ cho các khách hàng cũ, nơi đó là điều hợp lý để làm điều đó.

ActiveMQ Artemis

Trong trường hợp bạn không chú ý, đã có một chút hợp nhất trong vùng đất môi giới thông điệp Java. Nhà môi giới HornetQ đã được tặng cho Apache và hiện là một phần của dự án ActiveMQ. Lõi không đồng bộ của nó cung cấp cho chúng tôi một cơ sở tốt cho ActiveMQ thế hệ tiếp theo nên có quy mô tốt hơn và có hiệu suất tốt hơn so với nhà môi giới hiện tại. Nó đã có hỗ trợ ban đầu cho các giao thức AMQP và MQTT. Với các giao thức được làm cứng và các tính năng ở trên được triển khai đầy đủ, nó sẽ là một nhà môi giới tin nhắn rất tốt cho xương sống của cơ sở hạ tầng IoT của bạn.

Giúp đỡ từ bạn bè

Có một thông điệp tốt một nhà môi giới chắc chắn là một phần quan trọng của câu đố. Nhưng để triển khai IoT thực sự lớn, chúng tôi sẽ cần nhiều hơn thế. Chúng tôi cần phải có một cơ sở hạ tầng phức tạp hơn, cho phép chúng tôi phân vùng lưu lượng truy cập (về kết nối, đích, v.v.), cung cấp khả năng chịu lỗi và khả năng sẵn sàng cao. Có một vài dự án thú vị có thể giúp xây dựng cơ sở hạ tầng nhắn tin linh hoạt cho nhu cầu IoT.

Bộ định tuyến Qpid cung cấp định tuyến tin nhắn không có nhà môi giới giữa các máy khách, nhà môi giới và các điểm cuối khác dựa trên AMQP. Nó giúp xây dựng cấu trúc liên kết tối ưu và định tuyến tin nhắn từ máy khách đến đích cuối cùng của chúng. Ví dụ, bộ định tuyến điều phối có thể đóng vai trò là cổng giữa khách hàng và nhà môi giới, giúp số lượng lớn kết nối hoặc điểm đến được tập trung và phân vùng trên nhiều nhà môi giới mà không có nhận thức của khách hàng. Đó chỉ là một trong những ví dụ mà việc thêm bộ định tuyến vào mạng nhắn tin của bạn có thể giúp ích. Đây là một chủ đề thú vị và bạn sẽ nghe thấy nhiều điều thú vị hơn trong không gian này trong tương lai.

Fabric8OpenShift , mặt khác cung cấp cho chúng ta một cách dễ dàng để cung cấp và quản lý cơ sở hạ tầng nhắn tin này. Bạn có thể sử dụng chúng để dễ dàng triển khai các nhà môi giới, bộ định tuyến, cổng mới và khám phá các thành phần hiện có. Fabric8 cũng cung cấp một cổng có thể được sử dụng để phân vùng lưu lượng giữa các điểm cuối.

Có nhiều cách để giải quyết vấn đề này và giải pháp cuối cùng chắc chắn phụ thuộc vào trường hợp sử dụng thực tế. Nhưng có tất cả các thành phần này làm vững chắc và làm việc tốt với nhau là rất quan trọng trong việc kiến ​​trúc giải pháp cuối cùng.

Phần kết luận

Với bài đăng này, tôi đã cố gắng đưa ra một số quan điểm về nơi chúng ta đang ở và nơi chúng ta đang hướng đến với các trường hợp IoT hỗ trợ. Tôi hy vọng bạn thích nó và thấy nó hữu ích. Tôi sẽ đề cập đến chủ đề này chi tiết hơn nhiều tại Voxxed Days BelgradeApacheCon vào tháng 10. Cuối cùng, hãy xem bản demo tuyệt vời của Red Hat Summit IoT , cho thấy một số thứ này trong thực tế.

|