Trong các bài đăng trước, chúng ta đã tìm hiểu về hai trong số các vũ khí kiến ​​trúc và vận hành của Cloud Native: vùng chứa (container) và quản lý động (dynamic management). Tuy nhiên, trong thực tế khi trao đổi với những người dùng Cloud Native, họ thường không bắt đầu với vùng chứa và bộ điều phối (orchestrator). Có nhiều doanh nghiệp đã khởi đầu với kiến trúc dịch vụ vi mô microservice, rồi sau đó mới sử dụng container.

Trong bài viết hôm nay, chúng ta sẽ tìm hiểu về “các kiến trúc hướng tới microservice” (microservices-oriented architectures) và cách để loại kiến trúc này có thể tương thích với các công cụ Cloud Native khác.

Kiến trúc microservices (Microservices Architectures)

Về mặt lý thuyết, khái niệm microservice khá đơn giản: Đó là những ứng dụng nguyên khối phức tạp, đa mục đích (hay còn gọi là Monoliths) được phân chia thành các dịch vụ nhỏ hơn, thích hợp sử dụng cho một mục đích duy nhất, khép kín và độc lập, chỉ có thể kết nối với nhau thông qua những message (thông điệp) được xác định rõ ràng.

Trên lý thuyết, khi động lực tăng gấp ba – microservices có khả năng:

• Dễ dàng phát triển và cập nhật hơn.
• Mạnh mẽ hơn và có thể mở rộng.
• Tiết kiệm chi phí vận hành và hỗ trợ người dùng

Tuy nhiên, đạt được những lợi ích trên không phải là điều đơn giản. Cách để kiến trúc nên microservices có thể khiến người dùng vô cùng đau đầu. Sử dụng microservices giúp người dùng đạt được một số lợi thế đáng kể nhưng quan trọng hơn cả, bạn phải suy nghĩ kỹ về mục tiêu ban đầu của mình nếu không muốn nhận về một mớ lộn xộn chẳng đi đến đâu.

Hãy cùng bàn về trạng thái (State)

Hãy cùng xem xét và thảo luận xem điều gì cần phải quan tâm khi đề cập về microservices. Đó chính là trạng thái (state).

Có hai loại microservice thịnh hành: “phi trạng thái” (stateless) và “trạng thái” (stateful).

• Microservices dưới dạng “lưu trạng thái” (Stateful microservices) đọc và ghi trực tiếp các dữ liệu được lưu trong cơ sở dữ liệu. Cần lưu ý rằng thông thường, các microservices dưới dạng trạng thái khi hoạt động bình thường sẽ không chia sẻ cơ sở dữ liệu với những microservices khác, vì điều đó sẽ gây khó khăn cho việc cho việc duy trì các giao diện phân tách và được xác định hoàn toàn. Một dịch vụ dưới dạng trạng thái khi kết thúc sẽ lưu trữ lại trạng thái lúc đó.
• Microservices dưới dạng “phi trạng thái” (Stateless microservices) thường không lưu trữ bất cứ thứ gì. Kiến trúc sẽ xử lý các yêu cầu và gửi lại phản hồi. Những hoạt động đều dựa vào yêu cầu, nên khi hoàn tất yêu cầu, kiến trúc sẽ bỏ yêu cầu đó đi. Kiến trúc stateless microservices sẽ không lưu trữ một ghi chú lâu dài để nhận thức được lịch sử hoạt động. Một microservices dưới dạng phi trạng thái kết thúc sẽ không lưu trữ bất cứ thứ gì. Kiến trúc này có thể không đạt được yêu cầu do lỗi của hàm gọi (caller).

Đặc điểm của microservices

Trong bài đăng trước đây, chúng ta đã thảo luận rằng cloud native có 3 mục tiêu đầy tiềm năng: tốc độ (tức là tốc độ ra mắt tính năng – feature velocity hoặc thời gian để sản phẩm sinh ra giá trị – time to value), quy mô và lợi nhuận. Để tối ưu hoá từng mục tiêu, người dùng cần có những kiến trúc microservice được thiết kế riêng biệt.

Microservices cải thiện tốc độ ​​(Tốc độ ra mắt tính năng – Feature Velocity)

