Dịch vụ kính hiển vi và thủ tục lưu trữ

Các thủ tục lưu trữ được coi là thực hành xấu trong kiến ​​trúc microservice?

Đây là suy nghĩ của tôi:

• hầu hết các cuốn sách về microservice đề xuất một cơ sở dữ liệu cho mỗi dịch vụ microservice. Các thủ tục lưu trữ thường hoạt động trên cơ sở dữ liệu nguyên khối.

• một lần nữa, hầu hết các sách kiến ​​trúc microservice đều nói rằng chúng nên được tự chủ và kết nối lỏng lẻo. Sử dụng các thủ tục được lưu trữ bằng văn bản, nói cụ thể trong Oracle, kết hợp chặt chẽ microservice với công nghệ đó.

• hầu hết các sách kiến ​​trúc microservice (mà tôi đã đọc) khuyên rằng microservice nên được định hướng kinh doanh (được thiết kế sử dụng thiết kế theo hướng tên miền (DDD)). Bằng cách di chuyển logic nghiệp vụ vào các thủ tục được lưu trữ trong cơ sở dữ liệu, đây không còn là trường hợp nữa.

Bất kỳ suy nghĩ về điều này?

Không có gì rõ ràng cấm hoặc lập luận chống lại việc sử dụng các thủ tục được lưu trữ với microservice.

Tuyên bố miễn trừ trách nhiệm: Tôi không thích các thủ tục được lưu trữ từ POV của nhà phát triển, nhưng điều đó không liên quan đến microservice theo bất kỳ cách nào.

Các thủ tục lưu trữ thường hoạt động trên cơ sở dữ liệu nguyên khối.

Tôi nghĩ rằng bạn đang chịu thua một ngụy biện logic.

Thủ tục lưu trữ đang ngày càng giảm. Hầu hết các thủ tục được lưu trữ vẫn đang được sử dụng là từ một cơ sở mã cũ hơn được giữ xung quanh. Trước đó, cơ sở dữ liệu nguyên khối cũng phổ biến hơn nhiều so với khi microservice trở nên phổ biến.

Các procs và cơ sở dữ liệu nguyên khối được lưu trữ đều xảy ra trong các cơ sở mã cũ, đó là lý do tại sao bạn thấy chúng cùng nhau thường xuyên hơn. Nhưng đó không phải là một liên kết nhân quả. Bạn không sử dụng các procs được lưu trữ vì bạn có cơ sở dữ liệu nguyên khối. Bạn không có cơ sở dữ liệu nguyên khối vì bạn sử dụng các procs được lưu trữ.

hầu hết các cuốn sách về microservice đề xuất một cơ sở dữ liệu cho mỗi dịch vụ microservice.

Không có lý do kỹ thuật tại sao các cơ sở dữ liệu nhỏ hơn này có thể có các thủ tục lưu trữ.

Như tôi đã đề cập, tôi không thích các procs được lưu trữ. Tôi thấy chúng cồng kềnh và chống lại sự bảo trì trong tương lai. Tôi nghĩ rằng việc lan truyền sprocs trên nhiều cơ sở dữ liệu nhỏ càng làm trầm trọng thêm các vấn đề mà tôi đã không thích. Nhưng điều đó không có nghĩa là nó không thể được thực hiện.

một lần nữa, hầu hết các sách kiến ​​trúc microservice đều nói rằng chúng nên được tự chủ và kết nối lỏng lẻo. Sử dụng các thủ tục được lưu trữ bằng văn bản nói riêng trong Oracle, kết hợp chặt chẽ microservice với công nghệ đó.

Mặt khác, có thể đưa ra lập luận tương tự cho bất kỳ ORM nào mà microservice của bạn sử dụng. Không phải mọi ORM sẽ hỗ trợ mọi cơ sở dữ liệu. Khớp nối (cụ thể là độ kín của nó) là một khái niệm tương đối. Đó là một vấn đề lỏng lẻo như bạn có thể hợp lý.

