Giới thiệu công nghệ MicroServices

Giới thiệu Microservices (kiến trúc nhiều dịch vụ nhỏ) Microservices quan tâm giới phần mềm, công nghệ với nhiều viết, blog, thảo luận, truyền thông, hội thảo Kỳ vọng khả Microservice lên đỉnh giống xu hướng thời trang lan rộng Ngược lại, số người cho rằng, microservices khơng có lạ, chẳng qua SOA (kiến trúc hướng dịch vụ) đánh bóng, đổi tên mà Bài viết dịch từ viết "Introduction to Microservices" tác giả Chris Richardson Bài viết dài, nên nhiều chỗ phải lược dịch Một số chỗ khó hiểu người đọc VN, nên tơi thêm thích Một số quan điểm thiên kiến, khen Microservices, liệt kê nhược điểm khơng giải thích rõ trường hợp nhược điểm có giải pháp xử lý Tuy nhiên phải cơng nhận viết tốt đáng đọc Tiếp sau chủ đề Mặc cho kỳ vọng cao, hay đánh giá bảo thủ, kiến trúc microservices đem lại lợi ích giúp phương pháp agile thực hiệu xây dựng giải pháp phần mềm doanh nghiệp phức tạp Bài viết giải thích cơng ty, tổ chức bạn nên cân nhắc áp dụng kiến trúc microservices Xây dựng ứng dụng khối (monolithic applications) Tưởng tượng bạn phải xây dựng dịch vụ gọi taxi qua di động cạnh tranh với Uber Hailo Sau số buổi họp thu thập yêu cầu phân tích thiết kế, bạn chọn công nghệ (technology stack) tạo dự án Rails, Spring Boot, Play, hay Maven Dự án có kiến trúc chia khối lục giác (hexagol architecture) Kiến trúc đa diện giúp ứng dụng chun biệt mơ hình liệu đầu vào, đầu Trong lõi ứng dụng business logic thể khối dịch vụ, đối tượng cho vùng nghiệp vụ (domain objects) kiện (events: khách đặt xe, khách hủy xe, xe nhận khách ) Xung quanh lõi chuyển đổi (adapter) ví dụ kết nối vào sở liệu, gửi nhận thông điệp (messaging), web service giao diện web front end Kiến trúc khối có nhiều mặt, business logic trung tâm Mặc dù có cấu trúc module hóa hợp lý, ứng dụng kiểu đóng gói cài đặt thành khối (monolithic) Mã chạy cụ thể tùy thuộc vào ngôn ngữ lập trình hay thư viện framework Ví dụ ứng dụng Java đóng file WAR, triển khai application server Tomcat hay Jetty Dùng framework khác, ứng dụng Java file tự đóng gói để chạy JAR Ứng Rails hay Node.js đóng gói theo cấu trúc thư mục phân cấp Ứng dụng viết kiểu phổ biến Chúng dễ viết, dễ thử nghiệm, dễ copy & paste công cụ lập trình IDE dự án mẫu tối ưu để tạo ứng dụng khối đơn /*Do cần thuyết phục lập trình viên theo cơng nghệ/framework nên nhà sản xuất phải lập trình cần New Project, ấn nút Build & Run ứng dụng chạy ln*/ Có thể kiểm thử tự động giao diện web với Selenium Ứng dụng khối đơn dễ triển khai PHP, Python cần cập nhật mã Một số khác có chức khởi động nóng (hot reload: dịch lại nạp lên chạy tiếp) Node.js, Play Framework, Revel Để tăng khả chịu tải bổ xung thêm web application server giống sau cân tải (load balancer) /*Tất nhiên mở rộng sở liệu liên tục ghi thành nhiều không dễ dàng*/ Địa ngục kiến trúc khối Đáng tiếc rằng, cách tiếp cận kiến trúc đơn dễ dàng bắt đầu bộc lộ nhiều khiếm khuyết Ứng dụng thành công - số lượng người dùng tăng - yêu cầu tính tăng - liệu tăng - logic phức tạp - giao tiếp với hệ thống khác tăng kết ứng dụng khủng Sau kỳ phát triển (sprint), đội phát triển bổ xung vài tính mới, thêm code, thêm bảng, thêm logic Chỉ sau vài năm, ứng dụng đơn giản kềnh qi vật Tơi có trao đổi với lập trình viên, người viết cơng cụ phân tích phụ thuộc hàng nghìn gói thư viện JAR ứng dụng hàng triệu dòng code Chắc chắn số lượng lớn man month tiền để tạo quái vật khủng đến Ứng dụng khối mà phình to rắc rối gia đình nhiều hệ đơng nhà Nhà to đến gặp vấn đề Mọi nỗ lực tối ưu, phương pháp làm việc agile (mềm dẻo) khơng hiệu Một thư viện tham chiếu nhiều chỗ nâng cấp phải kiểm tra tất điểm, nghiệp vụ mà gọi Ứng dụng đơn dùng ngơn ngữ lập trình Đội lập trình quen với thuận tiện, dễ dàng cần nắm sâu ngôn ngữ, công cụ giải hầu hết vấn đề Họ dần lệ thuộc vào ngơn ngữ trở nên thiên vị, ngại cởi mở, tích hợp với cơng nghệ khác ngơn ngữ khác Thậm chí framework hay ngơn ngữ có nhược điểm cố hữu, tính đơn khối ứng dụng bó buộc lập trình viên thử nghiệm đưa vào thay đổi đột phá ngoại lai Ứng dụng khối có triệu dòng mã framework XYZ, liệu đội bạn có đủ dũng cảm, nguồn lực để viết lại toàn framework ABC hơn, tốt Lập trình giỏi, sáng tạo không muốn làm kiểu dự án mặc kẹt Tình trạng giữ khổ, xây khó, khiến dịch vụ - sản phẩm bạn ì ạch cạnh tranh so với dịch vụ uyển chuyển, linh hoạt Trong ứng dụng khối, chặt chẽ ưu điểm tự nhiên xuất phát từ kiến trúc, tiềm ẩn nguy ràng buộc cứng nhắc đóng bê tơng (tight coupling) Chi phí, thời gian, nỗ lực phát triển - sửa lỗi - kiểm thử chức tăng tỷ lệ bậc theo độ lớn ứng dụng Nói cách khác đi, mã nguồn khó đọc, khó bảo trì tỷ lệ bậc theo số ràng buộc, tham chiếu tạo dễ dãi phát triển Ở tơi có nói đến khả biên dịch nóng - khởi động lại (hot reload) code đổi, hay cân tải cách thêm nhiều ứng dụng web giống sau sau cân tại, ứng dụng to khủng, việc biên dịch nóng kéo dài hơn, khởi động lại chậm đi, copy phiên server lâu Có ứng dụng thời gian khởi động kéo dài từ 12-40 phút Việc lập trình gỡ rối tệ để thay ốc đoàn tầu hỏa chạy, mà phải dừng đoàn tầu khởi động lại Khởi động lại ứng dụng khối giống dừng đoàn tầu Gần đây, bạn nghe nói nhiều triển khai đặn (continous deployment) Những ứng dụng SaaS (Software application as Service) tiên tiến, cần phải cập nhật vài lần ngày Quá khó để triển khai lại ứng dụng cực lớn số nâng cấp nhỏ Hoạt động bị ngưng trệ, kiểm thử lại sau triển khai lâu công Kết triển khai đặn khó áp dụng với ứng dụng khối Khả mở rộng chịu tải ứng dụng khối khó thành phần khác tranh chấp, dị biệt nhu cầu dùng tài nguyên hệ thống Ví dụ module xử lý ảnh cần triển khai Amazon EC2 tối ưu CPU, khó cho module lưu nhớ tạm (cache) cần nhiều nhớ phải triển khai EC2 tối ưu nhớ Tóm lại, bám vào kiến trúc khối, vé xuống địa ngục cao lên thiên đường Microservice - đơn giản hóa phức tạp Nhiều tập đoàn Amazon, eBay, Netflix giải vấn đề ứng dụng khối kiến trúc microservices (nhiều dịch vụ nhỏ) Ý tưởng chia nhỏ ứng dụng lớn thành dịch vụ nhỏ kết nối với Mỗi dịch vụ nhỏ thực tập chức chuyên biệt quản lý đơn hàng, quản lý khách hàng Mỗi dịch vụ ứng dụng nhỏ có kiến trúc đa diện lõi business logic kết nối adapter khác Một số dịch vụ nhỏ lộ giao tiếp lập trình API cho dịch vụ nhỏ khác hay ứng dụng client gọi tới Khi vận hành, dịch vụ nhỏ chạy máy ảo (virtual machine) Docker container (ảo hóa tầng ứng dụng) Microservices công ty điều hành taxi kiểu Uber, Hailo Mỗi vùng chức thực thị dịch vụ nhỏ Ứng dụng web chia nhỏ chuyên cho đối tượng người dùng (một cho hành khách taxi, cho tài xế) Thiết kế giao diện cho đối tượng người dùng giúp tối ưu trải nghiệm tốt hơn, tốc độ nhanh hơn, dễ tương thích chức tối giản Mỗi dịch vụ đằng sau (back end service) lộ REST API (hiện nhiều lựa chọn khác Google Protobuf, Apache Thrift, Apache Avro tốn băng thông REST JSON) Các dịch vụ gọi / sử dụng API cung cấp dịch vụ khác Ví dụ dịch vụ quản lý tài xe sử dụng Notification Server để chủ động báo tài xế rảnh đón khách hàng tiềm Phần giao diện (UI services) gọi đến dịch vụ khác để lấy liệu hiển thị Hiện nay, pattern reactive cho phép dịch vụ thơng báo chủ động gửi liệu để giao diện cập nhật Đặc điểm kết nối dịch vụ là: - Synchronous (đồng - gọi xong chờ) - Asynchronous (bất đồng - gọi xong chạy tiếp Khi có kết xử lý), Cách gọi: - REST (tập lệnh gửi qua HTTP để truy vấn, thao tác liệu Kiểu liệu XML, JSON, JSONb) - RPC (remote procedure call -lệnh gọi từ xa Kiểu liệu binary, Thrift, Protobuf, Avro) - SOAP (Simple Object Access Protocol) Một số dịch API REST lộ cho thiết bị di động hành khách tài xế kết nối Ứng dụng người dùng cuối không kết nối trực tiếp vào dịch vụ đằng sau Thay vào có cổng API (API gateway) đứng Cổng API có số nhiệm vụ phân tải, lưu tạm (cache), kiểm tra quyền truy cập, đo theo dõi (API metering and monitoring) Kiến trúc microservice tương đương trục Y chiều mở rộng chịu tải (Scale Cube): trục X : bổ xung thêm web application sau phân tải trục Y: chia nhỏ ứng dụng khối thành nhiều dịch vụ nhỏ trục Z: phân vùng liệu để xử lý song song vùng trục Scale Cube Biểu đồ mô tả dịch vụ điều xe triển khai với Docker chạy Amazon EC2 Để tăng khả sẵn sàng, Docker container chạy máy ảo mây độc lập Nginx làm nhiệm vụ phân tải, phân phối đặn yêu cầu đến dịch vụ Các dịch vụ chạy Docker Container khác nhau, phía trước phân tải Kiến trúc microservices ảnh hưởng lớn đến quan hệ ứng dụng sở liệu Thay dùng chung sở liệu dịch vụ, dịch vụ có CSDL riêng /*Cách ngược lại tập quán tập trung hóa sở liệu Hệ có dư thừa liệu, chế foreign key ràng buộc quan hệ liệu áp dụng với bảng sở liệu tách biệt Thiết kế gây sốc nhiều lập trình q quen với mơ hình client - server, sở liệu ln trung tâm, tập hợp bảng.*/ Tuy nhiên, lưu liệu dịch vụ quan trọng bạn muốn kiến trúc microservice thực hiệu đảm bảo loose coupling (ít ràng buộc) /*Chú ý khuyến nghị tác giả, thực tế, vài dịch vụ dùng chung CSDL tính toàn vẹn liệu (ACID Atomicity, Consistency, Isolation, Durability) cần ưu tiên cao nhất.*/ Dịch vụ sử dụng sở liệu cục Từng dịch vụ nhỏ tùy chọn công nghệ lưu trữ liệu tối ưu ~ polygot persistence architecture Ví dụ: dịch vụ điều xe cần phải dùng CSDL hỗ trợ việc truy vấn theo tọa độ tốt Dịch vụ cache dùng công nghệ lưu tạm nhớ, in memory key-value storage Redis Phía bề nổi, kiến trúc microservice tương tự SOA (kiến trúc hướng dịch vụ) Cả hai có tập dịch vụ Điểm khác microservice khơng dùng chuẩn tập đồn lớn IBM, Microsoft, Oracle đặt WS-* hay Enterprise Service Bus Nó hướng đến chuẩn có tính cạnh tranh cao Protobuf, Thrift cởi mở hơn, dễ đọc JSON Microservices công ty start up khởi xướng từ 2010, SOA tập đoàn lớn đề xuất từ 1990 giải pháp thương mại họ ưu tiên dùng thông điệp dạng XML Microservice không áp dụng số phần SOA canonical schema (phân cấp thông điệp từ mức tập đồn - cơng ty - phòng ban - phận) Có thể thấy Microservice gọn hơn, đa dạng giao thức - chuẩn liệu Ưu điểm Microservices 1- Giảm thiểu gia tăng phức tạp rối rắm hệ thống lớn 2- Chia nhỏ ứng dụng khối cồng kềnh thành dịch vụ nhỏ dễ quản lý, bảo trì nâng cấp, tự chọn, nâng cấp cơng nghệ 3- Mỗi dịch vụ nhỏ định ranh giới rõ ràng dạng RPC hay API hướng thơng điệp 4- Microservice thúc đẩy tách rạch ròi khối chức (loose coupling - high cohesion), điều khó thực với ứng dụng khối Nếu muốn loose coupling high cohesion ứng dụng khối, phải thiết kế theo Design Pattern (Gang Of Four) liên tục tái cấu trúc (refactor) Mỗi dịch vụ nhỏ phát triển dễ hơn, nhanh hơn, dễ viết mã kiểm thử tự động Một số dịch vụ có thuê phát triển mà bảo mật hệ thống - mã nguồn phần dịch vụ lại Đội phát triển có nhiều lựa chọn cơng nghệ mới, framework, CSDL mới, đa dạng để nâng cấp dịch vụ nhỏ, chọn môi trường tối ưu để chạy Các dịch vụ bật tắt để kiểm nghiệm so sánh A|B, tăng tốc trình cải tiến giao diện Triển khai đặn khả thi với microservice Dịch vụ nhỏ đóng gói Docker container chuyển từ mơi trường phát triển sang môi trường chạy thật cấu hình thủ cơng lại, khơng phải copy file q lớn Nhược điểm microservices Nhược điểm microservices từ tên gọi Microservice nhấn mạnh kích thước nhỏ gọn dịch vụ Một số lập trình đề xuất dịch vụ siêu nhỏ cỡ 100 dòng code Chia nhiều dẫn đến manh mún, vụn vặt, khó kiểm sốt Việc lưu liệu cục bên dịch vụ nhỏ khiến liệu phân tán mức cần thiết Nhược điểm tiếp microservice đến từ đặc điểm hệ thống phân tán (distributed system): 1- Phải xử lý cố kết nối chậm, lỗi thông điệp không gửi thơng điệp gửi đến nhiều đích đến vào thời điểm khác 2- Đảm bảo giao dịch phân tán (distributed transaction) cập nhật liệu đắn (all or none) vào nhiều dịch vụ nhỏ khác khó nhiều, so với đảm bảo giao dịch cập nhật vào nhiều bảng sở liệu trung tâm 3- Theo nguyên tắc CAP (CAP theorem) giao dịch phân tán thỏa mãn điều kiện: consistency (dữ liệu điểm khác mạng phải giống nhau), availablity (yêu cầu gửi phải có phúc đáp), partition tolerance (hệ thống hoạt động mạng bị lỗi) Những công nghệ sở liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt chưa vượt qua nguyên tắc CAP 4- Kiểm thử tự động dịch vụ kiến trúc microservices yêu cầu phải chạy dịch vụ nhỏ khác mà phụ thuộc Do phân rã ứng dụng khối thành microservices cần kiểm tra mức độ ràng buộc dịch vụ mềm dẻo hay cứng nhắc - lệ thuộc Nếu ràng buộc đi, lỏng leo hơn, bạn hướng ngược lại 5- Nếu dịch vụ nhỏ thiết kế phục thuộc vào theo chuỗi A gọi B, B gọi C, C gọi D Nếu mắt xích có giao tiếp API thay đổi, liệu mắt xích khác có phải thay đổi theo khơng? Nếu có việc bảo trì, kiểm thử phức tạp tương tự ứng dụng khối Thiết kế dịch vụ tốt giảm tối đa ảnh hưởng lan truyền đến dịch vụ khác t hay đổi lan truyền ứng dụng khiến cho việc nâng cấp, kiểm tra khó khăn 6- Cuộc họp có người có bắt tay, người có bắt tay người có bắt tay, có 10 bắt tay Tổ hợp chập = 10, công thức tổng quát = n! /((n-2)! * 2!) Thực dịch vụ microservice giao tiếp với tất dịch vụ lại Nhưng khơng có quy tắc phân luồng - quản lý - đo đếm - theo dõi (manage meter - monitor) , số lượng kết nối dịch vụ nhỏ gia tăng tùy tiện, chất lượng kết nối khơng kiểm sốt Hệ thống chậm khơng thể biết đoạn nghẽn cổ chai đâu? Kết nối dịch vụ rối rắm 7- Triển khai dịch vụ microservices làm thủ công theo cách làm với ứng dụng khối phức tạp nhiều Ứng dụng khối bổ xung server giống hệt đằng sau cần Trong kiến trúc microservice, dịch vụ nhỏ nằm nhiều máy ảo hay Docker container khác nhau, dịch vụ có nhiều thực thể phân tán nhiều Theo Adrian Crockcroft, Hailo có 160 dịch vụ, NetFlix có 600 dịch vụ Trong dịch vụ đám mây, máy ảo, docker container, thực thể linh động bật tắt, dịch chuyển Vậy cần thiết phải có chế phát dịch vụ (service discovery mechanism) để cập nhật tự động địa IP cổng, mô tả, phiên dịch vụ ZooKeeper: giải pháp service discovery Kết luận Kiến trúc khối hữu hiệu ứng dụng đơn giản, chức Nó bộc lộ nhiều nhược điểm ứng dụng phát triển lớn nhiều chức Kiến trúc microservices chia nhỏ kiến trúc khối dịch vụ nhỏ Microservices hiệu quả, phù hợp cho ứng dụng phức tạp, liên tục phát triển thiết kế tận dụng công nghệ quản lý, vận hành tự động  ... động mạng bị lỗi) Những công nghệ sở liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt chưa vượt qua nguyên tắc CAP 4- Kiểm thử tự động dịch vụ kiến trúc microservices yêu cầu... nhiều chức Kiến trúc microservices chia nhỏ kiến trúc khối dịch vụ nhỏ Microservices hiệu quả, phù hợp cho ứng dụng phức tạp, liên tục phát triển thiết kế tận dụng công nghệ quản lý, vận hành... Ưu điểm Microservices 1- Giảm thiểu gia tăng phức tạp rối rắm hệ thống lớn 2- Chia nhỏ ứng dụng khối cồng kềnh thành dịch vụ nhỏ dễ quản lý, bảo trì nâng cấp, tự chọn, nâng cấp công nghệ 3- Mỗi