Trong kiến trúc microservices ta có thể sử dụng phương pháp kiểm thử đầu cuối để kiểm thử tích hợp các microservice trong hệ thống (Hình 2.22)
Hình 2.22.Kiểm thử tích hợp
Sau khi đã kiểm thử cho từng microservice trong hệ thống chúng ta sẽ tiến hành kiểm thử tích hợp bằng cách kiểm thử đầu cuối cho toàn hệ thống. Việc kiểm thử đầu cuối cho mỗi microservice thì rất đơn giản nhưng khi tích hợp
chúng lại thì lại rất khó khăn, đặc biệt là với các hệ thống lớn có nhiều microservice. Để khắc phục điều đó trong SOML, tôi thực hiện quá trình tích hợp liên tục (continuous integration) để thực hiện kiểm thử tích hợp. Mỗi khi hoàn thành một microservice nào tôi thực hiện triển khai và tích hợp nó vào hệ thống và thực hiện kiểm thử tích hợp microserice đó với các micorservice mà nó phụ thuộc trong hệ thống. Ưu điểm của phương pháp này là nhanh chóng phát hiện được lỗi nhưng nó lại cần phải có thêm một đội ngũ nhân viên để thực hiện việc này và mối quan hệ giữa các microservice trong hệ thống phải được xác định rõ ràng ngay từ đầu.
Ở chương 2, tôi đã trình bày các bước thiết kế, xây dựng hệ thống trên kiến trúc microservices từ mô hình hóa các microservice, triển khai và kiểm thử và áp dụng vào thiết kế, xây dựng ứng dụng mạng xã hội SOML. Chương tiếp theo, dựa trên các kiến thức về kiến trúc microservices và kinh nghiệm xây dựng ứng dụng SOML trên kiến trúc microservice tôi sẽ đưa ra một số phân tích, đánh giá về ưu nhược điểm của kiến trúc microservices và khả năng áp dụng kiến trúc microservices trong xây dựng và phát triển phần mềm.
Chương 3. Đánh giá microservices
Từ những kiến thức tôi đã tìm hiểu được và quá trình ứng dụng thực tế, trong chương này tôi sẽ trình bày những ưu, nhược điểm và đánh giá khi nào nên dùng kiến trúc microservices.
3.1.Ƣu điểm của microservices
Từ chương 1 và chương 2 ta có thể thấy tuy kiến trúc microservices còn là một kiểu kiến trúc mới nhưng lại có rất nhiều ưu điểm, nhất là khi xu hướng xây dựng phần mềm như một dịch vụ (SaaS – Software as a Service) đang ngày càng phát triển mạnh mẽ. Việc áp dụng kiến trúc microservices khiến cho các microservice trong kiến trúc microservices được xác định phạm vi trong một chức năng duy nhất giúp ta dễ dàng quản lý, bảo trì nâng cấp cho mỗi microservice khi cần thiết. Đặc biệt các microservice này lại hoàn toàn độc lập với nhau nên các nhà phát triển phần mềm có thể tự do lựa chọn các công nghệ thích hợp cho từng microservice. Điều này sẽ giúp nâng cao hiệu suất của hệ thống.
Các microservice càng được xác định ranh rới rõ ràng, tập trung vào một chức năng càng giúp các nhà phát triển dễ dàng xây dựng, kiểm thử và phát triển. Chính sự chuyên biệt của các microservice khiến nó hoạt động ổn định, ít có thay đổi về chức năng, nếu có thì chỉ có khả năng là loại bỏ hẳn chức năng này. Do đó khi xây dựng hệ thống dựa trên kiến trúc microservices ta sẽ hạn chế được việc thay đổi chỉnh sửa hệ thống, hoặc nếu có thì cũng không ảnh hưởng đến hệ thống, giúp hệ thống luôn hoạt động ổn định, tiết kiệm chi phí khi vận hành.
Các microservice có phạm vi nhỏ hơn so với dịch vụ trong các kiểu kiến trúc khác nên khi triển khai ta chỉ cần triển khai ở phạm vi nhỏ hơn. Trong quá trình triển khai nếu có bất kỳ vấn đề gì xảy ra ta đều có thể cô lập và phục hồi nó lại một cách nhanh chóng. Các microservice trong kiến trúc microservices tồn tại độc lập với nhau nên nếu có một số microservice ngừng hoạt động thì hệ thống vẫn hoạt động, hệ thống chỉ bị mất một chức năng mà microservice đó thực hiện.
Mỗi microservice trong kiến trúc microservices là hoàn toàn độc lập nhưng lại có thế kết nối với nhau thông qua các API, điều đó đảm bảo tính kết nối lỏng lẻo cho các microservice trong hệ thống. Điều này đảm bảo cho kiến trúc microservices khi các nhà phát triển phần mềm muốn muốn nâng cấp, sửa đổi bất kỳ microservice nào thì họ chỉ cần chỉnh sửa, kiểm thử lại microservice đó mà không gây ảnh hưởng đến hệ thống.
Các máy trạm kết nối đến các microservice trong hệ thống phải thông qua cổng API. Cổng API giúp hệ thống che giấu được kiến trúc bên trong, tăng độ an toàn và bảo mật cho hệ thống. Đối với việc dùng các dịch vụ được thuê, mua từ bên thứ ba, hệ thống cũng vẫn đảm bảo được tính bảo mật vì các dịch vụ này cũng vẫn phải thông qua cổng API để truy cập đến các microservice khác trong hệ thống.
Các microservice được đóng gói có thể chuyển từ môi trường phát triển sang môi trường chạy thật không phải cấu hình thủ công lại. Điều này giúp các nhà phát triển phần mềm có thể triển khai các hệ thống được xây dựng trên kiến trúc microservices một cách nhanh chóng, ít rủi ro, tỷ lệ thành công cao.
3.2.Nhƣợc điểm của micoservices
Nhược điểm đầu tiên của microservices cũng chính từ cổng API, tất cả các yêu cầu từ phía các máy trạm đến các microservie đều phải đi qua cổng API vì vậy cổng API có thể trở thành nút thắt cổ chai trong hệ thống. Để tránh vấn đề này khi xây dựng một hệ thống trên kiến trúc microservices chúng ta nên thiết kế và xây dựng một cổng API có khả năng mở rộng và áp dụng cơ chế bất đồng bộ để kết nối các máy trạm tới cổng API, từ cổng API đến các microservice và ngược lại. Hiện nay có rất nhiều nền tảng để xây dựng cổng API thỏa mãn các tiêu chí như vây như Netty14, Vertx15, Spring Reactor16 hoặc Jboss Undertow17.
Kiến trúc microservices nhấn mạnh kích thước nhỏ gọn của microservice. Một số nhà phát triển phần mềm đề xuất microservice siêu nhỏ cỡ dưới 100 dòng code. Việc chia microservice quá nhỏ sẽ dẫn đến hệ thống trở lên manh mún, khó kiểm soát. Việc lưu trữ dữ liệu bên trong những microservice quá nhỏ sẽ khiến dữ liệu bị phân tán quá mức cần thiết.
Các microservice trong kiến trúc microservices được triển khai phân tán khắp nơi trên mạng Internet vì vậy kiến trúc microservices cũng bị ảnh hưởng bởi các nhược điểm của các hệ phân tán:
Để kết nối một microservice đến các microservice khác nếu chúng ở xa nhau sẽ khiến hệ thống mất nhiều thời gian hơn nếu chúng ở gần nhau, điều này khiến cho hiệu suất của hệ thống bị giảm xuống. Để khắc phục điều này chúng ta có thể sử dụng cơ chế kết nối không đồng bộ để kết nối các microservice trong hệ thống. Tuy nhiên mặt trái khi sử dụng cơ chế bất đồng bộ là khó khăn trong việc cấp quyền để kết
14http://netty.io/
15http://mvnrepository.com/artifact/io.apiman/apiman-gateway-platforms-vertx/1.1.5.Final 16https://spring.io/
nối.
Các kết nối giữa các microservice trong kiến trúc microservices có thể thất bại bất cứ lúc nào vì có thể xảy ra các sự cố như kết nối chậm, lỗi khi thông điệp không gửi được hoặc thông điệp gửi đến nhiều đích đến vào các thời điểm khác nhau. Điều này khiến độ tin cậy của hệ thống bị giảm xuống.
Các microservice trong hệ thống phân tán khắp nơi trên mạng Internet đồng nghĩa với việc dữ liệu của hệ thống cũng bị phân tán. Theo nguyên tắc CAP (CAP theorem) thì giao dịch phân tán sẽ không thể thỏa mãn cả 3 điều kiện:
o Tính nhất quán (consistency): dữ liệu ở điểm khác nhau trong mạng phải giống nhau
o Tính sẵn sàng (availablity): các yêu cầu gửi đi phải có phúc đáp
o Khắc phục lỗi từng phần (partition tolerance): hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi.
Tuy nhiên những công nghệ cơ sở dữ liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt nhất hiện nay cũng chưa vượt qua nguyên tắc CAP.
Kiểm thử tự động một microservice trong kiến trúc microservices đôi khi yêu cầu phải chạy cả các microservice khác mà nó phụ thuộc. Vì vậy việc kiểm thử sẽ trở lên khó khăn trong việc phát hiện lỗi. Để khắc phục điều này, khi xác định các microservice cho hệ thống chúng ta nên khoanh vùng chức năng phụ thuộc nhau vào một microservice, đảm bảo tính kết nối lỏng lẻo cho các microservice trong hệ thống.
Hệ thống có hai microservice thì sẽ có một kết nối API giữa chúng, ba microservice thì sẽ có ba kết nối, có bốn microservice thì sẽ phải có sáu kết nối. Như vậy với hệ thống có n microservice thì sẽ có n! /((n-2)! * 2!) kết nối API. Điều này sẽ khiến cho các hệ thống có nhiều microservice không thể theo dõi được các kết nối của các microservice trong hệ thống. Hệ thống sẽ bị chậm do tắc nghẽn kết nối mà ta thì không thể tìm ra được kết nối gây tắc nghẽn. Để tránh tình trạng này, khi xây dựng hệ thống trên kiến trúc microservices chúng ta cần phải có quy tắc phân luồng, quản lý, đo đếm, theo dõi các microservice trong hệ thống.
3.3.Đánh giá
mãn các yêu cầu trong việc xây dựng và phát triển phần mềm trên dịch vụ hiện nay. Ưu điểm lớn nhất của kiến trúc microservices là sự độc lập của các microservice trong hệ thống giúp cho các microservice dễ dàng áp dụng các công nghệ phù hợp nhất cho nó và giúp hệ thống dễ quản lý, bảo trì và phát triển. Bên cạnh các ưu điểm nổi bật đó kiến trúc microservices cũng mang lại không ít thách thức cho các nhà phát triển phần mềm. Việc áp dụng kiến trúc microservices bắt buộc các nhà phát triển phải có kiến thức về thiết kế hướng miền (DDD – Domain-Driven Design) để phân vùng chính xác các chức năng có ràng buộc với nhau trên miền từ đó xác định biên các microservice cho hệ thống. Việc xác định sai biên cho các microservice sẽ kéo theo rất nhiều hạn chế cho kiến trúc mivroservices mà tôi đã trình bày ở phần 3.2.
Tuy nhiên nếu chúng ta áp dụng kiến trúc microservices một cách đúng đắn từ khâu xác định các microservice đến việc phân luồng, quản lý, đo đếm, theo dõi các microservice thì kiến trúc microservices sẽ là đáp án tối ưu nhất cho việc xây dựng phần mềm hướng dịch vụ. Đặc biệt, việc áp dụng kiến trúc microservices sẽ hiệu quả, phù hợp cho những ứng dụng phức tạp, đòi hỏi phải phát triển liên tục.
KẾT LUẬN
Luận văn đã tìm hiểu về kiến trúc microservices trong việc xây dựng các ứng dụng, hệ thống trong phần mềm, các bước để xây dựng, triển khai một ứng dụng, hệ thống dựa trên kiến trúc microservices. Việc áp dụng kiến trúc microservices để xây dựng ứng dụng mạng xã hội SOML đã cho thấy được nhiều các ưu điểm của hệ thống như hệ thống xây dựng trên microservices sẽ trở lên đơn giản, dễ quản lý. Việc chỉnh sửa, thay đổi và cập nhật công nghệ mới cho các microservice trong hệ thống trở lên dễ dàng hơn so với các kiểu kiến trúc phần mềm hiện đại khác. Bên cạnh đó việc áp dụng kiến trúc microservices cũng mang lại không ít khó khăn như việc hợp nhất các dữ liệu phân tán, giải quyết các tắc nghẽn kết nối giữa các micorservice trong hệ thống.
Hầu hết các nhược điểm khi áp dụng kiến trúc microservices đều xuất phát từ việc các nhà phát triển xác định sai các microservice trong hệ thống, vì vậy các nhà phát triển phần mềm khi muốn áp dụng kiến trúc microservices cần có kiến thức về thiết kế hướng miền (Domain-Driven Design) và cần phải có các quy tắc phân luồng, quản lý, đo đếm, theo dõi các microservice rõ ràng. Thực hiện được các điều này sẽ giúp cho chúng ta áp dụng kiến trúc microservices một cách đúng đắn và mang lại hiệu quả cao khi xây dựng và phát triển các hệ thống trên microservices.
Kiến trúc microservices tuy chỉ mới xuất hiện trong vài năm gần đây nhưng đã được rất nhiều các công ty lớn đưa vào nghiên cứu và áp dụng, điều này chứng tỏ các lợi ích mà kiến trúc microservices đang mang lại là rất to lớn. Đặc biệt là ngày nay, khi mà các sản phẩm phần mềm dịch vụ đang ngày phổ biến và thay thế các sản phẩm phần mềm đóng gói thì việc áp dụng kiến trúc microservices trong xây dựng và phát triển phần mềm là một yêu cầu cần thiết. Tuy nhiên kiến trúc microservices có phải là một kiểu kiến trúc cho tương lai hay không thì vẫn đang là một vấn đề gây nhiều tranh cãi cho các nhà phát triển phần mềm, các vấn đề về bảo mật và cơ sở dữ liệu trong micrservices vẫn đang là các vấn đề khó khăn khi chúng ta áp dụng kiến trúc microservices. Hướng phát triển tiếp theo của luận văn sẽ là nghiên cứu và thử nghiệm các phương pháp để bảo mật và các phương pháp để quản lý dữ liệu phân tán trong kiến trúc microservices.
TÀI LIỆU THAM KHẢO Tiếng Anh
1. Eric Newcomer, Greg Lomow. Understanding SOA with Web Services. 2004.
2. ICCI. Monolithic Applications Retrieved. 2007.
3. Martin Fowler. Microservices. 2014.
4. Stefan BorsjeJuly. How we build microservices at Karma. 2014.
5. Toby Clemson. Testing Strategies in a Microservice Architecture. 2014.
6. Sam Newman. Building Microservice. 2015.
7. Nikola Stjelja. Microservices architecture models - How to document and
think about microservices based architecture models. 2015.
8. Joachim Rohde. Amazon Architecture. 2007.
9. Sudhir Tonse & Nitesh Kant. MicroServices at NETFLIX. 2014.
10. Eric Evans. Domain-Driven Design. 2003.
11. Sam Ruby. Agile Web Development with Rails. 2013.
12. Peter Shaw. Postgres Succinctly. 2013.
13. Clément Nedelcu. Nginx HTTP Server - Second Edition. 2013.
14. Mike Cohn. Succeeding with Agile. 2010.
15. James Turnbull. The Docker Book. 2014.
Website 1. http://microservices.io/ 2. http://www.statista.com/statistics/272014/global-social-networks-ranked-by- number-of-users/ 3. https://www.docker.com/what-docker 4. https://aws.amazon.com/ 5. https://www.rabbitmq.com/ 6. http://kafka.apache.org/ 7. http://activemq.apache.org/ 8. https://getkong.org/about/ 9. https://cloud.google.com/appengine/docs/java/endpoints/ 10. http://aws.amazon.com/api-gateway/ 11. https://coreos.com/