Sprocs chịu đựng sự liên kết chặt chẽ nói chung bất kể microservice. Tôi sẽ khuyên bạn nên chống lại sprocs, nhưng không phải vì bạn đang sử dụng microservice. Đó là lập luận tương tự như trước đây: Tôi không nghĩ sprocs là con đường để đi (nói chung), nhưng đó có thể chỉ là sự thiên vị của tôi, và nó không liên quan đến microservice.

hầu hết các sách msa (mà tôi đã đọc) khuyên rằng microservice nên được định hướng kinh doanh (được thiết kế bằng cách sử dụng ddd). Bằng cách di chuyển logic nghiệp vụ vào các thủ tục được lưu trữ trong cơ sở dữ liệu, đây không còn là trường hợp nữa.

Điều này luôn luôn là sự kìm kẹp chính của tôi về sprocs: logic kinh doanh trong cơ sở dữ liệu. Ngay cả khi không có ý định, nó có xu hướng bằng cách nào đó luôn kết thúc theo cách đó.

Nhưng một lần nữa, sự kìm kẹp đó tồn tại bất kể bạn có sử dụng microservice hay không. Lý do duy nhất có vẻ như là một vấn đề lớn hơn là bởi vì các dịch vụ siêu nhỏ thúc đẩy bạn hiện đại hóa toàn bộ kiến ​​trúc của mình và các sprocs không còn được ưa chuộng nữa trong các kiến ​​trúc hiện đại.

Để viết phần mềm đòi hỏi bạn phải kết hợp chặt chẽ với một công nghệ.

Ít nhất là với môi trường thời gian chạy được cung cấp bởi ngôn ngữ lập trình đang được phát triển bên trong.

Nói chung, mặc dù bạn sẽ thấy rằng dịch vụ vi mô của bạn được kết hợp chặt chẽ với một số công nghệ:

• Khung dịch vụ mạng để cung cấp triển khai giao thức HTTP / SSL / SOAP cấp cao
• Kho lưu trữ / ORM / DAO Framework để cung cấp sự bền bỉ.
• Khung thao tác dữ liệu để cung cấp các công cụ để làm việc với dữ liệu.
• Process / Threading / OS Framework để cung cấp quyền truy cập vào các tài nguyên HĐH như đa tác vụ, hệ thống tệp, bộ nhớ, tính toán GPU, thẻ mở rộng, v.v ...

Và đó là để thực hiện một dịch vụ vi mô xương trần.

Thủ tục lưu trữ

Một thủ tục được lưu trữ chỉ đơn giản là một công nghệ khác mà bạn có thể chọn sử dụng hoặc không sử dụng. Nó không kỳ diệu làm cho mã của bạn nguyên khối, hoặc vi mô.

Mặc dù vậy, đó là:

• Một công nghệ khác. Mỗi công nghệ có trong ứng dụng làm giảm khả năng mà bất kỳ lập trình viên nhất định nào cũng có thể đọc, hiểu và đưa ra các lựa chọn thiết kế khôn ngoan cho công nghệ đó.
• Một ngôn ngữ sử dụng một mô hình lập trình khác nhau. Thật quá dễ dàng cho những người không phải là chuyên gia để thử và áp đặt quan điểm cấp bách, chức năng, OO, v.v ... của riêng họ lên nó, điều này thường dẫn đến kết quả ít hơn.
• Một API. Mà phải được duy trì như bất kỳ lớp nào khác trong cơ sở mã. Nó cũng có nghĩa là cơ sở dữ liệu đang cung cấp một giao diện không chung chung. Điều này làm cho việc thay thế chính công cụ cơ sở dữ liệu trở nên khó khăn hơn và áp dụng một cách minh bạch hành vi chung như trong bộ nhớ đệm.
• Một vật phẩm. Mà phải được phiên bản, thử nghiệm và triển khai. Điều này có thể được thực hiện, nhưng cơ sở dữ liệu là các tạo tác sống đòi hỏi một cách tiếp cận khác. Bạn thường không thể xóa bản gốc và thay thế nó. Thường thì cần có sự phối hợp cẩn thận các thay đổi theo thời gian để di chuyển hệ thống sang trạng thái mong muốn.

