Gần đây tôi đã đọc bài viết tuyệt vời này về kiến ​​trúc microservice: http://www.infoq.com/articles/microservice-intro

Nó tuyên bố rằng khi bạn tải một trang web trên Amazon, thì hơn 100 dịch vụ siêu nhỏ hợp tác để phục vụ trang đó.

Bài viết đó mô tả rằng tất cả giao tiếp giữa các dịch vụ siêu nhỏ chỉ có thể đi qua một API. Câu hỏi của tôi là tại sao thật tệ khi nói rằng tất cả các cơ sở dữ liệu ghi chỉ có thể đi qua một API, nhưng bạn có thể tự do đọc trực tiếp từ cơ sở dữ liệu của các dịch vụ vi mô khác nhau. Chẳng hạn, người ta có thể nói rằng chỉ có một vài khung nhìn cơ sở dữ liệu có thể truy cập được bên ngoài dịch vụ vi mô để nhóm duy trì dịch vụ vi mô biết rằng miễn là họ giữ nguyên các khung nhìn này thì họ có thể thay đổi cấu trúc cơ sở dữ liệu của dịch vụ vi mô của họ nhiều như họ muốn

Am i thiếu cái gì ở đây? Có một số lý do khác tại sao dữ liệu chỉ nên được đọc qua API?

Không cần phải nói, công ty của tôi nhỏ hơn đáng kể so với Amazon (và sẽ luôn như vậy) và số lượng người dùng tối đa chúng tôi có thể có là khoảng 5 triệu.

Cơ sở dữ liệu không tốt trong việc che giấu thông tin, điều này khá hợp lý, bởi vì công việc của họ là thực sự phơi bày thông tin. Nhưng điều này làm cho chúng trở thành một công cụ tệ hại khi nói đến việc đóng gói. Tại sao bạn muốn đóng gói?

Kịch bản: bạn liên kết trực tiếp một vài thành phần với RDBMS và bạn thấy một thành phần cụ thể trở thành cổ chai hiệu suất mà bạn có thể muốn không chuẩn hóa cơ sở dữ liệu, nhưng bạn không thể vì tất cả các thành phần khác sẽ bị ảnh hưởng. Bạn thậm chí có thể nhận ra rằng bạn sẽ tốt hơn với kho lưu trữ tài liệu hoặc cơ sở dữ liệu đồ thị so với RDBMS. Nếu dữ liệu được gói gọn bởi một API nhỏ, bạn có cơ hội thực tế để thực hiện lại API đã nói theo bất kỳ cách nào bạn cần. Bạn có thể chèn trong suốt các lớp bộ đệm và những gì không.

Việc dò dẫm với lớp lưu trữ trực tiếp từ lớp ứng dụng là đối nghịch với những gì mà nguyên tắc đảo ngược phụ thuộc gợi ý để làm.

Điều gì quan trọng và quan trọng hơn về microservice: API hoặc lược đồ cơ sở dữ liệu của nó? API, vì đó là hợp đồng của nó với phần còn lại của thế giới. Lược đồ cơ sở dữ liệu đơn giản là một cách thuận tiện để lưu trữ dữ liệu được quản lý bởi dịch vụ, hy vọng được tổ chức theo cách tối ưu hóa hiệu suất của microservice. Nhóm phát triển nên được tự do tổ chức lại lược đồ đó - hoặc chuyển sang một giải pháp kho dữ liệu hoàn toàn khác - bất cứ lúc nào. Phần còn lại của thế giới không nên quan tâm. Phần còn lại của thế giới quan tâm khi API thay đổi, vì API là hợp đồng.

Bây giờ, nếu bạn nhìn trộm vào cơ sở dữ liệu của họ

