Triển khai kiến ​​trúc microservices trong môi trường sản xuất

Informatec Digital » Recursos » Triển khai kiến ​​trúc microservices trong môi trường sản xuất

Việc áp dụng kiến ​​trúc microservices trong môi trường thực tế không chỉ đơn thuần là chia nhỏ một hệ thống nguyên khối thành các phần nhỏ hơn; nó còn liên quan đến việc xem xét lại cơ sở hạ tầng, đội ngũ, quy trình, dữ liệu, bảo mật và vận hành . Khi hệ thống chuyển từ lý thuyết sang môi trường sản xuất, các vấn đề phát sinh liên quan đến việc phát hiện dịch vụ, hợp đồng giữa các nhóm, CI/CD, khả năng quan sát, khả năng phục hồi và khả năng mở rộng. Nếu những vấn đề này không được giải quyết đúng cách, chúng có thể biến microservices thành một mớ hỗn độn phân tán.

Tin tốt là hiện nay chúng ta có rất nhiều kinh nghiệm tích lũy được từ các tổ chức như Netflix, Amazon, Google và các tập đoàn lớn khác đang vận hành hàng trăm microservice trong môi trường sản xuất . Dựa trên những bài học này, cùng với các thực tiễn tốt nhất trong môi trường doanh nghiệp sử dụng Kubernetes và OpenShift, chúng ta có thể phát triển một phương pháp rất mạnh mẽ để thiết kế, triển khai và vận hành microservice ở quy mô lớn mà không mất kiểm soát.

Tại sao nên triển khai kiến ​​trúc microservices lên môi trường sản xuất (và khi nào thì không đáng)?

Kiến trúc microservices được thiết kế tốt cho phép bạn làm việc với các nhóm nhỏ, tự chủ và đa chức năng, cùng chịu trách nhiệm về một dịch vụ từ đầu đến cuối. Mỗi nhóm hoạt động trong một bối cảnh được xác định rõ ràng, có thể triển khai thường xuyên và chịu trách nhiệm hoàn toàn về dịch vụ của mình, giúp giảm thời gian chu kỳ phát triển và đẩy nhanh việc cung cấp các tính năng mới.

Một lợi ích quan trọng khác là khả năng mở rộng độc lập cho từng dịch vụ . Bạn không cần phải tăng quy mô toàn bộ ứng dụng nếu chỉ có danh mục sản phẩm, thanh toán hoặc API công cộng gặp phải tình trạng tăng đột biến lưu lượng truy cập. Bạn có thể điều chỉnh từng microservice theo chiều ngang hoặc chiều dọc dựa trên mô hình tải của nó, đo lường chính xác chi phí của từng tính năng và duy trì tính khả dụng ngay cả khi một khu vực cụ thể gặp phải sự tăng đột biến về mức tiêu thụ.

Cách thức đóng gói và triển khai các dịch vụ này tạo điều kiện thuận lợi cho việc triển khai liên tục, ít rủi ro . Việc phát hành từng microservice một cách độc lập giúp việc thử nghiệm các ý tưởng mới và hoàn tác các phiên bản gặp sự cố trở nên đơn giản hơn nhiều: triển khai canary, hoàn tác xanh/đỏ và hoàn tác tự động giúp giảm chi phí thất bại và tạo điều kiện cho việc thử nghiệm.

Từ góc độ công nghệ, kiến ​​trúc microservices tạo điều kiện thuận lợi cho việc lựa chọn ngôn ngữ lập trình, framework và cơ sở dữ liệu cho từng dịch vụ. Không phải mọi nhu cầu đều phù hợp với cùng một bộ công nghệ: bạn có thể có các dịch vụ nghiệp vụ bằng .NET hoặc Java, xử lý dữ liệu bằng Scala/Spark, các dịch vụ chuyên biệt bằng Python hoặc F#, hoặc các microservices trí tuệ nhân tạo bằng R. Sự đa dạng có kiểm soát này cho phép bạn sử dụng công cụ phù hợp cho từng trường hợp, mà không cần phải chuyển đổi toàn bộ ứng dụng sang một công nghệ mới.

