Vào những năm 60 và 70, kiến trúc nguyên khối được ưa chuộng để phát triển các ứng dụng do tài nguyên tính toán hạn chế, đòi hỏi phải kết hợp tất cả các chức năng thành một đơn vị gắn kết duy nhất.
Đó là cho đến cuối những năm 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 quy mô và độ phức tạp ngày càng tăng của các ứng dụng, đặc biệt là với sự phát triển của internet và các hệ thống phân tán.
Điều này dẫn đến sự phát triển của các phương pháp mô-đun hơn, chẳng hạn như Kiến trúc hướng dịch vụ (SOA) và sau đó, kiến trúc vi dịch vụ (MSA), cuối cùng đã trở nên nổi bật vào đầu những năm 2010.
Điều đó nói rằng, đây chỉ là lời giải thích ngắn gọn về khái niệm cơ bản và cách sử dụng microservice. Vì vậy, hãy cùng thảo luận về cách microservice thay thế kiến trúc nguyên khối, cách thức hoạt động của microservice và một số ví dụ về microservice. Sau đó, chúng ta sẽ thảo luận về các khía cạnh chính của việc triển khai vi dịch vụ và những việc cần làm nếu bạn muốn triển khai vi dịch vụ.
Microservice là gì? Chúng hoạt động như thế nào?
Như tôi đã đề cập trước đó, microservice nổi lên như một giải pháp để tăng độ phức tạp và quy mô ứng dụ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 trong 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 vào năm 2014. Công việc của họ đã xác định các nguyên tắc và đặc điểm chính, bao gồm nhu cầu về các dịch vụ có thể triển khai độc lập, quản lý dữ liệu phi tập trung và thuyết bất khả tri về công nghệ.
Kể từ đó, microservice đã trở thành một lựa chọn kiến trúc chủ đạo, được hỗ trợ bởi những tiến bộ trong công nghệ container hóa như Docker, các công cụ điều phối như Kubernetes và nền tảng điện toán không có máy chủ. Nhưng microservice hoạt động như thế nào?
Microservice hoạt động như thế nào?
Về cốt lõi, kiến trúc microservice chia một ứng dụng lớn thành các dịch vụ nhỏ hơn, riêng biệt, mỗi dịch vụ chịu trách nhiệm về một khả năng kinh doanh cụ thể. Các dịch vụ này liên lạc với nhau qua mạng, thường thông qua API REST, gRPC hoặc trình trung chuyển tin nhắn như RabbitMQ hoặc Apache Kafka.
Theo định nghĩa của Martin Fowler và James Lewis, microservice đều có bốn đặc điểm chính như sau:
- Trách nhiệm duy nhất: 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 môn hóa và giảm độ phức tạp.
- Độc lập: Các vi dịch vụ có thể được phát triển, triển khai và mở rộng quy mô độc lập với nhau, mang lại sự linh hoạt và khả năng phục hồi.
- Quản lý dữ liệu phi tập trung: Các vi dịch vụ thường có cơ sở dữ liệu riêng, tránh sự cần thiết phải có một cơ sở dữ liệu tập trung, duy nhất.
- Thuyết bất khả tri về công nghệ: Các nhóm có thể chọn công nghệ tốt nhất cho từng dịch vụ mà không bị ràng buộc bởi việc lựa chọn 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 nguyên khối 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 duy nhất.
Các giai đoạn chính của việc triển khai microservice
Mặc dù kiến trúc microservice mang lại vô số lợi ích, chẳng hạn như khả năng mở rộng cao, tính linh hoạt, hiệu quả, cách ly lỗi, v.v., nhưng nó đòi hỏi phải biết cách triển khai microservice một cách hiệu quả và lập kế hoạch tốt để thành công.
Đó là lý do tại sao việc có ý tưởng toàn diện về các khái niệm chính, các giai đoạn và phương pháp hay nhất về dịch vụ vi mô trong việc triển khai dịch vụ vi mô là điều cần thiết để có một kiến trúc vi dịch vụ thành công. Vì vậy, hãy cùng khám phá các giai đoạn chính của việc triển khai microservice và nội dung của từng giai đoạn.
Lập kế hoạch và chuẩn bị cho việc triển khai microservice
Tất cả những điều tốt đẹp đều cần có kế hoạch và sự kiên nhẫn, đồng thời để triển khai microservice thành công, bạn chắc chắn sẽ cần rất nhiều kế hoạch và sự kiên nhẫn. Đó là lý do tại sao điều quan trọng là phải tuân theo các biện pháp thực hành tốt nhất về vi dịch vụ, lập kế hoạch và chuẩn bị mọi thứ bạn cần khi triển khai vi dịch vụ.
Như tôi đã đề cập trước đó, một trong những nguyên tắc và đặc điểm chính của microservice là Nguyên tắc trách nhiệm duy nhất. Bằng cách trung thành với nguyên tắc này và đảm bảo rằng mỗi vi dịch vụ tập trung và chịu trách nhiệm về một chức năng và khả năng, bạn cho phép nhóm của mình phát triển, triển khai và mở rộng quy mô dịch vụ một cách độc lập.
Hơn nữa, một tiểu thể loại của nguyên tắc này là nguyên tắc thiết kế khớp nối 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 để liên lạc và phụ thuộc tối thiểu vào các dịch vụ khác. Đổi lại, điều này cho phép các thay đổi hoặc cập nhật đối với một dịch vụ mà không ảnh hưởng đến các dịch vụ khác, cho phép mở rộng quy mô dịch vụ vi mô độc lập.
Điều này làm giảm nguy cơ xảy ra lỗi liên tiếp, trong đó sự cố hoặc lỗi ở một bộ phận của hệ thống sẽ gây ra phản ứng dây chuyền, dẫn đến lỗi trên toàn hệ thống và làm ngừng hoạt động toàn bộ dịch vụ.
Một phương pháp thực hành vi dịch vụ quan trọng là lưu trữ dữ liệu chuyên dụng cho từng dịch vụ khi triển khai vi dịch vụ như một phần mở rộng của nguyên tắc thiết kế khớp nối lỏng lẻo, vì điều này ngăn ngừa xung đột và cho phép khả năng mở rộng dịch vụ tốt hơn.
Ngoài ra, bạn sẽ cần các mẫu giao tiếp của vi dịch vụ không đồng bộ, như trình trung chuyển tin nhắn, để đảm bảo rằng mọi dịch vụ đều có thể giao tiếp mà không cần phụ thuộc trực tiếp.
Phần cuối cùng của vấn đề là triển khai các quy trình Tích hợp liên tục và Phân phối liên tục (CI/CD) cho các vi dịch vụ. Những quy trình này cho phép các nhóm triển khai các tính năng mới hoặc sửa lỗi thông qua Công cụ CI/CD như Jenkins và GitLab, cho phép các tổ chức duy trì sự ổ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 thể về việc lập kế hoạch và chuẩn bị cần thiết cho việc triển khai vi dịch vụ, hãy nói về các chiến lược triển khai vi dịch vụ.
Chiến lược triển khai microservice
Khi bạn triển khai vi dịch vụ, việc chọn chiến lược triển khai sẽ phụ thuộc vào chức năng dịch vụ, lưu lượng truy cập, thiết lập cơ sở hạ tầng, chuyên môn của nhóm và các cân nhắc về chi phí. Tuy nhiên, nhìn chung, các chiến lược triển khai microservices như sau:
- Phiên bản dịch vụ trên mỗi vùng chứa: Theo phương pháp này, mỗi vi dịch vụ chạy trong vùng chứa riêng, mang lại khả năng cách ly tốt hơn so với nhiều phiên bản trên mỗi mô hình máy chủ. Các vùng chứa tạo điều kiện dễ dàng mở rộng quy mô và cải thiện việc phân bổ tài nguyên.
- Phiên bản dịch vụ trên mỗi máy ảo: Mỗi dịch vụ chạy trong một máy ảo (VM) riêng biệt, mang lại khả năng cách ly thậm chí còn lớn hơn so với các container. Mặc dù điều này cải thiện tính bảo mật và độ ổn định nhưng nó thường phát sinh nhiều chi phí hơn.
- Phát hành theo giai đoạn: Ban đầu, triển khai các phiên bản vi dịch vụ cho một nhóm nhỏ người dùng, kiểm tra độ ổ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 có vấn đề phát sinh và cho phép khôi phục nhanh chóng để duy trì tính toàn vẹn của hệ thống.
- Triển khai Xanh-Xanh: Phương pháp này sử dụng hai môi trường sản xuất giống hệt nhau, trong đó một môi trường phục vụ lưu lượng truy cập trực tiếp trong khi môi trường còn lại dùng để thử nghiệm bản phát hành tiếp theo. Việc triển khai xanh lam cho phép khôi phục dễ dàng và cập nhật không có thời gian ngừng hoạt động vì lưu lượng truy cập có thể được chuyển đổi liền mạch giữa hai môi trường.
- Các bản phát hành theo giai đoạn: Chiến lược này liên quan đến việc triển khai dần dần các bản cập nhật cho các phân khúc người dùng hoặc môi trường khác nhau. Nó thường bắt đầu với môi trường nội bộ trước khi đến nơi sản xuất, hạn chế phạm vi bùng nổ của bất kỳ vấn đề tiềm ẩn nào và cho phép các nhóm giải quyết vấn đề theo từng giai đoạn.
- Triển khai không có máy chủ: Cách tiếp cận này tận dụng các nền tảng không có máy chủ như AWS Fargate và Google Cloud Run, tự động hóa việc quản lý cơ sở hạ tầng bằng cách xử lý việc mở rộng quy mô và phân bổ tài nguyên cho bạn. Với việc triển khai serverless, bạn không cần phải quản lý các máy chủ cơ bản, cho phép bạn tập trung vào chính các vi dịch vụ của mình.
Sau khi chọn một trong các vi dịch vụ ở trên để triển khai vi dịch vụ, bạn sẽ cần một công cụ điều phối vi dịch vụ.
Điều phối vi dịch vụ
Sau khi chọn một trong nhiều chiến lược triển khai vi dịch vụ, bạn sẽ cần một người chỉ huy đủ loại để điều phối vi dịch vụ. Các công cụ điều phối microservice, chẳng hạn như Kubernetes, giúp tự động hóa việc triển khai vi dịch vụ, mở rộng quy mô dịch vụ vi mô, giám sát vi dịch vụ và quản lý các vi dịch vụ được chứa trong bộ chứa.
Ví dụ: Airbnb sử dụng Kubernetes, cho phép các kỹ sư của họ triển khai hàng trăm thay đổi đối với các dịch vụ vi mô của họ 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ụ điều phối microservice như Kubernetes là tính năng cân bằng tải tích hợp.
Việc có tính năng cân bằng tải hiệu quả sẽ giúp phân phối lưu lượng truy cập đến trên nhiều phiên bản của vi dịch vụ. Điều này ngăn không cho bất kỳ phiên bản đơn lẻ nào trở thành nút cổ chai và nâng cao khả năng của hệ thống trong việc xử lý nhu cầu tăng đột biến.
Kubernetes đóng một vai trò quan trọng trong việc quản lý các vi dịch vụ thông qua khả năng tự phục hồi, trong đó các thùng chứa bị lỗi sẽ tự động được thay thế và khởi động lại. New York Times tận dụng tính năng này để duy trì các vi dịch vụ của mình mà không ảnh hưởng đến trải nghiệm người dùng và trải qua thời gian ngừng hoạt động.
Hơn nữa, Kubernetes cũng cải thiện tính bảo mật của vi dịch vụ dưới dạng cấu hình và bí mật, chẳng hạn như thông tin xác thực cơ sở dữ liệu hoặc khóa API bằng cách 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ý thông tin nhạy cảm của khách hàng và người dùng.
Cuối cùng, các công cụ điều phối dịch vụ vi mô như Kubernetes đặc biệt có lợi cho các chiến lược dịch vụ vi mô liên quan đến các bản cập nhật luân phiên và quá trình khôi phục, chẳng hạn như các bản phát hành theo giai đoạn. Các bản cập nhật luân phiên cho phép triển khai các phiên bản vi dịch vụ mới mà không bị gián đoạn dịch vụ bằng cách duy trì chạy một số phiên bản của phiên bản cũ.
Sau khi thiết lập công cụ điều phối vi dịch vụ, bạn sẽ cần xây dựng và tự động hóa Đường ống CI/CD để triển khai microservice.
Quy trình CI/CD để triển khai vi dịch vụ
Như chúng ta đã đề cập trước đó, quy trình Tích hợp liên tục và Phân phối liên tục cho vi dịch vụ là những khía cạnh quan trọng của việc triển khai vi dịch vụ. Quy trình CD trong quy trình CI/CD chịu trách nhiệm tự động triển khai các thay đổi mã vào sản xuất ngay khi chúng vượt qua giai đoạn thử nghiệm và tích hợp của quy trình CI/CD.
Sau đó, phần CD của quy trình CI/CD sẽ hoạt động để bất cứ khi nào thay đổi mã vượt qua giai đoạn thử nghiệm và tích hợp, dịch vụ sẽ được triển khai tới một công cụ điều phối vi dịch vụ như cụm Kubernetes.
Hơn nữa, tất cả các giai đoạn thử nghiệm và tích hợp đều được thực hiện tự động bởi quy trình CI/CD khi kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử toàn diện được tích hợp vào quy trình.
Điều này cho phép các nhóm xác thực các bản cập nhật ở từng giai đoạn trong khi vẫn duy trì sự ổn định của hệ thống. Ngoài ra, nếu có bất kỳ vấn đề nào với việc thay đổi mã, mặc dù đã trải qua nhiều thử nghiệm khác nhau, quá trình khôi phục tự động có thể trở 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 vi dịch vụ theo các phương pháp hay nhất về vi dịch vụ giúp các tổ chứ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 vi dịch vụ thông qua các công cụ CI/CD như CircleCI, AWS CodePipeline và GitLab để tự động hóa quy trình triển khai, đảm bảo chất lượng mã nhất quán và nhanh chóng cung cấp các tính năng mới trong khi vẫn duy trì sự ổn định của hệ thống.
Các mô hình giao tiếp microservice
Cách các vi dịch vụ 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 các vi dịch vụ của bạn. Nói chung, hai loại mô hình giao tiếp microservice chính được sử dụng: đồng bộ Và không đồng bộ mô hình giao tiếp microservice.
Trong các mẫu giao tiếp vi dịch vụ đồng bộ, các dịch vụ tương tác theo thời gian thực, nghĩa là dịch vụ sẽ gửi yêu cầu và chờ phản hồi trước khi tiếp tục. Các mẫu giao tiếp microservice đồng bộ được sử dụng phổ biến nhất là API REST (Chuyển trạng thái đại diện), gRPC (Cuộc gọi thủ tục từ xa của Google), Và GraphQL.
Thông thường, loại mô hình giao tiếp vi dịch vụ này được sử dụng trong các ngành 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 ngay lập tức. 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 các mô hình giao tiếp đồng bộ để đảm bảo rằng các giao dịch, truy xuất dữ liệu hoặc tương tác diễn ra ngay lập tức, duy trì trải nghiệm người dùng mượt mà và phản hồi nhanh.
Điều đó có nghĩa là, mặc dù các mẫu giao tiếp vi dịch vụ đồng bộ mang lại các lợi ích như phản hồi theo thời gian thực và tính đơn giản, nhưng chúng cũng có một số nhược điểm nhất định như tắc nghẽn tiềm ẩn do khả năng kết nối chặt chẽ, khả năng mở rộng thấp khi tải cao, thời gian phản hồi chậm và độ trễ cao trong các trường hợp lưu lượng truy cập cao.
Mặt khác, các mẫu giao tiếp vi dịch vụ không đồng bộ thường phù hợp hơn với vi dịch vụ vì chúng dựa trên nguyên tắc Khớp nối lỏng lẻo mà chúng ta đã thảo luận trước đó.
Kiểu mẫu giao tiếp microservice này tách riêng 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 nhà môi giới như Kafka hoặc RabbitMQ. Bằng cách gửi tin nhắn đến hàng đợi hoạt động như một bộ đệm, các dịch vụ sẽ giao tiếp độc lập thay vì chờ phản hồi như trong các 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 theo tốc độ riêng của chúng, cho phép người gửi tiếp tục công việc mà không cần đợi người nhận.
Mẫu giao tiếp vi dịch vụ không đồng bộ không chỉ cung cấp cấu trúc tách rời để triển khai vi dịch vụ mà còn cung cấp phản hồi theo thời gian thực tương tự như mẫu giao tiếp vi dịch vụ đồng bộ.
Điều này là do kiến trúc hướng sự kiện của các mẫu giao tiếp vi dịch vụ hướng sự kiện không đồng bộ, vì các dịch vụ giao tiếp bằng cách phát ra các 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ý các sự kiện này và phản ứng tương ứng. Điều này cho phép các hệ thống có độ phản hồi cao, phản ứng với những thay đổi trong thời gian thực mà không cần kết hợp 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) mô hình giao tiếp của microservice, các dịch vụ (nhà xuất bản) gửi tin nhắn đến một chủ đề và các dịch vụ khác (người đăng ký) lắng nghe chủ đề đó để nhận thông tin cập nhật. Mô hình này hỗ trợ nhiều thuê bao, phát tin nhắn đồng thời tới nhiều dịch vụ.
Cuối cùng, tương tự như các mẫu hướng sự kiện, không đồng bộ câu chuyện dựa trên vũ đạo các mô hình giao tiếp microservice cũng sử dụng các sự kiện để liên lạc với nhau; tuy nhiên, trong mẫu này, có một thứ tự cụ thể được áp dụng, nghĩa là các sự kiện sẽ kích hoạt bước tiếp theo và dịch vụ cụ thể để kích hoạt.
Sự khác biệt ở đây là trong các mẫu theo hướng sự kiện, không có trình tự hoặc quy trình công việc nhất định và nhiều dịch vụ có thể phản ứng với một sự kiện thay vì quy trình và thứ tự cụ thể trong mẫu saga dựa trên vũ đạo.
Loại mẫu giao tiếp vi dịch vụ không đồng bộ mà bạn sử dụng tùy thuộc vào nhiệm vụ và chức năng tổng thể của vi dịch vụ của bạn. Hàng đợi tin nhắn như RabbitMQ và Amazon SQS thường được sử dụng để lập lịch tác vụ, phân phối khối lượng công việc và thương mại điện tử cho các hệ thống thông báo và xử lý đơn hàng.
Các trình trung chuyển tin nhắn theo hướng sự kiện, chẳng hạn như Apache Kafka và AWS EventBridge, thường được sử 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 vi dịch vụ trong các lĩnh vực như dịch vụ tài chính và môi trường AWS.
Đối với các trình môi giới tin nhắn Xuất bản-Đăng ký (Pub/Sub) như Google Cloud Pub/Sub và Redis Streams, các trình môi giới tin nhắn này thường được sử dụng để nhắn tin có thể mở rộng trên các hệ thống phân tán nhằm phân tích thời gian thực và nhập sự kiện cũng như thông báo và ứng dụng trò chuyện theo thời gian thực.
Cuối cùng, trình môi giới tin nhắn saga dựa trên vũ đạo chủ yếu được sử dụng để xử lý đơn hàng thương mại điện tử, hệ thống đặt vé du lịch và các trường hợp sử dụng trong đó các giao dịch phức tạp, nhiều bước cần được điều phối trên nhiều dịch vụ mà không cần kiểm soát trung tâm.
Khám phá dịch vụ microservice
Sau khi thiết lập và triển khai mẫu liên lạc phù hợp với nhu cầu của mình, bạn cần đảm bảo rằng các dịch vụ của mình có thể định vị lẫn nhau ngay từ đầu. Như tôi đã đề cập trước đó, các công cụ điều phối microservice như Kubernetes đóng một vai trò quan trọng trong việc khám phá dịch vụ microservice.
Điều này được thực hiện thông qua tính năng khám phá dịch vụ tích hợp mà Kubernetes DNS cung cấp, cập nhật động các địa chỉ IP và bản ghi DNS khi dịch vụ mở rộng quy mô hoặc thay đổi vị trí trong cụm.
Phương pháp khám phá dịch vụ vi mô này được gọi là khám phá phía máy chủ vì trách nhiệm định tuyến được giao cho bộ cân bằng tải, sau đó bộ cân bằng tải sẽ truy vấn sổ đăng ký và chuyển hướng lưu lượng truy cập đến phiên bản thích hợp.
Mặt khác, chúng tôi cũng có phương pháp khám phá phía máy khách để khám phá dịch vụ vi mô, trong đó dịch vụ hoặc cổng API truy vấn sổ đăng ký dịch vụ như Consul hoặc Eureka để tìm các phiên bản có sẵn.
Việc chọn phương pháp khám phá dịch vụ nào là tốt nhất cho việc triển khai vi dịch vụ của bạn tùy thuộc vào yêu cầu và quy mô của hệ thống.
Với tính năng khám phá dịch vụ vi dịch vụ phía máy khách, máy khách có toàn quyền kiểm soát phiên bản 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ụ: việc triển khai vi dịch vụ của Netflix sử dụng tính năng khám phá dịch vụ vi dịch vụ phía máy khách với Eureka và Ribbon để cân bằng tải, cho phép khách hàng chọn phiên bản 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ụ vi mô phía máy chủ phù hợp hơn với 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 hệ thống phân tán.
Các giải pháp khám phá dịch vụ vi dịch vụ phía máy chủ như Kubernetes, AWS Elastic Load Balancing và Cổng API (Kong, NGINX, v.v.) giúp định tuyến lưu lượng truy cập hiệu quả và duy trì tính sẵn sàng cao và được các công ty như Airbnb, Pinterest, Expedia, Lyft, v.v. sử dụng.
Bảo mật vi dịch vụ
Mặc dù kiến trúc nguyên khối hầu như kém hơn MSA, nhưng một khía cạnh mà kiến trúc nguyên khối có lợi thế hơn là tính bảo mật. Vì các dịch vụ vi mô được xây dựng dựa trên nguyên tắc Loose Coupling và được phân phối tự nhiên nên không thể triển khai một biện pháp bảo mật chung, đơn lẻ.
Vì mỗi dịch vụ phải được bảo mật độc lập nên cần có các biện pháp bảo vệ bổ sung vì bề mặt tấn công trong vi dịch vụ lớn hơn nhiều. Vì mục đích này, các tiêu chuẩn như OAuth2 và JSON Web Token (JWT) thường được sử dụng để xác thực và ủy quyền, như bạn có thể đoán.
Ngoài ra, cổng API cũng thường được sử dụng để quản lý bảo mật trên các vi dịch vụ vì nó thực thi xác thực và ủy quyền tại điểm vào. Ngoài ra, API cổng cũng có thể triển khai giới hạn tốc độ, ghi nhật ký và giám sát, cung cấp thêm các lớp bảo mật vi dịch vụ.
Mặc dù những biện pháp này đảm bảo an toàn cho điểm vào chính nhưng vẫn cần có nhiều biện pháp bảo mật vi dịch vụ hơn để đảm bảo hoạt động liên lạc giữa các dịch vụ.
Đây là lúc các lưới dịch vụ phát huy tác dụng khi chúng thêm một lớp bảo mật vi dịch vụ mạng và mã hóa lưu lượng giữa các dịch vụ cũng như thực thi các chính sách như TLS lẫn nhau. Về cơ bản, các lưới máy chủ này thiết lập mã hóa đầu cuối toàn diện giúp cải thiện đáng kể tính bảo mật của vi dịch vụ.
Mở rộng quy mô dịch vụ vi mô
Một trong những lợi ích lớn nhất của MSA và lý do nó được phát triển để thay thế kiến trúc nguyên khối là khả năng mở rộng cao. Thông thường, việc mở rộng quy mô microservice có thể diễn ra theo hai cách: dọc và ngang.
Về cơ bản, việc mở rộng quy mô vi dịch vụ theo chiều dọc (mở rộng quy mô) là bổ sung thêm nhiều tài nguyên hơn, chẳng hạn như CPU hoặc bộ nhớ, vào một phiên bản hiện có. Ngoài ra, việc mở rộng quy mô dịch vụ vi mô theo chiều ngang (mở rộng quy mô) sẽ phân phối tải và tăng công suất.
Về mặt triển khai, việc mở rộng quy mô dịch vụ vi mô theo chiều dọc là dễ dàng hơn cả vì tất cả những gì bạn phải làm là sửa đổi một phiên bản 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 phiên bản đám mây hoặc bổ sung thêm dung lượng lưu trữ.
Kiểu chia tỷ lệ này thường được sử dụng trong trường hợp việc tăng sức mạnh RAM hoặc 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 lưu vào bộ nhớ đệm trong bộ nhớ.
Điều đó nói lên rằng, mặc dù việc mở rộng quy mô vi dịch vụ theo chiều dọc dễ dàng hơn và mang lại hiệu suất tăng ngay lập tức nhưng nó cũng có những hạn chế. Chia tỷ lệ theo chiều dọc bị giới hạn bởi dung lượng phần cứng của máy chủ, do đó, tại một thời điểm nào đó, bạn sẽ cần chuyển sang chia tỷ lệ theo chiều ngang để tiếp tục chia tỷ lệ theo chiều dọc.
Hơn nữa, chia tỷ lệ theo chiều dọc có chi phí cao vì phần cứng và phiên bản lớn hơn thường đi kèm với mức giá cao. Cuối cùng, nếu phiên bản mở rộng không thành công thì dịch vụ sẽ ngừng hoạt động hoàn toàn vì không có phiên bản bổ sung nào để xử lý tải.
Để mở rộng quy mô vi dịch vụ theo chiều ngang, thay vì nâng cấp tài nguyên của một phiên bản, bạn hãy triển khai các phiên bản mới của dịch vụ đó. Mặc dù các phiên bản này hoạt động độc lập nhưng 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ư chia tỷ lệ theo chiều dọc, tỷ lệ chia tỷ lệ vi dịch vụ theo chiều ngang là vô hạn, nghĩa là bạn có thể thêm bao nhiêu phiên bản tùy thích để xử lý khối lượng công việc ngày càng tăng và lưu lượng truy cập tăng đột biến, mang lại khả năng mở rộng cao hơn.
Hơn nữa, vì bạn có một số phiên bản, nên nếu một phiên bản bị hỏng, bạn sẽ không bỏ tất cả trứng vào một giỏ vì các phiên bản khác có thể tiếp tục xử lý yêu cầu. Cuối cùng, chia tỷ lệ theo chiều ngang sẽ tiết kiệm chi phí hơn nhiều về lâu dài vì bạn có thể sử dụng một số phiên bản nhỏ hơn và rẻ hơn để tạo ra hiệu suất mạnh mẽ hơn, đáng tin cậy hơn.
Điều đó có nghĩa là, việc mở rộng quy mô theo chiều ngang và thêm nhiều phiên bản hơn yêu cầu nhiều bộ cân bằng tải hơn, cơ chế khám phá dịch vụ vi mô và các công cụ điều phối vi dịch vụ, khiến kiến trúc vi dịch vụ của bạn trở nên phức tạp hơn nhiều.
Chia tỷ lệ 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 truyền thông xã hội, thường có lưu lượng truy cập dao động và khối lượng yêu cầu cao.
Điều đó nói lên rằng, đây thực sự không phải là trường hợp của một trong hai hoặc vì cả hai loại quy mô đều được hỗ trợ trong vi dịch vụ 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 quy mô theo chiều dọc vì việc triển khai và quản lý đơn giản hơn nhiều, nhưng theo thời gian và khi ứng dụng phát triển, quy mô theo chiều ngang được giới thiệu để đáp ứng nhu cầu lớn.
Cuối cùng, nền tảng đám mây cung cấp các dịch vụ tự động thay đổi quy mô, tự động thêm hoặc xóa phiên bản dựa trên nhu cầu thời gian thực, giúp các tổ chức cân bằng đáng kể tỷ lệ theo chiều dọc và chiều ngang.
Giám sát vi dịch vụ
Ở giai đoạn này, bạn đã hoàn thành khá nhiều việc triển khai vi dịch vụ của mình; tất cả những gì còn lại là đảm bảo nó hoạt động ổn định 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.
Những công cụ này cung cấp thông tin chi tiết theo thời gian thực về số liệu dịch vụ để các nhóm có thể theo dõi mức sử dụng tài nguyên, độ trễ và tỷ lệ lỗi. Ngoài ra, những công cụ này còn cung cấp tính năng theo dõi phân tán (Jaeger, Zipkin, v.v.), giúp trực quan hóa các luồng yêu cầu trên các dịch vụ và có thể mang lại lợi ích lớn cho việc chẩn đoán sự cố.
Cuối cùng, do lỗi có thể xảy ra trên nhiều dịch vụ do thiết kế phân tán của vi dịch vụ nên việc tổng hợp nhật ký là một phương pháp quan trọng trong giám sát vi dịch vụ. Bằng cách hợp nhất nhật ký vào một nền tảng tập trung và thiết lập cảnh báo theo thời gian thực, bạn sẽ luôn đi trước các vấn đề hai bước và có thể chủ động phản hồi trước khi chúng tác động đến người dùng.
suy nghĩ cuối cùng
Mặc dù thế giới microservice chắc chắn là một thế giới khó hiểu, nhưng việc hiểu các nguyên tắc cơ bản và các giai đoạn chính của việc triển khai microservice có thể giúp toàn bộ quá trình trở nên dễ dàng hơn nhiều. Ngoài ra, theo năm tháng, ngày càng có nhiều công cụ với nhiều tính năng hơn đáng kể được cung cấp cho bạn, giúp việc triển khai vi dịch vụ trở nên đơ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 vi dịch vụ, nhưng các chiến lược triển khai được sử dụng phổ biến nhất bao gồm phiên bản dịch vụ trên mỗi vùng chứa, bản phát hành theo giai đoạn, triển khai xanh lam và triển khai không có máy chủ, mỗi chiến lược đều 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 các vi dịch vụ?
Các vi dịch vụ phụ thuộc vào các công cụ điều phối vi dịch vụ như Kubernetes để tự động hóa việc triển khai, mở rộng quy mô và quản lý các dịch vụ được chứa trong container, cung cấp khả năng cân bằng tải, tự động thay đổi quy mô và tự phục hồi để đảm bảo các vi dịch vụ có khả năng linh hoạt và hiệu quả.
Làm cách nào để đảm bảo tính bảo mật trong môi trường microservice?
Do tính chất phân tán của chúng, các dịch vụ vi mô phức tạp hơn về mặt bảo mật so với kiến trúc nguyên khối. Bảo mật trong vi dịch vụ bao gồm việc xác thực và cấp phép các yêu cầu, mã hóa giao tiếp giữa các dịch vụ cũng như triển khai các cổng API và lưới dịch vụ như Istio để quản lý bảo mật tập trung.