Mỗi trong số này là một chi phí thực sự. Trong một số trường hợp, chi phí là hợp lý, trong những trường hợp khác thì không.

Bạn sẽ phải trả gần như cùng một bộ chi phí bằng cách lưu trữ một công cụ viết kịch bản. Giảm duy nhất là bạn có thể chọn mô hình lập trình tương tự như ngôn ngữ máy chủ.

Logic kinh doanh

Di chuyển các quy tắc kinh doanh vào cơ sở dữ liệu là thực tế xấu. Chỉ không phải vì thủ tục lưu trữ.

Đó là một thực tiễn tồi, bởi vì cơ sở dữ liệu và logic kinh doanh hoạt động ở các cấp độ cắt khác nhau.

• Một cơ sở dữ liệu trong một ứng dụng trưởng thành có thể được sử dụng trong nhiều thập kỷ. Nói chung các hệ thống này sẽ có động cơ được cập nhật định kỳ, nhưng cơ sở dữ liệu đã được di chuyển. Nó đã không bị giết và được xây dựng lại từ đầu. Không có lý do gì một dịch vụ vi mô không thể tồn tại lâu như vậy.

• Tương phản nhiều thập kỷ chống lại sự thay đổi nhanh chóng các quy tắc kinh doanh. Theo kinh nghiệm của tôi, một quy tắc kinh doanh cũ có lẽ đã vài năm tuổi, tuy nhiên hầu hết thay đổi nhanh chóng và bạn không bao giờ có thể biết quy tắc nào sẽ thay đổi tiếp theo. Một yêu cầu mới từ cơ quan quản lý, một sản phẩm cũ đang ngừng hoạt động, thay đổi đầu thư, thay đổi số lượng nhân viên báo cáo với sếp, v.v., v.v.

Nếu logic nghiệp vụ được phân phối trên các lớp cắt, đặc biệt là lớp chậm hơn và tồn tại lâu hơn, nó sẽ tạo ra khả năng chống thay đổi. Điều này không nhất thiết phải là một điều xấu. Rốt cuộc, cơ sở dữ liệu duy nhất không có logic nghiệp vụ trong đó là một cửa hàng ba.

Hành động đơn thuần chỉ định một lược đồ bảng là di chuyển logic nghiệp vụ vào cơ sở dữ liệu.

Kiến trúc

Bạn đang có xu hướng sử dụng công cụ thích hợp cho vấn đề phù hợp, không cần quá nhiều công cụ, cũng không quá khó để giải quyết, để đưa ra và duy trì giải pháp.

Điều này không dễ dàng.

Nhưng hãy nghĩ rằng điều không tưởng, bạn sẽ duy trì logic kinh doanh được phân phối trên nhiều ngôn ngữ như thế nào?

• Một danh mục ... để mỗi lần thực hiện quy tắc kinh doanh có thể được theo dõi và duy trì.
• Các thử nghiệm ... có thể được sử dụng theo từng quy tắc kinh doanh bất kể nó được thực hiện ở đâu và như thế nào.
• Một triển khai tham chiếu .. để khi tìm thấy sự khác biệt, một nguồn sự thật tồn tại (hoặc ít nhất là một nguồn tranh luận).

Nhưng điều này có một chi phí quá.

• Có tốt hơn để cho phép các quy tắc kinh doanh có nhiều triển khai? Điều đó mỗi người có thể tận dụng các kỹ năng của nhóm và các điều khoản khung, nhưng cần kiểm soát chất lượng chặt chẽ để tránh khỏi việc có nhiều mơ hồ nhỏ?
• Hoặc là tốt hơn để có một nguồn sự thật, được viết bằng một ngôn ngữ duy nhất? Có thể rẻ hơn để thực hiện, nhưng cũng là một nguồn thất bại duy nhất, bản thân nó là một thành phần nguyên khối chống lại sự thay đổi khi đối mặt với các nền tảng, khung công tác khác nhau hoặc chưa được phát minh ra các công cụ?