• Bạn thêm một phụ thuộc không mong muốn vào lược đồ của họ. Họ không thể thay đổi nó mà không có tác động đến dịch vụ của bạn.
• Bạn thêm tải không mong muốn và không thể đoán trước vào bên trong của họ.
• Hiệu suất của dịch vụ của bạn sẽ bị ảnh hưởng bởi hiệu suất của cơ sở dữ liệu của họ (họ sẽ cố gắng tối ưu hóa dịch vụ của họ để hoạt động tốt cho khách hàng và cơ sở dữ liệu của họ chỉ hoạt động tốt cho dịch vụ của họ)
• Bạn đang buộc việc triển khai của mình vào một lược đồ có thể không đại diện chính xác và rõ ràng cho các tài nguyên trong kho dữ liệu của họ - nó có thể có thêm chi tiết chỉ cần theo dõi trạng thái nội bộ hoặc đáp ứng việc triển khai cụ thể của họ (mà bạn không nên quan tâm).
• Bạn có thể vô tình phá hủy hoặc làm hỏng trạng thái dịch vụ của họ (và họ sẽ không biết bạn đang làm điều này)
• Bạn có thể cập nhật / xóa / xóa tài nguyên khỏi cơ sở dữ liệu của họ mà không biết họ đã xảy ra.

Hai điểm cuối có thể không xảy ra nếu bạn chỉ được cấp quyền truy cập đọc, nhưng các điểm khác không chỉ là lý do đủ tốt. Cơ sở dữ liệu chia sẻ là một điều xấu.

Thông thường các nhà phát triển ít kinh nghiệm (hoặc những người không học) thấy cơ sở dữ liệu quan trọng hơn dịch vụ, xem cơ sở dữ liệu là thực tế và dịch vụ chỉ là một cách để truy cập vào cơ sở dữ liệu . Đó là cách sai vòng.

Kiến trúc microservice rất khó để mô tả nhưng cách tốt nhất để suy nghĩ về nó là một cuộc hôn nhân giữa Kiến trúc hướng thành phần và Kiến trúc hướng dịch vụ. Phần mềm như một bộ phần mềm bao gồm nhiều thành phần kinh doanh nhỏ với trách nhiệm trong lĩnh vực kinh doanh rất cụ thể. Giao diện của họ với thế giới bên ngoài hoặc trong các dịch vụ được cung cấp hoặc các dịch vụ được yêu cầu thông qua API của các dịch vụ được xác định rõ ràng.

Viết và thậm chí đọc từ cơ sở dữ liệu nằm ngoài miền kinh doanh thành phần của bạn là trái với phong cách kiến ​​trúc này.

Lý do chính cho điều này là một API được cung cấp thông qua dịch vụ bởi một thành phần phần mềm khác có kỳ vọng hợp lý rằng API rất có thể sẽ tương thích ngược khi các bản phát hành mới của thành phần cung cấp dịch vụ trở nên khả dụng. Nếu tôi là nhà phát triển của thành phần "cung cấp" thì tôi chỉ phải lo lắng về khả năng tương thích ngược với API của mình. Nếu tôi biết rằng có ba nhóm phát triển khác đã viết các truy vấn tùy chỉnh đối với cơ sở dữ liệu của tôi thì công việc của tôi đã trở nên phức tạp hơn nhiều.

Thậm chí tệ hơn, có thể nhóm khác đã viết những điều này là chạy nước rút giữa trong một dự án quan trọng và họ không thể chấp nhận thay đổi này ngay từ thành phần của bạn. Bây giờ phát triển phần mềm cho thành phần của bạn trên một miền kinh doanh mà bạn sở hữu đang được thúc đẩy bởi sự phát triển trên một miền kinh doanh khác.

Tương tác đầy đủ thông qua các dịch vụ làm giảm sự ghép nối giữa các thành phần phần mềm khác nhau để các tình huống như thế này không xảy ra quá thường xuyên. Khi nói đến các thành phần khác bằng cách sử dụng Chế độ xem trong cơ sở dữ liệu, thì bạn có nhiều khả năng hơn để làm cho Chế độ xem tương thích ngược nếu có ai khác viết truy vấn chống lại nó. Tuy nhiên, tôi vẫn cảm thấy rằng đây phải là trường hợp ngoại lệ và chỉ nên được thực hiện để có thể báo cáo hoặc xử lý hàng loạt trong đó một ứng dụng sẽ cần phải đọc với số lượng dữ liệu khổng lồ.