Hơn nữa, việc chia nhỏ hệ thống thành các phần nhỏ, được xác định rõ ràng giúp dễ dàng tái sử dụng các chức năng như những khối xây dựng . Một microservice ban đầu được tạo ra như một phần của chức năng lớn hơn có thể được tái sử dụng sau này như một phần phụ thuộc của các phần khác trong hệ thống mà không cần viết lại logic. Và vì các dịch vụ được cô lập, nên sự cố ở một trong số chúng thường chỉ dẫn đến sự suy giảm một phần của hệ thống, chứ không phải là sự cố ngừng hoạt động hoàn toàn của hệ thống, miễn là khả năng phục hồi đã được thiết kế ngay từ đầu.

Thiết kế kiến ​​trúc và dịch vụ

Để kiến ​​trúc microservices hoạt động hiệu quả trong môi trường sản xuất, điều cần thiết là phải bắt đầu bằng việc thiết kế cẩn thận ranh giới và trách nhiệm của các dịch vụ . Trên thực tế, điều này thường bắt đầu bằng việc xác định các dịch vụ có quy mô lớn trong hệ thống monolith hiện có: các lĩnh vực chức năng lớn hoặc các miền kinh doanh (ví dụ: đơn đặt hàng, danh mục sản phẩm, người dùng, thanh toán) đã có sự phân tách logic nhất định.

Bắt đầu từ những khối xây dựng lớn này, quy trình bao gồm việc tinh chỉnh thiết kế để có được các microservice chi tiết, hoạt động trên một tập dữ liệu nhất quán , sở hữu mô hình riêng và biết chính xác những gì chúng cần đọc hoặc ghi vào các dịch vụ khác. Quy trình này thường dựa trên các khái niệm thiết kế hướng theo miền (DDD) và ngữ cảnh giới hạn, ngăn chặn một microservice trở thành một "khối kiến ​​trúc nguyên khối thu nhỏ".

Các API cung cấp các dịch vụ này phải có các hợp đồng được định nghĩa rõ ràng và ổn định . Điều này đòi hỏi tài liệu phải chặt chẽ (REST với OpenAPI, gRPC với các tệp .proto, v.v.), phiên bản hóa rõ ràng, duy trì khả năng tương thích ngược nếu có thể và tự động hóa việc xác thực hợp đồng để phát hiện các thay đổi gây lỗi trước khi chúng được đưa vào sản xuất.

Trong môi trường có hàng chục hoặc hàng trăm dịch vụ, việc tích hợp các mô hình khả năng phục hồi ngay từ giai đoạn thiết kế là rất quan trọng, để hệ thống được chuẩn bị cho các sự cố cục bộ . Các mô hình như cầu dao ngắt mạch, thử lại với khoảng thời gian chờ, thời gian chờ được xác định rõ ràng, vách ngăn và áp suất ngược giúp ngăn chặn sự cố của một dịch vụ làm sập toàn bộ hệ thống. Các công cụ kỹ thuật hỗn loạn như ChaosMonkey hoặc Gremlin rất hữu ích để kiểm tra thực tế cách nền tảng hoạt động trong các sự cố mô phỏng.

Nhiều hệ thống phức tạp kết hợp các dịch vụ CRUD tương đối đơn giản với các dịch vụ phức tạp hơn để xử lý các quy tắc kinh doanh thay đổi. Không phải tất cả các microservice đều yêu cầu kiến ​​trúc nội bộ phức tạp : một số có thể là các bộ điều khiển HTTP đơn giản với quyền truy cập dữ liệu cơ bản, trong khi những dịch vụ khác, chẳng hạn như dịch vụ đặt hàng hoặc thanh toán, có thể tận dụng các mô hình tiên tiến hơn (DDD, CQRS, sự kiện miền, v.v.).

Cơ sở hạ tầng sản xuất: điện toán đám mây, container và Kubernetes/OpenShift

