Giải pháp quản lý ứng dụng – Lựa chọn ESB hay Microservice ?

Chuyển đổi số đang trở nên cần thiết cho bất kỳ tổ chức nào mong muốn nâng cao giá trị kinh doanh của họ, khám phá các cơ hội mới và thực hiện trước các đối thủ cạnh tranh trên thị trường. Có một số phương pháp tích hợp khác nhau, và chúng tuân thủ các mẫu kiến trúc khác nhau. Bài viết này Chúng tôi chia sẻ một số kiến thức tổng quan về ESB và Microservice, bạn đọc cũng có thể áp dụng trong các giải pháp quản lý sản xuất, doanh nghiệp cuả mình : dựa theo ESB hay là Microservice ?

Giới thiệu

Đã hơn một thập kỷ khi Kiến trúc hướng dịch vụ (SOA) xuất hiện trong ngành. Enterprise Service Bus (ESB), được hỗ trợ bởi SOA, đã trở thành mẫu Middleware phổ biến nhất để giải quyết hầu hết các vấn đề xảy ra với các ứng dụng nguyên khối truyền thống. Tuy nhiên ESB không thể giữ vị trí là triển khai Middleware hàng đầu, khi các công nghệ, tự động hóa và cơ sở hạ tầng dựa trên đám mây đã được phát triển với ngày càng nhiều tính năng để xây dựng các ứng dụng đáng tin cậy, có thể mở rộng hơn.

Nếu một tổ chức sắp bắt đầu Chuyển đổi số , một trong những câu hỏi đầu tiên sẽ là lựa chọn triển khai và kiến trúc: Đó có phải là dựa trên ESB, dựa trên microservice, giải pháp lai hoặc phương pháp hoàn toàn khác. Khi có một loạt các tùy chọn có sẵn cho giải pháp tích hợp mới của bạn, điều đáng xem là lý do nào để bạn chọn một tùy chọn cụ thể chống lại tất cả các tùy chọn khác. Có những lợi ích cũng như nhược điểm trong mỗi lựa chọn được thảo luận ở trên.

Hãy xem sự khác biệt chính trong ESB và microservice sẽ giúp bất kỳ ai đưa ra quyết định về các giải pháp trong tương lai.

Enterprise Service Bus (ESB)

ESB là một kiến trúc Middleware dựa trên SOA. Nó dựa trên các nhà cung cấp dịch vụ, người tiêu dùng dịch vụ và các luồng sự kiện. Các nhà cung cấp dịch vụ tạo các sự kiện và xuất bản lên Bus Event được gọi là Enteprise Service Bus . ESB hỗ trợ cả các luồng sự kiện đồng bộ và không đồng bộ.

ESB đi kèm với một số tính năng khác nhau được yêu cầu trong khi tin nhắn được truyền qua nó. Nó bao gồm chuyển đổi thông điệp, chuyển đổi giao thức, phối hợp dịch vụ và làm đầy tải trọng. Các tính năng này có sẵn trong tất cả các triển khai ESB từ các nhà cung cấp khác nhau. Nó giúp giải pháp được tích hợp với các loại hệ thống khác nhau trong doanh nghiệp.

Khi một giải pháp tích hợp được xây dựng, một mình ESB sẽ không đáp ứng tất cả các yêu cầu Middleware trong phạm vi yêu cầu. Có một vài khả năng nền tảng Middleware khác sẽ được yêu cầu;

Quản lý API – để đưa tài nguyên nội bộ ra thế giới bên ngoài với bảo mật và QoS phù hợp
Message Queue – để xây dựng giao tiếp không đồng bộ với các hệ thống bên ngoài.
Quy trình kinh doanh – để thu hút con người hoặc thiết bị trong các luồng thông điệp trong các xác nhận nhất định.
Nhận dạng và quản lý truy cập – để quản lý quyền truy cập trong giải pháp.
Giám sát và cảnh báo – để xác định các vấn đề thời gian chạy và hành động nhanh chóng.

Sơ đồ sau cho thấy các hệ thống khác nhau có thể được kết nối thông qua ESB như thế nào.

Ưu điểm của ESB

ESB có một số lợi ích về tích hợp dịch vụ.

Độc lập về công nghệ: ESB hỗ trợ các loại giao thức vận chuyển khác nhau như HTTP / S, AMQP, MQTT khiến cho công nghệ của dịch vụ bên ngoài không phải là vấn đề đáng lo ngại. Bất kỳ dịch vụ nào được xây dựng trên bất kỳ công nghệ nào cũng có thể được tích hợp miễn là nó có thể giao tiếp bằng một trong các giao thức trên được ESB hỗ trợ.

