Do sự kết hợp của các yêu cầu kinh doanh / doanh nghiệp và sở thích của kiến trúc sư của chúng tôi, chúng tôi đã đến một kiến trúc cụ thể có vẻ hơi khó chịu với tôi, nhưng tôi có kiến thức kiến trúc rất hạn chế và thậm chí ít kiến thức về đám mây, vì vậy tôi rất thích kiểm tra sự tỉnh táo nếu có cải tiến có thể được thực hiện ở đây:
Bối cảnh: Chúng tôi đang phát triển một sự thay thế cho một hệ thống hiện có được viết lại hoàn chỉnh từ đầu. Điều này yêu cầu chúng tôi lấy nguồn dữ liệu từ một phiên bản SAP thông qua BAPI / SOAP Web Services, cũng như sử dụng một số cơ sở dữ liệu của riêng chúng tôi cho dữ liệu không có trong SAP. Hiện tại tất cả dữ liệu mà chúng tôi sẽ quản lý tồn tại trong các DB cục bộ trên một ứng dụng phân tán hoặc trong cơ sở dữ liệu MySQL sẽ cần phải được di chuyển khỏi. Chúng tôi sẽ cần tạo một số ứng dụng web sao chép chức năng của ứng dụng phân tán hiện có, cũng như cung cấp chức năng liên quan đến quản trị viên đối với dữ liệu chúng tôi kiểm soát.
Yêu cầu kinh doanh / doanh nghiệp:
Bất kỳ cơ sở dữ liệu nào chúng tôi kiểm soát phải được triển khai trong MS SQL Server
Giảm thiểu số lượng cơ sở dữ liệu được tạo
Giai đoạn 1 sẽ cho chúng tôi triển khai các ứng dụng của mình lên Azure, nhưng chúng tôi cần khả năng mang các ứng dụng này ra mắt trong tương lai
Nhóm Ops của chúng tôi muốn chúng tôi cập nhật mọi thứ vì họ cảm thấy điều đó sẽ giúp việc quản lý mã của họ đơn giản hơn rất nhiều.
Giảm thiểu / loại bỏ sao chép dữ liệu
Ngăn xếp mã hóa sẽ là .NET Core cho các dịch vụ microservice và Admin, nhưng Angular 5 cho ứng dụng front-end chính.
Từ những yêu cầu này, kiến trúc sư của chúng tôi đã đưa ra thiết kế này:
Mặt trước của chúng tôi sẽ cung cấp từ một loạt các dịch vụ siêu nhỏ (tôi sử dụng thuật ngữ đó một cách nhẹ nhàng vì chúng ở cấp độ 'Miền' và khá lớn), sẽ được chia thành Dịch vụ Đọc và Dịch vụ Viết trong mỗi miền. Cả hai sẽ có khả năng mở rộng và tải cân bằng thông qua Kubernetes. Mỗi người cũng sẽ có một bản sao chỉ đọc cơ sở dữ liệu của họ được đính kèm trong thùng chứa của họ, với một phiên bản chính của db có sẵn để ghi sẽ đẩy ra các bản cập nhật cho những bản sao chỉ đọc.
(Xin lỗi vì hình ảnh kém chất lượng, tôi đang làm lại chúng từ bộ nhớ vì, tự nhiên, không có tài liệu thực tế nào cho nội dung này ngoại trừ trong đầu của kiến trúc sư)
Giao tiếp giữa Dịch vụ với Dịch vụ sẽ diễn ra thông qua hàng đợi tin nhắn mà mỗi dịch vụ sẽ lắng nghe và xử lý mọi tin nhắn có liên quan. Việc sử dụng chính của việc này sẽ là để tạo email, vì không có gì khác chúng tôi đã xác định yêu cầu dịch vụ liên lạc với dịch vụ để biết thông tin. Bất cứ điều gì "logic kinh doanh" liên quan sẽ yêu cầu nhiều dịch vụ tham gia đều có khả năng chảy từ các giao diện người dùng, trong đó các giao diện sẽ gọi riêng từng dịch vụ và xử lý nguyên tử.
Từ góc nhìn của tôi, điều khiến tôi hiểu lầm là các trường hợp db chỉ đọc được quay bên trong các thùng chứa docker cho các dịch vụ. Bản thân dịch vụ và db sẽ có các nhu cầu khác nhau đáng kể về tải, do đó, sẽ có ý nghĩa hơn nhiều nếu chúng ta có thể tải cân bằng chúng một cách riêng biệt. Tôi tin rằng MYSQL có cách thực hiện điều đó với các cấu hình chính / nô lệ, nơi các nô lệ mới có thể xuất hiện bất cứ khi nào tải cao. Đặc biệt là trong khi chúng tôi có hệ thống của chúng tôi trên đám mây và đang trả tiền cho từng trường hợp, việc tạo ra một phiên bản mới của toàn bộ dịch vụ khi chúng tôi chỉ cần một phiên bản db khác có vẻ lãng phí (ngược lại, quay lên một bản sao db mới khi chúng tôi thực sự chỉ cần một ví dụ dịch vụ web). Tuy nhiên, tôi không biết những hạn chế của MS SQL Server cho việc này.
Mối quan tâm lớn nhất của tôi là xung quanh việc triển khai MS SQL Server. Khớp các trường hợp chỉ đọc rất chặt chẽ với các dịch vụ cảm thấy sai. Có cách nào tốt hơn để làm điều này?
LƯU Ý: Tôi đã hỏi điều này về kỹ thuật phần mềm và họ đã chỉ cho tôi ở đây. Xin lỗi nếu đây không phải là SE thích hợp.
Ngoài ra không có thẻ MS SQL Server