Kinh nghiệm thực tế cho thấy rằng kiến ​​trúc microservices hoạt động hiệu quả hơn nhiều khi được triển khai trên cơ sở hạ tầng đám mây với container và công cụ điều phối so với việc triển khai trên các máy ảo riêng lẻ. Các nền tảng như Kubernetes và OpenShift cung cấp các thành phần cơ bản cần thiết để đóng gói các dịch vụ thành container, mở rộng quy mô, cập nhật, cân bằng tải và quản lý tính khả dụng cao.

Thông thường, mỗi microservice được đóng gói trong một ảnh container dựa trên ảnh nền của công ty (ví dụ: OpenJDK 21 cho các dịch vụ Java) do nhóm hạ tầng quản lý. Ảnh nền này được cập nhật thường xuyên với các bản vá bảo mật, và khi một phiên bản mới được phát hành, các nhóm phát triển chịu trách nhiệm xây dựng lại và triển khai lại các dịch vụ của họ trong các môi trường tương ứng.

Trong Kubernetes/OpenShift, đơn vị triển khai cơ bản là pod, bao gồm một hoặc nhiều container . Thông thường, một microservice tương ứng với một loại pod và được triển khai bằng cách sử dụng các tài nguyên như Deployments (đối với các dịch vụ không trạng thái) hoặc StatefulSets (khi có trạng thái liên kết). Ngay từ đầu, số lượng bản sao tối thiểu cho mỗi môi trường được xác định để đảm bảo môi trường thử nghiệm, tiền sản xuất và sản xuất có mức độ khả dụng phù hợp với tầm quan trọng của chúng.

Việc tự động mở rộng quy mô được thực hiện bằng cách sử dụng HorizontalPodAutoscaler (HPA) , điều chỉnh số lượng bản sao dựa trên các chỉ số như CPU, bộ nhớ hoặc các chỉ số tùy chỉnh khác. Nền tảng cũng phải cấu hình các quy tắc chống liên kết pod để phân phối các bản sao của cùng một dịch vụ trên các nút khác nhau, ngăn chặn việc lỗi một nút duy nhất làm sập tất cả các phiên bản.

Về việc phân bổ tài nguyên theo chiều dọc, các tham số resources.requests và resources.limits được sử dụng để xác định phạm vi CPU và bộ nhớ mà một pod có thể tiêu thụ. Ví dụ, dành tối thiểu 100MB CPU và 256MB bộ nhớ, và cho phép tối đa 500MB và 2GB tương ứng cho một dịch vụ Java, điều chỉnh JVM (Xms, Xmx, Xss) để sử dụng hiệu quả tài nguyên của container.

Quản lý trạng thái: vi dịch vụ không trạng thái và có trạng thái

Hầu hết các microservice trong doanh nghiệp được thiết kế dưới dạng dịch vụ không trạng thái . Điều này có nghĩa là pod không lưu trữ thông tin cần thiết để tồn tại sau khi khởi động lại; trạng thái được lưu giữ trong cơ sở dữ liệu bên ngoài, hàng đợi tin nhắn hoặc các bộ lưu trữ khác. Cách tiếp cận này tạo điều kiện thuận lợi cho việc mở rộng quy mô theo chiều ngang một cách linh hoạt và triển khai dễ dàng, vì bất kỳ bản sao nào cũng có thể xử lý bất kỳ yêu cầu nào.

Tuy nhiên, có những trường hợp không có lựa chọn nào khác ngoài việc sử dụng các microservice có trạng thái được hỗ trợ bởi các volume lưu trữ bền vững . Điều này xảy ra với một số cơ sở dữ liệu, hệ thống tệp phân tán hoặc các thành phần yêu cầu duy trì dữ liệu cục bộ. Các pod này thường được triển khai với StatefulSets, được liên kết với PersistentVolumes bằng PersistentVolumeClaims và mở rộng theo chiều dọc thay vì chiều ngang.

Khi một microservice cần bộ nhớ lưu trữ lâu dài, một PersistentVolumeClaim (PVC) được yêu cầu với kích thước, chế độ truy cập và mục đích sử dụng , và nhóm vận hành sẽ cấp phát nó theo chính sách của nền tảng. PVC này được tham chiếu trong tệp cấu hình triển khai và được gắn vào pod để dịch vụ có thể đọc và ghi dữ liệu một cách lâu dài.

Mặc dù các mô hình có trạng thái có thể cần thiết trong những trường hợp cụ thể, nhưng khuyến nghị chung là nên giữ cho càng nhiều dịch vụ càng tốt ở dạng không trạng thái . Điều này giúp đơn giản hóa việc triển khai, mở rộng quy mô, khả năng phục hồi và khắc phục sự cố, đồng thời giảm độ phức tạp vận hành trong môi trường có nhiều microservice.

Phân quyền dữ liệu và chủ quyền dịch vụ

Trong các kiến ​​trúc hạ tầng truyền thống, việc tập trung hóa cơ sở dữ liệu và lưu trữ là điều phổ biến để tối đa hóa hiệu quả. Với kiến ​​trúc microservices, cách tiếp cận này lại mâu thuẫn với tính tự chủ của nhóm và sự tách rời giữa các thành phần. Nếu nhiều dịch vụ cùng chia sẻ một lược đồ quan hệ, bất kỳ thay đổi cấu trúc nào cũng có thể gây cản trở cho nhiều nhóm và vô tình phá vỡ tính tương thích.

Do đó, phương pháp được khuyến nghị là mỗi microservice nên sở hữu mô hình dữ liệu và cơ sở dữ liệu riêng , mặc dù trong môi trường phát triển, cơ sở dữ liệu đó chạy dưới dạng container trong cụm để đơn giản hóa việc triển khai. Trong môi trường sản xuất, các phiên bản được quản lý trên đám mây hoặc các máy chủ cơ sở dữ liệu có tính khả dụng cao khác thường được sử dụng, luôn duy trì ranh giới sở hữu rõ ràng.

Điều này không có nghĩa là không có sự tích hợp dữ liệu; mà có nghĩa là tính nhất quán giữa các dịch vụ được quản lý bằng các sự kiện và nhắn tin bất đồng bộ , chấp nhận tính nhất quán cuối cùng khi hợp lý. Thông thường, người ta sử dụng các bus sự kiện (RabbitMQ, Azure Service Bus, Kafka, v.v.) để truyền tải các thay đổi trạng thái giữa các microservice, giảm sự phụ thuộc quá lớn vào một cơ sở dữ liệu duy nhất.

Nền tảng đám mây giúp các nhóm dễ dàng lựa chọn loại cơ sở dữ liệu tối ưu cho từng dịch vụ (quan hệ, tài liệu, cặp khóa-giá trị, chuỗi thời gian, v.v.) mà không cần áp đặt một công nghệ duy nhất. Điểm mấu chốt là thiết kế xem xét khả năng di chuyển lược đồ và cấu trúc mà không vi phạm hợp đồng với các dịch vụ khác, và các quyết định về dữ liệu được đưa ra phù hợp với ranh giới miền của từng microservice.

Quản trị phân tán, đội nhóm và tổ chức

Việc chuyển sang kiến ​​trúc microservices mà không thay đổi cấu trúc tổ chức sẽ dẫn đến nhiều rắc rối. Thay vì các bộ phận chức năng riêng biệt truyền thống như mạng, hệ thống, cơ sở dữ liệu, phát triển và vận hành , cấu trúc dựa trên các nhóm sản phẩm được khuyến khích, tập hợp các chuyên gia từ bộ phận phát triển, kiểm thử phần mềm, vận hành hệ thống và, nếu cần, cả các nhà phân tích kinh doanh hoặc dữ liệu.

