Rhett Butler567
Senior Member
Có ưu điểm gì hơn k bác. E thấy chia nhiềi db sẽ ảnh hưởng tới HA lẫn replica n sang các db server khác
thảo luận Triển khai microservice cho backend springboot
- Người tạo chủ đề Hero Kun
- Ngày bắt đầu
thisismyfirstclone
Senior Member
Đã microservice rồi lại còn replicate nó sang db server khác làm gì vậy? HA thì mỗi service vẫn HA được (vd replicate db trong mỗi service)
Rhett Butler567
Senior Member
Service chết a bật lại đc chứ db a p có cơ chế replicate backup dữ liệu sang nhiều chỗ khác nhau chứ
thisismyfirstclone
Senior Member
À t tưởng a bảo replicate db của một service sang các service khác. Sr.
Niels Henrik Abel
Member
Nó là shared db, có gì lạ đâu. vẫn được dùng
thisismyfirstclone
Senior Member
Ông kia có bảo là không dùng đc đâu. Ông ấy bảo là làm thế thì không khác gì mono thôi.
The drawbacks of this pattern are:
- Development time coupling - a developer working on, for example, the OrderService will need to coordinate schema changes with the developers of other services that access the same tables. This coupling and additional coordination will slow down development.
- Runtime coupling - because all services access the same database they can potentially interfere with one another. For example, if long running CustomerService transaction holds a lock on the ORDER table then the OrderService will be blocked.
- Single database might not satisfy the data storage and access requirements of all services.
- Database per Service is an alternative approach
inside.begin.271
Senior Member
ưu điểm nhiều là đằng khác, cái chính là trính thắt nút cổ chai. Ví dụ cụ thể như bác thisismyfirstclone có đề cập ở trên.
Niels Henrik Abel
Member
Nó là 1 pattern của micro thì là miro. mono là mono. mono có scale out được từng service đâu.
thisismyfirstclone
Senior Member
Ủa thế làm theo cách này thì scale kiểu gì vậy, khi mà tất cả các services đều phụ thuộc vào chung 1 db. Có scale servers code lên thì throughput vẫn là throughput của 1 db.
Niels Henrik Abel
Member
ủa người ta phân db theo domain. ví dụ card có nhiều service nhưng 1 db, loan có nhiêu service nhưng 1 db. deposit nhiêu service 1 db.
scale service khi CPU tăng cao. mà cpu tăng cao chưa chắc là do db mà cứ kieu 1 db ko scale được
thisismyfirstclone
Senior Member
card, loan, deposit là các services r, thay vì monolithic là tất cả cùng một project.
Scale service khi CPU tăng cao là tăng số servers lên để giảm CPU sử dụng trên server (vd load balancer) thì cái này cả monolithic vẫn dùng được (triển khai monolithic trên 2 servers khác nhau để load balancer).
Vấn đề là khi monolithic toàn bộ services card, loan, deposit sẽ phải share cùng một db nên performance app sẽ giảm. Thêm nữa như trong bài nói, là dùng shared database có khả năng dẫn đến tightly coupled (Development time coupling), một vấn đề của monolithic, nghĩa là thay đổi logic order sẽ (khả năng cao) là thay đổi cả code lẫn bảng của product. Trong khi microservice thì các services sẽ sử dụng loosely coupled. Nghĩa là các services chỉ public interface (vd Rest API) để tương tác lẫn nhau, phần implementation của từng service sẽ giấu đi (code, database tables). Do đó, khi thay đổi một service thì sẽ ít gây ra ảnh hưởng đến service còn lại.
Sửa lần cuối:
Rhett Butler567
Senior Member
Phần authorization bác implement như nào vậy ? Bác lấy permission từ token r tự phân quyền hay gửi request cho keycloak validate vậy ?
AiLaDaddyCuaEm
Senior Member
Chưa Implement cái này bao giờ nhưng theo mình để quyền trong token thì ko ổn lắm, lỡ quyền lưu trong db có thay đổi rồi nhưng token vẫn giữ quyền cũ thì nó ko đồng bộ
Rhett Butler567
Senior Member
Quyền lưu trong db của keycloak thím. Khi thay đổi thì token keycloak trả về cx sẽ có quyền mớiChưa Implement cái này bao giờ nhưng theo mình để quyền trong token thì ko ổn lắm, lỡ quyền lưu trong db có thay đổi rồi nhưng token vẫn giữ quyền cũ thì nó ko đồng bộ
Rhett Butler567
Senior Member
Bác có thể mô tả rõ hơn cviec của gw và service k nhỉ
aNotHeRNo0b
Senior Member
:v tùy vào công ty muốn làm tới mức nào, cái gì cũng có 2 mặt mà bác :v dùng chung DB là trò anti-pattern của Microservice để move nhanh thôi. Mấy cái như Distributed Transaction thay vì phải implement 2PC hay Saga thì nhiều cty viết hẳn store-produced để xử luôn, nhanh gọn lẹ do dùng Shared-Database (anti-pattern) và cũng được xem là 1 loại Microservice nếu desisgn schema tốt mà
AiLaDaddyCuaEm
Senior Member
Cái bôi đen này hơi khoai, chia DB ra chắc còn dễ hơn.:v tùy vào công ty muốn làm tới mức nào, cái gì cũng có 2 mặt mà bác :v dùng chung DB là trò anti-pattern của Microservice để move nhanh thôi. Mấy cái như Distributed Transaction thay vì phải implement 2PC hay Saga thì nhiều cty viết hẳn store-produced để xử luôn, nhanh gọn lẹ do dùng Shared-Database (anti-pattern) và cũng được xem là 1 loại Microservice nếu desisgn schema tốt mà
Còn dùng store-produced vậy mỗi lần cần sửa logic phải mò xuống DB à ? t thấy vừa cực vừa rủi ro
aNotHeRNo0b
Senior Member
:v đánh đổi thôi bác, giờ chia 1 service 1 DB rồi đi maintain Replication / Backup cho mỗi con à. Chẳng qua thời nay nó có Cloud, cung cấp managed service thì bác thấy dễ thôi, chứ cứ thử on-prem thử xem, ói máu ấy chứ. Dùng managed thì ngon nma đến cuối tháng thì nóng ví vì bill thôi.Cái bôi đen này hơi khoai, chia DB ra chắc còn dễ hơn.
Còn dùng store-produced vậy mỗi lần cần sửa logic phải mò xuống DB à ? t thấy vừa cực vừa rủi ro
AiLaDaddyCuaEm
Senior Member
ko cần replica đâu thím, mình từng làm microservice. Ví dụ service A cần thông tin trong DB của service B thì chỉ cần mở 1 interface cho A gọi sang B service là được, tất nhiên nó là internal interface
aNotHeRNo0b
Senior Member
@@ ko có replica thì DB hẻo đui luôn service à bác??ko cần replica đâu thím, mình từng làm microservice. Ví dụ service A cần thông tin trong DB của service B thì chỉ cần mở 1 interface cho A gọi sang B service là được, tất nhiên nó là internal interface
Chủ đề tương tự
