Nếu một kiến ​​trúc microservice cần một cơ sở dữ liệu riêng cho mỗi microservice thì nó quá tốn kém & không thể quản lý được. Tại sao chúng ta thậm chí cần nó?

Tôi đọc về microservice và có vẻ phi logic với tôi để tạo một DB riêng cho mỗi dịch vụ chỉ để đạt được sự cô lập. Tôi có thể đạt được điều tương tự khi chỉ sử dụng các dịch vụ web và cơ sở dữ liệu duy nhất. Tại sao chúng ta thậm chí cần nó? Điều mà cơ sở dữ liệu riêng biệt là ngoài thảo luận. Hay tôi đơn giản là sai? Bạn có thể hướng dẫn tôi về điều này?

Tại sao chúng ta thậm chí cần nó?

Bạn không.

Tạo một cơ sở dữ liệu riêng cho mỗi dịch vụ giúp thực thi các ranh giới miền, nhưng đó chỉ là một cách tiếp cận. Không có gì ngăn bạn có tất cả các dịch vụ của bạn chia sẻ cùng một cơ sở dữ liệu.

Miễn là các dịch vụ của bạn hoạt động và không làm những điều bất ngờ đối với dữ liệu thuộc sở hữu của các dịch vụ khác, bạn sẽ ổn.

Tôi không biết những gì bạn đọc, nhưng bạn nên biết rằng có nhiều ý kiến ​​khác nhau về kiến ​​trúc microservice. Đây là một bài viết blog tốt về chủ đề này.

Tôi đã thấy mọi người đề cập đến ý tưởng này một phần, vì tầm thường, vì mỗi dịch vụ micros micros nên sở hữu và kiểm soát cơ sở dữ liệu của riêng mình và không có hai dịch vụ nào nên chia sẻ cơ sở dữ liệu. Ý tưởng là âm thanh: không chia sẻ một cơ sở dữ liệu duy nhất trên các dịch vụ vì sau đó bạn gặp phải các xung đột như cạnh tranh đọc / ghi mẫu, xung đột mô hình dữ liệu, thách thức phối hợp, v.v.

Nhưng một cơ sở dữ liệu duy nhất cung cấp cho chúng tôi rất nhiều sự an toàn và tiện lợi: giao dịch ACID, nơi duy nhất để tìm kiếm, được hiểu rõ (kinda?), Một nơi để quản lý, v.v.

Hành trình đến microservice chỉ là: một hành trình . Nó sẽ khác nhau cho mỗi công ty. Không có quy tắc cứng và nhanh, chỉ có sự đánh đổi.

Phần khó nhất về microservice: Dữ liệu của bạn

Như Dan Wilson trả lời, bạn không thực sự cần nó. Microservice là điều nóng mới, và giống như tất cả những thứ nóng mới, mọi người sử dụng chúng ở nhiều nơi ngay cả khi chúng không cung cấp nhiều giá trị.

Microservice cho phép bạn triển khai độc lập và mở rộng mọi thứ ở mức độ "vi mô". Mức độ chi tiết đó cung cấp một loạt lợi ích kỹ thuật và thậm chí nhiều lợi ích phi kỹ thuật hơn vì nó cho phép bạn phân tách các nhóm phát triển tốt hơn, phát hành khi cần thay vì phát hành lớn, thử các công nghệ hoặc quy trình mới một cách riêng lẻ, v.v. rất nhiều điều đó vì sự phụ thuộc vào DB. Nếu bạn không thể triển khai dịch vụ của mình mà không lo lắng về dữ liệu của dịch vụ khác, bạn đã mất.

Điều mà cơ sở dữ liệu riêng biệt là ngoài thảo luận. Hay tôi đơn giản là sai?

Điều đó nói rằng, bạn cũng hoàn toàn sai.

Khi bạn làm việc trong đám mây, cơ sở dữ liệu rẻ. Miễn phí thường xuyên! Chắc chắn, máy chủ tốn tiền, nhưng chúng tôi không nói về một máy chủ riêng lẻ trên mỗi dịch vụ siêu nhỏ (ít nhất, không phải lúc đầu). Một máy chủ duy nhất có một loạt các cơ sở dữ liệu (logic) chỉ hoạt động tốt miễn là bạn siêng năng trong việc tránh các truy vấn cơ sở dữ liệu chéo (giới thiệu các phụ thuộc gây hại cho "có thể triển khai độc lập và có thể mở rộng"). Địa ngục, truy vấn DB chéo là không thể trong một số dịch vụ cơ sở dữ liệu đám mây như Azure SQL. Bạn thậm chí không cần phải siêng năng ở đó ...