Rõ ràng điều này hoạt động tốt trong các nhóm phân phối lớn, nơi các nhóm phát triển được phân tách bằng miền kinh doanh như Amazon. Nếu bạn là một cửa hàng phát triển nhỏ, bạn vẫn có thể hưởng lợi từ mô hình này, đặc biệt nếu bạn cần nhanh chóng triển khai một dự án lớn, nhưng cũng có thể nếu bạn phải đối phó với phần mềm của nhà cung cấp.

Trong 20 năm qua tôi đã thấy một vài thiết kế cơ sở dữ liệu mô-đun lớn và tôi đã thấy kịch bản được đề xuất bởi David khá nhiều lần khi các ứng dụng có quyền truy cập vào lược đồ / bộ bảng của riêng chúng và đọc quyền truy cập vào lược đồ khác / bộ bàn. Thông thường dữ liệu này mà một ứng dụng / mô-đun có quyền truy cập chỉ đọc có thể được mô tả là "dữ liệu chủ" .

Trong thời gian đó tôi chưa thấy những vấn đề mà các câu trả lời trước đang gợi ý tôi nên thấy vì vậy tôi nghĩ rằng đáng để xem xét kỹ hơn những điểm nêu trong các câu trả lời trước một cách chi tiết hơn.

Kịch bản: bạn liên kết trực tiếp một vài thành phần với RDBMS và bạn thấy một thành phần cụ thể trở thành cổ chai hiệu suất

Tôi đồng ý với nhận xét này ngoại trừ đây cũng là một đối số để có một bản sao dữ liệu cục bộ để microservice đọc. Đó là, hầu hết các cơ sở dữ liệu trưởng thành đều hỗ trợ sao chép và do đó, không cần bất kỳ nỗ lực nào của nhà phát triển, "dữ liệu chủ" có thể được sao chép vật lý vào cơ sở dữ liệu microservice nếu điều đó là mong muốn hoặc cần thiết.

Một số người có thể nhận ra điều này trong chiêu bài cũ là "cơ sở dữ liệu doanh nghiệp" sao chép các bảng lõi vào "cơ sở dữ liệu của bộ". Một điểm ở đây là nói chung là tốt nếu cơ sở dữ liệu thực hiện điều này cho chúng tôi với việc sao chép dữ liệu đã thay đổi (chỉ deltas, ở dạng nhị phân và với chi phí tối thiểu cho cơ sở dữ liệu nguồn).

Ngược lại, khi các lựa chọn cơ sở dữ liệu của chúng tôi không cho phép hỗ trợ sao chép này, chúng tôi có thể gặp phải tình huống chúng tôi muốn đẩy "dữ liệu chủ" ra cơ sở dữ liệu microservice và điều này có thể dẫn đến một lượng lớn nỗ lực của nhà phát triển và cũng là một cơ chế kém hiệu quả.

có thể muốn không chuẩn hóa cơ sở dữ liệu, nhưng bạn không thể vì tất cả các thành phần khác sẽ bị ảnh hưởng

Đối với tôi tuyên bố này chỉ là không chính xác. Không chuẩn hóa là một thay đổi "phụ gia" và không phải là "thay đổi phá vỡ" và không có ứng dụng nào bị phá vỡ do không chuẩn hóa.

Cách duy nhất để phá vỡ một ứng dụng là nơi mã ứng dụng sử dụng cái gì đó như "select * ..." và không xử lý một cột phụ. Đối với tôi đó sẽ là một lỗi trong ứng dụng?

Làm thế nào có thể không chuẩn hóa phá vỡ một ứng dụng? Âm thanh như FUD với tôi.

Lược đồ phụ thuộc:

