Vài năm gần đây, hẳn nhiều bạn nghe tới thuật ngữ “Microservice Architecture”, đặc biệt là khi đề cập tới cách thiết kế phần mềm, ứng dụng chạy trong container. Mặc dù không có định nghĩa chính xác về loại kiến trúc này, nhưng có một vài đặc điểm phổ biến xoay quanh việc tự động triển khai, dữ liệu phi tập trung,….
“Microservices” – là một thuật ngữ mới về kiến trúc phần mềm, và đang dần trở thành một kiến trúc mặc định mỗi khi đề cập tới việc xây dựng các ứng dụng. Nói ngắn gọn, thì Microservice architecture là cách nói tới việc phát triển một ứng dụng duy nhất bằng cách phát triển hàng loạt dịch vụ nhỏ (micro-service). Lúc này, mỗi microservice sẽ có tiến trình chạy riêng và giao tiếp với các microservice khác thông qua các cơ chế kết nối đơn giản – thường là HTTP API hoặc RPC.
Mỗi microservice được xây dựng dựa vào một nghiệp vụ kinh doanh hoặc một tính năng cụ thể nào đó trong thiết kế, các microservice có thể triển khai một cách độc lập và tự động. Nghĩa là chúng ta có thể sử dụng các ngôn ngữ lập trình khác nhau và kỹ thuật lưu trữ dữ liệu khác nhau cho mỗi microservice.
Để hiểu tốt hơn về kiến trúc microservice, chúng ta nhìn lại một chút về kiến trúc monolithic. Monolithic architecture là cách xây dựng ứng dụng như một thực thể duy nhất bao gồm mọi thành phần nghiệp vụ hoặc tính năng thành một khối, hoặc thành các khối riêng lẻ nhưng khi triển khai thì ràng buộc nhau. Khi bạn triển khai hoặc cần sửa đổi monolithic application thì bạn phải tác động tới toàn bộ các thành phần bên trong. Ví dụ như thay đổi giao diện, thêm một tính năng,….
Monolithic đã từng rất thành công với các ứng dụng nhỏ, không cần thay đổi thường xuyên và phục vụ lượng người dùng lớn. Khi mà nhu cầu thay đổi lớn xảy ra, chẳng hạn như số lượng người dùng tăng lên, bổ sung thêm tính năng mới thì mới thấy Monolithic bộc lộ các mặt hạn chế:
- Việc mở rộng ứng dụng phải nâng cấp toàn bộ khối monolithic.
- Nguy cơ về mất an toàn thông tin do ứng dụng quá lớn
- Chỉ sử dụng được một ngôn ngữ lập trình
- Database bị khóa cứng khi thiết kế.
Với kiến trúc microservice thì sẽ chia nhỏ ứng dụng thành các khối service tách biệt nhau, sao cho việc triển khai, mở rộng chúng là hoàn toàn độc lập.
Ví dụ về kiến trúc Microservice vs Monilithic
Ví dụ sau sẽ minh họa rõ hơn cho các bạn về kiến trúc monolithic so với kiến trúc microservice. (Nguồn từ bài viết https://www.nginx.com/blog/introduction-to-microservices/)
Hãng taxi muốn xây dựng một ứng dụng đặt xe để canh tranh với Uber, Grab. Sau khi nghiên cứu các yêu cầu, họ thiết kế ra ứng dụng có kiến trúc như sau:
Toàn bộ nghiệp vụ được đặt ở phần lõi, gồm các module phục vụ mục đích khác nhau như tính cước, quản lý lái xe, bản đồ. Xoay quanh là các adapter để cung cấp giao diện giao tiếp với các thành phần khác như Database, mobile app, web GUI,…
Ứng dụng này được đóng gói và triển khai như một khối, thực tế thì phụ thuộc vào sử dụng ngôn ngữ và framwork nào để phát triển. Ví dụ có thể dùng Java và triển khai trên Tomcat hoặt Jetty. Các ứng dụng nguyên khối này triển khai khác đơn giản, đơn thuần là sao chép tập tin đã được biên dịch và đóng gói sẵn sang máy chủ có môi trường phù hợp là khởi động lên. Mở rộng hệ thống bằng cách tăng thêm máy chủ chạy ứng dụng và kết hợp với một cân bằng tải.
Không may là các tiếp cận này gặp hạn chế rất lớn. Khi lượng người dùng nhiều lên, ứng dụng cần phát triển để bổ sung các tính năng làm cho nó ngày càng phình to lên. Hẳn là bạn đã tưởng tượng ra viễn cảnh đụng vào một ứng dụng siêu lớn, phải tốn lượng công sức lớn tới mức nào để hiểu chứ chưa nói tới việc phát triển thêm tính năng hay khắc phục lỗi/lỗ hổng. Ngoài ra, ứng dụng càng lớn thì nó khởi động càng lâu, do lượng thư viện lớn, các hệ thống kết nối ràng buộc nhau theo thứ tự.
Nói chung nhược điểm của kiến trúc ứng dụng nguyên khối rất nhiều.
Và cách khắc phục là sử dụng kiến trúc micro-service. Mỗi service sẽ phụ trách một tính năng/chức năng riêng biệt. Kiến trúc mới sẽ như sau:
Lúc này, các service sẽ giao tiếp với nhau thông qua REST API, các service cũng có thể dùng cơ chế bất đồng bộ trong giao tiếp như RPC. Các service được phát triển, triển khai độc lập nhau. Khi một nghiệp vụ cần đáp ứng nhu cầu tải cao, sẽ chỉ cần tăng số tiến trình của chính service đó.
Một lưu ý nhỏ: Không phải cứ ứng dụng được thiết kế microservice là chạy trong container, thực ra container phù hợp cho việc triển khai các ứng dụng thiết kế microservice do khả năng scale và isolate. Bạn hoàn toàn có thể chạy microservice như các tiến trình thông thường trên máy chủ.
Ưu điểm của kiến trúc Microservice:
- Chia nhỏ ứng dụng thành một tập các service để quản lý. Mỗi service sẽ thực thi các tác vụ trong phạm vi nhất định, và giao tiếp với service khác thông qua RPC, API. Giải quyết những hạn chế mà kiến trúc monilithic rất khó làm do bị ảnh hưởng bởi công nghệ hay framework phát triển.
- Lợi ích thứ hai là việc phát triển service sẽ linh hoạt hơn, các team phát triển service khác nhau trong một ứng dụng hoàn toàn chủ động việc lựa chọn công nghệ, miễn là các service khác nhau có thể giao tiếp với nhau.
- Thứ ba đó là việc phát triển các service không phụ thuộc nhau. Các lập trình viên của mỗi service tự phát triển, kiểm thử, triển khai độc lập với service khác.
- Cuối cùng, các service triển khai và mở rộng một cách độc lập. Khi một service cần CPU cao thì chỉ cấp phát CPU cho chính service đó.
Nói đi cũng phải nói lại, không phải kiến trúc microservice thần thành cho mọi thứ, nó cũng có rất nhiều nhược điểm, vậy nhược điểm của nó là gì.
Nhược điểm của kiến trúc Microservice:
- Đầu tiên chính như cái tên của nó. Thế nào là một micro-service, có phải tính theo số dòng code không? Chia thế nào để đủ nhỏ, đủ gọi là micro.
- Tiếp theo là độ phức tạp của ứng dụng tăng lên. Việc giao tiếp giữa các microservice như thế nào? Dùng REST API hay RPC.
- Việc lựa chọn DB hay thiết kế DB cho mỗi microservice như thế nào? Dùng chung hay riêng?
- Vấn đề kiểm thử một service này có thể bị phụ thuộc vào service khác như thế nào.
- Vấn đề giao tiếp giữa các microservice bị nghẽn cổ chai ở đâu sẽ rất khó kiểm soát. Cần có sự giám sát, quản lý, theo dõi, phân luồng kết nối giữa các service
Kết luận.
Microservice là một xu hướng tiếp cận trong phát triển ứng dụng ngày nay. Do có công nghệ container hỗ trợ nên gần như là một tiêu chuẩn khi thiết kế phần mềm. Các bạn theo con đường DevSecOps cần phải nắm để hiểu và làm tốt nhất các công việc sau này như tự động hóa, giám sát, triển khai.
4 thoughts on “DevSecOps – Phần 2 – Kiến trúc Microservice là gì?”