Vào những năm 60 và 70, kiến trúc nguyên khối được ưa thích để phát triển ứng dụng do tài nguyên tính toán hạn chế, điều này yêu cầu kết hợp tất cả các chức năng thành một đơn vị duy nhất, gắn kết chặt chẽ.
Cho đến những năm cuối 90 và 2000, khi cấu trúc nguyên khối bắt đầu trở nên quá hạn chế đối với kích thước ngày càng tăng và độ phức tạp của các ứng dụng, đặc biệt là với sự trỗi dậy của internet và hệ thống phân tán.
Điều này dẫn đến sự phát triển của các cách tiếp cận module hơn, chẳng hạn như kiến trúc hướng dịch vụ (SOA) và, sau đó, kiến trúc microservices (MSA), cuối cùng trở nên nổi bật vào đầu những năm 2010.
Tuy nhiên, đây chỉ là một giải thích sơ lược về khái niệm cơ bản và cách sử dụng microservices. Vì vậy, hãy thảo luận về cách microservices thay thế kiến trúc nguyên khối, cách microservices hoạt động và một số ví dụ về microservices. Sau đó, chúng ta sẽ thảo luận về các khía cạnh chính của triển khai microservices và những gì cần làm nếu bạn muốn triển khai microservices.
Microservices là gì? Chúng hoạt động như thế nào?
Như tôi đã đề cập trước đó, microservices xuất hiện như một giải pháp cho sự phức tạp và kích thước ứng dụng ngày càng tăng, cho phép các công ty chia nhỏ các chức năng thành các dịch vụ có thể triển khai độc lập.
Thuật ngữ "microservices" được phổ biến bởi các chuyên gia ngành như Martin Fowler và James Lewis, những người đã chính thức giới thiệu nó trong một bài đăng trên blog năm 2014. Công việc của họ định nghĩa các nguyên tắc và đặc điểm chính, bao gồm nhu cầu các dịch vụ có thể triển khai độc lập, quản lý dữ liệu phân cấp và sự không phụ thuộc vào công nghệ.
Kể từ đó, kiến trúc microservices đã trở thành lựa chọn chính trong thiết kế ứng dụng, nhờ những tiến bộ trong công nghệ containerization như Docker, công cụ orchestration như Kubernetes, và các nền tảng serverless computing. Nhưng microservices hoạt động như thế nào?
Microservices Hoạt Động Như Thế Nào?
Về cơ bản, kiến trúc microservices chia một ứng dụng lớn thành các dịch vụ nhỏ hơn, độc lập, mỗi dịch vụ chịu trách nhiệm cho một khả năng kinh doanh cụ thể. Các dịch vụ này giao tiếp với nhau qua mạng, thường thông qua REST APIs, gRPC, hoặc các message brokers như RabbitMQ hoặc Apache Kafka.
Theo định nghĩa của Martin Fowler và James Lewis, microservices có bốn đặc điểm chính sau đây:
- Trách Nhiệm Đơn Lẻ: Mỗi microservice được thiết kế để thực hiện một nhiệm vụ hoặc chức năng cụ thể, cho phép chuyên biệt hóa và giảm độ phức tạp.
- Độc lập: Microservices có thể được phát triển, triển khai, và mở rộng độc lập với nhau, điều này cung cấp tính linh hoạt và khả năng phục hồi.
- Quản Lý Dữ Liệu Phi Tập Trung: Microservices thường có cơ sở dữ liệu riêng của chúng, tránh nhu cầu có một cơ sở dữ liệu duy nhất, tập trung.
- Không Phụ Thuộc Công Nghệ Các đội có thể chọn công nghệ tốt nhất cho mỗi dịch vụ mà không bị ràng buộc bởi lựa chọn của các dịch vụ khác.
Cách tiếp cận này trái ngược với kiến trúc monolithic truyền thống, trong đó tất cả các thành phần ứng dụng được tích hợp chặt chẽ thành một đơn vị gắn kết.
Các Giai Đoạn Chính của Triển Khai Microservices
Mặc dù kiến trúc microservices mang lại nhiều lợi ích như khả năng mở rộng cao, tính linh hoạt, hiệu quả, cô lập lỗi, v.v., nhưng nó đòi hỏi biết cách triển khai microservices một cách hiệu quả và cần nhiều kế hoạch để thành công.
Đó là lý do tại sao việc có một hiểu biết toàn diện về các khái niệm chính, giai đoạn, và các thực hành tốt nhất về microservices khi triển khai microservices là rất quan trọng đối với một kiến trúc microservices thành công. Vì vậy, hãy cùng khám phá các giai đoạn chính của triển khai microservices và những gì mỗi giai đoạn bao gồm.
Lập Kế Hoạch và Chuẩn Bị Cho Triển Khai Microservices
Tất cả những điều tốt đẹp đều cần kế hoạch và kiên nhẫn, và để triển khai microservices thành công, bạn chắc chắn sẽ cần rất nhiều kế hoạch và kiên nhẫn. Đó là lý do tại sao việc tuân theo các thực hành tốt nhất về microservices và lập kế hoạch cũng như chuẩn bị mọi thứ bạn cần khi triển khai microservices là rất quan trọng.
Như tôi đã đề cập trước đó, một trong những nguyên tắc và đặc điểm chính của microservices là Nguyên Tắc Trách Nhiệm Đơn Lẻ. Bằng cách tuân thủ nguyên tắc này và đảm bảo rằng mỗi microservice tập trung vào và chịu trách nhiệm cho một chức năng và khả năng, bạn cho phép đội của mình phát triển, triển khai, và mở rộng các dịch vụ độc lập.
Hơn nữa, một danh mục con của nguyên tắc này là nguyên tắc thiết kế kết hợp lỏng lẻo. Điều này có nghĩa là mỗi dịch vụ có thể hoạt động độc lập để giao tiếp và phụ thuộc tối thiểu vào các dịch vụ khác. Từ đó, điều này cho phép các thay đổi hoặc cập nhật cho một dịch vụ không ảnh hưởng đến các dịch vụ khác, cho phép mở rộng microservices độc lập.
Điều này làm giảm rủi ro những sự cố liên tục, khi một vấn đề hoặc sự cố trong một phần của hệ thống kích hoạt một phản ứng dây chuyền, dẫn đến những sự cố trên toàn bộ hệ thống và làm ngừng toàn bộ dịch vụ.
Một thực hành microservices quan trọng là có lưu trữ dữ liệu riêng dành cho mỗi dịch vụ khi triển khai microservices như một phần mở rộng của nguyên tắc thiết kế kết hợp lỏng lẻo, vì điều này ngăn chặn xung đột và cho phép khả năng mở rộng dịch vụ tốt hơn.
Ngoài ra, bạn cần các mẫu giao tiếp microservices không đồng bộ, chẳng hạn như message brokers, để đảm bảo mỗi service có thể giao tiếp mà không phụ thuộc trực tiếp vào nhau.
Phần cuối cùng là triển khai các pipeline Continuous Integration và Continuous Delivery (CI/CD) cho microservices. Những pipeline này cho phép các team triển khai các tính năng hoặc bản sửa lỗi mới thông qua Công cụ CI/CD như Jenkins và GitLab, giúp các tổ chức duy trì tính ổn định của hệ thống trong khi thường xuyên phát hành các khả năng mới.
Bây giờ bạn đã có ý tưởng tổng quan về các kế hoạch và chuẩn bị cần thiết cho việc triển khai microservices, hãy cùng tìm hiểu về các chiến lược triển khai microservices.
Chiến lược triển khai microservices
Khi triển khai microservices, việc chọn chiến lược triển khai phụ thuộc vào chức năng service, lưu lượng truy cập, cơ sở hạ tầng, kỹ năng của team và những cân nhắc về chi phí. Tuy nhiên, nói chung, các chiến lược triển khai microservices như sau:
- Dịch vụ trên mỗi Container: Trong cách tiếp cận này, mỗi microservice chạy trong container riêng của nó, cung cấp sự cô lập tốt hơn so với mô hình nhiều instances trên một host. Container giúp dễ dàng mở rộng quy mô và cải thiện phân bổ tài nguyên.
- Phiên bản Dịch vụ trên mỗi Máy ảo: Mỗi service chạy trong một máy ảo (VM) riêng biệt, cung cấp sự cô lập cao hơn so với containers. Mặc dù điều này cải thiện bảo mật và tính ổn định, nhưng thường gây ra chi phí chung cao hơn.
- Phát hành theo giai đoạn: Ban đầu, triển khai các phiên bản microservice cho một nhóm người dùng nhỏ, kiểm tra tính ổn định của chúng trước khi triển khai đầy đủ. Cách tiếp cận này giảm thiểu tác động nếu xảy ra vấn đề và cho phép rollback nhanh chóng để duy trì tính toàn vẹn của hệ thống.
- Triển khai Blue-Green: Phương pháp này sử dụng hai môi trường production giống hệt nhau, với một môi trường phục vụ lưu lượng trực tiếp trong khi môi trường còn lại được sử dụng để kiểm tra bản phát hành tiếp theo. Blue-green deployment cho phép rollback dễ dàng và cập nhật mà không có thời gian ngừng, vì lưu lượng có thể được chuyển mượt mà giữa hai môi trường.
- Phát hành từng giai đoạn: Chiến lược này liên quan đến việc dần dần triển khai các cập nhật cho các nhóm người dùng hoặc môi trường khác nhau. Nó thường bắt đầu với các môi trường nội bộ trước khi đến production, giới hạn phạm vi tác động của bất kỳ vấn đề nào và cho phép các team giải quyết vấn đề từng giai đoạn.
- Triển khai không máy chủ: Cách tiếp cận này sử dụng các nền tảng serverless như AWS Fargate và Google Cloud Run, tự động hóa quản lý cơ sở hạ tầng bằng cách xử lý scaling và phân bổ tài nguyên cho bạn. Với triển khai serverless, không cần phải quản lý các máy chủ cơ bản, giúp bạn tập trung vào các microservices của mình.
Khi bạn đã chọn một trong các microservices ở trên để triển khai microservices, bạn sẽ cần một công cụ orchestration microservices.
Điều phối Microservices
Sau khi chọn một trong nhiều chiến lược triển khai microservices, bạn sẽ cần một công cụ điều phối cho orchestration microservices. Các công cụ orchestration microservices, chẳng hạn như Kubernetes, giúp tự động hóa triển khai microservices, scaling microservices, giám sát microservices và quản lý các microservices được đóng gói trong container.
Chẳng hạn, Airbnb sử dụng Kubernetes, cho phép các kỹ sư của nó triển khai hàng trăm thay đổi vào microservices của mình mà không cần giám sát thủ công. Một tính năng quan trọng của các công cụ orchestration microservices như Kubernetes là tính năng load balancing tích hợp sẵn.
Có một tính năng load balancing đủ mạnh giúp phân phối lưu lượng đến giữa nhiều instances của một microservice. Điều này ngăn chặn bất kỳ instance nào trở thành điểm tắc nghẽn và tăng cường khả năng của hệ thống trong việc xử lý các đột biến lưu lượng.
Kubernetes đóng vai trò quan trọng trong quản lý microservices thông qua các khả năng tự chữa lành, trong đó các container bị lỗi được tự động thay thế và khởi động lại. The New York Times tận dụng tính năng này để duy trì các microservices của nó mà không ảnh hưởng đến trải nghiệm người dùng và thời gian ngừng hoạt động.
Hơn nữa, Kubernetes cũng cải thiện bảo mật microservices bằng cách quản lý các cấu hình và secrets, chẳng hạn như thông tin đăng nhập cơ sở dữ liệu hoặc API keys, sử dụng ConfigMaps và Secrets. Điều này đặc biệt quan trọng đối với các công ty và dịch vụ, như Uber, xử lý các thông tin khách hàng và người dùng nhạy cảm.
Cuối cùng, các công cụ orchestration microservices như Kubernetes đặc biệt hữu ích cho các chiến lược microservices liên quan đến rolling updates và rollbacks, chẳng hạn như các bản phát hành theo giai đoạn. Rolling updates cho phép các phiên bản microservice mới được triển khai mà không làm gián đoạn dịch vụ bằng cách giữ một số instances của phiên bản cũ chạy.
Sau khi thiết lập công cụ orchestration microservices của mình, bạn sẽ cần xây dựng và tự động hóa Quy trình CI/CD cho triển khai microservices.
Quy trình CI/CD cho Triển khai Microservices
Như chúng ta đã bàn trước đây, các quy trình Continuous Integration và Continuous Delivery dành cho microservices là những yếu tố quan trọng trong triển khai microservices. Phần CD trong quy trình CI/CD chịu trách nhiệm tự động triển khai những thay đổi code lên production ngay khi chúng vượt qua các giai đoạn test và integration của quy trình CI/CD.
Sau đó, phần CD của quy trình CI/CD phát huy tác dụng để khi code thay đổi vượt qua giai đoạn test và integration, dịch vụ sẽ được triển khai lên công cụ orchestration microservices như cluster Kubernetes.
Hơn nữa, các giai đoạn test và integration đều được thực hiện tự động bởi quy trình CI/CD thông qua các unit test, integration test và end-to-end test được tích hợp vào pipeline.
Điều này cho phép các team xác thực cập nhật ở từng giai đoạn trong khi duy trì tính ổn định của hệ thống. Ngoài ra, nếu có bất kỳ vấn đề nào với thay đổi code, dù có nhiều lớp test, các rollback tự động có thể quay lại phiên bản ổn định trước đó.
Cuối cùng, việc triển khai quy trình CI/CD cho microservices theo các phương pháp tốt nhất giúp các tổ chức đạt được phát triển nhanh hơn, giảm lỗi thủ công và duy trì các tiêu chuẩn chất lượng cao.
Nhiều công ty như Spotify, Expedia, iRobot, Lufthansa, Pandora, v.v. sử dụng quy trình CI/CD cho microservices thông qua các công cụ như CircleCI, AWS CodePipeline và GitLab để tự động hóa quy trình triển khai, đảm bảo chất lượng code nhất quán và phát hành các tính năng mới nhanh chóng trong khi duy trì tính ổn định của hệ thống.
Mẫu Giao tiếp Microservices
Cách thức microservices giao tiếp với nhau hoàn toàn phụ thuộc vào chức năng, kiến trúc tổng thể, khả năng mở rộng mong muốn và độ tin cậy của microservices của bạn. Nói chung, có hai loại mẫu giao tiếp microservices chính được sử dụng: đồng bộ và bất đồng bộ mẫu giao tiếp microservices.
Trong mẫu giao tiếp microservices đồng bộ, các dịch vụ tương tác theo thời gian thực, nghĩa là một dịch vụ sẽ gửi một yêu cầu và chờ phản hồi trước khi tiếp tục. Các mẫu giao tiếp microservices đồng bộ được sử dụng phổ biến nhất là REST (Truyền tải trạng thái đại diện) APIs, gRPC (Go Remote Procedure Call của Google), và GraphQL.
Thông thường, loại mẫu giao tiếp microservices này được sử dụng trong các ngành công nghiệp và bởi các công ty thường yêu cầu xử lý dữ liệu theo thời gian thực và phản hồi tức thì. Các ngành như tài chính, chăm sóc sức khỏe và thương mại điện tử thường sử dụng mẫu giao tiếp đồng bộ để đảm bảo các giao dịch, truy xuất dữ liệu hoặc tương tác diễn ra tức thì, duy trì trải nghiệm người dùng mượt mà và phản hồi nhanh.
Tuy nhiên, mặc dù mẫu giao tiếp microservices đồng bộ mang lại những lợi ích như phản hồi theo thời gian thực và tính đơn giản, chúng cũng có những nhược điểm nhất định như những nút thắt cổ chai tiềm ẩn do liên kết chặt chẽ, khả năng mở rộng thấp dưới tải cao, thời gian phản hồi chậm và độ trễ cao trong những khoảng thời gian lưu lượng cao.
Mặt khác, mẫu giao tiếp microservices bất đồng bộ thường phù hợp hơn cho microservices vì chúng dựa trên nguyên tắc Loose Coupling mà chúng ta đã bàn trước đây.
Loại mẫu giao tiếp microservices này tách rời các dịch vụ bằng cách cho phép chúng gửi và nhận tin nhắn thông qua một broker như Kafka hoặc RabbitMQ. Bằng cách gửi tin nhắn đến một hàng đợi hoạt động như bộ đệm, các dịch vụ giao tiếp độc lập mà không cần chờ phản hồi như cách chúng làm trong mẫu giao tiếp đồng bộ. Bộ đệm này cho phép các dịch vụ khác xử lý tin nhắn với tốc độ riêng, cho phép người gửi tiếp tục công việc mà không cần chờ người nhận.
Mẫu giao tiếp microservices bất đồng bộ không chỉ cung cấp cấu trúc tách rời cho triển khai microservices mà còn cung cấp cùng một phản hồi theo thời gian thực mà mẫu giao tiếp microservices đồng bộ cung cấp.
Điều này là do kiến trúc hướng theo sự kiện của mẫu giao tiếp microservices bất đồng bộ hướng theo sự kiện, vì các dịch vụ giao tiếp bằng cách phát ra sự kiện khi một hành động cụ thể xảy ra. Các dịch vụ khác có thể đăng ký những sự kiện này và phản ứng tương ứng. Điều này cho phép các hệ thống phản ứng nhanh chóng đối với những thay đổi theo thời gian thực mà không cần liên kết trực tiếp giữa các dịch vụ.
Hơn nữa, trong không đồng bộ Xuất bản-Đăng ký (Pub/Sub) trong mẫu giao tiếp microservices, các dịch vụ (publishers) gửi tin nhắn tới một topic, và các dịch vụ khác (subscribers) lắng nghe topic đó để nhận cập nhật. Mô hình này hỗ trợ nhiều subscriber, đồng thời phát tin nhắn tới nhiều dịch vụ.
Cuối cùng, tương tự như mẫu hướng theo sự kiện, giao tiếp microservices bất đồng bộ saga dựa trên choreography các mẫu giao tiếp microservices cũng sử dụng sự kiện để giao tiếp với nhau, tuy nhiên trong mẫu này, một thứ tự cụ thể được áp dụng, nghĩa là các sự kiện kích hoạt bước tiếp theo và dịch vụ cụ thể được kích hoạt.
Khác biệt ở đây là trong các mẫu hướng sự kiện, không có một chuỗi hoặc quy trình nhất định, và nhiều dịch vụ có thể phản ứng với một sự kiện thay vì tuân theo quy trình và thứ tự cụ thể trong mẫu saga dựa trên choreography.
Loại mẫu giao tiếp microservices không đồng bộ bạn sử dụng phụ thuộc vào tác vụ và chức năng tổng thể của microservices. Hàng đợi tin nhắn như RabbitMQ và Amazon SQS thường được dùng để lên lịch tác vụ, phân phối khối lượng công việc, và trong thương mại điện tử để xử lý đơn hàng và hệ thống thông báo.
Các event broker như Apache Kafka và AWS EventBridge thường được dùng để xử lý các luồng sự kiện quy mô lớn theo thời gian thực và định tuyến sự kiện giữa các microservices trong các lĩnh vực như dịch vụ tài chính và AWS environments.
Về các message broker Publish-Subscribe (Pub/Sub) như Google Cloud Pub/Sub và Redis Streams, những broker này thường được dùng cho gửi tin nhắn có khả năng mở rộng trên các hệ thống phân tán để phân tích dữ liệu theo thời gian thực, tiếp nhận sự kiện, thông báo theo thời gian thực và các ứng dụng chat.
Cuối cùng, các message broker saga dựa trên choreography chủ yếu được dùng cho xử lý đơn hàng thương mại điện tử, hệ thống đặt chuyến bay, và các trường hợp mà các giao dịch phức tạp, nhiều bước cần được phối hợp trên nhiều dịch vụ mà không cần kiểm soát tập trung.
Khám Phá Dịch Vụ Microservice
Sau khi bạn thiết lập và triển khai một mẫu giao tiếp phù hợp với nhu cầu của mình, bạn sẽ cần đảm bảo rằng các dịch vụ của bạn có thể tìm thấy nhau ngay từ đầu. Như tôi đã đề cập trước đó, các công cụ orchestration microservices như Kubernetes đóng vai trò quan trọng trong khám phá dịch vụ microservice.
Điều này được thực hiện thông qua khám phá dịch vụ tích hợp sẵn mà Kubernetes DNS cung cấp, cập nhật động các địa chỉ IP và DNS records khi các dịch vụ mở rộng hoặc thay đổi vị trí trong cluster.
Phương pháp khám phá dịch vụ microservice này được gọi là khám phá phía máy chủ vì trách nhiệm định tuyến được uỷ thác cho một load balancer, sau đó query registry và chuyển hướng traffic tới instance thích hợp.
Mặt khác, chúng ta cũng có phương pháp khám phá phía client cho khám phá dịch vụ microservice, trong đó dịch vụ hoặc API gateway query một service registry như Consul hoặc Eureka để tìm các instance có sẵn.
Việc chọn phương pháp khám phá dịch vụ nào tốt nhất cho triển khai microservices của bạn phụ thuộc vào yêu cầu và quy mô của hệ thống.
Với khám phá dịch vụ microservice phía client, client có toàn quyền kiểm soát instance nào mà nó giao tiếp. Điều này không chỉ cho phép tùy chỉnh nhiều hơn mà còn giảm độ phức tạp, vì không cần dịch vụ khám phá tập trung.
Ví dụ, triển khai microservices của Netflix sử dụng khám phá dịch vụ microservice phía client với Eureka và Ribbon cho cân bằng tải, cho phép client chọn instance tốt nhất dựa trên các tiêu chí như độ trễ và tải máy chủ.
Tuy nhiên, khám phá dịch vụ microservice phía máy chủ phù hợp hơn cho các môi trường lớn hơn vì khám phá dịch vụ tập trung có thể cải thiện hiệu quả và cho phép cân bằng tải nhất quán trên một hệ thống phân tán.
Các giải pháp khám phá dịch vụ microservice phía máy chủ như Kubernetes, AWS Elastic Load Balancing, và API Gateways (Kong, NGINX, v.v.) giúp định tuyến traffic hiệu quả và duy trì tính sẵn có cao, được sử dụng bởi các công ty như Airbnb, Pinterest, Expedia, Lyft, v.v.
Bảo mật Microservice
Mặc dù kiến trúc monolithic phần lớn kém hơn MSA, một khía cạnh mà kiến trúc monolithic có lợi thế là bảo mật. Vì microservices được xây dựng trên nguyên tắc Loose Coupling và có tính chất phân tán, không thể triển khai một biện pháp bảo mật chung, duy nhất.
Vì mỗi dịch vụ phải được bảo mật độc lập, các biện pháp bảo vệ bổ sung là cần thiết vì bề mặt tấn công lớn hơn nhiều trong microservices. Để đạt được mục đích này, các tiêu chuẩn như OAuth2 và JSON Web Tokens (JWT) thường được dùng để xác thực và phân quyền, như bạn có thể đoán.
Ngoài ra, một API gateway cũng thường được sử dụng để quản lý bảo mật trên các microservices vì nó thực thi xác thực và phân quyền tại điểm vào. Thêm vào đó, API gateways cũng có thể triển khai giới hạn tốc độ, ghi log và giám sát, những điều này cung cấp các lớp bảo mật bổ sung cho microservices.
Mặc dù những điều này bảo vệ điểm vào chính, các biện pháp bảo mật microservices bổ sung là cần thiết để bao phủ giao tiếp giữa các dịch vụ.
Đây là nơi các service mesh phát huy tác dụng vì chúng thêm một lớp bảo mật mạng cho microservices và mã hóa traffic giữa các dịch vụ cũng như thực thi các chính sách như TLS lẫn nhau. Những service mesh này về cơ bản thiết lập mã hóa end-to-end toàn diện giúp cải thiện đáng kể bảo mật microservices.
Scaling Microservice
Một trong những lợi ích lớn nhất của MSA, và chính lý do nó được phát triển để thay thế kiến trúc monolithic, là khả năng mở rộng cao. Thông thường, mở rộng microservices có thể xảy ra theo hai cách: theo chiều dọc và theo chiều ngang.
Về cơ bản, mở rộng microservices theo chiều dọc (scale up) là thêm nhiều tài nguyên hơn, chẳng hạn như CPU hoặc bộ nhớ, cho một instance hiện có. Ngoài ra, mở rộng microservices theo chiều ngang (scale out) phân phối tải và tăng công suất.
Về mặt triển khai, mở rộng microservices theo chiều dọc dễ hơn trong hai cách vì bạn chỉ cần sửa đổi một instance duy nhất bằng cách nâng cấp lên máy chủ lớn hơn, tăng bộ nhớ hoặc sức mạnh xử lý trong một cloud instance, hoặc thêm bộ nhớ lưu trữ.
Loại mở rộng này thường được dùng trong các trường hợp mà tăng RAM hoặc công suất CPU có thể cải thiện hiệu suất truy vấn và xử lý dữ liệu, chẳng hạn như các dịch vụ chịu trách nhiệm cho caching trong bộ nhớ.
Tuy vậy, mặc dù scaling theo chiều dọc của microservice dễ hơn và cung cấp cải thiện hiệu suất tức thì, nó cũng có những hạn chế. Scaling theo chiều dọc bị giới hạn bởi dung lượng phần cứng của máy chủ, nên lúc nào đó bạn sẽ cần chuyển sang scaling theo chiều ngang để tiếp tục mở rộng.
Hơn nữa, scaling theo chiều dọc có chi phí cao vì phần cứng và các instance lớn hơn thường đi kèm với mức giá cao. Cuối cùng, nếu instance đã được mở rộng gặp sự cố, dịch vụ sẽ ngừng hoạt động hoàn toàn, vì không có các instance bổ sung để xử lý tải.
Với scaling theo chiều ngang của microservice, thay vì nâng cấp tài nguyên của một instance duy nhất, bạn triển khai các instance mới của dịch vụ đó. Mặc dù các instance này hoạt động độc lập, chúng vẫn xử lý cùng một dịch vụ và các phần của cùng một khối lượng công việc.
Không giống như scaling theo chiều dọc, scaling theo chiều ngang của microservice không có giới hạn, nghĩa là bạn có thể thêm bao nhiêu instance tùy thích để xử lý khối lượng công việc ngày càng tăng và các đột biến lưu lượng truy cập, mang lại khả năng mở rộng lớn hơn.
Hơn nữa, vì bạn có nhiều instance, nếu một instance gặp sự cố, bạn không phải đặt tất cả trứng vào một giỏ, vì các instance khác có thể tiếp tục xử lý các yêu cầu. Cuối cùng, scaling theo chiều ngang tiết kiệm chi phí hơn nhiều trong dài hạn, vì bạn có thể sử dụng nhiều instance nhỏ hơn và rẻ hơn để tạo thành hiệu suất đáng tin cậy hơn và mạnh mẽ hơn.
Tuy vậy, scaling theo chiều ngang và việc thêm nhiều instance yêu cầu nhiều load balancer, cơ chế khám phá dịch vụ microservice và các công cụ điều phối microservice, làm cho kiến trúc microservice của bạn phức tạp hơn nhiều.
Scaling theo chiều ngang phù hợp hơn với các trường hợp sử dụng như dịch vụ web và ứng dụng như thương mại điện tử hoặc nền tảng mạng xã hội, thường trải qua lưu lượng truy cập biến động và khối lượng yêu cầu lớn.
Tuy vậy, đây không thực sự là vấn đề của một hoặc cái khác, vì cả hai loại scaling đều được hỗ trợ trong microservice và cần thiết trong nhiều trường hợp. Thông thường, các tổ chức nhỏ hơn sử dụng scaling theo chiều dọc vì nó dễ triển khai và quản lý hơn nhiều, nhưng theo thời gian và khi ứng dụng phát triển, scaling theo chiều ngang được giới thiệu để xử lý nhu cầu cao.
Cuối cùng, các nền tảng đám mây cung cấp các dịch vụ auto-scaling tự động thêm hoặc xóa các instance dựa trên nhu cầu theo thời gian thực, điều này giúp các tổ chức cân bằng scaling theo chiều dọc và chiều ngang một cách đáng kể.
Giám sát Microservice
Ở giai đoạn này, bạn hầu như đã hoàn thành triển khai microservice. Tất cả những gì còn lại là đảm bảo nó hoạt động nhất quán và đáng tin cậy. Đây là nơi các công cụ giám sát microservice như Prometheus và Grafana bước vào.
Các công cụ này cung cấp cái nhìn sâu sắc theo thời gian thực về số liệu dịch vụ để các team có thể theo dõi mức sử dụng tài nguyên, độ trễ và tỷ lệ lỗi. Ngoài ra, các công cụ này cũng cung cấp tracing phân tán (Jaeger, Zipkin, v.v.), giúp hình dung luồng yêu cầu trên các dịch vụ và có thể rất hữu ích cho việc chẩn đoán sự cố.
Cuối cùng, vì các lỗi có thể lan tỏa trên các dịch vụ do thiết kế phân tán của microservice, tổng hợp log là một thực hành quan trọng trong giám sát microservice. Bằng cách tập hợp các log vào một nền tảng tập trung và thiết lập các cảnh báo theo thời gian thực, bạn sẽ luôn sớm phát hiện các vấn đề và có thể phản ứng chủ động trước khi chúng ảnh hưởng đến người dùng.
Suy nghĩ cuối cùng
Mặc dù thế giới của microservice chắc chắn khó hiểu, nhưng hiểu những kiến thức cơ bản và các giai đoạn chính của triển khai microservice có thể giúp toàn bộ quá trình dễ dàng hơn nhiều. Hơn nữa, khi thời gian trôi qua, càng nhiều công cụ với nhiều tính năng hơn đáng kể sẵn có cho bạn, giúp triển khai microservice đơn giản hơn bao giờ hết.
Câu hỏi thường gặp
Những chiến lược triển khai nào thường được sử dụng cho microservice?
Mặc dù có nhiều chiến lược khác nhau để triển khai microservice, các chiến lược triển khai được sử dụng phổ biến nhất bao gồm các instance dịch vụ cho mỗi container, các bản phát hành theo giai đoạn, triển khai xanh-xám và triển khai serverless, mỗi chiến lược cung cấp các mức độ cách ly, tính linh hoạt và khả năng mở rộng khác nhau.
Kubernetes đóng vai trò gì trong việc điều phối microservice?
Microservice phụ thuộc vào các công cụ điều phối microservice như Kubernetes để tự động hóa triển khai, mở rộng và quản lý các dịch vụ được container hóa, cung cấp cân bằng tải, auto-scaling và khả năng tự lành bệnh để đảm bảo microservice đàn hồi và hiệu quả.
Làm cách nào để đảm bảo bảo mật trong môi trường microservice?
Do tính chất phân tán của chúng, microservice phức tạp hơn khi nói đến bảo mật so với kiến trúc khối. Bảo mật trong microservice liên quan đến xác thực và ủy quyền các yêu cầu, mã hóa giao tiếp giữa các dịch vụ và triển khai các gateway API và service mesh như Istio để quản lý bảo mật tập trung.
