Bài viết đầu tiên trong loạt 7 phần về xây đắp, sản xuất với xúc tiến những các dịch vụ bé dại (microservices) sẽ trình làng về quy mô phong cách thiết kế Microservice. Bài viết đang bàn về các lợi ích và tinh giảm Lúc thực hiện microservices với làm phương pháp nào vượt qua được sự phức hợp của microservices, nhằm nó biến đổi một sự chọn lọc lý tưởng phát minh cho những ứng dụng phức hợp.

Bạn đang xem: Api gateway là gì

khi bạn chọn lựa việc phát hành vận dụng dựa trên tập hòa hợp các các dịch vụ nhỏ, bạn phải ra quyết định giải pháp những Client (website client, Mobile client...) của áp dụng đó địa chỉ cùng với những microservice. Với một áp dụng đối kháng kăn năn (monolithic - hay đã có được nhân phiên bản ra nhiều địa điểm cùng cân bằng tải) thì những Client chỉ đối chọi thuần là tập phù hợp những thiết bị đầu cuối. Tuy nhiên, vào phong cách xây dựng microservices, mỗi microservice đã can dự với 1 tập vừa lòng các thứ đầu cuối được phân phân bổ một bí quyết sắc sảo (fine-grained). Bài viết này đang chu đáo phương thức Client cùng ứng dụng liên tưởng cùng nhau, trường đoản cú đó đề xuất biện pháp tiếp cận thực hiện API Gateway.

Giới thiệu

Hãy tưởng tượng nhiều người đang cải tiến và phát triển một ứng dụng chạy trên thiết bị di động (Smartphone client) cho hệ thống mua sắm trực đường. Và hết sức hoàn toàn có thể bạn cần làm một trang đọc tin cho thành phầm, hiển thị thông báo cụ thể về bất kỳ các loại sản phẩm làm sao được cung ứng.

Để rước ví dụ, sơ đồ gia dụng dưới đây diễn tả đông đảo gì các bạn sẽ bắt gặp khi dịch rời trên màn hình hiển thị công bố cụ thể của thành phầm trên áp dụng di động cầm tay của Amazon trên nền Android


*
Ứng dụng cầm tay Amazon

Mặc dù là một vận dụng cầm tay, trang thông tin thành phầm lại hiển thị không hề ít báo cáo. Ví dụ trên không chỉ gồm các lên tiếng cơ phiên bản của sản phẩm (tên gọi, biểu hiện và giá cả) nhưng nó còn hiển thị:

Số lượng món đồ trong giỏ.Lịch sử deals.Phản hồi từ khách hàng.Chình họa báo lúc sắp đến không còn hàng.Các tùy chọn Lúc vận chuyểnMột loạt gợi ý mua hàng bao hàm các mặt hàng hay được cài đặt kèm cùng với món đồ vẫn coi, những sản phẩm không giống được cài bởi vì quý khách hàng sẽ cài sản phẩm này, cùng những món đồ không giống được xem như vì chưng người tiêu dùng đang cài đặt sản phẩm.Các tùy lựa chọn tkhô nóng toán.

Lúc sử dụng kiến trúc khối hận nhất quán (monolithic), vận dụng di động cầm tay (thiết bị di động client) vẫn nhấn những tài liệu này bằng phương pháp gọi tuyệt nhất một trải đời qua REST (GET api.company.com/productdetails/productId) mang đến ứng dụng. Cân bằng thiết lập sẽ chuyển trải nghiệm này tới 1 trong vô số nhiều phiên bản sao của áp dụng. Sau kia ứng dụng truy nã vấn vào các bảng đại lý tài liệu không giống nhau và trả về ý kiến mang lại Client.

Trái lại, khi sử dụng phong cách xây dựng Microservice, tài liệu hiện trên trang mua sắm chọn lựa nằm trong về tương đối nhiều hình thức nhỏ khác biệt. Dưới đấy là một vài ba microservice tải các dữ liệu được hiển thị trên bảng ban bố cụ thể sản phẩm & hàng hóa nlỗi ví dụ:

Thương Mại & Dịch Vụ giỏ mặt hàng – Số lượng món đồ vào giỏ.Thương Mại Dịch Vụ đặt hàng – Lịch sử giao dịch.Dịch Vụ Thương Mại tổng kê (catalog) – tin tức cơ bản của món đồ, ví như thương hiệu sản phẩm, hình hình ảnh cùng túi tiền.Dịch Vụ Thương Mại reviews – Phản hồi tự khách hàng.Dịch vụ kho sản phẩm – Cảnh báo Lúc sắp đến không còn hàng.Thương Mại Dịch Vụ chuyên chở – Hình thức vận tải, hạn gửi, cùng những ngân sách sẽ được tính cá biệt trường đoản cú API của các đơn vị cung ứng hình thức chuyên chở.Thương Mại & Dịch Vụ khuyến cáo – Các thành phầm được khuyến nghị.

*

Để ra quyết định xem Smartphone client của họ làm cho cố gắng như thế nào để truy cập được tới các các dịch vụ trên, họ hãy xem những chọn lựa hoàn toàn có thể sau đây.

Giao tiếp thẳng trường đoản cú Client tới Microservice

Trên triết lý, mỗi Client rất có thể thẳng giới thiệu những đề nghị tới một trong các microservice. Mỗi một microservice thường sẽ có một điểm truy vấn đầu cuối công khai ( https://serviceName.api.company.name). Đường dẫn này vẫn chỉ đến cỗ cân đối cài đặt của microservice, bao gồm trọng trách phân phối hận những lệnh tận hưởng tới những bạn dạng sao đã nhàn rỗi của microservice. Để nhận thêm những thông tin về thành phầm, điện thoại client sẽ nên gửi yêu cầu cho tới từng hình thức được liệt kê sinh hoạt trên.

Không may, phương thức này vẫn còn đó các giảm bớt với trở ngại. Một trong các đó là tính ko đồng điệu thân nhu yếu của Client và những API phân tán được hỗ trợ bởi vì từng microservice. Client vào ví dụ bên trên nên gửi mang đến 7 thưởng thức riêng lẻ. Trong phần lớn ứng dụng phức hợp rộng có thể phải gửi nhiều hơn thế nữa. ví dụ như buổi giao lưu của Amazon diễn tả hàng trăm ngàn dịch vụ khác nhau thuộc tsi gia việc hiển thị trang thông tin mua hàng. Trong lúc 1 Client hoàn toàn có thể dễ dãi gửi hưởng thụ trải qua mạng LAN, thì bài toán này có thể ko kết quả nếu tiến hành qua mạng Internet nơi công cộng, thậm khí là cực kỳ khó khăn ví như triển khai qua mạng di động cầm tay. Cách tiếp cận này để cho Code của Client trsống đề xuất tinh vi hơn.

Một vụ việc là khi Client Call trực tiếp tới những microservice mà lại trong các kia áp dụng các giao thức ko thân mật và gần gũi với Web. Dịch vụ này hoàn toàn có thể thực hiện giao thức Thrift binary RPC (một giao thức được Apabịt đề xướng) trong những khi hình thức khác thực hiện giao thức tin nhắn AMQP (Một dạng Message Queue phổ cập hiện nay này). Không giao thức như thế nào vào nhị ví dụ trên là đơn thuần về website hoặc thân thiết cùng với tưởng lửa với thực hiện giỏi vào nội trên của chính nó. Bên xung quanh phạm vi tường lửa, một áp dụng tốt cần thực hiện những giao thức nhỏng HTTP.. và WebSocket.

Nhược điểm khác của giải pháp tiếp cận này là sự trở ngại trong Việc tái kết cấu (refactor) những Microservice. Theo thời gian, chúng ta đang muốn thay đổi biện pháp khối hệ thống phân chia các dịch vụ. Ta rất có thể vừa lòng nhất nhì hình thức dịch vụ hoặc phân loại một hình thức dịch vụ thành hai hoặc nhiều hình thức nhỏ dại rộng. Nếu Client tiếp xúc trực tiếp với những hình thức dịch vụ thì bài toán tiến hành tái cấu tạo có thể khôn cùng trở ngại.

Những sự việc được liệt kê trên làm cho vấn đề tiếp xúc trực tiếp Client và những microservice không được tác dụng.

Học viên được tham mê gia lập trình cùng giảng viên tuy nhiên tuy nhiên với lịch trình học tập Flip Learning. Như vậy chỉ bao gồm sinh hoạt hjwitteveen.com. Cam kết bài toán làm xây dựng cho học tập viên thực tập toàn thời hạn 6-12 tháng

Sử dụng cổng kết nối API (API Gateway)

Cổng kết nối API là phương pháp tiếp cận xuất sắc hơn rất nhiều. Một cổng kết nối API là một máy chủ tầm nã xuất độc nhất vào khối hệ thống. Nó tương tự như như mẫu thiết kế Facade dựa trên xây cất phía đối tượng người sử dụng. Cổng liên kết API bịt giấu đi công bố phong cách xây dựng hệ thống nội bộ với nó hỗ trợ các API tùy chỉnh thiết lập cho mỗi Client. Cổng liên kết API còn có trách nát nhiệm chính xác, giám sát, thăng bằng cài đặt, caching, định hình từng trải với quản lí thông tin, cập nhật phản hồi tĩnh.

Sơ vật dụng minh họa sau đây cho thấy thêm một API Gateway cân xứng trong phong cách xây dựng ứng dụng.


*
API Gateway

Cổng kết nối API có tác dụng nhiệmvụ định con đường các tận hưởng, phối hợp cùng biến hóa các giao thức. Tất cả thử khám phá từ Client gần như đi qua cổng liên kết API. Sau đó cổng liên kết API định tuyến các kinh nghiệm này cho tới microservice cân xứng. Cổng liên kết API Gateway đã xử trí một tận hưởng người dùngbằng cách Hotline đến hàng loạt microservice rồi tổng hòa hợp các công dụng. Nó hoàn toàn có thể biến hóa thân các giao thức web nhỏng HTTPhường, WebSocket cùng những giao thức nội cỗ ko thân thiện với website.

Cổng kết nối API cũng có thể cung cấp API thiết lập cho từng Client. Nó cung ứng API “thô” (coarse-grained) cho Mobile client. Cùng để ý lại ví dụ về kịch bạn dạng trang công bố cụ thể sản phẩm. Cổng kết nối API hoàn toàn có thể cung cấp liên kết cuối (/productdetails?productid=xxx) chất nhận được thiết bị di động client dìm tất cả thông báo chi tiết của sản phẩm chưa đến một lệnh hưởng thụ tốt nhất. Cổng liên kết API up load lệnh kinh nghiệm bằng cách tróc nã vấn đến các hình thức khác nhau như hình thức công bố thành phầm, các dịch vụ đề xuất, các dịch vụ tiến công giá… rồi tiếp nối tổng hợp lại kết quả.

Cổng liên kết API của Netflix (trang cung ứng Video trực tuyến) là ví dụ điển hình nổi bật. Dịch vụ streaming của Netflix xuất hiện trên hàng trăm ngàn các mô hình thiết bị không giống nhau như TV, Smart-box, điện thoại cảm ứng lý tưởng, khối hệ thống chơi trò chơi, laptop bảng, v.v… Ngay trường đoản cú thuở đầu, tham vọng của Netflix là hỗ trợ một API đa nền tảng gốc rễ (one size fits all) mang lại hình thức streaming. Netflix phân biệt phát minh của họ hoạt động ko kết quả bởi sự phong phú những lắp thêm cùng tham vọng độc nhất của mình. Ngày ni, Netflix sử dụng một cổng kết nối API cung ứng API thiết lập cấu hình (API tailored) cùng với những trang bị không giống nhau bằng phương pháp chạy các đoạn Code cân xứng cùng với từng cỗ đổi khác sản phẩm (device adapter). Bộ biến hóa xử lý các lệnh đề nghị bằng cách truy tìm vấn từ bỏ sáu đến bảy các dịch vụ “back-end”. Hàng ngày cổng giao tiếp API của Netflix cách xử trí cho sản phẩm tỉ hưởng thụ.

Xem thêm: Đau Thần Kinh Tọa ( Sciatica Là Gì ? Nguyên Nhân, Triệu Chứng Và Cách Điều Trị

*

Lợi ích với điểm yếu kém của cổng liên kết API (API Gateway)

Việc thực hiện cổng kết nối API hữu dụng ích với điểm yếu kém riêng biệt. Ích lợi Khủng nhất khi thực hiện cổng kết nối API là nó bít lốt đi cấu tạo bên trong của ứng dụng. Txuất xắc vì truy nã vấn cho những hình thức dịch vụ cụ thể, người tiêu dùng đơn giản là giao tiếp cùng với cổng kết nối. Cổng kết nối API hỗ trợ API tương xứng với từng Client. Việc làm này giảm thiểu con số điều đình (round trips) giữa Client với vận dụng, buổi tối giản hóa mã mối cung cấp phía Client.

Cổng liên kết API cũng đều có một vài điểm yếu. Nó là 1 trong số nhân tố cần thiết rất cần phải được cải cách và phát triển, triển khai cùng cai quản. Rủi ro không giống là cổng kết nối API phát triển thành nút thắt cổ cnhị khi cải cách và phát triển khối hệ thống (bottle-neck). Các Developer rất cần phải cập nhập cổng kết nối API để cung ứng cho các liên kết đầu cuối của microservice. Việc bảo đảm an toàn tiến trình cập nhập cổng liên kết API với dung tích nhẹ duy nhất có thể khôn xiết quan trọng. Nếu ko thì Developer sẽ yêu cầu chờ mang đến lượt bắt đầu được cập nhập. Mặc dù là nhược điểm, mà lại số đông các ứng dụng thực tế thực hiện cổng kết nối API.

Triển khai một cổng liên kết API

Sau khi đã nhìn qua nguyên nhân, ưu điểm cùng yếu hèn (trade-off) lúc thực hiện cổng liên kết API, hãy thuộc để ý hầu như vấn đề xây dựng API nhưng mà chúng ta nên quan tâm đến.

Hiệu năng và kĩ năng mở rộng.

Chỉ một lượng bé dại các đơn vị bao gồm trung bình cỡ nhỏng Netflix new yêu cầu cập nhật mang lại hàng tỉ yên cầu hàng ngày. Tuy thế, với những vận dụng, tính năng với khả năng không ngừng mở rộng của cổng kết nối API thường khôn xiết đặc trưng. Vì vậy, vấn đề này hoàn toàn phù hợp cùng với việc phát hành cổng liên kết API trên một gốc rễ cung cấp up load bất đồng điệu và chính sách non-blocking I/O. Có không hề ít những công nghệ không giống nhau được thực hiện nhằm tiến hành không ngừng mở rộng cổng liên kết API. Trong JVM (Java Virtual Machine) chúng ta cũng có thể sử dụng các Framework dựa vào phép tắc NIO (Non-blocking IO) nlỗi Netty, Vertx, Spring Reactor hoặc Jboss Undertow. Một chọn lựa thịnh hành ko cần sử dụng đến JVM là Node.js, nền tảng gốc rễ tạo ra trên Chrome’s JavaScript engine (V8 Engine). Lựa lựa chọn khác, bạn cũng có thể cần sử dụng NGINX Plus. (Một phút ít quảng cáo: NGINX Plus cung cấp khối hệ thống website VPS cùng proxy triển khai xong, có công dụng không ngừng mở rộng, tính năng cao, thuận tiện xúc tiến, tùy phát triển thành cùng xây dựng. Công nghệ này quản lí lí tính đúng đắn, truy vấn tinh chỉnh và điều khiển, cân bằng thiết lập lệnh thử dùng, đánh giá đệm và cung cấp hình thức dịch vụ giám sát và đo lường ứng dụng).

Sử dụng quy mô thiết kế liên can.

Cổng liên kết API giải pháp xử lý một số đòi hỏi bằng cách định tuyến (routing) chúng đến hình thức back-over tương thích. Nó xử trí các kinh nghiệm sót lại bằng cách truy vấn đến một loạt những các dịch vụ back-kết thúc cùng tổng phù hợp lại kết quả. Với một số trong những hưởng thụ, nlỗi lệnh yên cầu về chi tiết sản phẩm, các tận hưởng cho những hình thức dịch vụ back–kết thúc trọn vẹn độc lập cùng nhau. Để sút tđọc thời gian đánh giá, cổng kết nối API phải triển khai những những hiểu biết hòa bình vào và một thời gian. Thông thường, gồm các thử dùng lại dựa vào với nhau. Cổng kết nối API thứ nhất cần phải thanh tra rà soát đề xuất bằng cách call mang đến các hình thức xác thực trước khi định tuyến đường bọn chúng đến dịch vụ back–end. Tương từ, để lấy ban bố về sản phẩm vào list mong muốn của doanh nghiệp, cổng liên kết API trước tiên bắt buộc cảm nhận làm hồ sơ người tiêu dùng bao hàm đọc tin, với tiếp nối lấy lên tiếng của mỗi thành phầm. Một ví dụ thú vui về phân tán API là Netflix Video Grid.

Viết mã API yếu tố sử dụng các callbachồng bất đồng hóa truyền thống sẽ chuyển các bạn xuống âm ti. Mã mối cung cấp trsinh sống cần rối rắm, nặng nề gọi và thường xuyên gặp lỗi. Phương thức kết quả rộng là chúng ta viết mã nguồn cho cổng liên kết API dạng “Declarative sầu style” sử dụng thủ tục liên hệ. lấy một ví dụ về liên hệ trừu tượng với Scala thì gồm Future, Java8 bao gồm CompletableFuture, JavaScript có Promise (những lý lẽ up load bất đồng bộ). Hình như còn có technology Reactive sầu Extensions (có cách gọi khác là Rx hoặc ReactiveX), ban đầu được phát triển vì Microsoft mang đến nền tảng gốc rễ .NET. Netflix tiếp đến tạo thành RxJava mang đến JVM mục đích nhằm áp dụng đến cổng liên kết API của họ. Đồng thời còn có RxJS trên JavaScript, chạy được trên cả trình chú ý với Node.js. Áp dụng phương thức tác động sẽ giúp đỡ bạn viết được một cổng giao tiếp API đơn giản dễ dàng mà công dụng.

Truy vấn hình thức dịch vụ.

Một ứng dụng dựa trên gốc rễ microservices là 1 hệ thống phân tán và cần được áp dụng nguyên lý giao tiếp liên quy trình (inter-process communication mechanism). Có nhì phong cách giao tiếp liên quá trình. Lựa lựa chọn trước tiên áp dụng chế độ lập trình sẵn bất đồng nhất, dựa vào phép tắc truyền tin (messaging-based). Một số xúc tiến sử dụng những ứng dụng truyền tin trung gian (message broker) như JMS hoặc AMQP.. Số còn sót lại, ví như Zeromq thì chưa hẳn thực hiện trung gian mà lại tiếp xúc thẳng với các hình thức. Phong bí quyết khác của tiếp xúc liên quá trình là chính sách đồng bộ nhỏng HTTP hoặc Thrift. Một khối hệ thống thường xuyên sử dụng cả 2 phong thái lập trình đồng hóa cùng bất đồng bộ. Nó còn có thể thực thi theo khá nhiều phía cho từng phong thái. Do kia, cổng liên kết API đã nên cung ứng những nguyên tắc giao tiếp.

Phát hiện nay hình thức dịch vụ.

Cổng liên kết API cần phải biết địa chỉ (liên tưởng IP. và cổng) của từng microservice nhưng mà nó tiếp xúc. Với một ứng dụng truyền thống lâu đời, các bạn thường đề nghị thắt chặt và cố định các địa chỉ, cơ mà hiện giờ, với các microservice được xây cất dựa vào công nghệ năng lượng điện tân oán đám mây thì việc xác định vị trí các Microservice đổi thay một việc không hề dễ dàng và đơn giản. Với cơ sở hạ tầng hình thức dịch vụ như Khi sử dụng vận dụng truyền tin trung gian (message broker) với các vị trí được thắt chặt và cố định thì trọn vẹn hoàn toàn có thể chỉ ra rằng bởi các biến môi trường xung quanh của hệ điều hành quản lý. Tuy nhiên, xác định vị trí của các dịch vụ áp dụng thì ko đơn giản dễ dàng. Dịch vụ vận dụng được gán địa điểm động và địa chỉ bản sao của những dịch vụ cũng rất được biến đổi bởi vì năng lực trường đoản cú kiểm soát và điều chỉnh và tăng cấp. Do kia, một cổng kết nối API, cũng giống như bất kể hình thức Client làm sao vào khối hệ thống cũng phần lớn nên áp dụng qui định phân phát hiện tại các dịch vụ như: Server-Side Discovery hoặc Client-Side Discovery. Bài viết kì sau đang mô tả cụ thể về phát hiện hình thức. Lúc Này, bọn họ đồng ý rằng nếu như hệ thống thực hiện Client-Side Discovery thì cổng liên kết API buộc phải được tầm nã vấn cho Service Registry – cơ sở tài liệu đựng tất cả các diễn đạt (instances) của microservice và vị trí của bọn chúng.

Xử lý lỗi từng phần.

Một sự việc bạn cần để ý là vấn đề lỗi từng phần khi tiến hành một cổng kết nối API. Vấn đề này phát sinh vào toàn bộ các hệ thống phân tán mỗi một khi một hình thức Hotline mang lại một các dịch vụ không giống không hoạt động hoặc ý kiến khôn cùng chậm rì rì. Cổng liên kết API không lúc nào được ngăn vô thời hạn Khi mong chờ một hình thức dịch vụ downstream (bị mất kết nối). Tuy vậy, bí quyết up date lỗi phụ thuộc vào các thực trạng ví dụ như dịch vụ làm sao đã chạm chán sự việc. lấy một ví dụ, ví như dịch vụ lưu ý mua sắm không bình luận, cổng kết nối API buộc phải trả lại các quý hiếm còn lại của mặt hàng mang đến quý khách hàng Khi nó vẫn hữu dụng cho người sử dụng. Dịch vụ gợi ý mua sắm và chọn lựa có thể trống hoặc được thay thế bởi danh sách tốp 10 sản phẩm mắc mặt hàng. Tuy nhưng, trường hợp như hình thức dịch vụ về thông báo thành phầm nhưng ko đánh giá thì cổng liên kết API cần trả lại thông báo lỗi cho người tiêu dùng.

Cổng liên kết API đề xuất trả lại bộ nhớ lưu trữ đệm trường hợp nó có sẵn. lấy một ví dụ như túi tiền hàng hóa hiếm Khi chuyển đổi, cổng kết nối API rất có thể trả lại quý giá bộ nhớ đệm quý hiếm hàng hóa trong những khi Dịch Vụ Thương Mại Chi phí ko vận động. Dữ liệu hoàn toàn có thể lự lưu đệm bởi thiết yếu cổng liên kết API hoặc được lưu lại bên trên cỗ đệmkhông ngừng mở rộng nlỗi Redis hoặc Memcached. Bằng cách trả lại dữ liệu mặc định hoặc tài liệu đệm, cổng kết nối API bảo vệ rằng lỗi hệ thống sẽ không còn ảnh hưởng nhiều đến kinh nghiệm của người tiêu dùng.

Công nghệ Hystrix của Netflix là một trong những thư viện ấn tượng nhằm viết code gọi những hình thức từ bỏ xa. Hystrix lần ra mọi lệnh Gọi thừa quá ngưỡng cách thức. Nó tiến hành quy mô circuit breaker, góp cho tất cả những người dùng không thể đề xuất chờ đón có hại hồ hết dịch vụ ko ý kiến. Nếu tỉ lệ lỗi vào một các dịch vụ vượt quá ngưỡng lý lẽ, Hystrix đang đưa Circuit breaker với toàn bộ lệnh đòi hỏi vào thời gian nhất quyết đang không thắng cuộc tức thì nhanh chóng. Hystrix giúp cho bạn hiểu rõ về hành động dự trữ lúc một lệnh trải đời không thắng cuộc, ví như đọc tự cỗ đệm hoặc trả lại quý giá mang định. Nếu các bạn sử dụng JVM, chúng ta nên suy xét sử dụng Hystrix. Và nếu khách hàng sử dụng một môi trường không JVM, thì chúng ta nên cần sử dụng một tlỗi viện tương tự.

Tổng kết

Hoàn toàn phù hợp Khi tiến hành cổng liên kết API làm cho điểm kết nối duy nhất với khối hệ thống vận dụng bên trên căn nguyên microservices. Cổng liên kết API có trọng trách định tuyến đường tận hưởng, phân tán tài liệu cùng thay đổi giao thức, cung cấp cho mỗi Client một API thiết lập. Cổng kết nối API còn đậy giấu lỗi bên trên giải pháp các dịch vụ back–kết thúc bằng phương pháp trả về quý giá bộ nhớ đệm hoặc dữ liệu mang định. Bài viết kì cho tới, bọn họ đang nói đến cách tiến hành liên hệ thân những hình thức.

Người dịch: Phạm Đức Trung, lập trình viênJava - Java Spring tại hjwitteveen.comHiệu đính: Hoàng Giang Biển

Bài viết liên quan

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *