Có vẻ như đỉnh cao của sự cường điệu đối với microservice đã ở phía sau chúng ta. Chúng tôi không còn đọc các bài đăng vài lần một tuần “Cách tôi chuyển khối nguyên khối của mình sang 150 dịch vụ”. Bây giờ tôi nghe thấy nhiều suy nghĩ thông thường hơn: “Tôi không ghét đá nguyên khối, tôi chỉ quan tâm đến hiệu quả”. Chúng tôi thậm chí còn quan sát thấy một số cuộc di cư . Khi chuyển từ một ứng dụng lớn sang nhiều dịch vụ nhỏ hơn, bạn sẽ phải giải quyết một số vấn đề mới. Hãy để chúng tôi liệt kê chúng càng ngắn gọn càng tốt.
Bối cảnh: từ hóa học cơ bản đến cơ học lượng tử
Thiết lập cơ sở dữ liệu và ứng dụng cơ bản với quy trình nền là một quá trình khá đơn giản. Tôi xuất bản readme trên Github - và thường sau một giờ, nhiều nhất là vài giờ, mọi thứ đều hoạt động và tôi bắt đầu một dự án mới. Việc thêm và chạy mã, ít nhất là đối với môi trường ban đầu, được thực hiện vào ngày đầu tiên. Nhưng nếu chúng ta dấn thân vào lĩnh vực microservices, thời gian ra mắt lần đầu sẽ tăng vọt. Vâng, bây giờ chúng tôi có Docker với khả năng điều phối và một cụm máy K8, nhưng đối với một lập trình viên mới làm quen, tất cả điều này phức tạp hơn nhiều. Đối với nhiều đàn em, đây thực sự là một gánh nặng và là một sự phức tạp không đáng có.
Hệ thống này không dễ hiểu
Hãy tập trung vào đàn em của chúng ta một lát. Với các ứng dụng nguyên khối, nếu xảy ra lỗi, bạn có thể dễ dàng theo dõi và chuyển sang gỡ lỗi ngay lập tức. Bây giờ chúng tôi có một dịch vụ đang nói chuyện với một dịch vụ khác đang xếp hàng thứ gì đó trên bus tin nhắn đang xử lý dịch vụ khác - và sau đó xảy ra lỗi. Chúng tôi phải ghép tất cả các phần này lại với nhau để cuối cùng phát hiện ra rằng Dịch vụ A đang chạy phiên bản 11 và Dịch vụ E đang chờ phiên bản 12. Điều này rất khác với nhật ký tổng hợp tiêu chuẩn của tôi: phải sử dụng thiết bị đầu cuối/trình gỡ lỗi tương tác để đi bộ thông qua quá trình từng bước. Việc gỡ lỗi và hiểu biết vốn đã trở nên khó khăn hơn.
Nếu không thể sửa lỗi, có thể chúng tôi sẽ kiểm tra chúng
Hội nhập liên tục và phát triển liên tục hiện đang trở nên phổ biến. Hầu hết các ứng dụng mới mà tôi thấy đều tự động tạo và chạy thử nghiệm với mỗi bản phát hành mới, đồng thời yêu cầu thực hiện và xem xét các thử nghiệm trước khi đăng ký. Đây là những quy trình tuyệt vời không nên bỏ qua và đã là một sự thay đổi lớn đối với nhiều công ty. Nhưng bây giờ, để thực sự kiểm tra dịch vụ, tôi phải tải lên phiên bản hoạt động đầy đủ của ứng dụng của mình. Bạn có nhớ kỹ sư mới với cụm K8 gồm 150 dịch vụ không? Bây giờ chúng ta sẽ hướng dẫn hệ thống CI của mình cách hiển thị tất cả các hệ thống này để xác minh rằng mọi thứ thực sự hoạt động. Việc này có lẽ tốn quá nhiều công sức nên chúng tôi sẽ chỉ kiểm tra từng phần một cách riêng biệt: Tôi tin tưởng rằng thông số kỹ thuật của chúng tôi đủ tốt, các API sạch và lỗi dịch vụ sẽ được tách biệt và sẽ không ảnh hưởng đến những phần khác.
Mọi sự thỏa hiệp đều có lý do chính đáng. Phải?
Có nhiều lý do để chuyển sang microservices. Tôi đã thấy điều này được thực hiện để mang lại sự linh hoạt cao hơn, cho các nhóm mở rộng quy mô, để đạt được hiệu suất và mang lại sự bền vững tốt hơn. Nhưng trên thực tế, chúng tôi đã đầu tư hàng thập kỷ vào các công cụ và phương pháp thực hành để phát triển các khối nguyên khối tiếp tục phát triển. Tôi làm việc với các chuyên gia trong các công nghệ khác nhau. Chúng ta thường nói về việc mở rộng quy mô vì chúng đi vào giới hạn của một nút cơ sở dữ liệu Postgres. Hầu hết các cuộc trò chuyện đều xoay quanh .
Nhưng tôi luôn thích tìm hiểu về kiến trúc của họ. Họ đang ở giai đoạn nào của quá trình chuyển đổi sang microservice? Thật thú vị khi thấy ngày càng có nhiều kỹ sư nói rằng họ hài lòng với ứng dụng nguyên khối của mình. Nhiều người sẽ được hưởng lợi từ microservice và lợi ích sẽ lớn hơn những trở ngại trên con đường di chuyển. Nhưng cá nhân tôi, xin vui lòng cho tôi đơn xin việc nguyên khối, một chỗ trên bãi biển - và tôi hoàn toàn hạnh phúc.
Nguồn: www.habr.com