- Trung Nguyen
-
27/11/2020
-
12 min read
Ngày nay, nhiều ứng dụng văn minh cần được thiết kế xây dựng ở quy mô doanh nghiệp, đôi lúc thậm chí còn ở quy mô internet. Mỗi ứng dụng cần phân phối những nhu yếu về năng lực lan rộng ra ( scalability ), tính khả dụng ( availability ), bảo mật thông tin ( security ), độ đáng tin cậy ( reliability ) và năng lực hồi sinh ( resiliency demands ) .
Trong bài viết này, tôi sẽ nói về một số mẫu thiết kế (design pattern) có thể giúp bạn đạt được những khả năng nêu trên một cách dễ dàng. Tôi sẽ nói về từng mẫu, cách sử dụng mẫu đó trong môi trường đám mây (cloud), khi nào thì sử dụng và khi nào thì không.
Một số mẫu phong cách thiết kế không quá mới nhưng rất hữu dụng trong quốc tế đám mây quy mô internet hiện tại .Đây là list những mẫu phong cách thiết kế tôi sẽ luận bàn trong bài viết này :
- Circuit Breaker
- Command and Query Responsibility (CQRS)
- Event Sourcing
- Sidecar
- Backend-for-Frontend (BFF)
- Strangler
Vậy hãy khởi đầu nào .
Circuit Breaker
Các mạng lưới hệ thống phân tán ( distributed system ) phải được phong cách thiết kế bằng cách xem xét những góc nhìn hỏng hóc. Ngày nay, quốc tế đã vận dụng microservices và những dịch vụ này thường phụ thuộc vào vào những dịch vụ từ xa khác. Các dịch vụ từ xa này hoàn toàn có thể không phản hồi kịp thời do nhiều nguyên do khác nhau như mạng, tải ứng dụng, v.v. Trong hầu hết những trường hợp, việc thử lại sẽ hoàn toàn có thể xử lý yếu tố .Nhưng nhiều lúc hoàn toàn có thể có những yếu tố lớn như dịch vụ dừng hoạt động giải trí trong thời điểm tạm thời hoặc dịch vụ gặp sự cố phải dừng hoạt động giải trí trọn vẹn. Thật không có ý nghĩa nếu bạn liên tục thử lại trong những trường hợp như vậy. Đó là nơi mà mẫu Circuit Breaker hoàn toàn có thể có ích .
Sơ đồ trên ra mắt việc tiến hành mẫu Circuit Breaker, trong đó khi Service 1 hiểu rằng có lỗi hoặc timeout liên tục khi gọi Service 2. Thay vì thử lại, Service 1 chuyển hướng những cuộc gọi đến Service 2 và trả về phản hồi dự trữ .Có những thư viện nguồn mở thông dụng được sử dụng để tiến hành mẫu này rất thuận tiện như Hystrix của Netflix hoặc Reselience4J .Nếu bạn đang sử dụng API Gateway hoặc Sidecar proxy như Envoy thì cũng hoàn toàn có thể đạt được điều tựa như ở cấp proxy .
Lưu ý: Một điều rất quan trọng là phải ghi log đầy đủ và cảnh báo ngay khi Circuit Breaker được kích hoạt để theo dõi các yêu cầu nhận được trong thời gian này và nhóm vận hành biết về điều này.
Khi nào nên sử dụng mẫu này
- Khi một dịch vụ phụ thuộc vào một dịch vụ từ xa khác và nó có khả năng bị lỗi trong một số trường hợp.
- Khi một dịch vụ có mức độ phụ thuộc rất cao (ví dụ: dịch vụ dữ liệu chính).
Khi nào không nên sử dụng mẫu này
- Khi bạn đang xử lý các phần phụ thuộc cục bộ – Circuit Breaker có thể tạo thêm chi phí.
Command and Query Responsibility (CQRS)
CQRS là một design pattern rất hữu dụng cho những ứng dụng hiện đại liên quan đến việc sử dụng những kho tài liệu. Nó dựa trên nguyên tắc tách biệt những hoạt động giải trí đọc ( Query ) và ghi / update ( Command ) trong một kho tài liệu .Giả sử bạn đang kiến thiết xây dựng một ứng dụng nhu yếu bạn tàng trữ tài liệu trong cơ sở tài liệu như MySQL / PostgreSQL, v.v. Như mọi người đều biết, khi ghi tài liệu vào kho tài liệu, một hoạt động giải trí cần thực thi 1 số ít bước – như xác nhận, quy mô và tàng trữ – và do đó những thao tác ghi / update mất nhiều thời hạn hơn những thao tác đọc đơn thuần .Khi bạn đang sử dụng một cơ sở tài liệu duy nhất để thực thi cả thao tác đọc và ghi cùng một lúc và ở quy mô lớn, thì bạn hoàn toàn có thể khởi đầu thấy những yếu tố về hiệu suất .Trong những trường hợp như vậy, mẫu CQRS hoàn toàn có thể hữu dụng. Mẫu CQRS đề xuất kiến nghị sử dụng những quy mô tài liệu khác nhau cho những hoạt động giải trí đọc và ghi. Một số biến thể cũng yêu cầu sử dụng kho tài liệu riêng không liên quan gì đến nhau cho những quy mô này .
Nhiều cơ sở tài liệu doanh nghiệp cũng phân phối năng lực này nếu bạn đang giải quyết và xử lý cơ sở tài liệu tại chỗ .
Lưu ý: Ngày nay, một số lập trình viên thích sử dụng cơ sở dữ liệu NoSQL nhanh và hiệu quả như MongoDB và Elasticsearch để làm database đọc.
Tham khảo thêm về CQRS ở bài viết này:
Khi nào nên sử dụng mẫu này
- Khi bạn đang xem xét việc mở rộng một ứng dụng có số lượng các thao tác đọc và ghi rất lớn.
- Khi bạn muốn điều chỉnh hiệu suất của các thao tác đọc và ghi riêng biệt.
- Khi bạn chấp nhận thao tác đọc gần như thời gian thực hoặc tính nhất quán sau cùng.
Khi nào không nên sử dụng mẫu này
- Khi bạn đang xây dựng một ứng dụng CRUD thông thường không có lượng lớn các lần đọc và ghi cùng một lúc.
Event Sourcing
Event Sourcing là một mẫu phong cách thiết kế mê hoặc trong đó một chuỗi những sự kiện miền được tàng trữ dưới dạng nhật ký và khi duyệt qua tập hợp những nhật ký này sẽ cho biết trạng thái hiện tại của ứng dụng .Mẫu này thường được sử dụng cho những mạng lưới hệ thống không có năng lực khóa tàng trữ tài liệu và cần duy trì việc kiểm tra và lịch sử vẻ vang của những sự kiện – ví dụ : những ứng dụng đặt phòng khách sạn / hội nghị / chỗ ngồi .
Xem xét một mạng lưới hệ thống đặt phòng khách sạn trong đó người dùng dự kiến sẽ đặt hoặc hủy đặt phòng. Tại đây, bạn cần tàng trữ những lượt đặt và lượt hủy dưới dạng một chuỗi những sự kiện. Trước mỗi lượt đặt phòng, duyệt qua tập hợp những nhật ký sẽ hiển thị những phòng trống .
Lưu ý: Hầu hết các nhà cung cấp dịch vụ đám mây đều hỗ trợ các dịch vụ nhắn tin như Google Pub / Sub, Azure Service Bus, AWS SQS, v.v. Những dịch vụ này, kết hợp với kho dữ liệu nhất quán mạnh, có thể được sử dụng để triển khai mẫu này.
Khi nào nên sử dụng mẫu này
- Khi hoạt động CRUD thông thường không đủ tốt để đáp ứng nhu cầu.
- Thường phù hợp với các hệ thống đặt chỗ – như xe buýt, xe lửa, hội nghị, phòng chiếu phim, v.v. – hoặc hệ thống thương mại điện tử bao gồm các sự kiện như hoạt động giỏ hàng, thanh toán, v.v.
- Khi có yêu cầu kiểm tra mạnh mẽ và phát lại các sự kiện để tạo trạng thái hiện tại và quá khứ của ứng dụng.
Khi nào không nên sử dụng mẫu này
- Khi thao tác CRUD đủ tốt để đáp ứng nhu cầu của người dùng.
Sidecar
Các mẫu Sidecar trở nên thông dụng với sự trỗi dậy của microservices. Trong mẫu này, bạn tiến hành một thành phần của ứng dụng vào một quá trình hoặc một vùng chứa riêng không liên quan gì đến nhau. Điều này giúp đạt được sự trừu tượng và đóng gói .Envoy Proxy là một trong những proxy sidecar thông dụng nhất và được sử dụng thoáng đãng. Nó giúp bạn tách biệt tính năng cốt lõi của ứng dụng, sử dụng sidecar để tách biệt những tính năng chung như mạng, năng lực quan sát và bảo mật thông tin .
Loại sidecar như vậy hoàn toàn có thể giúp kiểu tiếp xúc trừu tượng L4 / L7. Sidecar như Envoy Proxy thậm chí còn còn giúp đạt được tính bảo mật thông tin cao hơn bằng cách tiến hành TLS lẫn nhau .Bạn hoàn toàn có thể sử dụng điều này tích hợp với lưới dịch vụ ( service mesh ) để đạt được tiếp xúc và bảo mật thông tin tốt hơn giữa những microservices khác nhau .
Khi nào nên sử dụng mẫu này
- Khi bạn xử lý nhiều microservices và không đồng nhất trong phạm vi sản phẩm.
- Khi bạn đang xử lý các ứng dụng cũ thường không đủ khả năng đối phó với các thách thức bảo mật và giao tiếp thời đại mới.
Khi nào không nên sử dụng mẫu này
- Khi bạn đang xử lý một số dịch vụ hạn chế cần giao tiếp với nhau.
- Các ứng dụng nhỏ trong đó triển khai sidecar có thể không kinh tế hoặc không thân thiện với hoạt động.
Backend-for-Frontend (BFF)
Trong một chu kỳ luân hồi tăng trưởng mẫu sản phẩm nổi bật, những kỹ sư backend chịu nghĩa vụ và trách nhiệm tạo ra những dịch vụ tương tác với những kho tài liệu và những kỹ sư frontend sẽ đảm nhiệm việc kiến thiết xây dựng giao diện người dùng. Ngày nay, những ứng dụng cần được thiết kế xây dựng để quan tâm đến việc sử dụng thiết bị di động cũng như máy tính để bàn .Mặc dù khoảng cách giữa thiết bị di động và máy tính để bàn về mặt phần cứng ngày càng gần, nhưng liên kết và sử dụng vẫn liên tục là thử thách so với những thiết bị di động .Trong những trường hợp như vậy, những mẫu BFF trở nên khá tiện lợi. Tại đây, bạn dự kiến sẽ thiết kế xây dựng / tùy chỉnh những dịch vụ backend cho giao diện người dùng đơn cử .
Để tối ưu hóa hiệu suất của máy khách di động, bạn hoàn toàn có thể muốn kiến thiết xây dựng một dịch vụ back-end riêng không liên quan gì đến nhau phân phối những phản hồi nhẹ và được phân trang .Bạn cũng hoàn toàn có thể muốn sử dụng mẫu này để tổng hợp những dịch vụ khác nhau nhằm mục đích giảm bớt tiếp xúc .
Lưu ý: Ngày nay nếu bạn đang sử dụng API Gateway, mẫu BFF có thể được triển khai dễ dàng trong chính API Gateway đó và bạn không cần phải duy trì các dịch vụ riêng biệt.
Khi nào nên sử dụng mẫu này
- Khi bạn muốn cung cấp một sản phẩm / dịch vụ cho các loại client khác nhau như máy tính để bàn và thiết bị di động.
- Khi bạn muốn tối ưu hóa phản hồi cho một loại client cụ thể.
- Khi bạn muốn giảm giao tiếp giữa các client di động và các dịch vụ khác.
Khi nào không sử dụng mẫu này
- Khi người dùng ứng dụng được mong đợi sử dụng một giao diện người dùng
- Khi các ứng dụng dành cho thiết bị di động và máy tính để bàn sẽ hiển thị thông tin tương tự và cung cấp chức năng tương tự
Strangler
Nếu bạn đang thao tác trong một tổ chức triển khai đang trên hành trình dài hướng tới hiện đại hóa ứng dụng, thì mẫu phong cách thiết kế Strangler là bắt buộc. Mẫu phong cách thiết kế Strangler ủng hộ việc tạo ra một mặt tiền trên di sản của bạn và một ứng dụng mới, cung ứng một cái nhìn trừu tượng cho người tiêu dùng .
Mô hình này tách người tiêu dùng khỏi các hoạt động di chuyển.
Lưu ý: Trong một tổ chức CNTT điển hình, nếu bạn đang chuyển từ ERP này sang ERP khác, design pattern này cực kỳ hữu ích. Nếu bạn đang sử dụng API Gateway, việc triển khai điều này thậm chí còn dễ dàng hơn.
Bạn cần quyết định hành động xem bạn muốn giữ mặt tiền khi kết thúc quy trình chuyển dời hay vô hiệu nó .
Khi nào nên sử dụng mẫu này
- Khi bạn đang di chuyển hoặc hiện đại hóa một ứng dụng phức tạp, phụ thuộc nhiều như di chuyển ERP.
Khi nào không nên sử dụng mẫu này
- Khi việc di chuyển đơn giản và thay thế trực tiếp là một lựa chọn tốt hơn.
Nếu Comdy hữu ích và giúp bạn tiết kiệm thời gian làm việc
Bạn hoàn toàn có thể vui mắt đưa Comdy vào whitelist của trình chặn quảng cáo ❤ ️ để tương hỗ chúng tôi trong việc trả tiền cho dịch vụ tàng trữ web để duy trì hoạt động giải trí của website .
