Dịch vụ vi mô: MonolithFirst?

Tôi đã nghiên cứu các kiến ​​trúc microservice cố gắng có được một cái nhìn tổng quan ở mức độ cao về tất cả các ưu và nhược điểm, whens và whys, v.v. Rất nhiều thông tin tôi đang đọc / xem đến từ Th thinkWorks (Martin Fowler, Neal Ford, et al).

Hầu hết các tác phẩm của Martin Fowler về chủ đề này đều đã được vài năm tuổi, khi microservice (như một tên hộ gia đình trong lập trình, nếu không phải trong thực tế nói chung) vẫn còn trẻ, do đó tôi dùng nhiều hạt muối.

Một điều đặc biệt là đây:

Khi tôi nghe những câu chuyện về các đội sử dụng kiến ​​trúc microservice, tôi đã nhận thấy một mô hình chung.

• Hầu như tất cả các câu chuyện microservice thành công đã bắt đầu với một tảng đá quá lớn và đã bị phá vỡ
• Hầu như tất cả các trường hợp tôi đã nghe nói về một hệ thống được xây dựng như một hệ thống microservice từ đầu, nó đã gặp rắc rối nghiêm trọng.

Mô hình này đã khiến nhiều đồng nghiệp của tôi lập luận rằng bạn không nên bắt đầu một dự án mới với microservice, ngay cả khi bạn chắc chắn rằng ứng dụng của bạn sẽ đủ lớn để làm cho nó đáng giá. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - nhấn mạnh họ)

Bây giờ, 3 năm sau và với microservice một thuật ngữ phổ biến hơn, nói chung có thể đồng ý rằng một hệ thống mới thường được phục vụ tốt hơn bằng cách có các khối dịch vụ lớn hơn (-than-microservice-but-small-than-monolith) để bắt đầu và thực hiện chúng chi tiết hơn như là một phần của một biện pháp tiến hóa?

Hoặc, có một tiêu chuẩn để bắt đầu một dự án từ đầu với kiến ​​trúc microservice dạng hạt, trái ngược với các tuyên bố trên không?

Có vẻ như một cách tiếp cận chung lành mạnh, nhưng tò mò về suy nghĩ của cộng đồng.

Nếu công ty của bạn đã làm microservice được một thời gian, một số phần có thể đã được xây dựng và bạn chỉ cần kết hợp chúng. Các ví dụ có khả năng có thể là xác thực như một dịch vụ hoặc lưu trữ dữ liệu blob. Trong trường hợp đó, bạn đã xác định ranh giới và bạn đang sử dụng lại mã trong một ứng dụng mới. Đó là một điều tốt.

Đối với mã mới mà bạn không chắc chắn nơi cần có ranh giới, hãy xây dựng nó trong một dịch vụ. Nếu bạn giữ mô-đun, bạn có thể tách microservice khỏi nó nếu cần. Đặc biệt là khi bạn tìm thấy các phần của dịch vụ của bạn cần phải mở rộng quy mô khác với phần còn lại.

Lợi ích của microservice là bạn có thể thêm các thể hiện để mở rộng quy mô công việc đang được thực hiện theo yêu cầu. Nếu một số công việc của bạn bùng nổ, có thể có ý nghĩa tách biệt điều đó thành microservice riêng của nó.

Nói chung:

• Nếu bạn đã xây dựng microservice, hãy sử dụng lại chúng
• Nếu bạn đang xây dựng một cái gì đó mới, hãy làm cho ý tưởng hoạt động trước
• Khi bạn đang xây dựng, hãy cố gắng giữ mọi thứ theo mô-đun để một số dịch vụ có thể dễ dàng bị phá vỡ
• Khi bạn đang xây dựng, nếu một phần dịch vụ của bạn cần có khả năng mở rộng theo yêu cầu ở một mức giá khác, hãy tách riêng nó thành dịch vụ riêng của nó

Rất thường xuyên, chúng tôi nghe thấy những hướng dẫn hữu ích từ những người thông minh có danh tiếng tốt như Martin Fowler, và sau đó biến nó thành một học thuyết cứng không thể bị lung lay theo bất kỳ cách nào.

Bạn phải đưa ra những tuyên bố như thế theo tinh thần chúng có ý nghĩa như thế nào. Martin Fowler đang cố gắng cứu người khỏi bị tê liệt bằng cách phân tích và bảo họ xây dựng thứ gì đó hoạt động trước. Bạn luôn có thể tách nó ra sau, khi bạn biết thêm về cách ứng dụng của bạn thực sự hoạt động.