Tôi sẽ mở đầu câu trả lời của mình bằng cách nói rằng tôi thực sự duy trì một vài dịch vụ siêu nhỏ sử dụng các thủ tục được lưu trữ. Ngoài ra, tôi đã viết rất nhiều thủ tục được lưu trữ ở nhiều điểm khác nhau trong sự nghiệp của mình và tôi chắc chắn đồng ý rằng mọi thứ có thể đi rất, rất sai nếu chúng được sử dụng không chính xác.

Vì vậy, câu trả lời ngắn gọn là, không, các thủ tục được lưu trữ vốn không phải là xấu trong kiến ​​trúc microservice. Nhưng bạn cần phải hiểu:

1. Bạn đang thêm trở ngại cho việc thay thế các công cụ lưu trữ. Nếu một số đặc điểm hoạt động hoặc hiệu suất hoặc giới hạn tính năng yêu cầu bạn chuyển đổi công cụ lưu trữ, chi phí sẽ lớn hơn vì bạn sẽ viết và thử nghiệm rất nhiều mã mới. Chạy nhiều hơn một công cụ lưu trữ (trong giai đoạn di chuyển hoặc để cách ly các hoạt động dựa trên nhu cầu hiệu suất) có thể gây ra các vấn đề về tính nhất quán trừ khi bạn sử dụng cam kết hai pha (2PC), có vấn đề về hiệu năng.
2. Bạn đã có một API khác để duy trì, điều đó có nghĩa là sự phụ thuộc của bạn có thể bị phá vỡ. Thêm, xóa hoặc thay đổi các loại tham số trên thủ tục có thể phá vỡ mã hiện có. Điều tương tự cũng xảy ra với các bảng và truy vấn, nhưng các công cụ của bạn có thể ít hữu ích hơn với việc theo dõi nơi mọi thứ có thể sai. Các vấn đề với các thủ tục được lưu trữ thường được tìm thấy trong thời gian chạy, rất muộn trong quá trình phát triển / triển khai.
3. Quyền cơ sở dữ liệu của bạn trở nên phức tạp hơn. Liệu một thủ tục chạy như người dùng đã đăng nhập hoặc như một số vai trò khác? Bạn cần suy nghĩ về điều này và quản lý điều này (hy vọng theo kiểu tự động.)
4. Bạn cần có khả năng chuyển sang các phiên bản mới một cách an toàn. Thông thường, một thủ tục phải được bỏ và tạo lại. Một lần nữa, quyền có thể gây ra một số vấn đề cho bạn.
5. Phục hồi di chuyển thất bại có thể có nghĩa là nỗ lực thêm. Khi môi trường sản xuất được tách ra khỏi các nhà phát triển, mọi thứ thậm chí còn khó khăn hơn.

Đây là một số cách sử dụng các thủ tục được lưu trữ mà tôi nghĩ thường đáng giá:

1. Thực thi lịch sử chỉnh sửa (nhật ký kiểm toán). Kích hoạt thường được sử dụng cho mục đích này và kích hoạt là các thủ tục được lưu trữ. Một số cơ sở dữ liệu cũng có thể không cho phép chèn và cập nhật hoàn toàn cho vai trò ứng dụng: khách hàng thực hiện các quy trình được thực hiện như một vai trò khác với các quyền phù hợp và thực thi tất cả các hành vi cần thiết.
2. Gia hạn các ràng buộc kiểm tra. Điều này có thể đưa bạn vào lãnh thổ logic kinh doanh, nhưng có những trường hợp các công cụ ràng buộc tích hợp trong cơ sở dữ liệu có thể không đủ cho những gì bạn cần. Thông thường, cách tốt nhất để thể hiện kiểm tra là với mã bắt buộc và bạn có nguy cơ để dữ liệu xấu vào nếu bạn phụ thuộc vào ứng dụng của mình để làm điều đó cho bạn.
3. Đóng gói các truy vấn phức tạp khi một khung nhìn không phù hợp hoặc quá phức tạp. Tôi đã thấy một vài trường hợp trong đó một khung nhìn đúng yêu cầu một số SQL cực kỳ phức tạp có thể được thể hiện dễ hiểu hơn nhiều trong một thủ tục được lưu trữ. Điều này có lẽ là hiếm, nhưng nó xảy ra.