Mỗi nhóm chịu trách nhiệm về một hoặc nhiều microservice trong cùng một miền chức năng, đảm nhiệm cả việc phát triển và vận hành (tự xây dựng, tự vận hành) . Điều này có nghĩa là nhóm quản lý các quy trình CI/CD của mình, hợp tác với bộ phận cơ sở hạ tầng để đáp ứng các nhu cầu cụ thể và tham gia vào việc giám sát và xử lý sự cố. Cơ sở hạ tầng và nền tảng đám mây tập trung vào việc cung cấp các dịch vụ chung và được tiêu chuẩn hóa.

Để ngăn chặn tình trạng quản trị phân tán này trở nên hỗn loạn, điều quan trọng là phải xác định các tiêu chuẩn đơn giản và danh mục chung : hình ảnh nền được phê duyệt, mô hình triển khai, quy ước đặt tên cho không gian tên và dịch vụ, hướng dẫn API, mẫu Dockerfile và Kustomize, v.v. Những hướng dẫn này đóng vai trò như "rào chắn" định hướng các nhóm mà không cản trở khả năng đưa ra quyết định của họ.

Trong nhiều môi trường doanh nghiệp, các không gian tên riêng biệt được sử dụng cho mỗi dự án hoặc miền , với ít nhất một không gian tên cho mỗi môi trường (phát triển, tiền sản xuất, sản xuất). Một dự án lớn có thể phân phối các dịch vụ nhỏ của mình trên nhiều không gian tên, miễn là việc cấu hình giao tiếp nội bộ được thực hiện đúng cách và các quy tắc bảo mật được tuân thủ.

CI/CD, tự động hóa và mô hình GitOps

Khi một kiến ​​trúc bao gồm hàng chục hoặc hàng trăm microservice, cách duy nhất để duy trì hoạt động của chúng là đầu tư mạnh vào tự động hóa đầu cuối . Điều này bao gồm các quy trình CI/CD nhất quán, định nghĩa triển khai khai báo, kiểm thử tự động và cơ chế hoàn tác tự động.

Một quy trình tích hợp và phân phối liên tục (CI/CD) điển hình xử lý việc biên dịch mã, chạy thử nghiệm, phân tích chất lượng bằng các công cụ như SonarQube , xây dựng ảnh container từ Dockerfile của công ty và cập nhật các tệp cấu hình triển khai. Từ đó, một hệ thống như ArgoCD hoặc tương tự sẽ áp dụng các thay đổi cho cụm máy chủ bằng cách sử dụng phương pháp GitOps.

Mỗi kho lưu trữ microservice thường bao gồm một Dockerfile tiêu chuẩn, một tệp cấu hình pipeline (ví dụ: ci.json) , các thuộc tính để phân tích chất lượng và một thư mục triển khai với các định nghĩa Kubernetes (Kustomize hoặc Helm) được phân tách theo môi trường. Webhook của kho lưu trữ sẽ kích hoạt pipeline khi các sự kiện như đẩy thẻ hoặc yêu cầu hợp nhất xảy ra.

Mô hình GitOps thiết lập kho lưu trữ Git làm nguồn thông tin đáng tin cậy cho cơ sở hạ tầng và triển khai . Các tệp cấu hình cho Triển khai, Dịch vụ, ConfigMaps, PVC, SealedSecrets và các tài nguyên khác được quản lý phiên bản tại đó, và các công cụ chuyên dụng xử lý việc đồng bộ hóa trạng thái cụm với những gì được định nghĩa trong Git. Điều này cung cấp khả năng truy vết, xem xét yêu cầu kéo và khả năng hoàn tác dễ dàng.

Cài đặt, bí mật và bảo mật

Trong một nền tảng microservices hoàn thiện, quản lý cấu hình dựa vào ConfigMaps cho các tham số không nhạy cảm và Secrets cho thông tin bí mật . Mỗi microservice thường có ConfigMap riêng biệt dành riêng cho môi trường của nó, lưu trữ các thuộc tính như URL của các dịch vụ phụ thuộc, cờ chức năng và các tham số điều chỉnh.

