Khi tự mình phát triển một hệ thống, tôi có nên sử dụng microservice không?

Tôi đang bắt đầu một dự án mới tại nơi làm việc và có khả năng sẽ gần như là nhà phát triển duy nhất trong dự án, mặc dù một hoặc hai nhà phát triển khác sẽ cần tích hợp các ứng dụng hiện có hoặc các tập lệnh đơn giản vào dự án chính. Dự án cần xử lý việc xử lý / xử lý dữ liệu hàng loạt và truyền dữ liệu quy mô nhỏ và cả thực thi mã theo yêu cầu và theo yêu cầu. Một số phần của khung sẽ bị ràng buộc nhiều bởi CPU và một số phần có thể bị ràng buộc I / O nặng; hầu hết dữ liệu phải nằm trên một máy, nhưng chúng tôi có thể tạo một cụm và kết nối VM để tăng sức mạnh tính toán có sẵn. Có thể sẽ có một hoặc nhiều ứng dụng web nhỏ phụ thuộc vào các dịch vụ được cung cấp khung cốt lõi này. Ngôn ngữ chính sẽ là Python cho mọi thứ.

Câu hỏi của tôi là liệu tôi nên thực hiện một cách tiếp cận microservice cho một nỗ lực như thế này hay gắn bó với một ứng dụng nguyên khối, với điều kiện là tôi sẽ tự mình thực hiện hầu hết sự phát triển. Tôi nghĩ rằng microservice (sử dụng Nameko) cung cấp sự phân tách tự nhiên giữa các yếu tố của khung có các mô hình thực thi khác nhau (đường ống dữ liệu, khởi chạy sự kiện, theo yêu cầu, ứng dụng web, v.v.) và cách rõ ràng để phân phối khối lượng công việc và giao tiếp qua nhiều quá trình. Mối quan tâm của tôi là có lẽ tôi sẽ kết thúc với cụm Kubernetes để quản lý (Tôi quen thuộc với Docker, nhưng vẫn còn khá mới đối với Kubernetes), nhiều dịch vụ (rabbitmq, redis, v.v.) chỉ cần để hỗ trợ chạy hệ thống, và có khả năng rất nhiều đoạn mã nhỏ để thực sự triển khai tất cả các khả năng cần thiết mà chúng ta '

Đối với một dự án có ít hơn một nhà phát triển, liệu microservice vẫn đơn giản hóa việc phát triển và duy trì một hệ thống phức tạp như thế này? Có phương pháp / hệ thống / khung nào tôi nên xem xét sử dụng thay thế, hoặc để giảm chi phí liên quan đến việc thiết kế hệ thống theo cách này không?

Các dịch vụ vi mô thường không mong muốn vì chúng biến phần mềm của bạn thành một hệ thống phân tán - và các hệ thống phân tán làm cho mọi thứ trở nên khó khăn hơn rất nhiều. Nhưng một kiến ​​trúc hướng dịch vụ có một số lợi ích quan trọng:

• các dịch vụ khác nhau có thể được phát triển và triển khai độc lập bởi các nhóm khác nhau
• các dịch vụ khác nhau có thể được thu nhỏ độc lập

Vì bạn sẽ là nhà phát triển duy nhất, bạn không cần linh hoạt để phát triển các dịch vụ một cách độc lập.

Nhưng bạn lưu ý rằng một số phần có thể bị ràng buộc bởi CPU. Vì vậy, nó có thể là mong muốn để quy mô những người độc lập với phần còn lại của ứng dụng. Nếu đó là trường hợp, điều đó không có nghĩa là bạn phải biến toàn bộ dự án thành một kiến ​​trúc microservice. Bạn chỉ cần chuyển phần thâm dụng CPU đó vào dịch vụ riêng của mình và có thể giữ phần còn lại trong một khối nguyên khối thuận tiện. Rất khó để phân chia hệ thống nên rất khó để nói, nhưng nói chung, ý tưởng DDD về bối cảnh bị ràng buộc trong phạm vi hướng là một hướng dẫn tốt.

Lưu ý rằng đá nguyên khối không phải là xấu. Đá nguyên khối không bằng một dự án lớn lộn xộn không thể nhầm lẫn. Khi bạn có thể chia hệ thống thành các dịch vụ siêu nhỏ khác nhau, bạn cũng có thể chia hệ thống thành các thành phần khác nhau trong một khối. Sự tách biệt giữa các thành phần này chỉ rõ hơn và được thi hành rõ ràng hơn trong kiến ​​trúc hướng dịch vụ. Điều này cũng có nghĩa là đối với một hệ thống được thiết kế tốt, việc biến một thành phần thành dịch vụ vào một thời điểm nào đó khá dễ dàng. Vì vậy, bạn không phải quyết định ngay bây giờ, bạn có thể chuyển sang microservice nếu và khi một tảng đá nguyên khối đã tự chứng minh là không phù hợp.

Cũng xem xét khái niệm của Martin Fowler về microservice Premium (2015): microservice giới thiệu sự phức tạp đáng kể của chính họ, bên cạnh sự phức tạp cơ bản của hệ thống của bạn. Bạn phải trả khoản tiền cao cấp này trên nền tảng năng suất giảm. Điều này có nghĩa là đối với các dự án đơn giản, microservice làm cho bạn kém năng suất hơn. Điều này thay đổi đối với các dự án phức tạp hơn: trong khi một giải pháp nguyên khối có thể ngày càng khó thực hiện hơn, một kiến ​​trúc microservice có quy mô tốt hơn nhiều và đòi hỏi nỗ lực gần như liên tục. Bạn phải biết liệu nỗ lực ban đầu thêm của microservice có xứng đáng với hệ thống phần mềm của bạn hay không. Vì bạn đang hỏi câu hỏi này, nên câu trả lời có lẽ là không có. Fowler tiếp tục:

Vì vậy, hướng dẫn chính của tôi thậm chí sẽ không xem xét các dịch vụ siêu nhỏ trừ khi bạn có một hệ thống quá phức tạp để quản lý như một khối nguyên khối. Phần lớn các hệ thống phần mềm nên được xây dựng dưới dạng một ứng dụng nguyên khối. Đừng chú ý đến tính mô đun tốt trong khối nguyên khối đó, nhưng đừng cố tách nó thành các dịch vụ riêng biệt.