Quản lý dữ liệu phi tập trung - đóng gói cơ sở dữ liệu vào microservice [đã đóng]

Gần đây tôi đã tham gia một khóa học về Thiết kế phần mềm và đã có một cuộc thảo luận / đề xuất gần đây về việc sử dụng mô hình 'microservice' trong đó các thành phần của dịch vụ được tách thành các thành phần phụ microservice độc ​​lập nhất có thể.

Một phần được đề cập là thay vì theo mô hình thường thấy là có một cơ sở dữ liệu duy nhất mà tất cả các dịch vụ micros nói chuyện, bạn sẽ có một cơ sở dữ liệu riêng chạy cho từng microservice.

Một lời giải thích tốt hơn và chi tiết hơn về điều này có thể được tìm thấy ở đây: http://martinfowler.com/articles/microservice.html trong phần Quản lý dữ liệu phi tập trung

phần nổi bật nhất nói điều này:

Microservice thích cho phép mỗi dịch vụ quản lý cơ sở dữ liệu của riêng mình, hoặc các phiên bản khác nhau của cùng một công nghệ cơ sở dữ liệu hoặc các hệ thống cơ sở dữ liệu hoàn toàn khác nhau - một cách tiếp cận được gọi là Polyglot Persistence. Bạn có thể sử dụng tính bền bỉ của polyglot trong một khối, nhưng nó xuất hiện thường xuyên hơn với microservice.

hinh 4

Tôi thích khái niệm này và, trong số nhiều thứ khác, xem đó là một cải tiến mạnh mẽ về bảo trì và có các dự án với nhiều người làm việc với chúng. Điều đó nói rằng, tôi không có nghĩa là một kiến ​​trúc sư phần mềm kinh nghiệm. Có ai đã từng thử thực hiện nó chưa? Những lợi ích và rào cản bạn đã chạy vào?

Hãy nói về những mặt tích cực và tiêu cực của phương pháp microservice.

Tiêu cực đầu tiên. Khi bạn tạo microservice, bạn đang thêm độ phức tạp vốn có trong mã của mình. Bạn đang thêm chi phí. Bạn đang làm cho việc tái tạo môi trường trở nên khó khăn hơn (ví dụ: đối với các nhà phát triển). Bạn đang làm cho việc gỡ lỗi các vấn đề không liên tục trở nên khó khăn hơn.

Hãy để tôi minh họa một nhược điểm thực sự. Hãy xem xét giả thuyết về trường hợp bạn có 100 microservice được gọi trong khi tạo một trang, mỗi trang sẽ thực hiện đúng 99,9% thời gian. Nhưng 0,05% thời gian họ tạo ra kết quả sai. Và 0,05% thời gian có yêu cầu kết nối chậm, trong đó, thời gian chờ TCP / IP là cần thiết để kết nối và mất 5 giây. Khoảng 90,5% thời gian yêu cầu của bạn hoạt động hoàn hảo. Nhưng khoảng 5% thời gian bạn có kết quả sai và khoảng 5% thời gian trang của bạn chậm. Và mỗi thất bại không thể tái sản xuất có một nguyên nhân khác nhau.

Trừ khi bạn đặt nhiều suy nghĩ xung quanh công cụ để theo dõi, tái tạo, v.v., điều này sẽ biến thành một mớ hỗn độn. Đặc biệt khi một microservice gọi một cái khác gọi một cái khác sâu vài lớp. Và một khi bạn gặp vấn đề, nó sẽ chỉ trở nên tồi tệ hơn theo thời gian.

OK, điều này nghe có vẻ như một cơn ác mộng (và hơn một công ty đã tạo ra những vấn đề lớn cho chính họ bằng cách đi theo con đường này). Thành công chỉ có thể là bạn nhận thức rõ ràng về nhược điểm tiềm năng và luôn nỗ lực để giải quyết nó.

Vậy còn cách tiếp cận nguyên khối đó thì sao?

Nó chỉ ra rằng một ứng dụng nguyên khối cũng dễ dàng mô đun hóa như microservice. Và một cuộc gọi chức năng vừa rẻ hơn và đáng tin cậy hơn trong thực tế so với cuộc gọi RPC. Vì vậy, bạn có thể phát triển điều tương tự ngoại trừ việc nó đáng tin cậy hơn, chạy nhanh hơn và liên quan đến ít mã hơn.

OK, vậy tại sao các công ty đi đến phương pháp microservice?

Câu trả lời là bởi vì khi bạn mở rộng quy mô, có giới hạn cho những gì bạn có thể làm với một ứng dụng nguyên khối. Sau rất nhiều người dùng, rất nhiều yêu cầu, v.v., bạn đạt đến điểm mà cơ sở dữ liệu không mở rộng được, máy chủ web không thể giữ mã của bạn trong bộ nhớ, v.v. Hơn nữa, các phương pháp tiếp cận microservice cho phép nâng cấp độc lập và gia tăng ứng dụng của bạn. Do đó, kiến ​​trúc microservice là một giải pháp để nhân rộng ứng dụng của bạn.