Các thông tin bí mật (thông tin đăng nhập, khóa, mã thông báo, chứng chỉ) được xử lý theo các chính sách bảo mật nghiêm ngặt . Trong các môi trường ít quan trọng hơn, việc lưu trữ chúng dưới dạng văn bản thuần do nhóm phát triển quản lý có thể được chấp nhận, nhưng trong môi trường tiền sản xuất và sản xuất, nên mã hóa chúng bằng các công cụ như Sealed Secrets hoặc các trình quản lý bên ngoài dựa trên đám mây chuyên dụng.

Khi cần chia sẻ một thông tin bí mật giữa nhiều dịch vụ (ví dụ: thông tin xác thực của OTEL Collector hoặc kho khóa chung ), thông tin đó có thể được tập trung hóa trong một kho lưu trữ cấu hình cho mỗi không gian tên. Các dự án chia sẻ không gian tên đó sẽ phối hợp để cập nhật thông tin khi cần thiết, duy trì quyền kiểm soát ai có thể đọc hoặc sửa đổi các tài nguyên này.

Về mặt bảo mật truyền thông, mô hình chủ đạo là Zero Trust : không có gì được coi là an toàn tuyệt đối chỉ vì lưu lượng truy cập là "nội bộ". Tất cả các cuộc gọi giữa các dịch vụ, cả nội bộ và bên ngoài, đều phải được xác thực và ủy quyền, lý tưởng nhất là bằng mTLS, mã thông báo JWT hoặc các cơ chế tương đương khác. Kiến trúc microservices không ủy thác bảo mật một cách mù quáng cho Trình quản lý API hoặc mạng; chúng cũng tự thực hiện các kiểm tra riêng.

Giao tiếp giữa các microservice, API và hệ thống nhắn tin

Trong một kiến ​​trúc microservices hoàn thiện, lớp giao tiếp được chia thành nhiều trường hợp. Đối với lưu lượng truy cập từ các máy khách (trình duyệt, ứng dụng di động, bên thứ ba) đến máy chủ, các API được công bố và quản lý bởi Trình quản lý API được sử dụng . Các API này thường là RESTful (thường sử dụng OpenAPI) hoặc, trong một số trường hợp, gRPC được hiển thị thông qua một cổng.

Các cuộc gọi giữa các microservice nằm trong cùng một namespace, hoặc thậm chí giữa nhiều namespace khác nhau trong cùng một dự án, thường được xử lý bởi các dịch vụ Kubernetes nội bộ với DNS nội bộ . Các cuộc gọi này bỏ qua API Manager công cộng nhưng vẫn tuân thủ các chính sách bảo mật, xác thực và ủy quyền. Đối với các trường hợp này, có thể sử dụng service mesh hoặc các cổng nội bộ thực thi các chính sách chung.

Khi các microservice thuộc về các miền chức năng hoặc dự án khác nhau , việc giao tiếp được coi là "công khai" ở cấp độ tổ chức. Trong những trường hợp này, thông lệ phổ biến là sử dụng API Manager hoặc interoperability bus, nơi quản lý các hợp đồng, hạn mức, bảo mật, phiên bản và kiểm toán, ngăn chặn sự liên kết trực tiếp giữa các cụm hoặc không gian tên độc lập.

Đối với việc tích hợp với các hệ thống cũ hoặc hệ thống bên ngoài, vốn không phải lúc nào cũng cung cấp các API hiện đại, người ta thường dựa vào các trình kết nối chuyên dụng thông qua một bus tương tác . Bằng cách này, các microservice sử dụng một ngôn ngữ chung (ví dụ: các sự kiện hoặc API REST nội bộ), và trình kết nối sẽ xử lý việc chuyển đổi giữa hệ thống cũ và hệ thống mới, luôn đảm bảo tính bảo mật cao.

Bên cạnh giao tiếp đồng bộ, nhắn tin bất đồng bộ cũng đóng vai trò quan trọng . Nó được sử dụng để tách rời các quy trình, hấp thụ các xung đột lưu lượng, truyền tải các sự kiện nghiệp vụ giữa các dịch vụ và cải thiện khả năng phục hồi. Mỗi sự kiện thường có một lược đồ được xác định rõ ràng và có phiên bản, với các cơ chế theo dõi để ngăn ngừa sự cố giữa nhà sản xuất và người tiêu dùng khi chúng phát triển.

Khả năng quan sát, bộ thu thập dữ liệu OTEL và hoạt động

Trong một hệ thống gồm nhiều microservice, việc chẩn đoán sự cố mà không có khả năng quan sát tốt là gần như bất khả thi. Đó là lý do tại sao các chỉ số, việc ghi nhật ký tập trung và theo dõi phân tán được tích hợp ngay từ giai đoạn thiết kế , cho phép hiểu được những gì đang xảy ra ở cả cấp độ dịch vụ và nền tảng.

Một thành phần trung tâm của sơ đồ này là OpenTelemetry Collector (OTEL Collector) , được triển khai trong không gian tên hoặc tập trung để thu thập số liệu, nhật ký và dấu vết từ tất cả các thành phần. Các microservice chỉ cần biết rằng chúng nên gửi dữ liệu đo lường của mình đến Collector; Collector sau đó sẽ chuyển tiếp dữ liệu đó đến các hệ thống quan sát (Prometheus, Grafana, Jaeger, Elastic, v.v.) mà không cần dịch vụ phải biết chi tiết.

Đối với lớp cơ sở hạ tầng, các bộ thu thập và xuất dữ liệu cấp nút được sử dụng để thu thập các chỉ số về CPU, bộ nhớ, ổ đĩa, mạng và nhật ký từ các pod, sau đó gửi chúng đến Prometheus và Elasticsearch tương ứng. Các công cụ như Grafana và Kibana được sử dụng để trực quan hóa thông tin này, xây dựng bảng điều khiển và xác định cảnh báo với ngưỡng thông minh cùng các quy trình vận hành liên quan.

Khi một dự án cần xử lý các chỉ số hoặc dấu vết một cách rất cụ thể, dự án đó có thể triển khai phiên bản OTEL Collector riêng trong không gian tên của mình, miễn là dự án đó được phê duyệt về mặt vận hành và mô hình bảo trì sản xuất được rõ ràng.

Chiến lược thử nghiệm, hợp đồng và kinh nghiệm phát triển tại địa phương

Việc kiểm thử kiến ​​trúc vi dịch vụ phân tán đòi hỏi chiến lược kiểm thử phức tạp hơn so với kiểm thử kiến ​​trúc nguyên khối. Kiểm thử đơn vị vẫn rất cần thiết, nhưng kiểm thử hợp đồng (cho API và sự kiện), kiểm thử tích hợp giữa các dịch vụ và kiểm thử đầu cuối bao quát toàn bộ luồng hoạt động đang ngày càng trở nên quan trọng.

Để ngăn ngừa các vấn đề tương thích, các kỹ thuật như kiểm thử hợp đồng hướng đến người tiêu dùng được sử dụng , trong đó khách hàng xác định các kỳ vọng về API và nhà cung cấp dịch vụ đáp ứng chúng. Mỗi thay đổi hợp đồng đều trải qua quá trình kiểm thử tự động trong các đường dẫn CI, ngăn chặn việc triển khai làm hỏng bất kỳ người dùng nào đã biết.

Khi số lượng dịch vụ vượt quá một trăm, việc sao chép toàn bộ hệ thống cục bộ trở nên không khả thi. Do đó, quá trình phát triển dựa vào việc mô phỏng các dịch vụ phụ thuộc hoặc kết nối đến môi trường từ xa . Thông thường, các nhà phát triển chỉ khởi chạy một tập hợp con các microservice và thay thế phần còn lại bằng các đối tượng giả lập, mô phỏng hoặc chuyển hướng một số lệnh gọi nhất định đến môi trường tích hợp dùng chung.

Kiểm thử đầu cuối ngày càng dựa vào các môi trường tạm thời hoặc "bản xem trước" được tạo từ các nhánh tính năng , thiết lập một môi trường biệt lập với các dịch vụ liên quan đến chức năng đó. Điều này giảm thiểu ma sát giữa các nhóm, giảm hiệu ứng "nó hoạt động trên máy của tôi" và phát hiện các vấn đề tích hợp trước khi đến các môi trường tốn kém hơn như môi trường tiền sản xuất.

Mô hình triển khai microservices trong môi trường sản xuất

Ngoài Kubernetes, có một số mô hình triển khai microservices trong môi trường sản xuất đáng để tìm hiểu vì chúng giải quyết các kịch bản khác nhau về tính cô lập, chi phí và độ trưởng thành . Một trong những mô hình lâu đời nhất là nhiều phiên bản dịch vụ trên mỗi máy chủ, trong đó một máy chủ vật lý hoặc ảo duy nhất chạy nhiều phiên bản của các dịch vụ khác nhau, thường là trên một máy chủ ứng dụng dùng chung.

Trong mô hình mỗi phiên bản dịch vụ trên một máy ảo (VM) , mỗi dịch vụ được đóng gói thành một ảnh VM (ví dụ: EC2 AMI) và chạy trên một phiên bản riêng biệt. Điều này mang lại sự cô lập mạnh mẽ nhưng đổi lại là mức tiêu thụ tài nguyên cao hơn và thời gian khởi động chậm hơn. Các công cụ như Packer hoặc các giải pháp dành riêng cho nhà cung cấp dịch vụ đám mây giúp dễ dàng tạo ra các ảnh VM sẵn sàng cho môi trường sản xuất.

Mô hình phổ biến nhất hiện nay là mỗi dịch vụ được cấu hình trong một container , trong đó mỗi microservice được xây dựng dưới dạng ảnh container và triển khai trên một hệ thống điều phối (Kubernetes, OpenShift, v.v.). Container nhẹ hơn máy ảo, khởi động rất nhanh và cho phép bạn đóng gói mọi thứ cần thiết cho dịch vụ, đơn giản hóa việc triển khai và cho phép tự động mở rộng quy mô.

Cuối cùng, các phương pháp điện toán phi máy chủ, chẳng hạn như AWS Lambda , đã trở nên phổ biến. Các gói chức năng này phản hồi các yêu cầu HTTP hoặc sự kiện từ các dịch vụ khác (S3, DynamoDB, hàng đợi, v.v.), người dùng chỉ trả tiền cho những gì họ sử dụng. Mô hình này đặc biệt phù hợp với các microservice rất nhỏ hoặc các tác vụ hướng sự kiện có thời gian tồn tại ngắn, mặc dù nó đặt ra thêm các vấn đề cần xem xét liên quan đến khả năng quan sát, khởi động nguội và giới hạn thực thi.

Trên thực tế, nhiều tổ chức cuối cùng sử dụng hệ sinh thái lai: phần cốt lõi của hệ thống chạy trên container và orchestrator, trong khi một số thành phần phụ trợ được triển khai dưới dạng các hàm serverless hoặc máy ảo chuyên dụng, luôn có giao diện rõ ràng và các giao thức được xác định rõ để tích hợp chúng vào toàn bộ hệ thống.

Khi đưa tất cả những điều này vào sản xuất, điều tạo nên sự khác biệt không chỉ là công nghệ được lựa chọn, mà còn là việc xây dựng một kiến ​​trúc có khả năng chịu lỗi, mở rộng khi cần thiết, triển khai tự động và có thể quan sát được . Với các nhóm làm việc tập trung vào sản phẩm, các hợp đồng được quản lý tốt, dữ liệu phi tập trung và một nền tảng đám mây mạnh mẽ, kiến ​​trúc microservices không chỉ là một lời hứa mà còn trở thành một cách hiệu quả và bền vững để phát triển các ứng dụng phức tạp trong nhiều năm tới.