11

Chúng ta có thể tách các phương pháp hay nhất được tuân theo thành hai loại chính.

  1. Quan điểm của nhà thiết kế
  2. Quan điểm của nhà phát triển

Phối cảnh nhà thiết kế

  • Điều đầu tiên, một nhà thiết kế nên hiểu rõ về Đặc điểm kỹ thuật chức năng. Ở một mức độ nào đó, Đặc điểm kỹ thuật có thể trải qua một vài sửa đổi nhỏ trong khi nhiệm vụ Đặc điểm kỹ thuật đang được tiến hành. Tuy nhiên, dự kiến ​​rằng Đặc điểm kỹ thuật chức năng đã xác định tất cả các thông báo, thành phần và quy trình cần thiết cho giao diện trước khi bắt đầu Thiết kế kỹ thuật.
  • Bây giờ đối với thiết kế luồng, tất cả các tổ chức đều có các luồng chung (luồng con) có thể tái sử dụng làm thư viện để kiểm tra và xử lý ngoại lệ. Nhưng tôi thích xác định các quy trình chung khác trong các dự án và chuẩn bị các quy trình chung độc lập cho điều đó. Chúng ta có thể gọi đây là một kiến ​​trúc microservice.

ví dụ 1

Giả sử bạn có ít dự án (hoặc các dự án giống nhau trên nhiều quốc gia) trong đó phần phụ trợ cuối cùng là cơ sở dữ liệu và các luồng IIB của bạn phải tạo một loạt các chèn SQL.

Đối với điều này, chúng ta có thể tạo một luồng, chấp nhận "SQL insert" làm đầu vào từ luồng chính và chúng ta có thể thực hiện chèn hàng loạt cùng một lúc. Bằng cách này, chúng tôi có thể giảm thời gian triển khai của các dự án mẫu tương tự.

Ví dụ 2

Tôi đã làm việc trong một dự án mà chúng tôi sử dụng Salesforce làm CRM và có nhiều dịch vụ cần kết nối với nó. Mỗi lần có một cuộc gọi đến salesforce để tìm nạp sessionID, hãy thực hiện một cuộc gọi khác cho giao dịch kinh doanh thực tế.

Ở đây chúng ta có một phạm vi để làm cho dịch vụ web gọi sessionID trở thành một luồng chung độc lập.

  • Có những tính năng thú vị mới trong IIB 10 với hiệu suất tốt hơn và dễ phát triển. Nhu la:
    • Thư viện được chia sẻ Dòng có thể gọi Dự án RestAPI (tạo API từ tài liệu Swagger), webUI để giám sát Giao dịch và các nút MQTT cho PUB SUB ngay cả khi không có MQ cục bộ Từ IIB 10.0.0.14. Có thể sử dụng tập hợp ngay cả khi không sử dụng MQ. Có ít mẫu tiêu chuẩn trong toàn tổ chức sẽ dẫn đến việc mã / mô-đun dễ sử dụng lại.

Quan điểm của nhà phát triển

Hãy để tôi bắt đầu với các tác vụ tốn CPU và bộ nhớ.

  • Phân tích cú pháp tin nhắn
  • Điều hướng một cây trong mã
  • Sao chép cây từ mọi nút sang nút tiếp theo
  • Mã đăng nhập
  • Quyền truy cập tài nguyên (DB / files / HTTP req, v.v.)
  1. Giảm mức sử dụng bộ nhớ và CPU bằng cách sử dụng phân tích cú pháp OnDemand / không rõ ràng. Cố gắng giảm phân tích cú pháp càng nhiều càng tốt.

Các phương pháp hay nhất về IBM IIB (Bus tích hợp)

Các tin nhắn liên tục tuân theo quy tắc 3 cam kết để hoàn thành "đơn vị công việc", do đó mất nhiều thời gian xử lý hơn. Đối với các tin nhắn không quan trọng như "truy vấn số dư", có thời hạn sử dụng, không cần sử dụng kiên trì.

  • Các biến tham chiếu ESQL nên được sử dụng để điều hướng cây thông báo.
Các phương pháp hay nhất về IBM IIB (Bus tích hợp)
  • Không có quá nhiều nút tính toán trong một luồng. Điều này giúp giảm bớt các cây thông báo bị sao chép.
  • Tránh các chức năng dưới đây trong mã ESQL để có hiệu suất tốt hơn:
  1. ĐÁNH GIÁ

  2. Cardinality - Cố gắng hoàn thành nhiệm vụ lặp lại bằng “Lastmove”

  3. Thay vì quá nhiều "IF ELSE", tốt hơn là sử dụng "CASE"

Các phương pháp hay nhất về IBM IIB (Bus tích hợp)
  • Có giao dịch được duy trì trong mỗi và mọi luồng
  • Như tôi đã nói ở trên, việc truy cập một tài nguyên như DB / files, v.v. có thể khiến chúng ta tốn thời gian và CPU. Có một luồng được thiết kế tốt làm giảm số lần truy cập
  • Có một hàng đợi gửi ra được định cấu hình cho tất cả các hàng đợi đầu vào. Nếu không, tất cả các thông báo không thành công có thể chuyển đến hàng đợi thư chết và sẽ khó xác định từng thông báo của dịch vụ để xử lý lại
  • Bộ nhớ cache toàn cầu giúp chia sẻ dữ liệu thường xuyên cần thiết trên tất cả các máy chủ tích hợp
  • Có kế hoạch xác minh AVP phù hợp và chi tiết sau khi khởi động lại các nút tích hợp
|