Nói chung, tôi khuyên bạn nên thử quan điểm trước và chỉ sử dụng các thủ tục khi cần thiết. Các khung nhìn được thiết kế tốt thực sự có thể hoạt động như một API, trừu tượng hóa các chi tiết về cách các bảng bên dưới được truy vấn. Tăng cường API của bạn (lượt xem) với các thủ tục được lưu trữ có ý nghĩa trong một số trường hợp. Thậm chí có thể phát JSON trực tiếp từ truy vấn SQL, bỏ qua toàn bộ mớ dữ liệu ánh xạ từ kết quả truy vấn đến mô hình dữ liệu của ứng dụng của bạn. Cho dù đó là một ý tưởng tốt là một cái gì đó để bạn xác định dựa trên nhu cầu của riêng bạn.

Vì bạn đã quản lý tài nguyên cơ sở dữ liệu của mình (lược đồ, quyền, v.v.) thông qua một số công cụ tự động, không, các thủ tục được lưu trữ vốn không phải là xấu đối với microservice.

Thủ tục lưu trữ là chi tiết thực hiện. Các hàm cơ sở dữ liệu, lambdas hoặc tập lệnh shell được lưu trữ ở đâu đó trong hệ thống tệp đều là các chi tiết triển khai và không liên quan đến kiến ​​trúc.

hầu hết các cuốn sách về microservice đề xuất một cơ sở dữ liệu cho mỗi dịch vụ microservice.

Ok, vì vậy chúng tôi có thể mã hóa các thủ tục được lưu trữ trong các cơ sở dữ liệu này.

một lần nữa, hầu hết các sách kiến ​​trúc microservice đều nói rằng chúng nên được tự chủ và ghép lỏng lẻo

Giữa các khả năng kinh doanh, vòng đời phát triển, quản lý, triển khai, địa điểm của nhóm, v.v. Không liên quan gì đến các chi tiết triển khai. Dịch vụ vi mô không giải quyết vấn đề kỹ thuật (ngược lại). Họ đến để giải quyết các vấn đề với ban quản lý và thời gian tiếp thị. Đó là một chiến lược, không phải là một chiến thuật. Một cách để thất bại nhanh chóng với chi phí ít nhất có thể. Nếu một khả năng kinh doanh nhất định được chứng minh là vô giá trị, chúng tôi sẽ loại bỏ nó mà không làm rối tung các khả năng khác, triển khai, quản lý dự án, phát hành ...

Lưu ý rằng "tách" đã hoạt động như một tác nhân tách rời. Giả sử chúng tôi có hai dịch vụ, A được hỗ trợ bởi Oracle và B bởi MongoDB. Nếu chúng ta không phá vỡ quy tắc vàng tách rời, có thể loại bỏ A + Oracle với các tác dụng phụ không đáng kể trên B.

Sử dụng các thủ tục được lưu trữ bằng văn bản nói riêng trong Oracle, kết hợp chặt chẽ microservice với công nghệ đó.

Nó có thể gây ra khóa nhà cung cấp. Nhiều lần, nhà cung cấp bị doanh nghiệp áp đặt vì lý do lịch sử hoặc hợp đồng ¹ . Điều quan trọng là phải biết cách không khóa mã của chúng tôi với nhà cung cấp. Ví dụ: một số ORM và khung triển khai ngôn ngữ truy vấn mới ẩn các chức năng và tính năng tích hợp trong cơ sở dữ liệu.

Mặc dù, nếu các dịch vụ của chúng tôi đủ vi mô, việc khóa nhà cung cấp không còn là vấn đề nữa vì nó ảnh hưởng đến một phần nhỏ của toàn bộ. Một phần nhỏ cần được thay thế (hoặc cách ly) nhanh chóng.