Vâng, ứng dụng hiện có một sự phụ thuộc vào lược đồ cơ sở dữ liệu và hàm ý là điều này phải là một vấn đề lớn. Mặc dù việc thêm bất kỳ phụ thuộc bổ sung rõ ràng là không lý tưởng, nhưng sự phụ thuộc vào lược đồ cơ sở dữ liệu không phải là vấn đề, vậy tại sao điều đó lại xảy ra? Có phải tôi vừa may mắn?

Dữ liệu chủ

Lược đồ mà chúng ta thường có thể muốn một dịch vụ siêu nhỏ có quyền truy cập chỉ đọc là phổ biến nhất mà tôi mô tả là " dữ liệu chủ " cho doanh nghiệp. Nó có dữ liệu cốt lõi là điều cần thiết cho doanh nghiệp.

Trong lịch sử, điều này có nghĩa là lược đồ mà chúng ta thêm phụ thuộc vào cả trưởng thành và ổn định (hơi cơ bản cho doanh nghiệp và không thay đổi).

Bình thường hóa

Nếu 3 nhà thiết kế cơ sở dữ liệu đi và thiết kế một lược đồ db được chuẩn hóa, họ sẽ kết thúc ở cùng một thiết kế. Ok, có thể có một số biến thể 4NF / 5NF nhưng không nhiều. Hơn nữa có một loạt các câu hỏi mà nhà thiết kế có thể yêu cầu để xác thực mô hình để nhà thiết kế có thể tự tin rằng họ đã đạt đến 4NF (Tôi có quá lạc quan không? Mọi người có đang vật lộn để đạt được 4NF không?).

cập nhật: Bằng 4NF ở đây, ý tôi là tất cả các bảng trong lược đồ đều có dạng bình thường cao nhất lên tới 4NF (tất cả các bảng đã được chuẩn hóa một cách thích hợp lên đến 4NF).

Tôi tin rằng quy trình thiết kế chuẩn hóa là lý do tại sao các nhà thiết kế cơ sở dữ liệu thường thoải mái với ý tưởng phụ thuộc vào lược đồ cơ sở dữ liệu được chuẩn hóa.

Quá trình chuẩn hóa đưa thiết kế DB thành một thiết kế "chính xác" đã biết và các biến thể từ đó phải được chuẩn hóa cho hiệu suất.

1. Có thể có các biến thể dựa trên các loại DB được hỗ trợ (JSON, ARRAY, hỗ trợ loại Geo, v.v.)
2. Một số có thể tranh luận về sự thay đổi dựa trên 4NF / 5NF
3. Chúng tôi loại trừ biến thể vật lý (vì điều đó không quan trọng)
4. Chúng tôi giới hạn điều này đối với thiết kế OLTP chứ không phải thiết kế DW vì đó là các lược đồ mà chúng tôi muốn cấp quyền truy cập chỉ đọc vào

Nếu 3 lập trình viên được đưa ra một thiết kế để thực hiện (dưới dạng mã) thì kỳ vọng sẽ dành cho 3 triển khai khác nhau (có khả năng rất khác nhau).

Đối với tôi có khả năng có một câu hỏi về "niềm tin vào sự bình thường hóa".

Phá vỡ thay đổi lược đồ?

Việc không chuẩn hóa, thêm cột, thay đổi cột để lưu trữ lớn hơn, mở rộng thiết kế với các bảng mới, v.v ... đều là những thay đổi không phá vỡ và các nhà thiết kế DB đã chuyển sang dạng thứ 4 bình thường sẽ tự tin về điều đó.

Thay đổi đột phá rõ ràng là có thể bằng cách bỏ các cột / bảng hoặc thực hiện thay đổi loại phá vỡ. Có thể có, nhưng về mặt thực tế tôi chưa gặp vấn đề gì ở đây cả. Có lẽ bởi vì nó được hiểu những thay đổi phá vỡ là gì và những điều này đã được quản lý tốt?

Tôi rất muốn nghe các trường hợp phá vỡ các thay đổi lược đồ trong bối cảnh của lược đồ chỉ đọc được chia sẻ.