Những lợi ích có giá trị ngay lập tức nhất của microservice có thể đạt được bằng cách mô đun hóa mã đơn giản. Bạn có thể cô lập các nhóm tính năng thành các mô-đun bằng bất kỳ hệ thống mô-đun nào bạn có (maven, npm, nuget, bất cứ thứ gì). Mỗi mô-đun có thể phục vụ một mục đích duy nhất, đặt repo riêng, sử dụng lược đồ DB riêng, quản lý cấu hình riêng của nó, có lịch trình tồn đọng và tính năng riêng của nó. Chúng vẫn có thể được triển khai cùng nhau trên một tảng đá nguyên khối. Đây là một khoản chi phí rất dễ quản lý và mang lại một số lợi ích tốt. Chi phí lớn hơn đến từ việc phân tách các triển khai chỉ thực sự có giá trị khi bạn có đủ quy mô để bắt buộc. Nếu mã của bạn đã được mô đun hóa, thì đó sẽ là một sự di chuyển dễ dàng hơn khi đến lúc.

Theo tôi, trước tiên có thể phát triển một khối nguyên khối (hoặc tốt hơn: phát triển các phần trong ứng dụng của bạn dưới dạng nguyên khối).

Có những trường hợp khi bạn không chắc chắn về tên miền và ranh giới của vấn đề của bạn (ví dụ: tôi xây dựng trang web quản lý tàu, tôi có cần dịch vụ tàu VÀ dịch vụ đội tàu hay dịch vụ tàu có đủ không?), Và trong những trường hợp như vậy nguyên khối có thể dễ dàng phát triển hơn.

Bạn nên dừng việc này nếu bạn cần đưa các công nghệ khác nhau vào hỗn hợp (ví dụ: các phần hiện có của bạn được viết bằng C #, nhưng vấn đề mới của chúng tôi đòi hỏi phải học máy, được thực hiện tốt nhất với python), hiểu rõ về các miền trong dự án hoặc các điều ước nguyên khối của bạn để mạ điện, ví dụ như mọi người chỉ xây dựng khối nguyên khối này và xóa bỏ khái niệm về các dịch vụ riêng biệt.

Tôi khá chắc chắn đã có một vài câu hỏi về bài viết chính xác này của MF.

Tôi chấp nhận nó là thế này:

Một Monolith với các vấn đề về bảo trì hoặc khả năng mở rộng được cải thiện bằng cách chia nhỏ nó thành các dịch vụ vi mô. Một dự án như vậy hầu như sẽ luôn luôn 'thành công' vì thậm chí phá vỡ một phần nhỏ có thể mang lại lợi nhuận có thể đo lường được và bạn có thể vẽ một đường bên dưới nó khi bạn hạnh phúc.

Cho dù một nửa nguyên khối của bạn + một hàng đợi tin nhắn và một vài quy trình công nhân được tính là 'Kiến trúc dịch vụ vi mô' là một đối số để xuống quán rượu, nhưng bạn chắc chắn sẽ gọi nó như vậy khi bạn nói về dự án.

Mặt khác, bất kỳ dự án mới nào, bất kể kiến ​​trúc được chọn đều có nguy cơ không đáp ứng được kỳ vọng, do đó, tự nhiên bạn sẽ mong đợi tỷ lệ thành công thấp hơn. Ngoài ra, nếu bạn đã bắt đầu nhắm đến việc tạo ra toàn bộ 'Kiến trúc vi mô thực hành tốt nhất' từ đầu thì bạn có thể mạo hiểm với các công nghệ mới và các dịch vụ siêu nhỏ khó hơn.

Ngoài ra, chúng ta phải nhớ rằng MF viết từ góc độ OOP lớn. Ông tự nhiên hoài nghi về một cách tiếp cận phân tán hiện đại hơn.

Trong thời đại ngày nay, tôi mong đợi bất kỳ giải pháp kinh doanh lớn nào sẽ kết hợp một yếu tố của microservice và chỉ một kẻ ngốc mới khuyên bạn nên tạo một ứng dụng nguyên khối khổng lồ trừ khi bạn đang phân phối một ứng dụng kiểu máy tính để bàn.

Theo kinh nghiệm (rộng lớn) của tôi, tôi đã chứng kiến ​​nhiều dự án thất bại vì vấn đề con người hơn là vấn đề công nghệ. Thật không may, mọi người không thích thất bại và vì vậy có xu hướng hiểu sai lý do cho sự thất bại và đổ lỗi cho công nghệ.

Trong lĩnh vực tài chính của tôi, hầu hết các dự án mới đều tuân theo kiến ​​trúc microservice ngày nay và dường như đó là một kiến ​​trúc chiến thắng từ quan điểm của TCO (tổng chi phí sở hữu). Các dự án này dường như không thất bại thường xuyên và khi chúng thực hiện các lý do được đưa ra thường không liệt kê kiến ​​trúc ứng dụng là vấn đề.