Và tôi thậm chí đã thấy các dịch vụ siêu nhỏ nơi họ chia sẻ cơ sở dữ liệu, nhưng mỗi dịch vụ có lược đồ riêng. Một lần nữa, bạn cần phải siêng năng trong việc tránh các truy vấn vượt qua ranh giới dữ liệu.

Rất nhiều nơi không siêng năng. Họ có nhà phát triển cấp nhập cảnh hoặc những người không coi trọng cách tiếp cận microservice hoặc dẫn đầu nhóm kém hoặc có áp lực dòng thời gian khiến mọi người phải dùng phím tắt.

Có một cơ sở dữ liệu riêng biệt là cách sạch nhất để thực thi việc tách rời đó cho phép độc lập dịch vụ, nhưng đó không phải là cách duy nhất. Và nó không quá đắt - đặc biệt là khi bạn so sánh nó với thời gian / tiền lương đã bỏ ra để cố gắng thực thi các ranh giới dữ liệu trong cơ sở dữ liệu dùng chung.

Tại sao chúng ta thậm chí cần nó?

Lợi ích to lớn của microservice, và phần lớn, SOA, là mức độ trừu tượng hóa cao của các bộ phận nội bộ không chỉ triển khai mà còn cả các công nghệ đang được sử dụng. Chẳng hạn, nếu một hệ thống được phát triển dưới dạng năm microservice bởi năm nhóm, một nhóm có thể quyết định chuyển sang ngăn xếp công nghệ hoàn toàn khác (ví dụ từ Microsoft stack sang LAMP) mà không cần hỏi ý kiến ​​của các nhóm khác.

Nhìn vào Amazon AWS hoặc Twilio. Bạn có biết dịch vụ của họ được triển khai bằng Java hay Ruby không? Họ có sử dụng Oracle hoặc PostgreSQL hoặc Cassandra hoặc MongoDB không? Họ sử dụng bao nhiêu máy? Bạn có quan tâm đến điều đó không; nói cách khác, những lựa chọn công nghệ đó có ảnh hưởng đến cách bạn sử dụng các dịch vụ đó không? ... Và quan trọng hơn, nếu chúng chuyển sang cơ sở dữ liệu khác, bạn có phải thay đổi ứng dụng khách của mình cho phù hợp không?

Bây giờ, điều gì xảy ra nếu hai dịch vụ sử dụng cùng một cơ sở dữ liệu? Đây là một phần nhỏ của các vấn đề có thể phát sinh:

• Nhóm phát triển dịch vụ 1 muốn chuyển từ SQL Server 2012 sang SQL Server 2016. Tuy nhiên, nhóm 2 phụ thuộc vào một tính năng không dùng nữa đã bị xóa trong SQL Server 2016.

• Dịch vụ 1 là một thành công lớn. Lưu trữ cơ sở dữ liệu trên hai máy (chính và chuyển đổi dự phòng) không còn là một tùy chọn nữa. Nhưng việc nhân rộng cụm cho nhiều máy đòi hỏi các chiến lược như shending. Trong khi đó, đội 2 hài lòng với quy mô hiện tại và không thấy lý do gì để chuyển sang bất cứ điều gì khác.

• Dịch vụ 1 sẽ chuyển sang UTF-8 làm mã hóa mặc định. Dịch vụ 2, tuy nhiên, rất vui khi sử dụng Mã Trang 1252 Windows Latin 1.

• Dịch vụ 1 quyết định thêm người dùng có tên cụ thể. Tuy nhiên, người dùng này đã tồn tại, được tạo bởi một vài tháng trước bởi nhóm thứ hai.

• Dịch vụ 1 cần rất nhiều tính năng khác nhau. Dịch vụ 2 là một thành phần rất quan trọng và cần giữ các tính năng cơ sở dữ liệu ở mức tối thiểu để giảm nguy cơ bị tấn công.

• Dịch vụ 1 yêu cầu 15 TB không gian đĩa; tốc độ không quan trọng, vì vậy các đĩa cứng thông thường hoàn toàn ổn. Dịch vụ 2 yêu cầu tối đa 50 GB, nhưng cần truy cập nhanh nhất có thể, nghĩa là dữ liệu phải được lưu trữ trên ổ SSD.

• ...

Mỗi sự lựa chọn nhỏ ảnh hưởng đến tất cả mọi người. Mọi quyết định cần phải được cộng tác, bởi mọi người từ mọi đội. Thỏa hiệp phải được thực hiện. So sánh điều đó với một sự tự do hoàn toàn để làm bất cứ điều gì bạn muốn trong bối cảnh của SOA.

nó quá [...] không thể quản lý được.

Sau đó, bạn đang làm sai. Tôi cho rằng bạn đang triển khai thủ công .