Điều gì quan trọng và quan trọng hơn về microservice: API hoặc lược đồ cơ sở dữ liệu của nó? API, vì đó là hợp đồng của nó với phần còn lại của thế giới.

Mặc dù tôi đồng ý với tuyên bố này, tôi nghĩ có một cảnh báo quan trọng mà chúng ta có thể nghe được từ Kiến trúc sư doanh nghiệp đó là "Dữ liệu tồn tại mãi mãi" . Đó là, trong khi API có thể là điều quan trọng nhất, dữ liệu cũng khá quan trọng đối với toàn bộ doanh nghiệp và nó sẽ rất quan trọng trong một thời gian rất dài.

Ví dụ: một khi có yêu cầu đưa vào Kho dữ liệu cho doanh nghiệp thông minh thì lược đồ và hỗ trợ CDC trở nên quan trọng từ quan điểm báo cáo kinh doanh bất kể API.

Các vấn đề với API?

Bây giờ nếu API hoàn hảo và dễ dàng thì tất cả các điểm đều được đưa ra vì chúng tôi luôn chọn API thay vì có quyền truy cập chỉ đọc cục bộ. Vì vậy, động lực để thậm chí xem xét truy cập chỉ đọc cục bộ là có thể có một số vấn đề khi sử dụng API mà truy cập cục bộ tránh được.

What motivates people to desire local read-only access?

Tối ưu hóa API:

LinkedIn có một bài thuyết trình thú vị (từ năm 2009) về vấn đề tối ưu hóa API của họ và tại sao nó quan trọng đối với họ ở quy mô của họ. http://www.sl slideshoware.net/linkedin/building-consistent-restful-apis-in-a-highperformance-en môi trường

Nói tóm lại, một khi API phải hỗ trợ nhiều trường hợp sử dụng khác nhau, nó có thể dễ dàng gặp phải tình huống trong đó nó hỗ trợ một trường hợp sử dụng một cách tối ưu và phần còn lại khá kém từ góc độ mạng và cơ sở dữ liệu.

Nếu API không có độ tinh vi như LinkedIn thì bạn có thể dễ dàng nhận được các tình huống trong đó:

• API tìm nạp nhiều dữ liệu hơn bạn cần (lãng phí)
• API trò chuyện là nơi bạn phải gọi API nhiều lần

Có, tất nhiên chúng ta có thể thêm bộ đệm vào API nhưng cuối cùng, lệnh gọi API là một cuộc gọi từ xa và có một loạt các tối ưu hóa có sẵn cho các nhà phát triển khi dữ liệu là cục bộ.

Tôi nghi ngờ có một nhóm người ngoài kia có thể thêm nó vào như:

• Sao chép dữ liệu chủ chi phí thấp vào cơ sở dữ liệu microservice (không mất chi phí phát triển và hiệu quả kỹ thuật)
• Niềm tin vào Bình thường hóa và khả năng phục hồi của các ứng dụng đối với các thay đổi lược đồ
• Khả năng dễ dàng tối ưu hóa mọi trường hợp sử dụng và có khả năng tránh các cuộc gọi API từ xa trò chuyện / lãng phí / không hiệu quả
• Cộng với một số lợi ích khác về các ràng buộc và thiết kế mạch lạc

Câu trả lời này đã có quá lâu. Xin lỗi !!

Quản lý nhà nước (có khả năng là cơ sở dữ liệu) có thể được triển khai trong vùng chứa của microservice và được hiển thị thông qua API. Cơ sở dữ liệu của microservice không hiển thị với các hệ thống khác bên ngoài vùng chứa - chỉ API. Ngoài ra, bạn có thể có một dịch vụ khác (ví dụ: bộ đệm) quản lý trạng thái thông qua API. Có tất cả các phụ thuộc của microservice (ngoài các lệnh gọi API đến các dịch vụ khác) trong một vùng chứa có thể triển khai là một điểm khác biệt chính trong kiến ​​trúc. Nếu một người không có được điều đó hãy quay lại và nghiên cứu kiến ​​trúc.