Lời nói đầu

Trước đây tôi đã viết một bài ghi lại những vụ tai nạn trong môi trường sản xuất và nhận được rất nhiều lời khen ngợi.

Sau đó, nhóm của chúng tôi đã có một số cuộc thảo luận để hỗ trợ vận hành và bảo trì, chúng tôi đã xây dựng nền tảng ghi nhật ký Granfa+Loki tốt hơn và cũng giới thiệu SkyWalking để theo dõi liên kết.

Nhưng tôi cũng gặp phải một số vấn đề trong quá trình này, tôi sẽ mô tả chúng ở bên dưới và sau đó chia sẻ mẹo đơn giản này. Tôi hy vọng nó sẽ hữu ích cho mọi người.

Nếu bạn không có thời gian để đọc nó ngay bây giờ, bạn có thể lưu nó trước và đọc chậm khi có thời gian. Nếu sau này bạn gặp phải tình huống tương tự, bạn có thể lấy nó ra và sao chép.

khó khăn

Như đã đề cập trước đó, nhóm chúng tôi đã xây dựng nền tảng log và theo dõi liên kết nhưng thực tế nó cũng mang lại một số khó khăn như sau:

1) Đối với các doanh nghiệp vừa và nhỏ, việc thiết lập một nền tảng như vậy đòi hỏi một số nguồn lực nhất định (tốn tiền) và những hạn chế về nguồn lực thường xảy ra trong thời gian bảo trì dự án, điều này làm tăng chi phí bảo trì do bạn không kiểm soát được chi phí. tay của ông chủ;

2) Đối với các thành viên trong nhóm, họ phải có khả năng nhất định để làm quen và sử dụng nền tảng đó cũng như thành thạo một số lệnh thường dùng. Tuy nhiên, các doanh nghiệp vừa và nhỏ có tỷ lệ luân chuyển nhân sự khá thường xuyên và không phải thành viên nào cũng tham gia công việc. có thể bắt đầu, điều này làm tăng khối lượng công việc một cách vô hình;

3) Trong quá trình khắc phục sự cố trực tuyến thì thuận tiện hơn rất nhiều nhưng cũng rắc rối hơn rất nhiều vì có những nền tảng có thể trực tiếp xác định vấn đề, nhưng lại rắc rối vì ngày càng có nhiều nền tảng, và một số thành viên nói rằng họ cảm thấy chóng mặt vì có quá nhiều địa chỉ (cười)).

Tóm lại, xem xét quy mô và khả năng kinh tế của công ty chúng tôi, nhóm chúng tôi cuối cùng đã quyết định sử dụng phương pháp đơn giản nhất để xác định vấn đề tốn thời gian của giao diện, đó là Spring AOP cắt giao diện của bên thứ ba để hoàn thành thời gian- tiêu thụ số liệu thống kê.

Tác dụng

Đầu tiên, hãy hiển thị hiệu ứng cuối cùng trực tuyến để mọi người có thể hiểu nhanh chóng.

Dự án của chúng tôi sử dụng microservices + K8s. Hình dưới đây là một nền tảng được Granfa + Loki xây dựng để thu thập nhật ký k8s. Việc tìm kiếm thông qua từ khóa có thể xác định trực tiếp tình trạng tốn thời gian khi gọi các giao diện của bên thứ ba.

Kịch bản mô phỏng

Hãy mô phỏng kịch bản và triển khai khía cạnh AOP để tính mức tiêu thụ thời gian của giao diện bên thứ ba.

1. Mô phỏng việc tạo hồ sơ người dùng

Lớp thực thể.

Sử dụng bản đồ để mô phỏng việc lưu trữ người dùng, thu thập người dùng và xóa người dùng.

2. Mô phỏng giao diện của bên thứ ba

Ở đây, chúng tôi chỉ đơn giản sử dụng chế độ ngủ luồng để mô phỏng việc gọi các giao diện của bên thứ ba tốn nhiều thời gian, giả vờ rằng một số giao diện tương ứng tiêu tốn rất nhiều thời gian.

3. dịch vụ phục vụ

4. dịch vụ điều khiển

5. Kiểm tra giao diện

Được, không vấn đề gì.

6. Phần AOP

Giới thiệu sự phụ thuộc.

Viết các lớp khía cạnh, đây là một lời giải thích ngắn gọn, chủ yếu làm rõ một số điểm.

1). Khía cạnh Pointcut sẽ trỏ đến lớp được gọi bởi giao diện của bên thứ ba, đó là RemoteClient trong trường hợp này;

2) Sử dụng các khía cạnh xung quanh, trong đó tên phương thức là từ khóa để truy xuất trực tuyến vị trí nhật ký sau này;

3) Sử dụng trực tiếp StopWatch để tính thời gian, loại bỏ nhu cầu giới thiệu các phụ thuộc khác;

4) JointPoint.proceed() được bao bọc trong các phương thức bắt đầu và dừng của StopWatch là hoạt động thực thi của giao diện bên thứ ba, để StopWatch có thể tính toán mức tiêu thụ thời gian của phương thức này;