Đây không phải là cách mọi thứ nên được thực hiện. Bạn cần tự động hóa việc triển khai các máy ảo (hoặc Docker container) chạy cơ sở dữ liệu. Khi bạn tự động hóa chúng, việc triển khai hai máy chủ hoặc hai mươi máy chủ hoặc hai nghìn máy chủ không khác nhau lắm.

Điều kỳ diệu về cơ sở dữ liệu bị cô lập là nó cực kỳ dễ quản lý . Bạn đã thử quản lý một cơ sở dữ liệu khổng lồ được sử dụng bởi hàng tá đội chưa? Nó là một cơn ác mộng. Mỗi đội đều có những yêu cầu cụ thể và ngay khi bạn chạm vào thứ gì đó, nó sẽ ảnh hưởng đến ai đó. Với một cơ sở dữ liệu được ghép nối với một ứng dụng, phạm vi trở nên rất hẹp, có nghĩa là có rất ít điều để suy nghĩ.

Nếu một cơ sở dữ liệu khổng lồ yêu cầu quản trị viên hệ thống chuyên biệt, cơ sở dữ liệu chỉ được sử dụng bởi một nhóm về cơ bản có thể được quản lý bởi nhóm này (DevOps cũng nói về điều đó), giải phóng thời gian của quản trị viên hệ thống.

nó quá tốn kém

Xác định chi phí.

Chi phí cấp phép phụ thuộc vào cơ sở dữ liệu. Trong kỷ nguyên của điện toán đám mây, tôi khá chắc chắn rằng tất cả những người chơi lớn đã thiết kế lại giấy phép của họ để phù hợp với bối cảnh thay vì một cơ sở dữ liệu khổng lồ, có rất nhiều cơ sở nhỏ. Nếu không, bạn có thể xem xét chuyển sang cơ sở dữ liệu khác. Nhân tiện, có rất nhiều mã nguồn mở.

Nếu bạn đang nói về sức mạnh xử lý, cả máy ảo và thùng chứa đều thân thiện với CPU và tôi sẽ không khẳng định rằng một cơ sở dữ liệu khổng lồ sẽ tiêu thụ ít CPU hơn rất nhiều máy nhỏ làm cùng một công việc.

Nếu vấn đề của bạn là bộ nhớ, thì máy ảo không phải là lựa chọn tốt cho bạn. Container là. Bạn sẽ có thể mở rộng bao nhiêu tùy ý, biết rằng chúng sẽ không tiêu tốn nhiều RAM hơn mức cần thiết. Mặc dù tổng mức tiêu thụ bộ nhớ sẽ cao hơn đối với nhiều cơ sở dữ liệu nhỏ so với một cơ sở dữ liệu lớn, tôi cho rằng sự khác biệt sẽ không quá quan trọng. YMMV.

Phụ thuộc vào những gì bạn coi là đắt đỏ.

Một cơ sở dữ liệu không nhất thiết phải là một máy chủ cơ sở dữ liệu thương mại đắt tiền (nghĩ rằng Oracle) không nhất thiết phải là một vấn đề đói tài nguyên. Tùy thuộc vào yêu cầu của bạn là gì, bạn có thể sử dụng cơ sở dữ liệu SQLite hoặc thậm chí hệ thống tệp như một bộ lưu trữ dữ liệu liên tục.

Tất cả các dịch vụ này cũng có thể chia sẻ một cá thể / máy chủ cơ sở dữ liệu duy nhất và chỉ có các lược đồ riêng biệt cho mỗi dịch vụ.

Đối số chính ở đây là dịch vụ cần sở hữu và kiểm soát dữ liệu của nó. Làm thế nào để nó đạt được điều đó, là một vấn đề lựa chọn và chi tiết kỹ thuật.

Cách tốt nhất mà một dịch vụ có thể sở hữu và kiểm soát dữ liệu của mình là có cơ sở dữ liệu cá nhân của riêng mình. Điều này cho phép hoàn toàn tự do lựa chọn công nghệ và tiến hóa sơ đồ dữ liệu. Cách duy nhất mà bất kỳ dịch vụ nào khác có thể truy cập dữ liệu thuộc sở hữu của một dịch vụ là yêu cầu dữ liệu từ một dịch vụ. Bằng cách này, nếu cần thay đổi biểu diễn dữ liệu nội bộ, nó có thể dễ dàng thay đổi và không có dịch vụ nào khác bị hỏng.

Vì vậy, để tóm tắt lại. Không nhất thiết phải có cơ sở dữ liệu cho mỗi dịch vụ và cũng không cần thiết. Nó chỉ đơn giản là một quyết định mà bạn cần phải đưa ra tại một số điểm khi phát triển microservice. Mỗi lựa chọn đều có ý nghĩa và hạn chế của nó. Nghiên cứu những người và đưa ra lựa chọn của riêng bạn.