iKonekt
Mở bảng điều khiển

Tách biệt

Ranh giới mà cơ sở dữ liệu giữ, chứ không phải mã nguồn

Mọi CRM đều tuyên bố hỗ trợ đa tenant. Lời tuyên bố thì rẻ; điều quan trọng là lớp nào đang giữ ranh giới đó. Nếu câu trả lời là "ứng dụng của chúng tôi luôn thêm bộ lọc đúng", thì sự đảm bảo chỉ tốt bằng lập trình viên ít được nghỉ ngơi nhất từng viết một truy vấn.

iKonekt đã hỗ trợ đa tenant ngay từ lần migration đầu tiên chứ không phải gắn thêm về sau, nghe thì như một lời khoe nhưng thực ra là một sự thừa nhận: gắn thêm nó sau này gần như không thể làm một cách thuyết phục, và ai đã từng thử đều có một câu chuyện để kể.

Việc tách biệt nằm ngay trong cơ sở dữ liệu. Cả hai mươi sáu bảng đều mang theo tenant mà nó thuộc về, và chính sách kiểm tra điều đó chạy trên mọi lần đọc và mọi lần ghi, hoàn toàn bên dưới tầng ứng dụng. Một truy vấn quên mất ranh giới sẽ không trả về khách hàng của người khác. Nó không trả về gì cả.

Bảo mật cấp dòng, bắt buộc

Không phải một quy ước, không phải một quy tắc review code. Cơ sở dữ liệu từ chối. Bảy mươi hai chính sách, được viết ra từng cái một thay vì sinh tự động — vì chính sách sinh tự động là chính sách không ai từng đọc.

Khóa ghép

Một bản ghi con tham chiếu đến tenant và bản ghi cha của nó cùng lúc, như một cặp. Một định danh lạc từ công ty khác sẽ không phân giải được — nó đơn giản không phải là một tham chiếu hợp lệ.

Không bao giờ có tenant mặc định

Một yêu cầu không có phạm vi sẽ không lặng lẽ biến thành yêu cầu cho tenant số không. Nó ném lỗi trước khi chạm tới cơ sở dữ liệu. Không có chế độ "không phạm vi" nào để bạn quên tắt.

Cái lỗi không thể tự lên tiếng

Trong lúc làm phần đa tenant, phần lớn sai sót đều ồn ào. Cho hai công ty cùng một miền khách hàng và cơ sở dữ liệu phản đối ngay lập tức, với mã lỗi và stack trace; bạn sửa xong trước giờ trưa.

Có một cái không phản đối. Một bảng ghi đè prompt có thể chỉnh sửa được khóa chỉ theo loại prompt — chứ không phải theo loại và tenant. Một công ty thứ hai chỉnh sửa bản sao của họ sẽ lặng lẽ ghi đè lên bản của công ty đầu tiên, bằng SQL hoàn toàn hợp lệ, không lỗi, không cảnh báo, và không có bài test nào thất bại. Nó được phát hiện bằng cách đọc từng chỉ mục duy nhất còn lại sau khi thay đổi một khóa, lần lượt từng cái, vì nghi ngờ rằng những cái ồn ào kia không ở một mình.

Chúng tôi nhắc đến điều này vì đó là hình dạng trung thực của công việc này. Tách biệt không phải là một tính năng bạn bật lên; đó là thói quen đọc những phần nhàm chán của schema với giả định rằng có gì đó trong đó không đồng ý với bạn.

Các bài test, để rõ ràng: 942 bài, chạy trên một cơ sở dữ liệu được dựng lại từ con số không sau mỗi thay đổi. Chúng không ở đó để chứng minh thiết kế là thông minh. Chúng ở đó vì kiểu thất bại của thiết kế này là im lặng, và thất bại im lặng cần có người hét lên thay.

Tách biệt mang lại gì cho một người bình thường

  • Một tập đoàn có thể vận hành nhiều công ty từ một bản cài đặt, và người bán ở công ty này sẽ không bao giờ thấy khách hàng của công ty khác — không phải bằng chính sách, mà bằng cấu trúc.
  • Một chương trình đối tác, một bộ prompt, một quyền yêu cầu trên khách hàng: tất cả đều giới hạn theo từng công ty, nên cấu hình của tenant này không thể trở thành của tất cả mọi người.
  • Một yêu cầu xóa dữ liệu được thực hiện trong phạm vi ranh giới chứ không phải trên một đống dữ liệu dùng chung, và đó chính là điều khiến việc trả lời một cách trung thực trở nên khả thi.
  • Và không ai phải nhớ bất cứ điều gì về nó. Đó mới là điểm mấu chốt — một cam kết phụ thuộc vào việc được nhớ thì không phải là cam kết.

Thêm một đoạn không nói về cơ sở dữ liệu

Mỗi dịch vụ anh em trong gia đình đều giữ thông tin xác thực riêng có tên của mình. Không gì nói chuyện bằng thông tin dùng chung, nên không dịch vụ nào có thể vô tình hành động như một dịch vụ khác — một kỷ luật nhỏ đến trực tiếp từ việc từng có một token dùng chung và không thích điều đó.

Đó là cùng một bản năng với quy tắc cơ sở dữ liệu. Hãy khiến điều sai trở nên bất khả thi thay vì chỉ bị khuyến cáo, và bạn sẽ dành sự chú ý cho khách hàng thay vì cho sự cảnh giác.

Ranh giớiBên dưới tầng ứng dụng
  • 126 bảngBảng nào cũng mang theo tenant của nó, với việc kiểm tra được bắt buộc bật.
  • 272 chính sáchĐược viết ra từng cái một, nên mỗi chính sách đều đã được một con người đọc qua.
  • 3942 bài kiểm thửChạy trên cơ sở dữ liệu dựng lại từ con số không, sau mỗi thay đổi.
  • 40 tenant mặc địnhMột yêu cầu không có phạm vi không bao giờ chạm tới dữ liệu.

Đo trên bản dựng thực tế

“Ứng dụng của chúng tôi luôn lọc theo công ty.”

Từ “luôn” đang gánh vác rất nhiều việc trong câu đó.

Hãy đẩy ranh giới xuống vào trong cơ sở dữ liệu và một mệnh đề WHERE bị quên sẽ trả về không có gì thay vì khách hàng của người khác. Một màn hình trống là một thất bại tốt hơn một lời giới thiệu lúng túng.

Dành cho tập đoàn vận hành nhiều thương hiệu →