Khả năng sử dụng lại dịch vụ: Một khi các dịch vụ được hiển thị thông qua ESB dưới dạng dịch vụ ảo, chúng có thể được sử dụng bởi bất kỳ dịch vụ nào khác bất kể giới hạn của mạng và công nghệ. Tích hợp mới sẽ đòi hỏi nỗ lực tối thiểu để được thêm vào giải pháp.

Quản trị và giám sát tập trung: ESB có khả năng truy nguyên nguồn gốc của tất cả các dịch vụ và do đó nó có thể là điểm trung tâm để quản lý việc sử dụng dịch vụ và theo dõi số liệu thống kê. Nếu các dịch vụ được kết nối thông qua kết nối điểm tới điểm, thì việc giám sát sẽ được thực hiện tại mỗi kết nối.

Khả năng bảo trì: Không có sự kết hợp chặt chẽ giữa các dịch vụ cuối và do đó những dịch vụ này có thể được cập nhật độc lập mà không ảnh hưởng đến các dịch vụ khác. Ngoài ra các loại kiểm soát khác nhau có thể được áp dụng ở lớp ESB thay vì cập nhật các dịch vụ thực tế.

Dung sai lỗi: Lỗi dịch vụ và quy trình phục hồi có thể được xử lý tại ESB và các dịch vụ cuối sẽ không bị ảnh hưởng. Ví dụ: nếu một dịch vụ không thành công, ESB có thể định tuyến các thông báo đến điểm cuối dịch vụ chuyển đổi dự phòng cho đến khi dịch vụ ban đầu hoạt động.

Triển khai không phức tạp: ESB có một phương thức triển khai đơn giản sẽ chứa tất cả các khả năng định tuyến và điều phối dịch vụ được tích hợp. Các nhà cung cấp khác nhau có thể có các kiểu triển khai khác nhau, nhưng cuối cùng, nó sẽ không quá phức tạp để xử lý.

Nhược điểm của ESB

Đã thêm độ trễ trong chuyển tin đi và về : Lớp ESB sẽ thêm bước bổ sung trong luồng dịch vụ và thêm một chút độ trễ cho thời gian đáp ứng. Do đó, hiệu suất có thể không giống như truy cập trực tiếp vào dịch vụ riêng lẻ thông qua kết nối điểm tới điểm.

Yêu cầu kết nối: Tất cả các dịch vụ yêu cầu phải có kết nối với ESB để tạo điều kiện cho việc gọi dịch vụ và điều này sẽ phải chịu thêm chi phí để thiết lập VPN và cơ sở hạ tầng khác.

Single point of failure : Có tất cả các dịch vụ được chuyển qua một nơi duy nhất, nó sẽ có nguy cơ bị lỗi một điểm. Điều này có thể tránh được bằng cách chuyển đổi dự phòng thích hợp (chuyển đổi dự phòng máy khách hoặc back-end) và khả năng tự động chữa lành của các nền tảng lưu trữ mới nhất. Nhiều nhà cung cấp ESB hỗ trợ các mẫu triển khai có tính sẵn sàng cao tinh vi để tránh những thất bại này.

Sự phức tạp trong khả năng mở rộng: Ngay cả chỉ một dịch vụ duy nhất được yêu cầu mở rộng, không có cách nào để tăng khả năng của dịch vụ đó một cách độc lập. Thay vào đó, nó đòi hỏi phải mở rộng toàn bộ ESB với tất cả các dịch vụ khác. Nó sẽ là một sự lãng phí tài nguyên và chi phí.

Microservice

Kiến trúc microservice (MSA) ngày nay phổ biến hơn so với Kiến trúc hướng dịch vụ. Với nhiều tính năng hấp dẫn được cung cấp bởi các công nghệ và nền tảng đám mây mới nhất, thật công bằng khi nói rằng microservice được triển khai trong các nền tảng đám mây đáng tin cậy, có khả năng mở rộng cao mang lại nhiều giá trị hơn ESB trong SOA.

Mỗi microservice có chức năng kinh doanh riêng. Do đó, so với ESB truyền thống, microservice có quyền kiểm soát chi tiết tốt hơn và khả năng mở rộng cao hơn.

Các đặc điểm sau đây có sẵn trong một microservice điển hình.

Nó có một phạm vi duy nhất của chức năng kinh doanh. Nếu bạn cần có được chức năng hợp nhất, thì tùy chọn là tích hợp một vài Microservice và xây dựng một Microservice tổng hợp.
Mỗi microservice có cơ sở dữ liệu riêng của mình. Cơ sở dữ liệu tập trung không được khuyến khích và sẽ không cung cấp giá trị của kiểm soát hạt mịn.
Các dịch vụ được kết nối rất lỏng lẻo. Không có giao tiếp trực tiếp với nhau trong các Microservice cốt lõi.
Mỗi microservice sẽ có thời gian chạy riêng, chủ yếu chạy trên container riêng của nó.
Nó có thời gian khởi động rất thấp cung cấp tính sẵn sàng cao trong trường hợp thất bại và khả năng mở rộng.
Microservice có thể được phát triển độc lập, triển khai và nhân rộng mà không ảnh hưởng đến toàn bộ hệ thống.
Việc triển khai microservice sẽ phức tạp với nhiều thông tin liên lạc xung quanh nó. Do đó, bắt buộc phải có CI / CD on-premise.
Thành công của việc triển khai microservice phụ thuộc vào giao tiếp giữa các microservice và do đó cần cơ sở hạ tầng rất ổn định.