Nguyên tắc cá nhân của tôi là đi từ mã bằng ngôn ngữ kịch bản (ví dụ Python) sang C ++ được tối ưu hóa nói chung có thể cải thiện 1-2 bậc độ lớn về cả hiệu suất và mức sử dụng bộ nhớ. Đi theo con đường khác đến một kiến ​​trúc phân tán sẽ tăng thêm độ lớn cho các yêu cầu tài nguyên nhưng cho phép bạn mở rộng quy mô vô thời hạn. Bạn có thể làm cho một công trình kiến ​​trúc phân tán, nhưng làm như vậy thì khó hơn.

Vì vậy, tôi sẽ nói rằng nếu bạn đang bắt đầu một dự án cá nhân, hãy đi nguyên khối. Học cách làm tốt điều đó. Không được phân phối vì (Google | eBay | Amazon | vv). Nếu bạn đặt chân đến một công ty lớn được phân phối, hãy chú ý đến cách họ làm cho nó hoạt động và đừng làm hỏng nó. Và nếu bạn buộc phải thực hiện quá trình chuyển đổi, hãy hết sức cẩn thận vì bạn đang làm một việc gì đó rất khó để có được rất, rất sai.

Tiết lộ, tôi có gần 20 năm kinh nghiệm trong các công ty thuộc mọi quy mô. Và vâng, tôi đã thấy các kiến ​​trúc nguyên khối và phân tán gần gũi và cá nhân. Dựa trên kinh nghiệm mà tôi nói với bạn rằng kiến ​​trúc microservice phân tán thực sự là thứ bạn làm vì bạn cần chứ không phải vì nó sạch hơn và tốt hơn.

Tôi hoàn toàn đồng ý với câu trả lời của btilly, nhưng chỉ muốn thêm một điều tích cực khác cho microservice, mà tôi nghĩ là một nguồn cảm hứng ban đầu đằng sau nó.

Trong thế giới của microservice, các dịch vụ được liên kết với các miền và được quản lý bởi các nhóm riêng biệt (một nhóm có thể quản lý nhiều dịch vụ). Điều này có nghĩa là mỗi nhóm có thể phát hành các dịch vụ hoàn toàn riêng biệt và độc lập với bất kỳ dịch vụ nào khác (giả sử phiên bản chính xác, v.v.).

Trong khi đó có vẻ như là một lợi ích tầm thường, hãy xem xét điều ngược lại trong một thế giới nguyên khối. Ở đây, nơi một phần của ứng dụng cần được cập nhật thường xuyên, nó sẽ tác động đến toàn bộ dự án và bất kỳ nhóm nào khác làm việc với nó. Sau đó, bạn sẽ cần phải giới thiệu lập lịch, đánh giá, v.v. và toàn bộ quá trình chậm lại.

Vì vậy, theo sự lựa chọn của bạn, cũng như xem xét các yêu cầu mở rộng của bạn, cũng xem xét bất kỳ cấu trúc nhóm nào được yêu cầu. Tôi đồng ý với khuyến nghị của btilly rằng bạn bắt đầu sử dụng Monolithic và sau đó xác định sau đó microservice có thể trở nên có lợi, nhưng lưu ý rằng khả năng mở rộng không phải là lợi ích duy nhất.

Tôi đã làm việc tại một nơi có nhiều nguồn dữ liệu độc lập. Họ đã đặt tất cả chúng vào một cơ sở dữ liệu, nhưng vào các lược đồ khác nhau được truy cập bởi các dịch vụ web. Ý tưởng là mỗi dịch vụ chỉ có thể truy cập lượng dữ liệu tối thiểu mà họ cần để thực hiện công việc.

Nó không vượt quá nhiều so với cơ sở dữ liệu nguyên khối, nhưng tôi đoán điều này chủ yếu là do bản chất của dữ liệu đã có trong các nhóm bị cô lập.

Các dịch vụ web được gọi từ mã máy chủ web đã tạo ra một trang, do đó, nó rất giống với kiến ​​trúc microservice của bạn, mặc dù có thể không vi mô như từ gợi ý và không được phân phối, mặc dù chúng có thể được (lưu ý rằng một WS đã gọi ra để lấy dữ liệu từ dịch vụ bên thứ 3, do đó, có 1 phiên bản của dịch vụ dữ liệu phân tán ở đó). Công ty đã làm điều này quan tâm đến bảo mật hơn quy mô, tuy nhiên, các dịch vụ và dịch vụ dữ liệu này cung cấp một bề mặt tấn công an toàn hơn trong đó một lỗ hổng có thể khai thác trong một sẽ không cung cấp quyền truy cập đầy đủ vào toàn bộ hệ thống.

Roger Sessions trong các bản tin Objectwatch xuất sắc của mình đã mô tả một cái gì đó tương tự với khái niệm Pháo đài phần mềm của anh ấy (tiếc là các bản tin không còn trực tuyến, nhưng bạn có thể mua sách của anh ấy).