Microservices sẽ khiến công nghệ trong cuộc sống trở nên dễ dàng hơn, đây được xem là trong những động lực phổ biến để chuyển sang sử dụng kiến trúc microservices. Nếu có một nhóm nhiều người phải cùng làm việc trên một nguồn cơ sở mã (codebase) lớn, có thể diễn ra tình trạng va chạm và cộng hưởng nhiều xung đột, cũng cũng như khiến người dùng phải hiểu quá nhiều mã code. Vì vậy, mọi việc sẽ dễ dàng hơn khi từng dịch vụ được chia nhỏ và được phân tách bằng một giao diện rõ ràng. Bằng phương pháp này, mỗi microservice có thể thuộc về một nhóm nhỏ tương ứng – nơi có những người có thể hợp tác làm việc hiệu quả vì họ có cùng mục tiêu hướng tới. Sau đó, các nhóm có thể an toàn triển khai các sự thay đổi trong nội bộ mà không cần tương tác với các đội nhóm còn lại – miễn là không có ai thay đổi giao diện lập trình ứng dụng API….

Microservices hỗ trợ mở rộng quy mô

Vào những thập niên trước, người dùng cần chi 5 triệu đô la cho một máy tính cồng kềnh chỉ chạy được trong 10 năm mà không có thời gian ngưng nghỉ – downtime (trên thực tế, tập đoàn IBM đã từng có một số khách hàng sử dụng chiếc máy tính khổng lồ này lên đến 30 năm). Máy tính khổng lồ là một ví dụ điển hình cho phương pháp mở rộng theo chiều dọc. Tôi không muốn sử hữu một máy tính cồng kềnh, vì các lý do quan trọng như sau:

• Bất kỳ một máy móc nào rồi cuối cùng sẽ hết dung lượng
• Một máy chỉ có thể đặt ở một nơi – máy không thể phản hồi một cách nhanh chóng tới người dùng trên toàn thế giới
• Không gian trống của phòng sẽ được tận dụng cho những công việc khác tốt hơn.

Khi muốn liên tục mở rộng quy mô hoặc khi người dùng rải rác ở nhiều nơi, tôi sẽ cần sử dụng đến phương pháp mở rộng quy mô theo chiều ngang (nhiều máy nhỏ phân tán thay cho một máy lớn).

Về cơ bản, tôi muốn tạo ra nhiều bản sao của một ứng dụng hơn để hỗ trợ nhiều người dùng hơn. Bản chất khép kín của microservices sẽ phù hợp trong trường hợp này, một phiên bản riêng lẻ của microservice ngoài kết nối được với những microservice khác, còn có thể kết nối với chính những phiên bản của nó, do đó chúng ta có thể an tâm khởi tạo vô số bản sao của một microservice. Nhờ vậy, chúng ta có thể mở rộng theo chiều ngang một cách hiệu quả. Thật tuyệt vời phải không nào?

Trên thực tế, có một sự thật còn tuyệt hơn như thế. Nhiều bản sao của ứng dụng cùng chạy trên quy mô lớn có thể đem đến khả năng phục hồi – nếu một bản sao bị lỗi, chỉ cần khởi động một bản sao khác. Chúng ta thậm chí có thể tự động hoá quá trình này bằng cách gửi ứng dụng vào vùng chứa (container), sau đó sử dụng bộ điều phối (orchestrator) để cung cấp khả năng chịu lỗi (fault tolerance). Tự động hóa được khả năng phục hồi được xem là một ví dụ điển hình cho việc phối hợp vô cùng nhịp nhàng giữa microservices, container và quản lý động.

Microservices cải thiện lợi nhuận

Lấy một ví dụ gần đây hơn, nếu sử dụng gần hết dung lượng của một ứng dụng nguyên khối (monolithic application) trên phiên bản đám mây có dụng lượng khổng lồ, thì tôi phải mua một phiên bản dung lượng lớn hơn, thậm chí ngay cả khi tôi hầu như không sử dụng bộ xử lý trung tâm CPU.

Tuy nhiên, nếu các chức năng tốn hao bộ nhớ được tách thành microservice riêng biệt, tôi có thể mở rộng những microservice độc lập này, và có thể sẽ dùng những loại máy móc chuyên dụng để lưu trữ riêng chức năng đó. Một kiến ​​trúc microservices linh hoạt có thể cung cấp cho người dùng nhiều tùy chọn lưu trữ hơn, từ đó giúp người dùng tiết kiệm chi phí.

Thế nhưng vấn đề là gì?

Dường như mọi việc nghe tốt đẹp đến mức khó tin, mà quả thực như vậy. Việc quản lý các kiến trúc microservices thực sự rất phức tạp. Những hệ thống phân tán đã từng thất bại theo những cách chúng ta không tưởng tượng được.

