Tài liệu Luận văn cntt xây dựng kiến trúc triển khai liên tục cho các hệ thống dựa trên vi dịch vụ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN TRỌNG HIẾU XÂY DỰNG KIẾN TRÚC TRIỂN KHAI LIÊN TỤC CHO CÁC HỆ THỐNG DỰA TRÊN VI DỊCH VỤ LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM HÀ NỘI - 2018 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN TRỌNG HIẾU XÂY DỰNG KIẾN TRÚC TRIỂN KHAI LIÊN TỤC CHO CÁC HỆ THỐNG DỰA TRÊN VI DỊCH VỤ Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 8480103.01 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. VÕ ĐÌNH HIẾU HÀ NỘI - 2018 LỜI CAM ĐOAN Tôi xin cam đoan rằng luận văn thạc sĩ Kĩ thuật phần mềm "Xây dựng kiến trúc triển khai liên tục cho các hệ thống dựa trên vi dịch vụ" là sản phẩm nghiên cứu khoa học của riêng cá nhân tôi, dưới sự giúp đỡ rất lớn của Giảng viên hướng dẫn là TS. Võ Đình Hiếu, không sao chép lại của người khác. Những điều được trình bày trong toàn bộ nội dung của luận văn này hoặc là của chính cá nhân tôi, hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có nguồn gốc rõ ràng và được trích dẫn hợp pháp. Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Hà nội, tháng 11 năm 2018 Học viên Nguyễn Trọng Hiếu LỜI CẢM ƠN Trước tiên, tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc đến thầy giáo, TS. Võ Đình Hiếu - người đã dành nhiều tâm huyết, tận tình chỉ bảo và giúp đỡ tôi trong suốt quá trình bắt đầu thực hiện đề tài cho đến khi hoàn thành. Tôi xin gửi lời cảm ơn chân thành tới các thầy cô giáo khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà nội - nơi tôi đã theo học trong thời gian qua. Các thầy cô đã cung cấp cho tôi những kiến thức quý báu, tạo điều kiện tốt nhất cho tôi trong suốt quá trình học tập và nghiên cứu tại trường. Cuối cùng, tôi xin chân thành cảm ơn những người thân trong gia đình, bạn bè cùng khóa, đồng nghiệp trong cơ quan đã giúp đỡ và tạo điều kiện cho tôi trong quá trình học tập và nghiên cứu thực hiện luận văn này. Tuy rằng tôi đã cố gắng hết sức trong quá trình làm luận văn nhưng không thể tránh khỏi thiếu sót, tôi rất mong nhận được những góp ý của thầy cô và các bạn. Hà nội, tháng 11 năm 2018 Học viên Nguyễn Trọng Hiếu MỤC LỤC LỜI CAM ĐOAN -------------------------------------------------------------------------------1 LỜI CẢM ƠN ------------------------------------------------------------------------------------1 BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ---------------------------------------------1 DANH MỤC HÌNH VẼ ------------------------------------------------------------------------1 DANH MỤC BẢNG BIỂU --------------------------------------------------------------------1 MỞ ĐẦU ------------------------------------------------------------------------------------------1 CHƯƠNG 1: KIẾN THỨC CƠ BẢN -------------------------------------------------------4 1.1 Tính toán đám mây--------------------------------------------------------------------4 1.1.1 Giới thiệu về tính toán đám mây -----------------------------------------------4 1.1.2 Sự phổ biến của ứng dụng dựa vào đám mây ---------------------------------5 1.2 Tích hợp, chuyển giao và triển khai liên tục -------------------------------------6 1.2.1 Tích hợp liên tục ------------------------------------------------------------------6 1.2.2 Chuyển giao liên tục -------------------------------------------------------------7 1.2.3 Triển khai liên tục ----------------------------------------------------------------8 1.3 Kiến trúc hệ thống ---------------------------------------------------------------------8 1.3.1 Kiến trúc một khối----------------------------------------------------------------9 1.3.2 Kiến trúc hướng dịch vụ ------------------------------------------------------- 10 1.3.3 Kiến trúc vi dịch vụ ------------------------------------------------------------ 11 1.4 Các mô hình triển khai ------------------------------------------------------------- 13 1.4.1 Mô hình triển khai tùy biến --------------------------------------------------- 13 1.4.2 Mô hình không tùy biến kết hợp với Reverse Proxy----------------------- 14 1.4.3 Mô hình không tùy biến với ứng dụng vi dịch vụ -------------------------- 15 1.5 Khái niệm Container ---------------------------------------------------------------- 17 CHƯƠNG 2: YÊU CẦU CỦA HỆ THỐNG TRIỂN KHAI LIÊN TỤC ----------- 21 2.1 Yêu cầu về điều phối container --------------------------------------------------- 21 2.1.1 Khám phá dịch vụ -------------------------------------------------------------- 21 2.1.2 Bộ lập lịch ----------------------------------------------------------------------- 22 2.1.3 Điều phối container ------------------------------------------------------------ 23 2.2 Yêu cầu cho các nhà phát triển --------------------------------------------------- 24 2.2.1 Khả năng tự triển khai --------------------------------------------------------- 24 2.2.2 Nhận được các thông tin về kết quả build ----------------------------------- 25 2.3 Yêu cầu về vận hành ---------------------------------------------------------------- 25 2.3.1 Quản lý cấu hình ---------------------------------------------------------------- 25 2.3.2 Thu thập và lưu trữ log -------------------------------------------------------- 25 2.3.3 Giám sát và thông báo lỗi ----------------------------------------------------- 26 2.3.4 Triển khai không bị gián đoạn và có khả năng đảo ngược phiên bản --- 27 2.3.5 Thiết kế mạng triển khai ------------------------------------------------------- 27 CHƯƠNG 3: THIẾT KẾ HỆ THỐNG TRIỂN KHAI LIÊN TỤC ----------------- 28 3.1 Luồng triển khai cơ bản ------------------------------------------------------------ 28 3.2 Phân tích và lựa chọn công nghệ ------------------------------------------------- 29 3.2.1 Hệ thống quản lý mã nguồn --------------------------------------------------- 29 3.2.2 Máy chủ CI và máy chủ triển khai ------------------------------------------- 30 3.2.3 Công nghệ container ----------------------------------------------------------- 32 3.2.4 Nền tảng điều phối container ------------------------------------------------- 32 3.2.5 Kubernetes ----------------------------------------------------------------------- 36 3.2.6 Kênh thông báo ----------------------------------------------------------------- 38 3.2.7 Hệ thống thu thập và quản lý log --------------------------------------------- 39 3.2.8 Công nghệ giám sát hệ thống và cảnh báo ---------------------------------- 41 3.2.9 Giải pháp quản lý cấu hình ---------------------------------------------------- 43 3.3 Luồng triển khai liên tục hoàn thiện--------------------------------------------- 43 CHƯƠNG 4: CÀI ĐẶT VÀ ĐÁNH GIÁ ------------------------------------------------- 47 4.1 Cài đặt --------------------------------------------------------------------------------- 47 4.1.1 Hệ thống vi dịch vụ mẫu------------------------------------------------------- 47 4.1.2 Cách thức tổ chức mã nguồn và quá trình build ảnh docker -------------- 48 4.1.3 Cài đặt môi trường sản phẩm ------------------------------------------------- 53 4.2 Đánh giá kết quả --------------------------------------------------------------------- 58 KẾT LUẬN ------------------------------------------------------------------------------------- 61 TÀI LIỆU THAM KHẢO ------------------------------------------------------------------- 63 PHỤ LỤC --------------------------------------------------------------------------------------- 65 BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT STT Thuật ngữ viết tắt Thuật ngữ đầy đủ 1 EFK Elasticsearch, Fluentd, Kibana 2 VPC Virtual Private Cloud 3 VM Virtual Machine 4 CI Continuous Integration 5 IaaS Infrastructure as a Service 6 PaaS Platform as a Service 7 SaaS Software as a Service 8 IAC Infrastructure as code 9 DNS Domain Name System 10 SOA Service Oriented Architecture 11 Container Công nghệ container, ảo hóa mức hệ điều hành DANH MỤC HÌNH VẼ Hình 1.1: Các bước cơ bản trong tích hợp liên tục [5] ........................................ 7 Hình 1.2: Bảng so sánh kiến trúc một khối, kiến trúc hướng dịch vụ và kiến trúc vi dịch vụ [5] ......................................................................................................... 8 Hình 1.3: Kiến trúc một khối cho ứng dụng đặt hàng ......................................... 9 Hình 1.4: Kiến trúc hướng dịch vụ cho ứng dụng đặt hàng ............................... 11 Hình 1.5: Kiến trúc vi dịch vụ cho ứng dụng đặt hàng ...................................... 12 Hình 1.6: Mô hình triển khai không tùy biến - cập nhật ứng dụng [5] .............. 14 Hình 1.7: Mô hình triển khai không tùy biến - cấu hình reverse proxy khi cập nhật [5] ................................................................................................................ 15 Hình 1.8: Mô hình triển khai không tùy biến với vi dịch vụ - cập nhật dịch vụ [5] ........................................................................................................................ 16 Hình 1.9: Mô hình triển khai không tùy biến với vi dịch vụ - cấu hình reverse proxy [5].............................................................................................................. 16 Hình 1.10: Công nghệ container ........................................................................ 17 Hình 1.11: Khác biệt giữa container và máy ảo................................................. 18 Hình 1.12: Kiến trúc Docker .............................................................................. 19 Hình 1.13: Kiến trúc chi tiết của Docker ........................................................... 20 Hình 2.1: Bộ lập lịch .......................................................................................... 22 Hình 2.2: Điều phối container và các thành phần .............................................. 23 Hình 2.3: Cách thức thu thập log trước đây ....................................................... 26 Hình 3.1: Luồng triển khai liên tục cơ bản ........................................................ 28 Hình 3.2: Mô hình rẽ nhánh ............................................................................... 30 Hình 3.3: Máy chủ CI Jenkins ........................................................................... 31 Hình 3.4: Kiến trúc master-slave của Jenkins [15] ............................................ 32 Hình 3.5: Kiến trúc của Docker Swarm [16] ..................................................... 33 Hình 3.6: Kiến trúc của Apache Mesos ............................................................. 35 Hình 3.7: Kiến trúc Mesosphes Marathon [17] ................................................. 35 Hình 3.8: Kiến trúc của Kubernetes [10] ........................................................... 36 Hình 3.9: Ánh xạ Service và Pod trong Kubernetes .......................................... 37 Hình 3.10: Phần mềm Slack............................................................................... 39 Hình 3.11: Luồng sử dụng cơ bản Fluentd với Elasticsearch và Kibana ........... 41 Hình 3.12: Heapster trong Kubernetes [20] ....................................................... 42 Hình 3.13: Kiến trúc Prometheus [21] ............................................................... 43 Hình 3.14: Hệ thống triển khai liên tục hoàn thiện ............................................ 44 Hình 3.15: Kết nối mạng triển khai ................................................................... 45 Hình 4.1: Mối quan hệ của ccs-service và forex-service ................................... 47 Hình 4.2: Mỗi vi dịch vụ có thể có nhiều bản sao chạy ..................................... 48 Hình 4.3: Cách tổ chức mã nguồn ..................................................................... 48 Hình 4.4: Cấu hình webhook cho build tiền hợp nhất trên Gitlab ..................... 49 Hình 4.5: Cấu hình Gitlab plugin trên Jenkins cho tiền hợp nhất ...................... 50 Hình 4.6 Trạng thái build tiền hợp nhất được cập nhật theo thời gian thực trên Gitlab................................................................................................................... 51 Hình 4.7: Build tiền hợp nhất chạy thành công ................................................. 51 Hình 4.8: Thông báo từ Jenkins tới Slack .......................................................... 52 Hình 4.9: Groovy DSL cho Jenkins ................................................................... 52 Hình 4.10: Các tác vụ trong Jenkins .................................................................. 53 Hình 4.11: Cách thức kết nối mạng trong kubernetes ....................................... 54 Hình 4.12: Các máy trong Kubernetes cluster ................................................... 55 Hình 4.13: Cách thức cài đặt và quản lý log ...................................................... 55 Hình 4.14: Cách thức cài đặt Prometheus .......................................................... 56 DANH MỤC BẢNG BIỂU Bảng 3-1: So sánh Docker Swarm, Mesosphere Marathon và Kubernetes ....... 38 Bảng 3-2: So sánh Logstash và Fluentd ............................................................. 40 Bảng 4-1: Kết quả của giải pháp triển khai liên tục ........................................... 58 MỞ ĐẦU Trong những thập kỉ qua, chúng ta đã chứng kiến nhiều sự thay đổi trong cách mà một tổ chức phát triển và chuyển giao phần mềm, đặc biệt là về tốc độ và chất lượng chuyển giao [1] . Trước đây, mô hình phát triển phần mềm phổ biến là mô hình thác nước, trong đó việc phát triển được chia làm nhiều giai đoạn từ việc lập kế hoạch, phân tích yêu cầu, thiết kế hệ thống, cài đặt, kiểm thử, triển khai và bảo trì. Tuy nhiên, tỉ lệ thành công của những dự án phát triển phần mềm theo mô hình thác nước là rất thấp. Một trong những lí do phổ biến đó là yêu cầu hệ thống được khảo sát và được sử dụng để xây dựng phần mềm từ đầu dự án về cơ bản không chính xác hoặc có thiếu sót: có những yêu cầu chỉ sinh ra khi người sử dụng thực sự dùng phần mềm. Những phương pháp xây dựng phần mềm linh hoạt (agile) được phát minh để khắc phục những điểm yếu của mô hình thác nước đó. Thay vì để người dùng phải chờ đợi 6 tháng hay 1 năm cho mỗi lần phát hành, các tổ chức sẽ liên tục cập nhật phần mềm cho người sử dụng (thường là 1 tháng), thu thập phản hồi, sửa đổi hay bổ sung thêm yêu cầu để cải tiến phần mềm cho những lần cập nhật sau. Vấn đề phát triển phần mềm đã được cải thiện đáng kể, tuy nhiên vấn đề mới lại nảy sinh: các công việc liên quan tới vận hành cũ không còn theo kịp tốc độ phát triển phần mềm: những nhà phát triển muốn phát hành bản cập nhật mới nhanh nhất có thể để có thể lấy phản hồi từ người sử dụng, nhưng qúa trình từ các bản dịch tới khi sản phẩm được triển khai thành công mất nhiều thời gian. Các khái niệm tích hợp, chuyển giao và triển khai liên tục được giới thiệu với những kinh nghiệm thực tiễn giúp giải quyết vấn đề nêu trên. Tuy nhiên, do giới hạn về công nghệ, mục tiêu của triển khai liên tục chưa đạt được vào thời điểm mà nó được giới thiệu: triển khai đòi hỏi phần cứng, mà việc chuẩn bị phần cứng mất nhiều thời gian (mua bán, cài đặt, quản lý, ...). Với sự phát triển của Internet và sự xuất hiện của tính toán đám mây, các ứng dụng không còn bị bó buộc vào cơ sở hạ tầng vật lý mà đã có thể được triển khai trên các nền tảng đám mây. Những ứng dụng có thể sử dụng tài nguyên co dãn của đám mây để mở rộng, thu hẹp tùy vào nhu cầu sử dụng. Những ứng dụng như vậy được gọi là những ứng dụng dựa vào đám mây. Kiến trúc các hệ thống phần mềm cũng tiến hóa để sử dụng lợi ích mà nền tảng đám mây mang lại. Trước đây, những dụng máy chủ (server-side application) truyền thống thường được xây dựng bằng một kiến trúc gồm nhiều lớp, với mỗi lớp chứa các loại thành phần khác nhau. 1 Lớp trên cùng, chịu trách nhiệm giao tiếp với người dùng, là lớp giao diện. Lớp giao diện thực hiện việc xử lý các yêu cầu HTTP và trả lại kết quả là giao diện HTML hoặc dữ liệu ở dạng JSON/XML tới người sử dụng. Ngay phía dưới lớp giao diện là lớp logic nghiệp vụ, chịu trách nhiệm tính toán và xử lý dữ liệu thô sang dữ liệu có ý nghĩa theo nghiệp vụ nhất định. Lớp logic nghiệp vụ không tương tác với cơ sở dữ liệu một cách trực tiếp mà dựa vào lớp truy xuất dữ liệu phía dưới. Cuối cùng là lớp truy xuất dữ liệu. Đây là cửa ngõ để truy cập vào cơ sở dữ liệu của các lớp khác. Lớp truy xuất dữ liệu cung cấp giao diện (API) một khối cho các lớp khác, độc lập với cơ sở dữ liệu đang được sử dụng (MySQL, PostgresSQL, …) Những ứng dụng sử dụng kiến trúc này thường được đóng gói và triển khai như một khối thống nhất. Những ứng dụng như vậy gọi là ứng dụng một khối (monolith). Ứng dụng một khối có ưu điểm là dễ phát triển, kiểm thử và triển khai; tuy nhiên do tất cả các thành phần (module) đều được đóng vào một gói, ứng dụng ngày càng trở nên lớn và phức tạp, khiến việc hiểu và sửa đổi ứng dụng khó khăn hơn. Kích cỡ của ứng dụng sẽ làm chậm quá trình khởi động. Mỗi khi có cập nhật gì thì toàn bộ ứng dụng cần phải được triển khai lại, dẫn đến việc triển khai liên tục trở nên khó khăn hơn. Việc scale ứng dụng cũng sẽ đòi hỏi nhiều tài nguyên và phức tạp. Ngoài ra, lỗi trong một module hoàn toàn có thể khiến cho cả ứng dụng một khối bị sập. Khi muốn thay đổi công nghệ mới thì có khi cả ứng dụng cần phải được phát triển lại, gây lãng phí thời gian và tiền bạc. Kiến trúc vi dịch vụ (microservice) được sinh ra để giải quyết những vấn đề trên. Ý tưởng của kiến trúc này là chia ứng dụng ra những dịch vụ nhỏ hơn, hoàn toàn riêng biệt với nhau và giao tiếp với nhau thông qua các API. Ví dụ: những dịch vụ liên quan tới nghiệp vụ được phát triển riêng, cung cấp các API cho các dịch vụ khác. Những thành phần giao diện người dùng cũng được tách ra như một dịch vụ, chúng giao tiếp với những dịch vụ nghiệp vụ để lấy dữ liệu cần thiết và hiển thị lên cho người dùng. Kiến trúc vi dịch vụ giải quyết được những vấn đề mà những ứng dụng một khối gặp phải. Đầu tiên, vviệc chia ứng dụng ra thành những dịch vụ nhỏ hơn cho phép các dịch vụ được phát triển và kiểm thử nhanh chóng, độc lập. Mỗi đội sẽ được giao phát triển một hoặc một vài dịch vụ trong ứng dụng, cách biệt với các dịch vụ khác. Điều này khiến mã nguồn trở nên nhỏ hơn, dễ hiểu và quản lý. Ngoài ra, do tính chất độc lập, mỗi dịch vụ nhỏ trong ứng dụng có thể được triển khai độc lập bởi mỗi đội. Do các dịch vụ trong ứng dụng chỉ giao tiếp với nhau thông qua API, mỗi dịch vụ có thể sử dụng công nghệ riêng. Điều này giúp việc cập nhật công nghệ cho toàn bộ ứng dụng trở nên dễ dàng (cập nhật lần lượt). Nhờ có kiến trúc vi dịch vụ, việc tích hợp liên tục trở nên khả thi do việc triển khai mỗi dịch vụ là độc lập với các dịch vụ khác. 2 Không những thế, việc mmở rộng (scale) ứng dụng trở nên đơn giản và nhanh chóng, do việc mở rộng ứng dụng sẽ được phân nhỏ thành mở rộng các dịch vụ. Kiến trúc vi dịch vụ hiện nay thường được sử dụng cùng với công nghệ container. Mỗi ảnh container là một đóng gói của ứng dụng kèm những thư viện cần thiết để ứng dụng có thể chạy được. Container sử dụng nhân chung với nhân hệ điều hành nên nhẹ hơn nhiều so với công nghệ máy ảo. Ngoài ra, container giúp cho ứng dụng chạy như nhau trên mọi môi trường, do vậy hỗ trợ tốt trong việc triển khai các dịch vụ trong kiến trúc vi dịch vụ. Cùng với nền tảng đám mây, kiến trúc vi dịch vụ và công nghệ container giúp cho ý tưởng về việc triển khai liên tục trở nên ngày một thực tế hơn. Tuy nhiên, vấn đề gặp phải của kiến trúc vi dịch vụ sử dụng container là khi số lượng dịch vụ tăng lên, việc quản lý và phối hợp những dịch vụ đó trở nên khó hơn nhiều lần so với các ứng dụng một khối. Ngoài ra, việc giám sát nhiều dịch vụ cũng phức tạp hơn so với cách triển khai truyền thống; khi có lỗi xảy ra thì việc xem log và sửa lỗi cũng gây những khó khăn nhất định cho đội phát triển. Với thực trạng như vậy, luận văn sẽ đề xuất ra giải pháp để giải quyết những vấn đề trên, từ đó đảm bảo được việc tích hợp, triển khai liên tục cho quá trình phát triển phần mềm. Luận văn bao gồm 04 chương với nội dung của các chương được phân bố như sau: Chương 1 sẽ giới thiệu về các khái niệm cơ bản liên quan tới tính toán đám mây, tích hợp và triển khai liên tục, các kiến trúc hệ thống phần mềm cũng như công nghệ container. Chương 2 tập trung vào việc phân tích yêu cầu để xây dựng mô hình triển khai liên tục cho cho một hệ thống vi dịch vụ sử dụng container. Dựa vào yêu cầu đã được phân tích ở Chương 2, Chương 3 đưa ra đề xuất thiết kế một luồng triển khai liên tục cho các hệ thống dựa trên vi dịch vụ nói chung, đồng thời trình bày và so sánh các công nghệ hiện tại cho các thành phần trong luồng để xây dựng nên một thiết kế hoàn thiện. Trong Chương 4, luận văn trình bày cụ thể cách thức cài đặt một luồng triển khai liên tục mẫu cho hệ thống phần mềm chuyển đổi tiền tệ và đánh giá kết quả đạt được. Phần Kết luận sẽ tổng kết thành quả nghiên cứu của luận văn và hướng phát triển dự định trong tương lai. 3 CHƯƠNG 1: KIẾN THỨC CƠ BẢN Cùng với sự xuất hiện và phổ biến của phương pháp phát triển phần mềm linh hoạt, các ý tưởng mới liên tục xuất hiện để tận dụng tối đa lợi ích mà phương pháp này mang lại. Trong đó, nổi bật nhất là ý tưởng về việc tích hợp, chuyển giao và triển khai liên tục: phần mềm sẽ được dịch (build), đóng gói và phát hành ngay khi có sự thay đổi trên hệ thống quản lý mã. Tuy nhiên, ý tưởng này không thể thực hiện được tại thời điểm mà nó được đề xuất do nhiều giới hạn về công nghệ và cơ sở hạ tầng. Với sự xuất hiện của tính toán đám mây, sự tiến hóa trong kiến trúc phần mềm (từ kiến trúc một khối tới kiến trúc vi dịch vụ) hay ý tưởng về đóng gói ứng dụng trong container, việc xây dựng một hệ thống triển khai liên tục đã trở nên khả thi hơn. Để giúp làm rõ hơn những nội dung trong các chương tiếp theo, chương này sẽ giới thiệu các khái niệm cơ bản nêu trên một cách chi tiết. 1.1 Tính toán đám mây 1.1.1 Giới thiệu về tính toán đám mây Tính toán đám mây là sự cung cấp, phân phối sức mạnh tính toán, hệ thống lưu trữ, ứng dụng hoặc các nguồn tài nguyên công nghệ thông tin khác thông qua nền tảng đám mây, sử dụng kênh truyền internet và giá cả được tính toán dựa vào khối lượng sử dụng [2]. Sử dụng tính toán đám mây, một công ty hay tổ chức không cần đầu tư nhiều chi phí ban đầu vào việc chuẩn bị các thiết bị phần cứng, hay dành nhiều thời gian để quản lý chúng. Thay vào đó, công ty/tổ chức chỉ cần cung cấp đúng yêu cầu về chủng loại và kích thước nguồn tài nguyên tính toán cho nhà cung cấp dịch vụ, mọi thứ sẽ được cung ứng gần như ngay lập tức. Một đặc điểm quan trọng của đám mây đó là các dịch vụ gần như trong suốt với người dùng, nghĩa là người dùng gần như không cần quan tâm làm thế nào mà dịch vụ đó được cung ứng mà chỉ cần tập trung vào việc làm thế nào để sử dụng chúng. Với giao diện người dùng đơn giản, hầu hết các dịch vụ đám mây đòi hỏi rất ít kiến thức về quản trị. Tính toán đám mây được chia thành ba mô hình cơ bản [3]: • Cơ sở hạ tầng như một dịch vụ (Infrastructure as a service - IaaS): cung cấp cho người dùng các tài nguyên tính toán ở cấp độ thấp nhất, bao gồm: máy chủ, mạng, hệ thống lưu trữ, trung tâm dữ liệu, ... và giá cả tính theo khối lượng sử dụng. Đối với người sử dụng, đặc biệt là các doanh nghiệp, lợi ích mà IaaS mang lại là rất lớn, điển hình là việc không cần đầu tư phần cứng, cơ sở hạ tầng 4 có thể thay đổi linh động tùy vào nhu cầu sử dụng và việc có nhiều dịch vụ linh hoạt, sáng tạo đi kèm. • Nền tảng như một dịch vụ (Platform as a service - PaaS): cung cấp môi trường được xây dựng trên nền tảng đám mây với tất cả mọi thứ cần thiết để phát triển và chuyển giao những ứng dụng trên nền web (cloud). Người dùng không cần gánh chi phí cũng như quan tâm tới các công việc phức tạp liên quan tới việc mua, quản lý thành phần phần cứng, phần mềm, cung ứng hay hosting như cách truyền thống. Lợi ích của PaaS đối với người dùng trước hết là ở việc phát triển và đưa phần mềm ra thị trường nhanh hơn so với trước đây, việc triển khai phần mềm mới lên đám mây chỉ mất vài phút. Ngoài ra, Paas giúp giảm thiểu sự phức tạp của việc quản lý phần giữa (middleware). • Phần mềm như một dịch vụ(Software as a service - SaaS): là các ứng dụng trên nền tảng đám mây, chạy trên những máy tính "nằm trong đám mây", được sở hữu và vận hành bởi nhà cung cấp nền tảng đám mây, kết nối tới người dùng qua internet và trình duyệt. Với SaaS, người dùng có thể nhanh chóng đăng kí và bắt đầu sử dụng phần mềm mà gần như không phải làm bất cứ việc gì liên quan tới phát triển; các ứng dụng và dữ liệu có thể được truy cập từ bất cứ máy tính nào có kết nối Internet. Người dùng cũng không cần lo lắng về việc mất mát dữ liệu do dữ liệu đã được lưu trữ trong đám mây. Hơn thế, các dịch vụ có khả năng scale linh hoạt theo nhu cầu sử dụng, do vậy hiệu năng luôn được đảm bảo. 1.1.2 Sự phổ biến của ứng dụng dựa vào đám mây Việc chuyển đổi sang đám mây là sự phát triển tự nhiên đối với việc cung ứng các dịch vụ công nghệ thông tin. Nền tảng đám mây cung cấp một môi trường với các tài nguyên đa dạng, từ tính toán, lưu trữ cho tới mạng, có khả năng co dãn, linh động theo nhu cầu sử dụng. Ngày càng nhiều công ty, tổ chức chuyển dần sang phát triển phần mềm, ứng dụng cho nền tảng đám mây thay vì cách phát triển truyền thống, bởi: • Tốc độ: Ngày nay tốc độ có yếu tố quan trọng quyết định sự tồn tại của một công ty, tổ chức. Các tính năng mới khi được hoàn thành cần được triển khai ngay để thu hút người sử dụng, giành lấy thị phần. Những công ty lớn như Google, Facebook, Amazon, Uber, Grab, ... triển khai tính năng mới, hay đơn giản chỉ là bản vá, bản nâng cấp hàng chục tới hàng trăm lần mỗi ngày. Điều này giúp họ thu hút người dùng trước khi đối thủ kịp phản ứng, nhanh chóng sửa lỗi trước khi có vấn đề phát sinh. Đặc điểm co dãn và khả năng kết nối của đám mây giúp việc triển khai liên tục này trở nên khả thi. 5 • Khả năng cô lập lỗi: Kiến trúc sử dụng cho các ứng dụng dựa vào đám mây giúp cho việc cô lập lỗi trở nên dễ dàng hơn. Đối với các phần mềm truyền thống, kiến thúc thường được sử dụng là một khối, tuy nhiên đối với nền tảng đám mây, kiến trúc phổ biến nhất hiện nay là vi dịch vụ. Với vi dịch vụ, khi lỗi xảy ra, chỉ những thành phần có lỗi bị ảnh hưởng. Chúng có thể được tắt đi và thay thế mà không gây ảnh hưởng tới cả hệ thống tổng thể. Cụ thể về kiến trúc này sẽ được giới thiệu trong các phần sau. • Khả năng co dãn (scale): Khi ứng dụng giành được thị phần nhất định, số lượng người dùng có thể sẽ tăng lên nhanh chóng. Trước khi xuất hiện nền tảng đám mây, các công ty thường phải nâng cấp phần cứng cho máy chủ bằng việc nâng cao sức mạnh máy (scale-up), do việc mở rộng năng lực theo chiều ngang (scale-out) đòi hỏi quá trình mua máy, cài đặt, tích hợp mất quá nhiều thời gian và phần mềm truyền thống không được thiết kế phù hợp cho việc scale-out. Kể cả khi việc scale-out có thể được thực hiện thì cũng không hiệu quả. Với sự xuất hiện của những nền tảng đám mây như Amazon Web Services (AWS), Google Cloud Platform (GCP) hay Microsoft Azure, cùng với việc xuất hiện các công nghệ, kiến trúc mới cho nền tảng đám mây, việc mở rộng theo chiều ngang (scale-out) có thể được thực hiện chỉ trong vòng vài phút. 1.2 Tích hợp, chuyển giao và triển khai liên tục 1.2.1 Tích hợp liên tục Tích hợp liên tục là quá trình tự động hóa việc dịch (build) và kiểm thử mã mỗi khi các thành viên trong đội cập nhật mã lên hệ thống quản lý phiên bản (tích hợp liên tục đòi hỏi những nhà phát triển phải tích hợp mã vào một kho chứa mã duy nhất). Tích hợp liên tục khuyến khích các nhà phát triển chia sẻ mã và các bài kiểm thử đơn vị (unit test) bằng việc hợp nhất những thay đổi trên máy lên kho quản lý mã chung ngay khi hoàn thiện một tác vụ nhỏ nào [4]. Từ yêu cầu hợp nhất, các máy chủ sẽ kích hoạt luồng (pipeline): lấy mã mới về máy chủ CI, chạy quá trình dịch, kiểm thử, … Nếu có lỗi xảy ra ở bất cứ phần nào trong luồng, sửa lỗi là việc được ưu tiên hàng đầu. Tích hợp liên tục ngày càng trở nên phổ biến hơn bởi những nhà phát triển phần mềm thường sẽ làm việc một cách độc lập, và cuối cùng họ sẽ cần tích hợp mã với những thành viên khác trong đội, hoặc rộng hơn là các đội khác trong công ty. Việc chờ đợi nhiều ngày để tích hợp mã sẽ gây ra nhiều lỗi hợp nhất (merge conflict) khó giải quyết. Luồng (pipeline) tích hợp được khởi động mỗi khi có mã được đẩy lên kho chứa mã chung giúp giảm thiểu đáng kể vấn đề trên. 6 Với mỗi công ty, tổ chức, pipeline tích hợp được xác định tùy thuộc vào công cụ sử dụng, ngôn ngữ lập trình cũng như rất nhiều yếu tố khác, tuy nhiên luồng thực hiên cơ bản bao gồm các bước sau [5]: 1. Đẩy mã lên kho chứa mã chung 2. Phân tích tĩnh 3. Kiểm thử trước khi triển khai 4. Đóng gói và triển khai lên môi trường kiểm thử 5. Kiểm thử sau khi triển khai 1.2.2 Chuyển giao liên tục Về cơ bản, một luồng chuyển giao liên tục bao gồm các bước giống như luồng tích hợp liên tục đã liệt kê ở phần trước đó. Điểm khác biệt lớn nhất đó là: bước "5. Kiểm thử sau khi triển khai" trong tích hợp liên tục thường đòi hỏi việc can thiệp bằng tay. Các bản dịch không vượt qua được các bài kiểm tra ở bước này sẽ bị loại. Còn trong Chuyển giao liên tục, sẽ có các cơ chế để tự động hóa bước này. Kết quả cuối cùng là một bản dịch mà luôn sẵn sàng để triển khai trên môi trường sản phẩm thực tế. Hình 1.1: Các bước cơ bản trong tích hợp liên tục [5] 7 1.2.3 Triển khai liên tục Triển khai liên tục là mục tiêu cuối cùng trong chuỗi tự động hóa này. Bản dịch cuối cùng sau bước chuyển giao liên tục là bản dịch luôn sẵn sàng để triển khai vào môi trường thực tế, tuy nhiên việc triển khai hay không và chọn phiên bản nào để triển khai lại phụ thuộc vào quyết định của đội vận hành. Trong triển khai liên tục, bất cứ bản dịch nào vượt qua được tất cả các bài kiểm thử đều sẽ được triển khai tự động lên môi trường sản phẩm thực tế. Không có sự can thiệp của con người trong qúa trình này. 1.3 Kiến trúc hệ thống Trong những năm gần đây, kiến trúc phần mềm web đã phát triển với một tốc độ nhanh chóng. Với sự phổ biến của các dịch vụ Internet, chúng ta có thể thấy sự chuyển dịch từ kiến trúc một khối theo tầng/lớp, sang kiến trúc hướng dịch vụ và như hiện nay là kiến trúc vi dịch vụ. Việc lựa chọn một kiến trúc phần mềm cụ thể phụ thuộc hoàn toàn vào những yêu cầu về khả năng co dãn (scale), độ phức tạp hay khả năng triển khai. Đối với ứng dụng web, khả năng co dãn là một trong những yếu tố quan trọng hàng đầu. Hình 1.2 thể hiện sự so sánh của ba kiểu kiến trúc nêu trên về khả năng co dãn (scale) và sự tách biệt của các thành phần trong hệ thống. Hình 1.2: Bảng so sánh kiến trúc một khối, kiến trúc hướng dịch vụ và kiến trúc vi dịch vụ [6] 8 1.3.1 Kiến trúc một khối Kiến trúc một khối thường sẽ gộp những tính năng thiết yếu lại, từ đó phát triển cũng như triển khai như một khối duy nhất. Trong kiến trúc một khối, cách thiết kế phổ biến là phân chia các thành phần theo dạng module hoặc theo lớp. Ví dụ: phân chia thành lớp giao diện người dùng, tới lớp logic nghiệp vụ, lớp truy cập cơ sở dữ liệu và cuối cùng là lớp tích hợp để tích hợp với các dịch vụ ngoài. Hình 1.3: Kiến trúc một khối cho ứng dụng đặt hàng Ưu điểm của kiến trúc này bao gồm: Đơn giản hóa cho việc phát triển và kiểm thử: do các thành phần đều được đóng gói vào làm một, việc phát triển và kiểm thử chỉ cần thực hiện trên một khối. Đơn giản cho việc triển khai: khi máy chủ đã được cài đặt các phần mềm thiết yếu, cách triển khai đơn giản nhất là chỉ cần sao chép phần mềm đã đóng gói vào máy chủ và chạy. Đơn giản trong việc scale theo chiều ngang: phân chia dữ liệu ra thành các thành phần khác nhau, sao chép ứng dụng ra thành nhiều phần, mỗi phần truy cập vào một phần dữ liệu, đặt tất cả các thành phần đằng sau một bộ Load Balancer. Kiến trúc này về cơ bản vẫn hoạt động tốt đối với những giai đoạn đầu của dự án. Nhiều hệ thống phần mềm lớn hiện nay vẫn đang sử dụng kiến trúc này. Tuy nhiên, kiến trúc một khối có nhiều điểm hạn chế như [7]: cách tiếp cận này có giới hạn về 9 kích thước và độ phức tạp, ứng dụng có thể trở nên quá lớn, phức tạp để có thể hiểu và tiếp tục phát triển hay kích cỡ của ứng dụng làm việc khởi động trở nên chậm hơn. Ngoài ra, mỗi khi có cập nhật gì thì đều cần triển khai lại toàn bộ ứng dụng, do vậy việc triển khai liên tục trở nên khó khan. Nếu việc phân chia dữ liệu khó khăn, ứng dụng khó có thể scale theo chiều ngang như miêu tả ở trên. Ngoài ra, ứng dụng một khối có nhiều rào cản trong việc áp dụng các công nghệ mới, bởi việc thay đổi trong bộ khung hay ngôn ngữ lập trình có thể ảnh hưởng tới toàn bộ ứng dụng. 1.3.2 Kiến trúc hướng dịch vụ Kiến trúc hướng dịch vụ (Service-Oriented Architecture) nổi lên như một cách để giải quyết vấn đề các thành phần phụ thuộc vào nhau quá nhiều trong kiến trúc một khối. Kiến trúc hướng dịch vụ là mẫu kiến trúc phần mềm trong đó các thành phần ứng dụng cung cấp dịch vụ cho các thành phần khác thông qua giao thức giao tiếp qua mạng [8]. Có hai vai trò chính trong kiến trúc hướng dịch vụ: vai trò thành phần cung cấp dịch vụ và vai trò thành phần tiêu thụ dịch vụ. Một phần mềm có thể đóng cả hai trò, tùy vào từng hoàn cảnh cụ thể. Lớp tiêu thụ là điểm mà những thành phần tiêu thụ (có thể là người dùng, dịch vụ khác hoặc các bên thứ ba) tương tác với kiến trúc hướng dịch vụ, và Lớp cung cấp là lớp chứa tất cả các dịch vụ được định nghĩa trong kiến trúc hướng dịch vụ. Đường giao tiếp dịch vụ doanh nghiệp (Enterprise Service Bus-ESB) là một kiểu kiến trúc tích hợp cho phép giao tiếp được thực hiện thông qua một bus chứa nhiều kết nối điểm-tới-điểm (point-to-point) giữa thành phần cung cấp và tiêu thụ. Hình 1.4 đưa ra một ví dụ về kiến trúc hướng dịch vụ sử dụng trong hệ thống đặt hàng. 10