Hình dưới đây cho thấy microservice được đặt trong một giải pháp trong các lớp khác nhau như thế nào để thuận tiện cho việc quản lý và giao tiếp.

Ưu điểm của microservice

Khả năng mở rộng cao: Các dịch vụ độc lập có thể được thu nhỏ độc lập với các dịch vụ khác dựa trên yêu cầu cụ thể của chức năng kinh doanh.

Độc lập về công nghệ: Các Microservice có thể được xây dựng bằng các công nghệ khác nhau và được triển khai trong các nền tảng khác nhau miễn là có thể thiết lập liên lạc giữa mỗi dịch vụ. Do đó, sự phát triển sẽ linh hoạt hơn với các kỹ năng có sẵn trong tổ chức. Quan trọng nhất, công nghệ thực hiện có thể được lựa chọn dựa trên các yêu cầu hiệu suất. Ví dụ, các ứng dụng thời gian thực hiệu suất cao có thể được xây dựng bằng công nghệ nhẹ, thân thiện với hiệu suất trong khi các dịch vụ xử lý dữ liệu hàng loạt có thể được xây dựng bằng công nghệ có khả năng lưu trữ dữ liệu và bộ đệm.

Khả năng phục hồi của dịch vụ: Các Microservice được thiết kế dựa trên nguyên tắc các lỗi được nêu ra tại thời điểm sớm nhất giúp kích hoạt các lỗi và phục hồi trong một khoảng thời gian ngắn. Nó sẽ tránh được toàn bộ lỗi hệ thống echo do lỗi của một dịch vụ. Các mẫu kiến trúc như bộ ngắt mạch và thời gian chờ sẽ giúp đạt được yêu cầu này.

Hỗ trợ phát triển nhanh nhóm chéo : Mỗi microservice có thể được phát triển và triển khai bởi các nhóm khác nhau và do đó doanh nghiệp không cần phải đợi cho đến khi tất cả các nhóm hoàn thành công việc của mình để xem kết quả trong sản xuất.

Tiếp thị nhanh hơn: Phát triển microservice sẽ liên quan đến việc triển khai CI / CD toàn diện và do đó các bản phát hành có thể được lên kế hoạch và thực hiện song song, không có bất kỳ sự phụ thuộc nào vào nhau. Nó sẽ dẫn đến chiến lược đi đến thị trường nhanh hơn cho doanh nghiệp.

Theo cách này, ứng dụng microservice là một tổ ong của các dịch vụ có thể cắm được. Chúng cho phép bạn nhanh chóng phát triển, thêm hoặc xóa các tính năng mà không ảnh hưởng đến tổng thể lớn hơn.

Nhược điểm của microservice

Yêu cầu về cơ sở hạ tầng: microservice sử dụng nhiều tính năng của các dịch vụ container dựa trên đám mây để có được lợi thế tối đa về khả năng mở rộng, độ tin cậy và khả năng chịu lỗi. Do đó, nó đòi hỏi cơ sở hạ tầng cụ thể với khả năng tự động hóa toàn diện để đạt được lợi ích tối đa.

Giao tiếp phức tạp: Sự thành công của việc triển khai microservice hoàn toàn phụ thuộc vào giao tiếp mạng. Vì có rất nhiều dịch vụ để phục vụ các chức năng kinh doanh phức tạp, lưu lượng mạng sẽ cao hơn và đòi hỏi cơ sở hạ tầng mạng đáng tin cậy.

Hỗ trợ giao dịch giữa các dịch vụ không dễ dàng: Các dịch vụ độc lập thực hiện một bộ chức năng duy nhất và do đó rất khó xử lý các tình huống như giao dịch với các Microservice tiêu chuẩn. Nó đòi hỏi nỗ lực thiết kế và phát triển bổ sung để thực hiện các kịch bản như vậy một cách hiệu quả, trong khi vẫn duy trì các tính năng microservice khác không thay đổi.

Khó di chuyển từ nguyên khối : Nếu tổ chức đã có các ứng dụng cũ được xây dựng dựa trên kiến trúc nguyên khối, sẽ cần một nỗ lực rộng rãi để chuyển đổi nó thành các Microservice và chuyển sang cơ sở hạ tầng khác.

