Cảnh báo: bài đăng lớn, một số ý kiến, mơ hồ 'hãy làm những gì tốt nhất cho bạn'
Nói chung, điều này được thực hiện như một phương tiện để thực hiện 'kiến trúc lục giác' xung quanh cơ sở dữ liệu của bạn. Bạn có thể có các ứng dụng web, ứng dụng di động, ứng dụng máy tính để bàn, nhà nhập khẩu số lượng lớn và xử lý nền đều tiêu thụ cơ sở dữ liệu của bạn một cách thống nhất. Chắc chắn bạn có thể hoàn thành điều tương tự ở một mức độ nào đó bằng cách viết một thư viện phong phú để truy cập cơ sở dữ liệu của bạn và có tất cả các quy trình của bạn sử dụng thư viện đó. Và thực sự, nếu bạn đang ở trong một cửa hàng nhỏ với một hệ thống rất đơn giản, đó thực sự có lẽ là một con đường tốt hơn để đi; Đó là một cách tiếp cận đơn giản hơn và nếu bạn không cần các khả năng tiên tiến của một hệ thống phức tạp hơn, tại sao phải trả tiền cho sự phức tạp? Tuy nhiên, nếu bạn đang làm việc với một bộ hệ thống lớn, tinh vi, tất cả đều cần tương tác với cơ sở dữ liệu của bạn ở quy mô, thì '
Độc lập và bảo trì nền tảng
Nếu bạn có cơ sở dữ liệu và bạn viết thư viện Python để tương tác với cơ sở dữ liệu đó và mọi người kéo vào thư viện đó để tương tác với cơ sở dữ liệu, điều đó thật tuyệt. Nhưng giả sử đột nhiên bạn cần viết một ứng dụng di động và ứng dụng di động đó bây giờ cũng cần nói chuyện với cơ sở dữ liệu. Và các kỹ sư iOS của bạn không sử dụng Python và các kỹ sư Android của bạn không sử dụng Python. Có thể các chàng trai iOS muốn sử dụng ngôn ngữ của Apple và các kỹ sư Android muốn sử dụng Java. Sau đó, bạn sẽ bị kẹt viết và duy trì thư viện truy cập dữ liệu của mình bằng 3 ngôn ngữ khác nhau. Có thể các nhà phát triển iOS và Android quyết định sử dụng một cái gì đó như Xamarin để tối đa hóa mã họ có thể chia sẻ. Hoàn hảo, ngoại trừ có lẽ bạn vẫn sẽ phải chuyển thư viện truy cập dữ liệu của mình sang .NET. Và sau đó công ty của bạn vừa mua một công ty khác, người ' Ứng dụng web là một sản phẩm khác nhau nhưng có liên quan và doanh nghiệp muốn tích hợp một số dữ liệu từ nền tảng của công ty bạn vào nền tảng của công ty con mới mua. Chỉ có một vấn đề: Công ty con là một công ty mới thành lập và quyết định viết phần lớn đơn đăng ký của họ bằng tiếng Anh. Ngoài ra, vì bất kỳ lý do gì (lý do có thể nằm ngoài tầm kiểm soát của bạn), nhóm di động đang điều khiển Xamarin đã quyết định không dành cho họ và họ muốn sử dụng các công cụ và ngôn ngữ dành riêng cho thiết bị di động mà họ sẽ phát triển. Nhưng trong khi bạn ở giai đoạn đó, nhóm của bạn đã cung cấp một phần lớn thư viện truy cập dữ liệu của bạn bằng .NET và một nhóm khác trong công ty đã viết một số nội dung tích hợp Salesforce điên rồ và quyết định thực hiện tất cả điều đó trong .NET kể từ đó đã là một thư viện truy cập dữ liệu cho.
Vì vậy, bây giờ, do có một sự kiện rất thực tế, bạn có thư viện truy cập dữ liệu của mình được viết bằng Python, .NET, Swift, Java và Dart. Chúng cũng không đẹp như bạn muốn. Bạn không thể sử dụng ORM hiệu quả như bạn muốn, vì mỗi ngôn ngữ có các công cụ ORM khác nhau, vì vậy bạn phải viết nhiều mã hơn bạn muốn. Và bạn đã không thể dành nhiều thời gian cho mỗi lần hóa thân như bạn muốn, bởi vì có 5 người trong số họ. Và phiên bản Dart của thư viện đặc biệt nhiều lông vì bạn phải tự tạo ra các công cụ giao dịch của riêng mình cho một số thư viện vì các thư viện và hỗ trợ chỉ thực sự không có ở đó. Bạn đã cố gắng giải thích rằng vì điều này, ứng dụng Dart chỉ có chức năng chỉ đọc cho cơ sở dữ liệu của bạn, nhưng doanh nghiệp đã quyết định rằng bất kỳ tính năng nào họ đang lên kế hoạch đều đáng để nỗ lực thêm. Và hóa ra có một lỗi trong một số logic xác thực tồn tại trong tất cả các hóa thân của thư viện truy cập dữ liệu của bạn. Bây giờ bạn phải viết bài kiểm tra và mã để sửa lỗi này trong tất cả các thư viện này, nhận đánh giá mã cho các thay đổi của bạn cho tất cả các thư viện này, nhận QA trên tất cả các thư viện này và phát hành các thay đổi của bạn cho tất cả các hệ thống bằng cách sử dụng tất cả các hệ thống những thư viện này. Trong khi đó, khách hàng của bạn không hài lòng và đã đưa lên Twitter, kết hợp các kết hợp thô tục mà bạn không bao giờ có thể tưởng tượng được, có thể được nhắm mục tiêu vào sản phẩm hàng đầu của công ty bạn. Và chủ sở hữu sản phẩm quyết định không hiểu lắm về tình hình.
Xin hiểu rằng trong một số môi trường, ví dụ trên là bất cứ điều gì ngoài kế hoạch. Cũng xem xét rằng chuỗi các sự kiện này có thể diễn ra trong một vài năm. Nói chung, khi bạn đến điểm mà các kiến trúc sư và doanh nhân bắt đầu nói về việc kết nối các hệ thống khác với cơ sở dữ liệu của bạn, đó là khi bạn sẽ muốn "đặt API REST trước cơ sở dữ liệu" lên lộ trình của mình. Hãy xem xét nếu sớm, khi rõ ràng cơ sở dữ liệu này sẽ bắt đầu được chia sẻ bởi một vài hệ thống, rằng một dịch vụ web / API REST đã được đặt trước nó. Sửa lỗi xác nhận của bạn sẽ nhanh hơn và dễ dàng hơn nhiều vì bạn đang thực hiện một lần thay vì 5 lần. Và phát hành bản sửa lỗi sẽ dễ dàng hơn rất nhiều để phối hợp, bởi vì bạn '
TLDR; Việc tập trung logic truy cập dữ liệu dễ dàng hơn và duy trì các máy khách HTTP rất mỏng so với việc phân phối logic truy cập dữ liệu tới từng ứng dụng cần truy cập dữ liệu. Trên thực tế, máy khách HTTP của bạn thậm chí có thể được tạo từ siêu dữ liệu. Trong các hệ thống lớn, API REST cho phép bạn duy trì ít mã hơn
Hiệu suất và khả năng mở rộng
Một số người có thể tin rằng nói chuyện trực tiếp với cơ sở dữ liệu thay vì thông qua dịch vụ web trước sẽ nhanh hơn. Nếu bạn chỉ có một ứng dụng, điều đó chắc chắn đúng. Nhưng trong các hệ thống lớn hơn, tôi không đồng ý với tình cảm. Cuối cùng, ở một mức độ quy mô nào đó, sẽ rất có lợi khi đặt một số loại bộ đệm trước cơ sở dữ liệu. Có thể bạn đang sử dụng Hibernate và muốn cài đặt lưới Infinispan làm bộ đệm L2. Nếu bạn có một cụm gồm 4 máy chủ mạnh mẽ để lưu trữ dịch vụ web của bạn tách biệt với các ứng dụng của bạn, bạn có thể đủ khả năng để có một cấu trúc liên kết nhúng với sao chép đồng bộ được bật. Nếu bạn cố gắng đặt nó trên một cụm gồm 30 máy chủ ứng dụng, thì chi phí cho việc sao chép trong thiết lập đó sẽ quá nhiều, vì vậy bạn sẽ phải chạy Infinispan ở chế độ phân tán hoặc trong một loại cấu trúc liên kết chuyên dụng nào đó và đột nhiên Hibernate phải truy cập mạng để đọc từ bộ đệm. Thêm vào đó, Infinispan chỉ hoạt động trong Java. Nếu bạn có ngôn ngữ khác, bạn sẽ cần các giải pháp bộ đệm khác. Chi phí mạng phải đi từ ứng dụng của bạn đến dịch vụ web của bạn trước khi tiếp cận cơ sở dữ liệu sẽ nhanh chóng được bù đắp bởi nhu cầu sử dụng các giải pháp bộ nhớ đệm phức tạp hơn nhiều thường đi kèm với chi phí của chính họ.
Ngoài ra, lớp HTTP của API REST của bạn cung cấp một cơ chế bộ đệm có giá trị khác. Các máy chủ của bạn cho API REST có thể đặt các tiêu đề bộ đệm vào các phản hồi của chúng và các phản hồi này có thể được lưu trong bộ đệm ở lớp mạng, có tỷ lệ đặc biệt tốt. Trong một thiết lập nhỏ, với một hoặc hai máy chủ, cách tốt nhất của bạn là chỉ sử dụng bộ nhớ cache trong ứng dụng khi nói chuyện với cơ sở dữ liệu, nhưng trong một nền tảng lớn có nhiều ứng dụng chạy trên nhiều máy chủ, bạn muốn tận dụng mạng để xử lý bộ nhớ đệm của bạn, bởi vì khi được cấu hình đúng cách, một cái gì đó như mực hoặc véc ni hoặc nginx có thể mở rộng đến mức điên rồ trên phần cứng tương đối nhỏ. Hàng trăm ngàn hoặc hàng triệu yêu cầu mỗi giây thông lượng rẻ hơn rất nhiều để thực hiện từ bộ đệm HTTP so với từ máy chủ ứng dụng hoặc cơ sở dữ liệu.
Trên hết, việc có rất nhiều máy khách chỉ vào cơ sở dữ liệu của bạn, thay vì tất cả chúng đều chỉ vào một vài máy chủ, lần lượt trỏ đến cơ sở dữ liệu, có thể khiến việc điều chỉnh cơ sở dữ liệu và kết nối khó khăn hơn rất nhiều. Nói chung, hầu hết khối lượng công việc thực tế trên một máy chủ ứng dụng là công cụ ứng dụng; chờ đợi dữ liệu quay trở lại từ cơ sở dữ liệu thường tốn thời gian, nhưng nhìn chung không tốn kém lắm về mặt tính toán. Bạn có thể cần 40 máy chủ để xử lý khối lượng công việc của ứng dụng, nhưng có lẽ bạn không cần 40 máy chủ để sắp xếp tìm nạp dữ liệu từ cơ sở dữ liệu. Nếu bạn dành nhiệm vụ đó cho một dịch vụ web, dịch vụ web có thể sẽ chạy trên các máy chủ ít hơn nhiều so với phần còn lại của ứng dụng, điều đó có nghĩa là bạn sẽ cần ít kết nối hơn tới cơ sở dữ liệu. Điều này rất quan trọng, vì cơ sở dữ liệu thường không
TLDR; Điều chỉnh, chia tỷ lệ và lưu trữ bộ nhớ truy cập dữ liệu của bạn dễ dàng hơn khi đó là điều xảy ra bên trong một dịch vụ web chuyên dụng duy nhất so với khi nó xảy ra trên nhiều ứng dụng khác nhau sử dụng các ngôn ngữ và công nghệ khác nhau
Suy nghĩ cuối cùng
Xin đừng thoát khỏi suy nghĩ này "Ôi chà, tôi nên luôn luôn sử dụng API REST để lấy dữ liệu của mình" hoặc "Tên ngốc này đang cố nói rằng chúng tôi đã làm sai vì ứng dụng web của chúng tôi nói chuyện trực tiếp với cơ sở dữ liệu, nhưng công cụ của chúng tôi hoạt động tốt! " . Điểm chính tôi đang cố gắng thực hiện là các hệ thống khác nhau và các doanh nghiệp khác nhau có các yêu cầu khác nhau; Trong rất nhiều trường hợp, việc đặt API REST trước cơ sở dữ liệu của bạn thực sự không có ý nghĩa. Đó là một kiến trúc phức tạp hơn đòi hỏi phải chứng minh sự phức tạp đó. Nhưng khi sự phức tạp được bảo đảm, sẽ có rất nhiều lợi ích khi có API REST. Có thể cân nhắc các mối quan tâm khác nhau và chọn phương pháp phù hợp cho hệ thống của bạn là điều tạo nên một kỹ sư giỏi.
Ngoài ra, nếu API REST đang cản trở mọi thứ, có thể có gì đó sai hoặc thiếu trong bức tranh đó. Tôi không tin rằng có thêm lớp trừu tượng về bản chất làm cho việc gỡ lỗi khó hơn. Khi tôi làm việc với các hệ thống n-tier lớn, tôi muốn đảm bảo rằng tôi có bối cảnh ghi nhật ký phân tán. Có lẽ khi người dùng bắt đầu một yêu cầu, hãy tạo GUID cho yêu cầu đó và đăng nhập tên người dùng của người dùng đó và yêu cầu họ đã thực hiện. Sau đó, chuyển GUID đó khi ứng dụng của bạn nói chuyện với các hệ thống khác. Với tính năng tổng hợp và lập chỉ mục nhật ký thích hợp, bạn có thể truy vấn toàn bộ nền tảng của mình để người dùng báo cáo sự cố và có thể nhìn thấy tất cả các hành động của họ và họ lướt qua hệ thống để nhanh chóng xác định nơi xảy ra sự cố. Một lần nữa, nó là một kiến trúc phức tạp hơn,
Nguồn:
http://alistair.cockburn.us/Hexagonal+arch architecture
https://github.com/brettwooldridge/HikariCP/wiki/ về -Pool- Sizing