Điều nghịch lý là nếu bạn muốn hệ thống thân thiện với nhà phát triển, bạn có thể thiết kế các microservices làm điều đó. Sẽ có nhiều rắc rối liên quan đến hàng đợi (queues), chi phí lưu trữ đắt đỏ, vận hành chậm hơn, nhưng các microservice sẽ dễ phát triển và hỗ trợ người dùng tốt hơn.

Tuy nhiên, nếu bạn muốn hệ thống sở hữu siêu cường (hyperscale) với giá thành rẻ thì cần phải có kiến thức về những phương thức lỗi phân tán phức tạp (complex distributed failure modes). Trong ngắn hạn, các nhà phát triển sẽ gặp nhiều khó khăn và cần học hỏi nhiều hơn.

Vì thế, ưu tiên ban đầu của bạn sẽ là gì: dễ sử dụng, hay quy mô và lợi nhuận? Thật ra người dùng nên bắt đầu với những thứ đơn giản, sau đó tăng dần độ khó khi đã quen thuộc và có nhiều chuyên môn hơn.

Microservice vs Kiến trúc nguyên khối (Monolith)

Không phải tất cả các ứng dụng đều hưởng nhiều lợi ích khi tiếp cận kiến trúc Cloud Native. Ví dụ: một yếu tố quan trọng của quản lý động – dừng nhanh một container – sẽ chỉ hoạt động khi ứng dụng nằm trong container sẵn sàng thực hiện điều đó. Vấn đề sẽ xảy ra khi ứng dụng đang chứa đựng quá nhiều thông tin về trạng thái bên trong cần được lưu trữ khi quy trình (process) ngưng lại. Mà trạng thái lưu trữ thì chậm, không nhanh được.

Rất nhiều ứng dụng cũ vẫn duy trì trạng thái (state), bởi vì đó là cách chúng ta từng dùng để kiến trúc nên mọi thứ – như những “kiến trúc nguyên khối” lớn, đa mục đích nhưng khởi động và dừng lại khá chậm chạp. Phương pháp này thực tế mang lại nhiều lợi ích, nên chúng ta vẫn lựa chọn loại kiến trúc như vậy. Tuy nhiên, liên quan đến một số khía cạnh của quản lý động, phương pháp này lại không hoạt động hiệu quả lắm.

Nếu bạn vẫn đang sử dụng một kiến trúc nguyên khối, Cloud Native vẫn đem lại những lợi ích nhất định, nhưng Cloud Native chỉ có thể tối ưu khả năng mở rộng và khả năng phục hồi đối với các microservices độc lập và nhỏ, vì những microservices này có thể dừng và khởi động nhanh chóng, cũng như giao tiếp với nhau thông qua những giao diện rõ ràng. Bạn sẽ được hưởng các lợi thế về khả năng mở rộng và khả năng phục hồi này dù đang sử dụng kiến ​​trúc microservices dễ sử dụng nhưng đắt đỏ, hay siêu cường nhưng phức tạp (hoặc trung hoà các yếu tố trên theo cách đa số người dùng đều chọn).

Vì vậy, việc sử dụng microservices, container và quản lý động có thể đem đến như tốc độ nhanh chóng, mở rộng quy mô, năng suất, khả năng phục hồi và tiết kiệm chi phí. Và tất cả các yếu tố này thậm chí có thể phối hợp linh hoạt hơn như thế! Nghe thật tuyệt vời nhưng chúng ta sẽ bắt đầu từ đâu? Trong bài tiếp theo, chúng ta sẽ xem xét về điều đó…

Về VTI Cloud

VTI Cloud là Đối tác cấp cao (Advanced Consulting Partner) của AWS, với đội ngũ hơn 50+ kỹ sư về giải pháp được chứng nhận bởi AWS. Với mong muốn hỗ trợ khách hàng trong hành trình chuyển đổi số và dịch chuyển lên đám mây AWS, VTI Cloud tự hào là đơn vị tiên phong trong việc tư vấn giải pháp, phát triển phần mềm và triển khai hạ tầng AWS cho khách hàng tại Việt Nam và Nhật Bản.

Xây dựng các kiến trúc an toàn, hiệu suất cao, linh hoạt, và tối ưu chi phí cho khách hàng là nhiệm vụ hàng đầu của VTI Cloud trong sứ mệnh công nghệ hóa doanh nghiệp.

Liên hệ với chúng tôi: Tại đây

Nguồn: Anne từ blog.container-solutions.com