Ví dụ về Microservice

Netflix

Netflix bắt đầu áp dụng mô hình microservice vào năm 2009 sau khi những thách thức mở rộng dẫn đến việc ngừng dịch vụ thường xuyên . Họ đã phá vỡ cấu trúc ứng dụng nguyên khối của mình trước khi thuật ngữ microservice thậm chí được đặt ra và sự chuyển đổi của họ bắt đầu.

Netflix bắt đầu bằng cách chuyển hệ thống mã hóa phim không phải khách hàng của mình sang đám mây AWS của Amazon và trong hai năm, nền tảng này đã chuyển tất cả các dịch vụ web hướng tới khách hàng của mình sang AWS.

Đến năm 2012, quá trình chuyển đổi đã hoàn tất và Netflix bao gồm hàng trăm Microservice dựa trên đám mây được kết nối với nhau. Sự sẵn sàng của Netflix để đón nhận phong trào microservice là một trong những đóng góp quan trọng nhất cho sự phát triển phi thường của nền tảng.

SoundCloud

SoundCloud ban đầu phát triển nền tảng của mình dưới dạng ứng dụng Ruby on Rails nguyên khối có biệt danh là Mothership. The Mothership cho phép hàng trăm ngàn nhạc sĩ cộng tác và chia sẻ âm nhạc của họ. Tuy nhiên, SoundCloud phải đối mặt với những thách thức mở rộng mà nó không thể giải quyết bằng các bản vá hỗ trợ tần số âm nhạc.

Thay vì tháo gỡ hoàn toàn Mothership, SoundCloud chỉ cần ngừng thêm các tính năng. Họ bắt đầu sử dụng các Microservice riêng biệt để thêm chức năng mới mà họ yêu cầu. Dần dần, SoundCloud bắt đầu loại bỏ các chức năng khác nhau khỏi khối, thay thế chúng bằng microservice. Điều này đã cho phép SoundCloud phát triển tự do hơn với các tính năng sẵn sàng sản xuất và chu kỳ phản hồi ngắn hơn.

Uber

Giống như SoundCloud và Netflix, Uber bắt đầu như một ứng dụng nguyên khối. Khi Uber trải qua sự tăng trưởng nhanh chóng, nó đã trải qua một số cuộc đấu tranh. Họ đấu tranh để thêm các tính năng mới, giải quyết các lỗi và khắc phục nợ kỹ thuật trong một lưu ký phần mềm duy nhất (vị trí lưu trữ cho các gói phần mềm). Hơn nữa, các nhà phát triển yêu cầu kiến thức chuyên sâu và kinh nghiệm với các hệ thống hiện có chỉ để thực hiện một thay đổi duy nhất.

Lấy cảm hứng từ Netflix và các công ty tăng trưởng nhanh khác, Uber đã quyết định chia ứng dụng nguyên khối của mình thành nhiều cơ sở mã để tạo ra kiến trúc microservice. Uber đã chọn cách tiếp cận microservice với mục tiêu là thúc đẩy quyền sở hữu rõ ràng, mang lại khả năng mở rộng tổ chức tốt hơn và cung cấp khả năng phục hồi và chịu lỗi nhiều hơn thông qua cam kết của họ đối với microservice.

ESB hoặc microservice: Cái nào là tốt nhất?

Khi bạn chọn giải pháp phù hợp cho tổ chức, các yếu tố sau cần được đánh giá.

Các loại dịch vụ được tích hợp
Giao thức truyền thông cần thiết
Số hiệu suất
Yêu cầu giao dịch
Hạn chế bảo mật
Sự phụ thuộc giữa các dịch vụ
Thời gian kinh doanh
Chi phí mục tiêu cho cơ sở hạ tầng
Skillset của team

Rõ ràng là microservice cung cấp các lợi thế bổ sung với bộ đặc tính phong phú mà nó có, được hỗ trợ bởi các nền tảng triển khai đám mây mới nhất. Tuy nhiên, có một vài lợi thế và hạn chế trong cả hai triển khai như đã đề cập trước đây. Không có câu trả lời duy nhất để nói rằng một thực hiện là tốt nhất. Dựa trên yêu cầu của bạn trong tổ chức của bạn, một trong những giải pháp này sẽ tốt hơn các giải pháp khác.

Các yêu cầu cần được phân tích cẩn thận cùng với sự phát triển của Chiến lược Chuyển đổi số của tổ chức trong 5 năm 10 năm tới, trước khi đưa ra quyết định về tùy chọn sẽ được sử dụng. Ngay cả một cách tiếp cận lai cũng sẽ hoạt động miễn là các mục tiêu kinh doanh của tổ chức có thể đạt được thông qua kiến trúc giải pháp.