5) Việc in nhật ký ở cuối cũng rất quan trọng. Bạn có thể tham khảo ví dụ của tôi và in ra tên lớp và phương thức () để truy xuất sau này. Đồng thời, tốt nhất nên sử dụng đơn vị ms cho thời gian. tiêu thụ, để nó có thể rõ ràng trong nháy mắt.

7. Hiệu ứng

Chúng tôi thực hiện thủ công một số giao diện trong kịch bản mô phỏng để quan sát quá trình in nhật ký.

Như bạn có thể thấy, mức tiêu thụ thời gian tương ứng với phương pháp đã được tính toán.

Bằng cách này, nhật ký của k8s cuối cùng sẽ được nền tảng nhật ký thu thập như thế này và cuối cùng chúng tôi có thể xác định trạng thái tốn thời gian của tất cả các giao diện bên thứ ba cùng một lúc thông qua tìm kiếm từ khóa.

Cuối cùng, tôi đưa ra nhật ký về thời gian chờ giao diện của bên thứ ba mà chúng tôi đặt trong một môi trường sản xuất nhất định để mọi người xem. Chính loại thống kê này đã giúp chúng tôi xác định các vấn đề về giao diện của các nhà sản xuất khác. Trước đây, họ luôn phàn nàn. vấn đề của chúng tôi. Họ đã chụp ảnh màn hình này để khiến họ cúi đầu thừa nhận tội lỗi và sau đó họ đã khắc phục vấn đề.

Đây là lệnh chúng tôi sử dụng trong Granfa để định vị trực tiếp giao diện của bên thứ ba dựa trên tên lớp và tên phương thức.

Đây là số liệu thống kê được lấy ra mà giao diện của họ luôn hết thời gian chờ trong một khoảng thời gian nhất định và cũng là bằng chứng cuối cùng được gửi cho họ.

Tóm tắt

Cuối cùng mình sẽ tóm tắt lại lợi ích của phương pháp này nếu đồng nghiệp của mình cũng gặp trường hợp tương tự như công ty mình thì có thể tham khảo.

1) Nó tiết kiệm chi phí bảo trì. Không cần phải xây dựng thêm phần mềm trung gian hoặc cơ sở hạ tầng để định vị. Nói chung, họ vẫn quen với việc xác định các vấn đề thông qua nhật ký. nền tảng theo dõi Việc thiết lập rất đơn giản, nhưng trong quá trình sử dụng, rõ ràng chúng tôi nhận thấy rằng nó sẽ gây ra những hạn chế về tài nguyên và yêu cầu bảo trì thường xuyên. Chi phí này sẽ tăng dần theo thời gian;

2) Các thành viên trong nhóm không cần phải học thêm các kỹ năng, đặc biệt là trong nhóm ngành Internet có nhịp độ phát triển nhanh chóng này, nơi nhân sự thay đổi thường xuyên là một vấn đề tốn nhiều công sức và thường chỉ do một người nắm vững. , anh lại thay đổi công việc và phải làm lại từ đầu cho công ty;

3) Nền tảng trở nên phức tạp không phải là điều tốt. Chỉ cần địa chỉ môi trường có thể tích lũy nhiều Excel. Một nhóm nhỏ vẫn thích cách giải quyết vấn đề đơn giản nhất sau khi xem xét toàn diện, nhân lực hoàn toàn có thể thay thế nền tảng. thực ra tôi thích những nhân viên như thế này).

Ngoài ra, đề cập một chút, phương pháp này có thể áp dụng cho cả kiến ​​trúc đơn lẻ và kiến ​​trúc phân tán. Tuy nhiên, một điều cần lưu ý về kiến ​​trúc phân tán là tốt nhất các dịch vụ của bên thứ ba phải độc lập, để bạn có thể sử dụng các khía cạnh AOP. đã được cấu hình hoàn hảo, nếu không bạn cần phải giới thiệu nó cho từng dịch vụ.

tái bút

Mã nguồn sẽ được chia sẻ trong phần bình luận. Nếu quan tâm, bạn có thể tải xuống và tự mình dùng thử. Nó cũng chứa cấu hình logback do tôi biên soạn, bao gồm cấu hình nhật ký màu và nhận xét chi tiết cho từng cấu hình. của mã là dòng Mã đã chạy hơn nửa năm có thể được sử dụng trực tiếp. Bạn chỉ cần sửa đổi cách trỏ khía cạnh của mình và in nhật ký tên lớp và tên phương thức.

---

Bài viết gốc được gõ bằng tay, từng chữ một, bàn phím dính đầy máu. Nếu thấy hữu ích, vui lòng cho tôi một đề xuất ~.

Tôi cam kết chia sẻ kinh nghiệm làm việc và những điều thú vị của mình. Nếu bạn thích, bạn có thể theo dõi trên trang chủ ~.

Cuối cùng, bài viết này nói về việc ngừng đổ lỗi! Thủ thuật nhỏ để tính thời gian tiêu thụ của giao diện bên thứ ba này là một bài viết rất thoải mái. Nếu bạn muốn biết thêm về nó, đừng trách móc nữa! Thủ thuật nhỏ này tính thời gian sử dụng của giao diện bên thứ ba và rất tiện lợi. Vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .