Như phần 1 mình đã đề cập, thì các phần tiếp theo mình sẽ chia sẻ các vấn đề mà bản thân mình gặp phải khi làm testing trong 1 hệ thống sử dụng kiến trúc Microservices, bạn nào chưa coi qua các phần trước có thể theo dõi lại ở danh sách kế bên
Bạn sẽ làm gì khi được tham gia 1 dự án với mô hình kiến trúc Microservices?
Một ngày đẹp trời bạn nhận được một lời đề nghị tham gia dự án mới để xây dựng sản phẩm thật là hoành tráng. Khi đó mọi người đều nói rằng sẽ áp dụng kiến trúc Microservices. Vậy khi đó bạn cần sẽ làm gì để giúp cho team cũng như đồng đội testers sau này sẽ cảm thấy không phải bơi trong một mớ hỗn độn, mọi thứ trở nên rối rắm, và bản thân mình cũng không biết phải giải thích với đồng đội mới hệ thống này hoạt động ra sao.
😩 Thật ra mình chưa được trải qua kinh nghiệm đó, nhưng từ kinh nghiệm mình trải qua với hệ thống hiện tại thì, nếu bạn được tham gia dự án đó từ ban đầu thì đó là cơ hội to lớn để bạn có thể cùng đội ngũ Developer xây dựng nền móng vững chắc cho sản phẩm sau này, ở đây theo quan điểm của mình thì đối với những sản phẩm mới, đang trong quá trình phát triển để ra được một MVP (Minimum Viable Product) thì bạn có thể đặt những câu hỏi sau trong quá trình chuẩn bị phát triển nó:
- Microservices trong thời điểm này liệu có thật sự cần thiết? Câu hỏi này nó như cách để cả team cùng ngồi lại nhìn nhận vì sao mình chọn thiết kế hệ thống theo Microservices, những ưu điểm và nhược điểm khi chọn cách này trong giai đoạn MVP, từ đó team sẽ cùng thống nhất với nhau về cách xây dựng và phát triển sản phẩm ngay từ nền móng ban đầu.
- Nếu sử dụng Microservices thì boundary context cho những services đó là gì? Có cần phải phát triển dựa theo mô hình DDD (Domain-Driven Design) không?
- Việc thực hiện ghi lại các documents liên quan về hệ thống sẽ được thực hiện ra sao? Có thể sẽ có bạn thắc mắc là nếu làm theo mô hình Agile thì trong mô hình đó có một ý đại khái là “Working software over comprehensive documentation”, dịch ra thì kiểu đại khái “việc phát triển sản phẩm và giúp nó hoạt động sẽ quan trọng hơn việc phát triển những tài liệu một cách đầy đủ/toàn diện”, ở đây mọi người lưu ý cụm từ “1 cách đầy đủ/toàn diện” thì nó mang hàm ý các bạn phải biết việc phát triển những tài liệu thế nào là vừa đủ, để nó cân bằng 2 thứ giữa việc phát triển phần mềm và tài liệu “vừa đủ” để các bên liên quan vẫn có thể tham khảo sau này.
- Các services bên trong thì có thể thực hiện việc testing cho nó như thế nào? Việc hỏi câu này sẽ giúp các bạn định hướng cho team về khả năng testability của service ngay từ lúc ban đầu, tránh việc sau khi phát triển xong cũng không biết cách nào để test cho được những cái mình muốn test.
- Có các dependencies services nào bên ngoài có thể cản trở việc testing hoặc phát triển sản phẩm không? Câu này cũng giúp các bạn định hướng khả năng testability của services
Đấy là những gì mình nghĩ có thể cần thiết để giúp cho các bạn khi được tham dự một dự án thiết kế và xây dựng sản phẩm theo mô hình Microservices ngay từ ban đầu. Những câu hỏi trên có thể giúp mọi người định hướng được việc xây dựng và kiểm tra sản phẩm có thể rõ ràng hơn.
Cách để một người mới tìm hiểu kiến thức về hệ thống Microservices trong dự án trong giai đoạn hậu MVP?
Trở lại với câu chuyện của mình 🥲 , thời điểm mình tham gia dự án thì sản phẩm đã được xây dựng cũng hơn 6 năm. Và theo độ dài vòng đời của một startup thì sản phẩm này vẫn đang ở trong giai đoạn còn non trẻ. Và vì còn non trẻ cho nên việc chạy đua để sớm ra tính năng, sớm ra MVP là điều quá hiển nhiên.
Và nó cũng kéo theo một hệ quả là khi mình tham gia dự án thì những tài liệu về hệ thống khá là rời rạc cũng như có phần bị “lạc hậu” khá nhiều. Bên cạnh đó các tài liệu về testing cũng không thật sự có đầy đủ, việc cân bằng giữa đẩy nhanh tiến độ phát triển sản phẩm và chất lượng sản phẩm vẫn luôn là một bài toán khó trong các mô hình phát triển sản phẩm, dù bạn có làm theo mô hình Waterfall hay Agile, thì nó vẫn luôn rất khó giải quyết.
Vì thế bài toán đầu tiên mình cần giải quyết là làm sao để có thể nắm được kiến thức về hệ thống một cách nhanh nhất có thể 🥲
Confluence Page hay bất kỳ nơi nào chứa các documents hoặc notes là người bạn của bạn
Ở công ty của mình thì mọi tài liệu hiện tại đang được lưu trữ trên Confluent Page, tuy có những tài liệu nó không có hoặc bị outdated nhưng ít nhất mình cũng sẽ có được những thông tin ban đầu về hệ thống, mặc dù những thông tin đó có thể vẫn sẽ còn khá rời rạc và chưa có tính kết nối với nhau.
Khi tìm kiếm trên các trang lưu trữ tài liệu thì kỹ năng xây dựng từ khóa để tìm kiếm là phần rất quan trọng, nó tượng tự kỹ năng khi bạn gặp vấn đề và cần tìm cách tìm kiếm trên Google. Một vài keywords mình thường dùng để tìm kiếm tài liệu về hệ thống như sau: “Tên_service SAD”, “Tên_service sequence diagram”, “Tên_service API document” , “Tên_service Architecture”, “Tên_serivce Error Code” hoặc chỉ cần đơn giản là tìm kiếm với tên service mà bạn đang muốn tìm hiểu.
Kỹ năng đọc Sequence Diagram và cách hiểu hình vẽ High-level Software Architect Design là thứ cần thiết
Khi bạn đa có trong thay thông tin hay tài liệu của service mình cần thì điều kế tiếp là bạn phải biết cách đọc và hiểu nó. Nó như kiểu võ công bí kíp đã đưa tới tận tay cho bạn và việc còn lại chỉ là làm sao để luyện thành võ công của mình 😄
Như ví dụ sau đây thì mình mượn tạm cái hình của TiDB khi mô tả về cách nó hoạt động bên trong nó:
Như hình sequence digram này thì các bạn sẽ thấy nó sẽ có những flows tương tác giữa 3 hệ thống bao gồm tidb, pd và tikv, trong đó thì giữa tidb và pd sẽ có khối lệnh riêng để truy vấn toàn bộ những key theo region và sau đó thì giữa tidb và tikv để truy vấn toàn bộ data theo những region key đã tìm được từ khối lệnh trên. Và cuối cùng là khối lệnh giữa client và tidb
Từ những thông tin được thể hiện trong sequence diagram thì các bạn đa có cái nhìn rõ hơn về cách các services sẽ tương tác với nhau như thế nào
Bên cạnh đó việc đọc và hiểu high-level architect sẽ giúp cho bạn có cái nhìn tổng quan hơn về toàn bộ hệ thống bên dưới, bạn có thể dễ dàng biết được những critical services sẽ là những services nào, những service nào sẽ là consumer và provider của nhau
Như ví dụ sau thì mình cũng mượn tạm hình của TiDB:
Như hình ở trên thì mình có thể nắm được là hệ thống kiến trúc của TiDB sẽ có 4 phần bao gồm TiDB, TiKV PD và TiSpark, và phần TiSPark sẽ là 1 phần riêng biệt không ảnh hưởng TiDB. Phần PD sẽ có nhiệm vụ quản lý metadata, và nó sẽ liên quan tới việc quản lý cluster của TiDB và có thể nó là phần quan trọng trong hệ thống TiDB
Hãy dùng Mindmap để tạo nên bức tranh tổng thể về toàn bộ hệ thống của sản phẩm mình đang làm
Mình nghĩ có nhiều cách để các bạn có thể xâu chuỗi những mảnh nhỏ về thông tin hệ thống thành 1 bức tranh tổng thể hơn, còn với mình thì vẫn duy trì thói quen sử dụng Mindmap cho việc này. Nó giúp mình vừa có thể dễ dàng visualize những thông tin mà mình có được thành bức tranh tổng thể hơn, bên cạnh đó khi visualize nó lên Mindmap thì mình cũng có thể nhìn ra những chỗ thông tin mà mình vẫn còn thiếu để từ đó có thể tìm cách đi tìm kiếm những thông tin đó.
Exploratory testing và những tool liên quan tới MIM là cách hiệu quả để tìm hiểu thêm về sản phẩm ở mặt business knowledge và technical knowledge
Việc kế tiếp bạn cần làm là tiến hành explore product như góc nhìn của một end user và kèm theo những tool để giúp bạn có cái nhìn ở mặt kỹ thuật. Bên mình thì sản phẩm nó sẽ được phát triển trên 2 nền tảng là Web và native mobile application, vì thế mình kết hợp cả việc dùng chrome developer tool và những tools dạng MIM (man in middle) như mitm.proxy hoặc Proxyman để intercept network.
Ở đây mình thường sẽ thực hiện 1 user journey flow và sau đó coi thử với flow đó thì hệ thống nó sẽ có những APIs nào tương tác trong flow đó, và kế tiếp là mình sẽ liên kết với những thông tin mình đã có được từ SAD và sequence diagram để có thể có một bức tranh ở mặt user journey flow.
Việc này sẽ cực kỳ có ích khi các bạn bắt đầu phát triển tính năng mới, hoặc khi sản phẩm của các bạn đã có end user sử dụng, khi đó nếu bạn gắp phải những issue (ở đây mình chỉ gọi là issue vì có thể nó chưa hẳn là bug nhé) hoặc khi khách hàng thông báo về những issue họ gặp phải thông qua hệ thống CS (customer service) thì các bạn có thể dùng khả năng suy luận để dự đoán và giới hạn khả năng issue nó từ đâu. Như hình sau từ bài viết của Oracles from the Inside Out – Michael Bolton
“Oracle is the principle or mechanism used to identify the problem. Oracle helps in making decision about the fault”
Hy vọng phần hai này sẽ có những thông tin hữu ích cho các bạn khi tham gia phát triển một sản phẩm theo mô hình Microservices ở thời điểm ban đầu hoặc là “tay ngang” như mình. Mình xin kết thúc phần hai ở đây, viết nãy giờ cũng khá dài rồi, hẹn các bạn ở phần ba, nơi mình giãi bày tiếp về những khó khăn trong quá trình phát triển tiếp tính năng và việc thực hiện testing cho nó 🥲
Tôi là Tester 