hầu hết các sách MSA (mà tôi đã đọc) khuyên rằng microservice nên được định hướng kinh doanh (được thiết kế bằng DDD).

Nó nên được định hướng kinh doanh và ở đây điều. Không phải tất cả các doanh nghiệp đều tận dụng DDD. DDD và microservice trùng lặp ở nhiều điểm, nhưng chúng không gây ra hậu quả. Chúng tôi có thể kết thúc với một hệ sinh thái microservice bao gồm các dịch vụ thiếu máu. Hoặc bao gồm một hỗn hợp của cả hai: các dịch vụ triển khai một miền phức tạp và các dịch vụ thiếu máu câm cung cấp POJO trực tiếp từ DB. Không có gì sai với điều đó.

Về sách, họ chỉ tập trung vào việc thực hiện chiến lược. Các chiến thuật - làm thế nào để tận dụng lợi thế của điện toán phân tán - làm thế nào để nó hoạt động để thành công, nhưng chúng (thường) không thể tin được vào chiến lược. Chiến lược khác nhau giữa các công ty và hiếm khi phụ thuộc vào các nhà phát triển. Vì vậy, chúng tôi vẫn phải ngoại suy và điều chỉnh những gì sách nói với nhu cầu, yêu cầu và ràng buộc cụ thể của chúng tôi. Mục tiêu là làm cho chiến lược kinh doanh có lợi nhuận và bền vững.

Luôn luôn nhớ rằng bất kỳ kiến ​​trúc là một phương tiện để kết thúc. Các quy tắc kinh doanh. Chúng tôi không xây dựng hệ sinh thái microservice cho thời trang hoặc yêu thích nghệ thuật.

Nó thực sự không có gì để làm với microservice.

Các thủ tục được lưu trữ có thể có ý nghĩa nếu dịch vụ của bạn có kiến ​​trúc phân lớp 'kiểu cũ' trong đó DB là nền tảng của dịch vụ, với quyền truy cập dữ liệu và lớp logic nghiệp vụ ở trên cùng. Giao diện giữa dịch vụ và cơ sở dữ liệu trong một kiến ​​trúc như vậy rất cụ thể với các chi tiết trong cùng của dịch vụ. Thông thường, sẽ có các bộ điều hợp dành riêng cho dịch vụ cho từng loại cơ sở dữ liệu được hỗ trợ và tính đặc hiệu của API được bộ điều hợp hiển thị cho phép sử dụng các quy trình được lưu trữ trong các lớp bên dưới.

Có rất nhiều vấn đề với kiến ​​trúc như thế. Quan trọng nhất là nó làm cho hầu hết logic rất khó để kiểm tra đơn vị. Những kiến ​​trúc này không còn được ưa chuộng.

Nếu bạn đang sử dụng "kiến trúc sạch" kiểu mới hơn, "kiến trúc củ hành" hoặc tương tự, thì cơ sở dữ liệu sẽ là một phụ thuộc được chèn , được chỉ định ở các lớp bên ngoài. Vì được định nghĩa trong các lớp bên ngoài, giao diện được cung cấp cho cơ sở dữ liệu phải chung chung . Nó không thể phản ánh các chi tiết trong cùng của dịch vụ, bởi vì các chi tiết đó phải được ẩn khỏi các lớp ngoài cùng của kiến ​​trúc. Việc xác định một giao diện thủ tục được lưu trữ chung có thể hoạt động với bất kỳ cơ sở dữ liệu hoặc khai thác thử nghiệm đơn vị nào là vô cùng khó khăn và không thực sự cần thiết, vì vậy các quy trình được lưu trữ thường không thực tế trong các loại kiến ​​trúc này.

Mối quan hệ với microservice chỉ là microservice là mới và tăng dần - chúng tôi không còn làm nguyên khối nữa - và những phong cách kiến ​​trúc mới này cũng đã lên cao - chúng tôi không làm các lớp phẳng nữa.