Thuật ngữ business event đã không còn xa lạ trong kinh tế nói chung và trong CNTT nói riêng. Một khách hàng đăng ký mở thẻ tín dụng online, một đơn đặt hàng được xác nhận trên trang web thương mại điện tử, thời điểm khách hàng check-in, tình huống hành lý thất lạc, … là một số ví dụ có thể kể đến về các business event quan trọng tùy thuộc vào từng ngành nghề kinh doanh.

Liệu doanh nghiệp đã xác định và làm chủ được business event của mình, và xây dựng được kiến trúc phần mềm phù hợp? Những gì đã thay đổi trong những năm vừa qua là cách thức chúng ta xây dựng kiến trúc này và các công nghệ được sử dụng đằng sau chúng, không chỉ là vận hành on-premises và trên servers, EDA hiện nay có thể được hiểu như là kiến trúc SOA hướng sự kiện hay SOA 2.0.

1. Nhìn lại lịch sử kiến trúc phần mềm và hướng đi của doanh nghiệp

Trước tiên hãy cùng nhìn lại sự phát triển của các mô hình kiến ​​trúc và công nghệ trong ngành công nghiệp phần mềm. Trở lại năm 1996, Gartner đã mô tả về một kiến ​​trúc hướng dịch vụ để xây dựng toàn bộ các ứng dụng doanh nghiệp được tạo từ các giao diện (interfaces), điều kiện ràng buộc (contracts) và lệnh gọi (calls). Đến năm 2000, khái niệm REST được giới thiệu bởi Roy Fielding, đã tạo nền tảng cho các API dựa trên REST và vài năm sau đó, Gartner bắt đầu thảo luận về điện toán đám mây (cloud computing). Năm 2009, Gartner cho rằng một trong những công nghệ có xu hướng chiến lược nhất là Kiến trúc hướng Web được tạo bởi SOA + WWW + REST.

Năm 2011, một biến thể của SOA được sử dụng để mô tả kiểu kiến ​​trúc mới: Microservices. Trong những năm tiếp theo, với việc ngày càng có nhiều khách hàng chuyển sang đám mây, các mô hình kiến ​​trúc hướng đến đám mây mới được áp dụng. Với các công nghệ dựa trên Containers, Microservices và trình trung gian thông báo hiệu suất cao (high performing event brokers), kiến ​​trúc hướng sự kiện bắt đầu được áp dụng và thảo luận, không còn chạy on-premises nữa mà chạy trên cloud với các công nghệ cloud-native.

2. Nhu cầu của doanh nghiệp số không ngừng “tiến hóa”

Sự phát triển nhanh chóng không chỉ nằm ở kiến trúc phần mềm, mà còn ở nhu cầu của doanh nghiệp. Nhìn lại những gì đã diễn ra trong các ngành công nghiệp chỉ ứng dụng on-premises, rất dễ để nhận thấy rằng trước đây việc dự đoán nhu cầu về tải (expected load) của doanh nghiệp là có thể thực hiện: trong tài chính, nguồn cấp dữ liệu (stock feed) là không đổi, trong sản xuất, dữ liệu về cảm biến (sensor data) cũng là một dòng cố định. Khi nhu cầu về tải tăng lên, thông thường doanh nghiệp chỉ tăng thêm năng lực tính toán (computation power) hoặc bộ nhớ để mở rộng quy mô theo chiều dọc (scale vertically) với nhiều phần cứng cần bảo trì hơn.

Hầu hết các ứng dụng được xây dựng dưới mô hình monolith kiến trúc 3 lớp. Nhược điểm của nó là khó khăn về bảo trì, trở nên nặng nề và cồng kềnh nếu bổ sung thêm nhiều chức năng mới. Trong dài hạn, khi deploy ứng dụng mới trên một hệ thống ứng dụng phức tạp như vậy sẽ khiến startup time kéo dài, gây cản trợ dịch vụ và giảm thiểu cam kết chất lượng dịch vụ. Ngoài ra, những ứng dụng mới ngày nay sử dụng các ngôn ngữ khác nhau như Java, Scala, Grovvy, … – sẽ gặp khó khăn khi muốn thích nghi khung phần mềm và nền tảng bởi giới hạn của các monolith này. Khi thay đổi về tải xảy ra, kiến trúc monolith đặt ra yêu cầu đầu tư về phần cứng servers, storage, cũng như nhân sự tham gia quá trình bảo trì. Tuy nhiên, kiến trúc monolith vẫn tối ưu với các ứng dụng nhỏ, không có ảnh hưởng lớn về yếu tố kinh doanh và số lượng người dùng ít. Một trong những ưu điểm của kiến trúc monolith lúc này là tốc độ nhanh do không chịu ảnh hưởng nhiều của độ trễ mạng.

