Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô

Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI - BÙI MINH CHIẾN THIẾT KẾ VÀ XÂY DỰNG MICROSERVICE VỚI KHẢ NĂNG ĐÁP ỨNG SỰ THAY ĐỔI VỀ QUY MÔ Chuyên ngành : CÔNG NGHỆ THÔNG TIN LUẬN VĂN THẠC SĨ KỸ THUẬT CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN: PGS.TS CAO TUẤN DŨNG Hà Nội – Năm 2019 LỜI CAM ĐOAN Tôi – Bùi Minh Chiến – xin cam đoan • Luận văn tốt nghiệp (LVTN) Thạc sĩ cơng trình nghiên cứu thân hướng dẫn PGS.TS Cao Tuấn Dũng • Các kết nêu Luận văn tốt nghiệp trung thực, khơng phải chép tồn văn cơng trình khác Hà Nội, ngày … tháng … năm 2019 Tác giả LVThS Bùi Minh Chiến LỜI CẢM ƠN Đầu tiên, xin gửi lời cảm ơn sâu sắc tới Thầy giáo – PGS.TS Cao Tuấn Dũng – Phó viện trưởng, Viện Công nghệ thông tin Truyền thông, Trường Đại học Bách Khoa Hà Nội hướng dẫn cho tơi lời khun q trình thực luận văn Tiếp theo, xin chân thành cảm ơn thầy cô Viện Công nghệ thông tin truyền thông, Viện đào tạo sau đại học, Trường Đại học Bách Khoa Hà Nội tạo điều kiện cho tơi suốt q trình học tập nghiên cứu trường Cuối cùng, tơi xin bày tỏ lịng cảm ơn tới người thân gia đình, bạn bè động viên giúp đỡ để tơi hồn thành luận văn Hà Nội, ngày … tháng … năm 2019 Tác giả LVThS Bùi Minh Chiến MỤC LỤC LỜI CAM ĐOAN LỜI CẢM ƠN MỤC LỤC DANH MỤC BẢNG BIỂU DANH MỤC HÌNH ẢNH .6 MỞ ĐẦU Đặt vấn đề Phương pháp đề xuất Bố cục luận văn CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ KIẾN TRÚC HỆ THỐNG .9 1.1 Kiến trúc khối (Monolithic) .9 1.1.1 Khái niệm 1.1.2 Ưu nhược điểm kiến trúc Monolithic 10 1.2 Kiến trúc hướng dịch vụ (SOA) 11 1.3 Kiến trúc dịch vụ siêu nhỏ (Microservice) 12 1.3.1 Khái niệm 13 1.3.2 Các thành phần Microservice 14 1.3.3 Các kiến trúc Microservice 16 1.3.4 Ưu nhược điểm kiến trúc Microservice .18 1.3.5 Các nguyên tắc phát triển Microservice 20 CHƯƠNG 2: CÁC ĐẶC TÍNH MICROSERVICE 23 2.1 Các đặc tính Microservice 23 2.2 Tính ổn định (Stability) 23 2.3 Tính sẵn sàng (Availability) 23 2.4 Tính co giãn (Scalablity) 24 2.5 Tính mở rộng (Elasticity) 27 2.6 Tính độc lập (Independent) 27 2.7 Tính đa chiều (Polyglot) 28 CHƯƠNG 3: THIẾT KẾ HỆ THỐNG .30 3.1 Mô tả toán 30 3.2 Mơ hình hệ thống 31 3.2.1 Bộ tổng hợp (Aggregator) 32 3.2.2 Bộ cân tải (Load balancing) .33 3.2.2.1 Virtual Message Router (VMR) .34 3.2.2.2 Các tính VMR .34 3.2.3 Bộ xử lý yêu cầu (Microservice) 35 CHƯƠNG 4: THỬ NGHIỆM VÀ ĐÁNH GIÁ 37 4.1 Công nghệ môi trường sử dụng .37 4.1.1 Ngôn ngữ lập trình .37 4.1.2 Môi trường sử dụng 37 4.2 Các tiêu chí đánh giá 37 4.3 Cài đặt kết thử nghiệm 38 4.3.1 Triển khai cài đặt hệ thống 38 4.3.2 Thử nghiệm 42 KÊT LUẬN 52 TÀI LIỆU THAM KHẢO 53 DANH MỤC BẢNG BIỂU Bảng 1: Kết thực với Microservice 43 Bảng 2: Kết thực với Microservice 43 Bảng 3: Kết thực với Microservice 44 Bảng 4: Kết thực với Microservice 44 Bảng 5: Kết thực với Microservice 45 Bảng 6: So sánh thử nghiệm (1 microservice) thử nghiệm (2 microservice) 48 Bảng 7: So sánh thử nghiệm (2 microservice) thử nghiệm (3 microservice) 49 DANH MỤC HÌNH ẢNH Hình 1: Kiến trúc nguyên khối monolithic 10 Hình 2: So sánh kiến trúc khối kiến trúc microservice .14 Hình 3: Kiến trúc microservice 15 Hình 4: Mơ hình tổng hợp (Aggregator Pattern) 17 Hình 5: Mơ hình Proxy (Proxy Pattern) 17 Hình 6: Mơ hình đường ống (Pipeline Pattern) .18 Hình 7: Tính sẵn sàng Microservice .24 Hình 8: Khối co giãn (Scale Cube) 25 Hình 9: Co giãn theo trục X 25 Hình 10: Co giãn theo trục Z 26 Hình 11: Co giãn theo trục Y 26 Hình 12: Ví dụ tính Polyglot Microservice 29 Hình 13: Giao diện phần liệu đầu vào 31 Hình 14: Mơ hình hoạt động hệ thống 32 Hình 15: Hình ảnh hệ thống gửi tin nhắn .33 Hình 16: Các thành phần VMR 34 Hình 17: Mơ hình tương tác Solace với 35 Hình 18: Giao diện chương trình 38 Hình 19: Cấu hình Aggregator 39 Hình 20: Cấu hình xử lý 39 Hình 21: Khởi động Aggregator .40 Hình 22: Khởi động Aggregator thành cơng 40 Hình 23: Trạng thái kết nối thành công tới server Solace giao diện 41 Hình 24: Khởi động xử lý .41 Hình 25: Khởi động xử lý thành công 42 Hình 26: Kết so sánh số lượng yêu cầu đáp ứng 46 Hình 27: Kết so sánh độ lệch chuẩn đỗ trễ đáp ứng yêu cầu .46 Hình 28: So sánh tương quan khả đáp ứng yêu cầu độ lệch chuẩn độ trễ thời gian đáp ứng 47 Hình 29: So sánh thử nghiệm (1 microservice) thử nghiệm (2 microservice) .48 Hình 30: So sánh tương quan thử nghiệm (1 microservice) với thử nghiệm (2 microservice) 50 Hình 31: So sánh kết cuối thử nghiệm thử nghiệm 50 MỞ ĐẦU Đặt vấn đề Nhu cầu sử dụng dịch vụ lúc ngày tăng cao thời đại số ngày phát triển vũ bão Chính nhu cầu ngày tăng nên nhiều dịch vụ chuyển sang tảng trực tuyến để mau chóng bắt cặp với xu hướng mục tiêu phục vụ nhu cầu người dùng kịp thời nơi lúc Cùng với phát triển điện toán đám mây thúc đẩy thay đổi mạnh mẽ cách mà nhà phát triển ứng dụng cách triển khai ứng dụng Chính phát triển mạnh nhanh khiến cho loại ứng dụng kiến trúc dịch vụ thay đổi theo nhiều theo nhu cầu người sử dụng thay thay đổi theo thời gian trước Sự thay đổi phù hợp để trải nghiệm người sử dụng thời đại số đáp ứng thời điểm để dịng thơng tin không bị ngắt quãng hay bị ứ đọng mà đáp ứng dịch vụ cách kịp thời nhanh chóng Phương pháp đề xuất Nếu sử dụng kiến trúc nguyên khối lượng người dùng tăng lên, để đáp ứng lượng truy cập tăng cao bên cung cấp dịch vụ phải nâng số máy chủ lên để đáp ứng lượng truy cập Nhưng để triển khai thêm thêm máy nhiều thời gian phải triển khai gần nguyên hệ thống máy ảo số hệ thống gồm nhiều chức bên chức mà người dùng sử dụng lúc khiến cho chức bổ sung để đáp ứng không cần thiết khiến cho việc lãng phí Chính điều nên giải pháp cho việc đáp ứng nhu cầu người dùng tăng cao nâng số lượng dịch vụ mà người dùng cần thiết lên để đáp ứng yêu cầu mà tiết kiệm chi phí, khơng bị thừa hay lãng phí cho dịch vụ mà khơng cần bổ sung Đấy lý nên chia dịch vụ từ kiến trúc nguyên khối sang thành dịch vụ nhỏ (microservice), phù hợp cho việc nâng số service lúc nhu cầu tăng cao mà tiết kiệm chi phí, đáp ứng yêu cầu người dùng Trong luận văn sử dụng thử nghiệm để mô tả đáp ứng service có lượng request từ phía người dùng tăng lên Khi tiếp nhận lượng request lớn từ phía người dùng, thời gian sử dụng service để xử lý có nhiều service tham gia thời gian đáp ứng Tất số liệu đánh giá mang tính tương đối thực tế cịn nhiều yếu tố ảnh hưởng đến việc gửi nhận request từ phía người dùng tốn để áp dụng mang tính chất tham khảo để đánh giá phần liên quan tới tính mở rộng microservice Trong chương sau mô tả Microservice, kiến trúc microservice sử dụng triển khai mơ tả chi tiết tốn áp dụng để thử nghiệm khả đáp ứng microservice Bố cục luận văn Sau bố cục luận văn: Chương 1: Giới thiệu chung Chương 2: Các đặc tính microservice Chương 3: Thiết kế hệ thống mơ tả tốn Chương 4: Thử nghiệm đánh giá Kết luận: Đưa kết đạt luận văn định hướng phát triển tiếp cho toán Phụ lục tài liệu tham khảo CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ KIẾN TRÚC HỆ THỐNG Vấn đề áp dụng ứng dụng phần mềm vào quản lý doanh nghiệp xử lý nghiệp vụ điều mẻ Tuy nhiên với phát triển khơng ngừng công nghê, việc áp dụng phần mềm vào quản lý xử lý vấn đề nghiệp vụ khơng cịn đơn giản trước Bắt đầu từ trang web, phần mềm quản lý ngày nào, doanh nghiệp cịn xây dựng cho hệ sinh thái đa tảng, kết nối nhiều thiết bị giúp doanh nghiệp quản lý lúc, nơi Tân dụng tối đa nguồn lực có Các hệ thống ERPs, CRMs hay nhiều phần mềm khác chứa hàng trăm tính gói gọn ứng dụng doanh nghiệp Việc doanh nghiệp xây dựng hệ sinh thái riêng cho dẫn đến hệ thống thiết kế trở nên phức tạp Các công nghệ không ngừng phát triển dẫn đến hệ doanh nghiệp phải liên tục update nâng cấp hệ thống Các cơng việc bảo trì nâng cấp gặp nhiều khó khăn trước, cấu trúc thiết kế nguyên khối (monolithic) khơng thể đáp ứng Chính mà kiến trúc Microservice ngày nhà phát triển ý năm trở lại với nhiều ưu điểm khắc phục vấn đề cịn tồn ứng dụng có kích thước lớn phát triển hay bảo trì độc lập mà khơng ảnh hưởng đến tồn bọ phần mềm, tăng nâng số lượng chức lên nhu cầu sử dụng tăng cao hạ xuống không cần thiết Các đặc điểm kiến trúc Mcroservice kỳ vọng đẩy nhanh chu kỳ phát triển dịch vụ Web hay phát triển hệ thống phần mềm khác, giúp cơng việc bảo trì nâng cấp hệ thống trở nên đơn giản 1.1 Kiến trúc khối (Monolithic) 1.1.1 Khái niệm Monolithic kiến trúc thiết kế ứng dụng nguyên khối tất Tất thành phần chương trình kết nối với nhau, phụ thuộc lẫn hoạt động tảng xác định từ lúc bắt đầu phát triển Mỗi ứng dụng nguyên khối độc lập, tất khối từ lúc phát triển tới lúc hoàn thiện sản phẩm để đem vào sử dụng Hình 21: Khởi động Aggregator Hình 22: Khởi động Aggregator thành công Khi chạy xong tổng hợp aggregator, để xác định xem cài đặt thành công để chạy chưa ta kiểm tra thông số “Connected” hình 40 Hình 23: Trạng thái kết nối thành công tới server Solace giao diện Nếu trạng thái hiển thị “Yes” nghĩa bạn kết nối thành công tới server Solace Message “No” ngược lại trường hợp có vấn đề kết nối chương trình bị lỗi chạy Tiếp theo ta cần khởi động microservice để thực công việc gửi lên Ta truy cập vào thư mục worker chạy lệnh “ /gradlew bootRun” để khởi chạy hình sau: Hình 24: Khởi động xử lý Khi chạy thấy dòng chữ “************* Solace initialized correctly!! ************” có nghĩa ta khởi động thành cơng microservice 41 Hình 25: Khởi động xử lý thành công Tất aggregator microservice đểu triên khai môi trường JDK Để tăng số lượng microservice hoạt động ta làm với cách tương tự bên đạt số lượng mong muốn 4.3.2 Thử nghiệm Để thử nghiệm luận văn này, ta thực chạy với liệu đầu vào để lấy kết so sánh với Dữ liệu trả mang tính chất tham khảo mơi trường thực tế u cầu cơng việc thực tế khác Dữ liệu trả số liệu tính tốn dựa theo số liệu đầu vào từ thử nghiệm thử nghiệm sau Bộ liệu đầu vào dùng để thử nghiệm thực thiện là: • Yêu cầu gửi lên: 1000 request • Số lượng yêu cầu gửi lên 100 yêu cầu/giây • Thời gian thực cơng việc trễ thấp nhất: 200 mili giây • Thời gian thực cơng việc trễ cao nhất: 300 mili giây Với đầu vào ta thử nghiệm lần lần thay đổi số lượng Microservice để kiểm tra tính đáp ứng tăng dần số lượng microservice lên Ta thực kiểm tra kết tương ứng với tiêu chí khả đáp ứng microservice độ lệch chuẩn độ trễ thời gian phản hồi từ microservice tới ứng dụng phía người dùng Kết thử nghiệm với microservice hoạt động, ta thu kết bảng đây: 42 Lần thử nghiệm Request Rate / Sec Std Dev 3.95 45.413 3.90 45.936 3.90 44.407 3.93 40.316 3.92 45.921 Bảng 1: Kết thực với Microservice Với liệu đầu vào ta thu kết với microservice chạy số lượng yêu cầu thực trung bình khoảng 3.922 request/giây tổng độ lệch chuẩn độ trễ thời gian thực 44.399 giây Thử nghiệm với hai Microservice hoạt động với đầu vào nêu trên, ta nhận kết trả sau: Lần thử nghiệm Request Rate / Sec Std Dev 7.95 20.148 7.93 20.219 7.92 20.155 7.99 20.007 8.01 20.849 Bảng 2: Kết thực với Microservice Với liệu đầu vào ta thu kết tăng số lượng microservice chạy lên hai số lượng yêu cầu thực trung bình tăng lên khoảng 7.96 request/giây tổng độ lệch chuẩn độ trễ yêu cầu 20.276 giây Với thử nghiệm ba Microservice hoạt động lúc, ta nhận kết trả bảng sau: 43 Lần thử nghiệm Request Rate / Sec Std Dev 11.80 8.801 11.92 9.079 12.01 8.873 11.82 8.691 11.82 8.736 Bảng 3: Kết thực với Microservice Với liệu đầu vào ta thu kết ba microservice chạy số lượng u cầu thực trung bình tăng lên khoảng 11.87 request/giây, tổng độ trễ request phản hồi 8.836 giây Thử nghiệm tăng số lượng Microservice lên bốn chạy lúc, ta kết sau hoàn tất lần thử nghiệm bảng sau: Lần thử nghiệm Request Rate / Sec Std Dev 15.82 1.239 15.82 1.247 15.78 1.717 15.92 1.565 15.99 1.482 Bảng 4: Kết thực với Microservice Với liệu đầu vào hình ta thu kết bốn microservice chạy số lượng yêu cầu thực trung bình tăng lên 15.87 request/giây tổng độ lệch chuẩn độ trễ yêu cầu 1.450 giây Ta tiếp tục tăng lên năm Microservice, kết ta nhận sau hồn tất hình sau: 44 Lần thử nghiệm Request Rate / Sec Std Dev 17.28 0.051 17.44 0.051 17.25 0.066 17.47 0.052 17.47 0.051 Bảng 5: Kết thực với Microservice Bộ liệu dầu vào không thay đổi với năm microservice hoạt động số lượng yêu cầu thực trung bình tăng lên 17.38 request/giây tổng độ lệch chuẩn độ trễ giảm trung bình cịn 0.054 giây Với tổng độ trễ thời gian số lượng microservice tăng lên đến ta thấy gần công việc gửi lên đáp ứng nên độ trễ thời gian sau xử lý thấp, thời gian vấn đề truyền dẫn xử lý Khi liệu đầu vào bên thử nghiệm tăng lên microservice hoạt động lúc kết với cấu hình máy thử nghiệm kết tương đương với microservice hoạt động Kết luận số lượng microservice đủ lớn đáp ứng với lượng cơng việc cần xử lý microservice với thử nghiệm nêu Tổng hợp kết so sánh số lượng yêu cầu đáp ứng theo thời gian thay đổi số lượng Microservice ta sơ đồ sau: 45 Compare request response 20.00 18.00 Request / second 16.00 14.00 12.00 10.00 8.00 6.00 4.00 2.00 0.00 Number Microservice Active Hình 26: Kết so sánh số lượng yêu cầu đáp ứng Dựa theo kết sơ đồ ta thấy số lượng Microservice hoạt động tăng lên đồng nghĩa với việc nhiều request đầu vào đáp ứng thời điểm mà số lượng công việc đầu vào không đổi Kết so sánh độ lệch chuẩn độ trễ đáp ứng xong yêu cầu thay đổi số lượng Microservice ta sơ đồ sau: COMPARE STV.DEV 0.051 0.051 0.066 0.052 0.051 1.239 1.247 1.717 1.565 1.482 8.801 9.079 8.873 8.691 8.736 20.148 20.219 20.155 20.007 20.849 TOTAL STD.DEV SENCOND 45.413 45.936 44.407 40.316 45.921 NUMBER MICROSERVICE ACTIVE Hình 27: Kết so sánh độ lệch chuẩn đỗ trễ đáp ứng yêu cầu Ở sơ đồ so sánh độ lệch chuẩn thời gian trễ trêm, ta thấy số lượng Microservice độ trễ nhiều lượng yêu cầu cao mà khả xử lý 46 Microservice lại không đổi Khi số lượng Microservice tăng lên độ trễ giảm dần Khi số lượng Microservice tăng lên đến năm microservice hoạt động với đầu vào không đổi, ta thấy độ lệch chuẩn gần giá trị chứng tỏ với đầu vào thử nghiệm nêu bên với microservice gần đáp ứng Có nghĩa tăng lên microservice khả đáp ứng microservice hoạt động 20.00 18.00 16.00 14.00 12.00 10.00 8.00 6.00 4.00 2.00 0.00 60.00 50.00 40.00 30.00 20.00 10.00 Total Std.Dev Second Request / Second Chart Summary 0.00 Number Microservice Active calc rate std dev Hình 28: So sánh tương quan khả đáp ứng yêu cầu độ lệch chuẩn độ trễ thời gian đáp ứng Với sơ đồ kết hình 28 ta thấy với đầu vào thử nghiệm sử dụng với số lượng microservice thấp thời gian đáp ứng lượng cơng việc lớn ta tăng dần số lượng microservice lên Khi số lượng microservice thấp độ trễ thời gian thực lượng cơng việc cao nhiều so với số lượng microservice tăng lên dần Thử nghiệm nhằm mục tiêu để so sánh tính đáp ứng microservice lượng cơng việc tăng lên nhiều với số lượng microservice thay đổi với kết thử nghiệm theo kịch thử nghiệm bên để kiểm tra xem số lượng microservice tăng thêm giảm mà khơng gây lãng phí tài ngun máy chủ mà đáp ứng yêu cầu Với thử nghiệm thứ ta tăng lượng công việc lên gấp đôi lượng yêu cầu gửi lên giữ nguyên thời gian thực công việc giao động khoảng thử nghiệm bên Vì khả đáp ứng với microservice khơng đổi nên ta thử nghiệm với hai microservice hoạt động lúc trở lên kết so sánh với kết thử nghiệm với microservice bảng sau: 47 Thử nghiệm Thử nghiệm (1 microservice) (2 microservice) Lần thử nghiệm Request Rate / Sec Std Dev Request Rate / Sec Std Dev 3.95 45.413 7.92 45.812 3.90 45.936 7.94 45.266 3.90 44.407 8.00 44.739 3.93 40.316 7.96 39.378 3.92 45.921 7.90 44.917 Bảng 6: So sánh thử nghiệm (1 microservice) thử nghiệm (2 microservice) Kết từ bảng ta thấy số lượng request xử lý theo thời gian có khác biệt số lượng microservice hoạt động khác mà tổng thời gian độ lệch chuẩn gần tương đương tổng kết cuối (số có sai lệch phần thời điểm thực kiểm thử liệu khác số lượng request lớn nên xảy phần số liệu sai lệch với không đáng kể) Với bảng số liệu ta có sơ đồ sau: Compare Ex.1 (1 ms) & Ex.2 (2 ms) 48.000 46.000 44.000 42.000 40.000 38.000 36.000 Hình 29: So sánh thử nghiệm (1 microservice) thử nghiệm (2 microservice) 48 Với sơ đồ ta thấy tương đồng thời gian xử lý, lượng công việc nhiều gấp đôi đáp ứng với nhiều microservice khả xử lý độ trễ thời gian tương đương với lượng công việc thử nghiệm bên Tiếp tục thử nghiệm ta tăng lên ba microservice để đáp ứng số lượng công việc thử nghiệm so sánh với kết hai microservice đáp ứng công việc ta có bảng kết sau: Thử nghiệm Thử nghiệm (2 microservice) (3 microservice) Lần thử nghiệm Request Rate / Sec Std Dev Request Rate / Sec Std Dev 7.95 20.148 11.89 20.641 7.93 20.219 12.00 20.866 7.92 20.155 11.98 20.608 7.99 20.007 12.00 20.624 8.01 20.849 11.95 20.310 Bảng 7: So sánh thử nghiệm (2 microservice) thử nghiệm (3 microservice) Kết từ thử nghiệm thử nghiệm tương đồng ta tăng số lượng microservice lên thêm Để nhìn thấy tổng quan ta tham khảo sơ đồ sau để thấy rõ điều so sánh thử nghiệm kết thử nghiệm thử nghiệm 2: 49 Compare Ex.1 & Ex.2 50.000 45.000 40.000 35.000 30.000 25.000 20.000 15.000 10.000 5.000 0.000 Hình 30: So sánh tương quan thử nghiệm (1 microservice) với thử nghiệm (2 microservice) Ta thấy với microservice với đầu vào thử nghiệm bên microservice với thử nghiệm thời gian đáp ứng thử nghiệm tương đối đồng khơng có nhiều khác biệt Thử nghiệm tiếp tục cách tăng số lượng microservice lên với đầu vào thử nghiệm thử nghiệm lên tiếp tục, ta có sơ đồ tổng quát sau kết thu Hình 31: So sánh kết cuối thử nghiệm thử nghiệm Biểu đồ ta thấy số lượng công việc nhiều gấp đôi thử nghiệm so với thử nghiệm cần tăng thêm microservice ta đáp ứng 50 với yêu cầu để đáp ứng hết Khi ta tăng số lượng microservice lên sáu lớn khơng có khác biệt lớn với liệu đầu vào thử nghiệm tốn mà thời gian đáp ứng tức yêu cầu lên trả cho người dùng gần xong Với lượng công việc ta thấy cần xem xét vào cân đối đủ đáp ứng lượng cơng việc dù gấp đôi gấp ba mà không cần tăng nhiều microservice để tránh dư thừa mà đạt hiệu suát tốt để phục vụ người dùng Nhưng kèm với việc tăng số lượng Microservice lên để đáp ứng cơng việc ta cần xem xét thêm khả mở rộng phần cứng việc quan tâm đến phần mềm Mỗi triển khai thêm Microservice ta phải hao tổn lượng tài nguyên phần cứng định để hoạt động Ta cần đánh giá cho phù hợp số lượng Microservice cho công việc hay nhu cầu cụ thể để khơng bị hoang phí tài ngun để tiết kiệm chi phí mà phù hợp cho hệ thống đáp ứng làm việc 51 KÊT LUẬN Thông qua luận văn ta hiểu khái niệm đặc tính kiến trúc Microservice với tốn dùng để thử nghiệm mơ hình Các hệ thống lớn xem xét đánh giá từ đầu lúc lên ý tưởng phát triển hệ thống áp dụng dễ dàng kiến trúc Microservice Nếu đánh giá để phát triển theo mơ hình kiến trúc Microservice nhiều ưu điểm khả phát triển độc lập thành phần hệ thống, giúp đẩy nhanh trình thành sản phẩm cuối Nhưng song song với điều cịn có thách thức với phương pháp xây dựng hệ thống theo kiến trúc Microservice nên định sử dụng Khó khăn ban đầu mà nhà phát triển gặp việc chuyển hệ thống từ kiến trúc cũ sang thành hệ thống phân tán chức Việc co giãn chức theo trục Y kết hợp với co giãn theo trục X phần khó khăn trình phát triển vận hành hệ thống việc đồng liệu thực việc mở rộng tăng số lượng microservice để đảm bảo tính tồn vẹn tính sẵn sàng liệu Nếu kiểm sốt tốt tồn thành phần hệ thống phát huy hầu hết ưu điểm kiến trúc microservice đem lại, ngược lại gặp vấn đề việc vận hành kiểm sốt khơng tốt từ khâu thiết kế ban đầu hệ thống ngày khó quản lý hoạt động mong muốn người phát triển người sử dụng mà hệ thống ngày nhiều tính sau dễ dẫn đến gây rối chung cho toàn hệ thống hay ứng dụng Nhưng dựa vào điều mà ta khẳng được kiến trúc Microservice hướng đầy hứa hẹn tương lai sau dành cho nhà phát triển hệ thống ứng dụng sau giúp cho việc đẩy nhanh trình phát triển đến giai đoạn khai thác ứng dụng bước sau Hướng phát triển sau cải tiến hồn chỉnh cho ví dụ sử dụng luận văn áp dụng dụng kiến trúc microservice vào toán cụ thể sống công việc giao làm gặp phải để đưa đề xuất đắn cho việc áp dụng phát triển 52 TÀI LIỆU THAM KHẢO [1] Khakame Peter Wamboko (2016) - Development of a Scalable Microservice Architecture for Web Services using OS-level Virtualization (http://erepository.uonbi.ac.ke/bitstream/handle/11295/99091/Msc_Project Final_re port-2016.pdf) [2] Rajagopalan Ranganathan (September 17, 2018) - A highly-available and scalable microservice architecture for access management (https://aaltodoc.aalto.fi/bitstream/handle/123456789/34401/master_Ranganathan_Ra jagopalan_2018.pdf) [3] Prof Dr Wilhelm (Willi) Hasselbring (2016) - Microservices for Scalability (https://icpe2016.spec.org/fileadmin/user_upload/documents/icpe_2016/ICPE2016key note_WillyHasselbring.pdf) [4] F´abio de Carvalho Ribeiro (Sep 3, 2018) - Elastic Microservices Platform (https://estudogeral.sib.uc.pt/bitstream/10316/83536/1/Elastic_Microservices_Platfor m.pdf) [5] Martin Fowler and James Lewis (2014) - Microservice (https://martinfowler.com/articles/microservices.html) [6] G Steinacker (2014) - Scaling with Microservices and Vertical Decomposition (https://dev.otto.de/2014/07/29/scaling-with-microservices-and-verticaldecomposition/) [7] Alison Jarns (Oct 25 2018) – Fundamental principles of microservice design (https://blogs.mulesoft.com/dev/microservice-design-principles/) [8] Tutorialpoinst - Microservice Architecture tutorial (https://www.tutorialspoint.com/microservice_architecture/microservice_architecture _tutorial.pdf) [9] Chris Richardson, Floyd Smith (2016) - Microservice From Design to Deployment (https://ungrid.unal.edu.co:8888/img/Microservices_Designing_Deploying.pdf) [10] Sahiti Kappagantula (July 03 2018) - Microservice Architecture — Learn, Build, and Deploy Applications (https://dzone.com/articles/microservice-architecture-learn-build-and-deploy-a) [11] Jamie Maguire - Microservice Architecture (Examples and Diagram) (https://www.devteam.space/blog/microservice-architecture-examples-and-diagram/) [12] Website: https://microservices.io/ 53 [13] Website: https://dzone.com/microservices-news-tutorials-tools [14] Website: https://docs.solace.com/Solace-SW-Broker-Set-Up/SW-BrokerArchitecture.htm [15] Website: https://3yecy51kdipx3blyi37oute1-wpengine.netdna-ssl.com/wpcontent/uploads/2017/02/Solace-VMR-Datasheet.pdf 54 ... giây Với đầu vào ta thử nghiệm lần lần thay đổi số lượng Microservice để kiểm tra tính đáp ứng tăng dần số lượng microservice lên Ta thực kiểm tra kết tương ứng với tiêu chí khả đáp ứng microservice. .. thực với Microservice 43 Bảng 2: Kết thực với Microservice 43 Bảng 3: Kết thực với Microservice 44 Bảng 4: Kết thực với Microservice 44 Bảng 5: Kết thực với Microservice. .. tương ứng hoạt động bình thường Nguyên tắc 5: Khả kết hợp (Composability) Một nguyên tắc thiết kế microservice phải xác định chức hay tính service Khi thiết kế microservice có khả kết hợp với microservice