Phần trước chúng ta đã đề cập đến một mô hình triển khai ứng dụng rất hay gọi là kiến trúc Vi dịch vụ. Để dễ hiểu, hãy cùng tìm hiểu một ví dụ sau đây 🙂
Chẳng hạn bạn đang phát triển một ứng dụng thương mại điện tử để nhận các đơn hàng từ phía khách hàng, sau đó kiểm tra trong kho và tài khoản tín dụng, cuối cùng là vận chuyển hàng. Ứng dụng này bao gồm một số thành phần ghép lại với nhau:
- StoreFrontUI để thực thi phần giao diện người dùng
- Các dịch vụ backend để kiểm tra tài khoản tín dụng, duy trì kho bãi và vận chuyển đơn hàng.
Như vậy ứng dụng mà ta đang triển khai ở đây bao gồm một tập các dịch vụ.
Phân tích kết quả
Bây giờ chúng ta hay phân tích các lợi ích của phương pháp này:
- Thứ nhất là các vi dịch vụ tương đối nhỏ, do đó:
- Dễ hiểu
- IDE chạy nhanh hơn nên lập trình viên sẽ năng suất hơn
- Web container khởi động nhanh hơn, do đó tăng tốc quá trình phát triển
- Mỗi dịch vụ có thể được triển khai độc lập với nhau, từ đó dễ dàng triển khai các phiên bản mới của dịch vụ một cách thường xuyên
- Dễ dàng mở rộng. Có thể thực hiện quá trình phát triển đồng thời với nhiều team khác nhau, mỗi team đảm nhận một dịch vụ và có thể làm việc độc lập với team khác.
- Cải thiện khả năng cô lập lỗi. Chẳng hạn, nếu một dịch vụ bị rò rỉ bộ nhớ thì chỉ có dịch vụ ấy bị ảnh hưởng mà thôi. Các dịch vụ khác vẫn hoạt động bình thường như chưa có gì xảy ra. Đối lập với mô hình này là kiến trúc nguyên khối, khi đó một thành phần lỗi sẽ gây tê liệt toàn hệ thống.
- Mỗi dịch vụ có thể được phát triển và triển khai độc lập
- Loại bỏ việc tuân theo một tập các nền tảng công nghệ trong một thời gian dài
Tuy có nhiều lợi ích kể trên, mô hình này cũng có những hạn chế:
- Lập trình viên phải đương đầu với sự phức tạp trong việc tạo ra một hệ thống phân tán.
- Các công cụ hay IDE cho lập trình viên thường được tạo ra dành cho các ứng dụng nguyên khối và không hỗ trợ cho việc phát triển các ứng dụng phân tán.
- Kiểm thử khó hơn
- Lập trình viên phải tạo ra cơ chế liên lạc giữa các dịch vụ
- Khó thực thi các trường hợp đa dịch vụ mà không sử dụng các giao dịch phân tán
- Cần phải cận trọng trong việc phối hợp giữa các team khi sử dụng đa dịch vụ
- Phức tạp trong việc quản lý vận hành một hệ thống bao gồm nhiều dịch vụ kiểu khác nhau.
- Tiêu hao nhiều bộ nhớ hơn. Mô hình kiến trúc vi dịch vụ sẽ thay thế N ứng dụng nguyên khối bằng NxM dịch vụ riêng lẻ. Nếu mỗi dịch vụ chạy trên một máy ảo JMV riêng (để tách biệt các dịch vụ) thì sẽ có phần tiêu hao thêm bằng M lần. Hơn nữa, nếu mỗi dịch vụ chạy trên một máy ảo riêng (chẳng hạn EC2 instance) thì phần tiêu hao sẽ còn nhiều hơn.
Một thử thách đối với việc sử dụng mô hình này là quyết định khi nào nên dùng khi nào không. Lúc ban đầu xây dựng một ứng dụng thì bạn sẽ không gặp những vấn đề mà mô hình này cần giải quyết. Hơn nữa là việc dùng một kiến trúc phân tán chặt chẽ sẽ làm chậm quá trình phát triển phần mềm. Đây có thể coi là vấn đề lớn đối với các startup khi mà thử thách khó khăn nhất là làm sao để cải tiến mô hình kinh doanh và ứng dụng đi kèm một cách nhanh chóng.
Sau nữa là thử thách về việc làm sao để mở rộng và đảm bảo tách biệt về mặt chức năng, bởi sự phụ thuộc một cách rối rắm các thành phần có thể làm việc tách ứng dụng nguyên khối thành một tập các dịch vụ trở nên khó khăn.
Một thách thức khác là việc quyết định làm sao để phân vùng hệ thống thành nhiều vi dịch vụ. Đây có thể coi là một nghệ thuật, tuy nhiên có một số chiến lược có thể hỗ trợ cho việc này. Một cách tiếp cận là phân vùng các dịch vụ bằng “động từ” hay “trường hợp sử dụng”. Chẳng hạn bạn thấy là một ứng dụng thương mại điện tử đã được phân vùng có một dịch vụ Shipping đảm nhận vai trò vận chuyển các đơn hàng đã hoàn thành. Một ví dụ tiêu biểu của việc sử dụng “động từ” là một dịch vụ Login phụ trách trường hợp sử dụng là Login.
Một cách khác để phân vùng là chia hệ thống dựa theo tên hoặc tài nguyên. Một dịch vụ sẽ đảm nhận tất cả các hoạt động của toàn bộ tài nguyên cùng loại. Chẳng hạn, bạn có thể nhận thấy là một hệ thống thương mại điện tử cần có một dịch vụ kho bãi để giám sát những sản phẩm nào được lưu trong kho.
Xét một cách lý tưởng thì mỗi dịch vụ chỉ nên đảm nhận một số lượng nhỏ các chức năng. Bob Martin nói về việc thiết kế các class dùng nguyên lý đơn nhiệm Single Responsibility Principle (SRP) . SRP định nghĩa một vai trò cho một class như là một lý do để thay đổi, và phát biểu rằng một class chỉ nên có 1 lý do duy nhất cho việc thay đổi. Thế nên cũng là hợp lý khi áp dụng SRP vào thiết kế dịch vụ.
Thiết kế của các tiện ích dành cho Unix cũng tương tự . Unix có rất nhiều các tiện ích như là grep, cat và find. Mỗi tiện ích này thực hiện đúng một chức năng và thực thi chức năng đó rất ngon nghẻ, hơn nữa có thể dùng gộp với các tính năng khác bằng cách sử dụng một đoạn mã shell để thực hiện các nhiệm vụ phức tạp.
Các trường hợp sử dụng đã được biết đến
Hầu hết các trang web lớn như Netflix, Amazon hay eBay đều chuyển đổi từ kiến trúc nguyên khối sang kiến trúc vi dịch vụ.
Netflix là một dịch vụ video streaming rất nổi tiếng và chiếm đến 30% lưu lượng internet, nó có một kiến trúc hướng dịch vụ rất lớn. Nó phải đảm nhận hơn một tỷ lần gọi service mỗi ngày tới API phát video từ hơn 800 loại thiết bị khác nhau. Mỗi lần gọi API như vậy lại được chia thành khoảng 6 lần gọi đến các dịch vụ backend.
Amazon.com ban đầu có kiến trúc 2 tầng. Để có thể mở rộng họ đã chuyển sang kiến trúc hướng dịch vụ bao gồm hàng trăm các dịch vụ backend. Một số ứng dụng sẽ gọi đến những dịch vụ này bao gồm các ứng dụng vận hành trang Amazon.com và các dịch vụ web API. Trang Amazon.com gọi đến 100-150 dịch vụ để lấy dữ liệu xây dựng lên trang web này.
Trang đấu giá trực tuyến ebay.com cũng “tiến hóa” từ kiến trúc nguyên khối sang kiến trúc hướng dịch vụ. Tầng ứng dụng bao gồm nhiều ứng dụng độc lập với nhau. Mỗi ứng dụng thực hiện một xử lý logic về mặt nghiệp vụ riêng liên quan đến một phạm vi chức năng nhất định như là mua hay bán. Mỗi ứng dụng được chia theo trục X còn một số ứng dụng khác như tìm kiếm được chia theo trục Z. Ebay.com cũng áp dụng phương pháp mở rộng kết hợp theo các trục X, Y, Z đối với tầng database.
Đam mê Code 