Nhưng những mô hình kinh doanh thời đại mới như Netflix sẽ không thể áp dụng kiến trúc monolith. Khi chuyển dịch lên đám mây, doanh nghiệp tiếp cận được với một lượng khách hàng lớn hơn, cũng là lúc lượng tải không còn dễ dàng dự đoán nữa. Ngoài ra, khách hàng giờ đây mong muốn dịch vụ cung cấp 24x7x365. Dễ dàng nhận thấy nhất là ở các ngành Bán lẻ và Thương mại điện tử. Một cửa hàng bán lẻ trực tuyến cần hoạt động vào ban đêm, thông thường sẽ có ít nguồn lực hơn, nhưng với một công ty toàn cầu, khái niệm về ban đêm sẽ không còn nữa, doanh nghiệp cần hoạt động 24 giờ 1 ngày. Điều này dẫn đến nhu cầu tối ưu hóa tài nguyên và mở rộng quy mô theo chiều ngang (scale horizontally) tùy thuộc vào lượng tải, để đáp ứng yêu cầu và tăng trải nghiệm của khách hàng.

Nói một cách ngắn gọn, công nghệ đám mây đã thay đổi hoàn toàn cuộc chơi và một kiến trúc phần mềm phù hợp là yếu tố then chốt.

3. Doanh nghiệp đã làm chủ được các “Business Moment” của mình?

Gartner đề cập đến “Business Moment” như một trọng tâm của hoạt động kinh doanh. Các “thời điểm kinh doanh” này có thể lấy ví dụ như lỗi hệ thống trong một vài phút, hay một khách hàng trung thành đang có mặt tại cửa hàng hoặc trên trang web thương mại điện tử của bạn, … Về mặt chức năng, các business event giải quyết 3 chức năng nghiệp vụ chính: giải pháp cho vận hành (operational visibility), kiểm tra và theo dõi (track and trace), và quy tắc kinh doanh (business rule).

Trong ngân hàng, business event giải quyết các bài toán như tăng tỷ lệ phản hồi đối với các marketing offers, công cụ xây dựng luật bán chéo giữa ngân hàng và các sản phẩm thẻ dựa trên dữ liệu real-time về giao dịch, hay tốc độ đáp ứng của công nghệ với các bài toán nghiệp vụ, …Trong hàng không, business event là các tình huống như yêu cầu nhận biết toàn cảnh vấn đề về chuyến bay muộn, ảnh hưởng của thời tiết, xung đột trong vận hành như thất lạc hành lý , và các yêu cầu quản trị nguồn dữ liệu real-time, …Trong logistics, doanh nghiệp cần có câu trả lời cho giải pháp về tăng cường chuỗi cung ứng và sự phối hợp giữa người giao hàng, người nhận hàng trong quy trình nghiệp vụ chạy trên nhiều hệ thống phân tán, để tạo nên giá trị gia tăng và tăng tính cạnh tranh.

Những khoảnh khắc này là những cơ hội nhất thời cần được tận dụng – tốc độ phản hồi với “event” càng nhanh,  giá trị có được càng lớn. Về bản chất, event mang tính không đồng bộ (asynchronous). Cách thức xử lý các sự kiện không đồng bộ này có thể được xây dựng dựa trên khái niệm về trình xử lý thông điệp (message broker) – khái niệm mang tính xương sống đã không còn mới lạ trong Kiến trúc hướng dịch vụ SOA.

 

Bước đầu tiên để xây dựng kiến trúc hướng sự kiện là phá vỡ các monolith thành nhiều dịch vụ nhỏ có tính chuyên môn hóa cao, nhằm mục đích đạt được tính linh hoạt và khả năng mở rộng cần thiết:

• Highly scalable: các microservices có thể mở rộng theo chiều ngang, khi một số dịch vụ xác định cần phát triển, có thể deploy trên nhiều servers và kiến trúc hạ tầng.
• Resilient: các dịch vụ được phát triển có tính độc lập, không ảnh hưởng đến các dịch vụ khác, trường hợp nếu 1 dịch vụ có lỗi, toàn bộ hệ thống sẽ không bị ảnh hưởng.
• Easy to deploy: dễ dàng deploy các microservice-based apps.
• Faster time-to-market: tăng thời gian ra thị trường nhờ chu kỳ phát triển ngắn, hỗ trợ agile deployment.
• Service Discovery
• Observability: khả năng quan sát các metrics, monitoring, distributed logging, distributed tracing.
• Security and Access Control
• Resiliency for inter-service communications: circui-breaking, retries & timeouts, fault injection, fault handling, load balancing & failover.

Nhưng các Microservices là chưa đủ để xây dựng một kiến trúc hướng sự kiện nếu ứng dụng vẫn phụ thuộc vào phương thức request – reply để trao đổi thông điệp. Lúc này một trình trung gian sẽ giúp dịch vụ gửi thông điệp đến queue và một dịch vụ khác lắng nghe và nhận thông điệp. Apache Kafka được lựa chọn để thực hiện nhiệm vụ này.

CQRS: Command and Query Responsibility Segregation

Bằng việc xác định 2 yếu tố công nghệ chính là Microservices và Apache Kafka, kiến trúc hướng sự kiện cloud-native được mô tả như trên. Các Microservices không chỉ làm nhiệm vụ publish events đến broker, mà còn tích hợp được với các cơ sở dữ liệu, các bên cung cấp dịch vụ phần mềm thứ ba, các hệ thống on-premises, hoặc dàn dựng các kịch bản khác. Kiến trúc phần mềm này kết hợp những lợi ích của Microservices và event brokers khi áp dụng cùng với CQRS, độc lập mở rộng và đáp ứng được nhu cầu sáng tạo, đổi mới về công nghệ trong tương lai.

4. Use Cases & Success Stories

Ngành sản xuất cần bao quát được nhiều lĩnh vực như: quản lý nhà máy sản xuất, bộ phận thu mua cần tương tác với nhà cung cấp, bộ phận logistic để vận chuyển hàng hóa, … Trong quá trình sản xuất, rất nhiều dữ liệu – event được tạo ra. Đối với những event thiết yếu, nhà quản lý cần hành động ngay lập tức để tránh làm giảm chất lượng hoặc lãng phí. Để có thể trao đổi dữ liệu với tất cả các bên liên quan, doanh nghiệp rất có thể cần tích hợp các hệ thống on-premises với các nhà cung cấp phần mềm như một dịch vụ (Saas providers). Với EDA, có thể sử dụng nhiều microservices cho 1 cảm biến để tăng năng suất xử lý dữ liệu nhằm tránh thất thoát dữ liệu. Với EDA, doanh nghiệp sản xuất có thể kết nối thành công các dịch vụ on-premises, public cloud  và private cloud, đồng thời giảm thời gian tiếp thị để tích hợp các dịch vụ mới, chẳng hạn như trường hợp mua lại hoặc thay thế hệ thống hiện có.

Lĩnh vực ngân hàng bán lẻ từng là một trong những lĩnh vực cuối cùng chuyển sang hoạt động trực tuyến, nhưng ngày nay khái niệm về ngân hàng truyền thống đã thuộc về quá khứ. Các dịch vụ ngân hàng số giúp khách hàng tương tác với ngân hàng qua nhiều cách khác nhau. Mỗi hoạt động đơn lẻ có thể được mô hình hóa thành một sự kiện và EDA là giải pháp hoàn hảo để xử lý các hoạt động cũng như bảo vệ chống gian lận. EDA cũng cho phép giảm thời gian đưa sản phẩm ra thị trường để thực hiện các chiến dịch marketing và thử nghiệm các tình huống gian lận.

Ngành công nghiệp cá cược và casino trực tuyến là lĩnh vực có số lượng dữ liệu bùng nổ cần được xử lý trong một phần giây do các last minute bets. Điều này có nghĩa là các dịch vụ cần có khả năng mở rộng quy mô ngay lập tức và thường sinh ra thông qua nhiều hệ thống để cập nhật tỷ lệ cược. Khả năng áp dụng các công nghệ mới nổi và thời gian ra thị trường nhanh chính là chìa khóa tạo ra sự khác biệt của lĩnh vực có tính cạnh tranh cao như gaming.

Bán lẻ chắc chắn là lĩnh vực đã chứng kiến tầm quan trọng của khách hàng trực tuyến. Hầu hết các nhà bán lẻ đều cố gắng đáp ứng nhu cầu giao hàng tận nhà, nhưng rất ít nhà bán lẻ thực sự làm tốt điều này. EDA có thể hỗ trợ mở rộng quy mô và tăng tính agile trong update dịch vụ mới.  Ngoài ra, EDA giúp triển khai marketing theo thời gian thực và tăng hài lòng khách hàng với các ưu đãi “at the right time, in the right place”. EDA là dạng kiến trúc hỗ trợ mọi kế hoạch bán và mọi yêu cầu tích hợp.

5. Lời kết

Trong giai đoạn tình hình kinh tế biến động mạnh mẽ, doanh nghiệp ở bất kỳ ngành nghề nào đều đang đối mặt với sự cạnh tranh gay gắt, nhu cầu và kỳ vọng biến động không ngừng từ khách hàng, song song đó là hành lang pháp lý ngày càng chặt chẽ. Để giải được bài toán về ưu tiên sáng tạo đổi mới trong công nghệ để đáp ứng được với phương hướng kinh doanh, câu hỏi đặt ra là doanh nghiệp, với những tài nguyên hiện tại, đã sẵn sàng cho những thay đổi đó chưa?

______________

ENAO là đối tác ưu tiên của TIBCO tại Việt Nam, với nhiều năm kinh nghiệm phát triển phần mềm và cung cấp các dịch vụ outsourcing, tư vấn, triển khai giải pháp bằng các giải pháp kỹ thuật tiên tiến, giúp doanh nghiệp gỡ rối các vấn đề phức tạp luôn xuất hiện trong hành trình chuyển đổi số.