Hướng dẫn xây dựng API gateway bằng Nodejs

 Ở bài viết trước, chúng ta đã tìm hiểu các chức năng và tầm quan trọng của API gateway trong kiến trúc microservice. Các tiêu chí trong việc lựa chọn giải pháp API gateway cần được cân nhắc kĩ lưỡng trước khi đưa ra quyết định. 

Trong bài viết này, chúng ta sẽ đi xây dựng một API gateway và tự tay thực hiện cấu hình các chức năng cơ bản của API gateway. Các tính năng sẽ bao gồm:

• Routing
• Authentication
• Rate limit
• Logging
• Caching

1. Kiến trúc hệ thống 

1.1 Kiến trúc tổng thể

Hệ thống demo sẽ bao gồm 2 ứng dụng backend và một API gateway. Hai ứng dụng backend sẽ đại diện cho các microservice backend. Authentication service làm nhiệm vụ xác thực các request, authentication service giả lập flow của jwt token

1.2 Source code 

• gateway.ts: Api gateway trung tâm
• id.ts: Authentication Service xác thực, giả lập login và sử dụng xác thực qua token
• order.ts: Order service - Vai trò backend microservice
• customer.ts: Customer service - Vai trò backend microservice

Các bạn có thể download source code tại đây

1.3 Công nghệ

Trong bài viết này chúng ta sẽ xây dựng API gateway dựa trên Nodejs. Nodejs là môi trường chạy javascript phía server, với ưu điểm là cài đặt đơn giản, hiệu suất cao, tiêu thụ ít tài nguyên hệ thống. Nodejs rất phù hợp cho xây dựng Rest API server. Các package tham gia vào xây dựng API gateway

• express: framework xây dựng web server
• express-http-proxy: package proxy server cho phép xử lý các request dạng http, forward request tới các host khác nhau và trả về response cho client. 
• express-rate-limit: package xử lý rate limit
• node-cache: module cache đơn giản xoay quanh các phương thức get value, set value, set time to live của dữ liệu

2. Xây dựng các tính năng và demo

2.1 Cấu hình địa chỉ dịch vụ

API gateway sẽ thực hiện chức năng routing dựa trên url để điều hướng request  tới các microservice.

Cấu hình nằm ở file service.address.ts

 Trên môi trường production, khi triển khai với các container engine, các bạn hoàn toàn có thể thực hiện ghi đè file này trong phase đóng gói ứng dụng hoặc cài đặt mount file cấu hình trong runtime bằng tính năng của các container engine

2.2 Cài đặt

Ở đây mình sử dụng typescript để viết nodejs, Với các bạn chưa sử dụng nodejs, có thể tìm hiểu trước cách cài đặt nodejs nhé.

Để tiện cho việc làm demo nên mình đặt tất cả các file service đại diện cho các microservice trong cùng một project. Nhưng các file server này hoàn toàn độc lập với nhau, ngoại trừ việc sử dụng chung các common handler và middle ware.

Để chạy ở local, các bạn cần

1. Cài đặt môi trường nodejs, typescript tương ứng với version trong package.json
2. Download source code
3. npm install
4. ts-node <tên file server>: ví dụ ts-node gateway.ts

2.3 Authentication

Authentication tập trung tại API gateway sẽ chỉ thực hiện một lần trên mỗi request của client, từ đó  dễ dàng quản lý và maintain tập trung cho nhà phát triển. API gateway sẽ sử dụng API xác thực được cung cấp bởi authentication service, xác thực duy nhất một lần trên request của client thay vì phải xác thực trên mỗi service thực thi nếu như chưa có API gateway

Sau khi start API gateway service, authentication service, order service, truy cập vào địa chỉ 

localhost:3000/api/order/orders để kiểm tra

Khi chưa cung cấp token hoặc token sai, Hệ thống trả về message và status code 401 Unauthorized.

Để có thể truy cập hệ thống, người dùng thực hiện gọi API login để lấy token

Và truyền jwtToken vào request, lúc này request thành công và trả về dữ liệu

***Lưu ý, các phương thức xác thực trên Authentication service chỉ giả lập các api cần thiết cho việc tích hợp với API gateway, không dùng cho các dự án thực tế

2.4 Routing

Routing là tính năng cơ bản của API gateway, với tác dụng làm cổng truy cập tập trung của cả hệ thống. Client chỉ cần biết đến một địa chỉ domain duy nhất và thay đổi đường dẫn sẽ có thể truy cập được đến các microservice khác nhau trong hệ thống. Điều này giúp hệ thống dễ dàng mở rộng khi có thêm service mới.

Khi start API gateway, ứng dụng sẽ đọc các địa chỉ từ file cấu hình và khởi tạo cấu hình routing

Với key là url path, value là địa chỉ của dịch vụ đích. Phần "/api" là root path thêm do người dùng quy định, có thể không cần thiết.

Kiểm tra với order service và customer service

Lúc này ta có thể thấy phía client gọi đến một hệt thống microservice chỉ cần biết địa chỉ của API gateway mà k

2.5 Caching

Ở ví này, hệ thống triển khai với logic cache đơn giản

1. API này có cho phép áp dụng cache không, có chuyển tới (2), không chuyển tới (4)
2. Trong cache chưa có cache cho url_method này, chuyển đến 4, đã có chuyển đến 3
3. Lấy dữ liệu trong cache và chuyển tới (7)
4. Forward request tới dịch vụ
5. Kiểm tra response trả ra, API này có áp dụng cache không? có chuyển tới (6), không chuyển tới (7)
6. Lưu lại dữ liệu vào cache với key = url_method, value = response, set timetolive của cache , tới (7)
7. Trả về, và kết thúc request 

Các bạn chạy ứng dụng và theo dõi log để thấy trong thời gian cache, request được trả về ngay từ API gateway, không cần service gốc phải xử lý. Việc này sẽ giảm thời gian tối đa của request, đồng thời giảm tải cho cả hệ thống

2.6 Logging

Việc sử dụng API gateway kết hợp với các package cho phép proxy request, người dùng có thể truy cập tới toàn bộ dữ liệu từ request gọi đến và các response trả ra trước khi response này thực sự trả về tới người dùng cuối, từ đó có thể Log được các dữ liệu cần thiết. Ngoài ra cũng có thể điều hướng response hoặc modify dữ liệu trả về.

Ở đây ta sử dụng một middleware để bóc tách dữ liệu từ các request và response tùy theo mục đích sử dụng các dữ liệu này.

2.7 Rate limit

Rate limit cho phép hệ thống có thể ngăn chặn các request bất thường ngay từ API gateway, tránh việc gây quá tải hoặc rủi ro trên service xử lý.

Package express-rate-limit cung cấp một cài đặt đơn giản cho việc limit các request, trên hình là cài đặt giới hạn mỗi IP được truy cập 10 request trong vòng 1 phút

Chạy demo với file test-ratelimit.ts với 15 request gọi liên tiếp. Kết quả từ API thứ 10 trở đi đã bị chặn với mã code trả về 429, message too many request

3. Kết

Xây dựng API Gateway bằng Node.js không chỉ giúp quản lý các dịch vụ một cách hiệu quả mà còn mang lại sự linh hoạt và bảo mật cao cho hệ thống của bạn. Qua bài viết này, chúng ta đã cùng tìm hiểu từ những khái niệm cơ bản, cách lựa chọn công cụ phù hợp, đến việc triển khai một API Gateway hoàn chỉnh. 

Hy vọng rằng, với những kiến thức này, bạn sẽ dễ dàng áp dụng vào dự án thực tế, tối ưu hóa hiệu suất và nâng cao trải nghiệm người dùng. Nếu bạn gặp bất kỳ khó khăn nào trong quá trình triển khai, hãy để lại câu hỏi, và chúng ta sẽ cùng thảo luận để tìm ra giải pháp tốt nhất. Chúc bạn thành công!

API gateway là gì? Các tiêu chí khi lựa chọn giải pháp API gateway

1. API gateway là gì?

API Gateway là một thành phần quan trọng trong kiến trúc microservices, đóng vai trò như một cửa ngõ để quản lý và điều phối các yêu cầu đến các dịch vụ.

Giả sử bạn có một hệ thống triển khai bằng kiến trúc microservice. Và đây là những điều sẽ xảy ra trên thực tế khi không có API gateway.

• Mỗi service sẽ phải xử lý authentication trên chính nó, ngay cả khi request đã được authentication một lần rồi và request gọi qua một service khác, request này sẽ vẫn phải authentication một lần nữa.
• Các nhu cầu về log API, xử lý hành vi của API dựa trên request/response...  cần implement trên mỗi service riêng lẻ, bất tiện khi có service mới hoặc thay đổi global trên những nhu cầu tập trung này.
• Mất kiểm soát giữa api internal và public api cho client, không có giải pháp limit giữa các nhóm api có quyền truy cập khác nhau.
• Lộ các địa chỉ truy cập của dịch vụ đầu cuối và kiến trúc dịch vụ bên trong (do url thường kèm tên dịch vụ hoặc các địa chỉ IP khác nhau) của hệ thống do cần cung cấp trực tiếp địa chỉ public để client kết nối. Gia tăng rủi ro bảo mật của hệ thống. 

Đây mới chỉ là một số ít vấn đề được liệt kê. Mục đích chính của API gateway là tạo ra một lớp trung gian giữa client và hệ thống microservice phía sau. API gateway hoạt động như một endpoint duy nhất.

Các giao tiếp từ phía client trên cả hai chiều request và response sẽ hoàn toàn được kiểm soát khi đi qua API gateway.

Trong bài viết này chúng ta sẽ tìm hiểu các tính năng của API gateway và tại sao những ứng dụng này lại quan trọng trong hệ thống microservice.

2. Các ứng dụng của API gateway

2.1 Routing

Ứng dụng phổ biến nhất của API gateway là chức năng routing. Do mục đích đồng nhất entry point cho hệ thống và dễ dàng quản lý các kết nối từ phía client . Lúc này API gateway đóng vai trò như bộ phận một cửa, tất cả các request sẽ đi vào đây và được chuyển đến các microservice phía sau theo các rule được thiết lập sẵn. 

Client request phổ biến là các Rest API nhưng cũng có thể là các dạng connection khác. API gateway  nhận diện các request từ các dữ liệu bao gồm: đường dẫn url, header, body... sau đó so sánh với các rule routing được cài đặt để điều hướng request đến các target service phía sau. Target service là các microservice triển khai cùng hệ thống, các VM hoặc bất cứ dịch vụ nào được chỉ định bằng domain hoặc địa chỉ IP.

2.2 Caching

Nhà phát triển đặt các bộ dữ liệu đệm (cache) ngay trên API gateway để tăng cường hiệu năng hệ thống. Bằng cách kết hợp thêm với một số công vụ phục vụ lưu trữ và phân phối dữ liệu cache như Redis, dữ liệu được trả về ngay khi request tới API gateway mà không cần request tới backend service phía sau

2.3 Rate limiting 

Tính năng Rate limit giúp ngăn chặn việc lạm dụng hoặc lượng đột biến các traffic bất thường gây hại cho hệ thống. Rate Limit sẽ giúp bảo vệ tài nguyên hệ thống microservice phía sau bằng cách ngăn chặn khi có quá nhiều traffic đến.

Trong thực tế rate limit được sử dụng trong các trường hợp

• Ngăn chặn brutal force
• Giảm nguy cơ bị DDoS
• Ngăn chặn các hành vi crawler data
• Cân bằng lượng sử dụng giữa các người dùng trong trường hợp một số khách hàng phát sinh quá nhiều request

 API gateway sẽ giới hạn tần suất truy cập của các API trên các resource khác nhau. Ngoài việc chỉ định pattern của request nào sẽ bị giới hạn, điều kiện giới hạn các request sẽ dựa trên những thông số đặc trưng cho một native request như địa chỉ IP hoặc các thông tin về authentication nằm trong header hoặc cookie.

2.4 API composition và aggregation

Request aggregation là một pattern cho phép kết hợp dữ liệu nằm phân tán trên các service khác nhau trong một response duy nhất. Việc gọi api cross qua nhiều service sẽ làm giảm hiệu năng chung, do các request phải xử lý tuần tự, thêm vào việc quản lý các request cũng trở lên khó khăn khi debug. Request aggregation sẽ tổng hợp các request trên, fetching data và trả về trong một lần xử lý .

2.5 Logging và monitoring

API gateway collect metrics và logs từ các request, cung cấp cái nhìn thực tế về lượng sử dụng và performance của hệ thống. Việc collect log bao gồm phương thức đơn giản như log dữ liệu ra console, gửi tới các queue để tổng hợp hay áp dụng các giải pháp thu thập log enterprise như Fluentd kết hợp với ELK, EFK

2.6 Authentication và Authorization

Khi hệ thống microservice không có API gateway, mỗi service phải thực hiện authentication trên chính nó. Cho dù việc authentication được ủy quyền cho một service riêng biệt, Khi một request cần gọi qua nhiều service, việc authentication sẽ thực hiện lại khi một service gọi tới một service khác. Điều này là không cần thiết và lãng phí thêm một số round chip trên mỗi request. 

Thiết kế đúng sẽ thực hiện Authentication và Authorization tập trung tại API gateway. Lúc này, các request được thực hiện xác thực một lần duy nhất tại API gateway, thông tin xác thực của tài khoản sẽ đi cùng với request vào các service backend bên trong mà không cần thực hiện xác thực lại. 

2.7 Giới hạn điểm truy cập

Trong hệ thống microservice, số lượng các dịch vụ có thể lên tới hàng chục, hàng trăm service. Việc quản lý các endpoint cho các mục đích khác nhau sẽ trở nên khó khăn. Sẽ có những API public internet phục vụ cho phía client web, một số cho mobile, một số lại phục vụ cho external rest API hoặc callback cho người dùng tích hợp, một số khác lại chỉ dành cho nội bộ giữa các service... Việc public toàn bộ các API của hệ thống ra internet là rất rủi ro cho hệ thống

Sự đa dạng mục đích các endpoint này đòi hỏi các phương thức log, authentication và authorization khác nhau. API gateway sẽ tập trung các công cụ và giải pháp thực hiện quản lý truy cập tại một điểm nút duy nhất, giúp dễ dàng trong quản lý các kết nối một cách hiệu quả

3. Lựa chọn API gateway

Lựa chọn giải pháp API gateway phù hợp rất quan trọng với việc phát triển và mở rộng hệ thống về sau. Các nhu cầu về ứng dụng của API gateway chưa xuất hiện ngay khi hệ thống mới phát triển, chính vì vậy nên nếu nhà phát triển lựa chọn một giải pháp không phù hợp trong giai đoạn đầu, họ có thể phải thay thế giải pháp đó trong giai đoạn sau của hệ thống. Nhà phát triển lựa chọn một trong các framework opensource có sẵn để cài đặt API gateway, hoặc tự xây dựng một api gateway cho riêng hệ thống với bằng cách custom hoặc kết hợp với một số thư viện sẵn có.

3.1 Sử dụng Framework opensource

Có khá nhiều các API gateway framework nổi tiếng trên thị trường. Những framework này có cộng đồng sử dụng rất lớn. Bạn đã từng nghe đến Kong hoặc NGINX trong các hệ thống microservice. Chúng ta cùng xem xét qua một số Framework phổ biến và điểm mạnh của chúng.

Framework	Language	Key Feature	Best For
Kong	Lua	Many plugins	Large deployments
NGINX	C	Speed	High-traffic sites
Tyk	Go	User-friendly dashboard	Easy management
Express Gateway	JavaScript	Node.js compatible	JS dev teams
KrakenD	Go	No database required	Microservices
Apache APISIX	Lua	Cloud-native	Kubernetes setups

Các framework này có ưu điểm là có performance cao hơn nhiều so với việc tự xây dựng API gateway, ngoài ra interface sử dụng cũng được building sẵn, dễ dàng sử dụng và cài đặt. Hầu hết các framework này sử dụng các file cấu hình để thực hiện cài đặt cấu hình chức năng, ít đòi hỏi việc custom code. Việc mở rộng hoặc custom các tính năng đòi hỏi cài thêm các plugin hoặc người dùng cần implement theo interface của plugin mà Framework yêu cầu.

3.2 Cân nhắc các tiêu chí lựa chọn

Tuy việc sử dụng API gateway framework khá tiện lợi nhưng bạn cũng cần cân nhắc các yếu tố khác trước khi tích hợp nó vào hệ thống.

• Team stack: Đôi khi nhà phát triển sẽ cần mở rộng tính năng của Framework sẵn có tích hợp với một thành phần sẵn có của hệ thống. Lúc này việc custom plugin hoặc đọc hiểu để chỉnh sửa các cấu hình của framework để đáp ứng nhu cầu sẽ phụ thuộc vào ngôn ngữ mà framework có phù hợp với tech stack của team hay không. Việc học thêm Lua chỉ để custom Kong gateway sẽ không phải là một quyết định sáng suốt với một team Java
• Tính năng: Api gateway có rất nhiều tính năng hữu ích nhưng không phải tất cả các framework đều hỗ trợ các tính năng này. Nhà phát triển cần xác định phạm vi những feature cần thiết nhất cho hệ thống của mình.
• Chi phí: API gateway hỗ trợ tính năng ở các package khác nhau, một số chỉ có ở bản trả phí mà không có ở bản community hay opensource.
• Khả năng mở rộng, tích hợp: API gateway cần có khả năng mở rộng, custom và tích hợp. Sẽ ra sao nếu như API gateway bạn chọn chỉ hỗ trợ authentication bằng JWT nhưng lại không hỗ trợ phương thức basic authentication hoặc api-key và lại không có phương án nào custom, mở rộng. 
• Khả năng scale/Performance: Nếu như hệ thống phải chịu tải tới hàng triệu request trong một thời gian ngắn thì lúc này hiệu năng của API gateway lại cần được đặt lên hàng đầu. Ví dụ như NGINX rất nhẹ, chiếm ít tài nguyên xử lý nhưng lại có thể xử lý gấp 2.6 lần số request khi so với Kong API gateway với các response 1Kb
• Khả năng Triển khai, cài đặt: Khả năng dễ dàng triển khai hoặc cài đặt bằng các file cấu hình hoặc deploy trên VM hoặc trên container. Điều này sẽ quyết định framwork sẽ triển khai đồng bộ với hệ thống phần mềm, tiết kiệm effort cho việc maintain.

3.3 Tự xây dựng API gateway

Một giải pháp khác cho API gateway là việc tự xây dựng một API gateway hoặc sử dụng kết hợp cả giải pháp custom với framework. Tự xây dựng API gateway có ưu điểm là dễ triển khai, gần với techstack của team, dễ dàng tích hợp với các giải pháp về authentication và authorization sẵn có của hệ thống. Các thành phần khác của hệ thống cũng dễ dàng được tích hợp và tái sử dụng cùng với gateway mà không cần tuân theo bản mẫu của framework. Nhưng ngược lại, việc tự xây dựng API gateway có thể gặp các rủi ro về bảo mật và hiệu năng kém hơn so với sử dụng framework.

Nguyên lý cơ bản của Tự xây dựng API gateway sẽ dựa trên nền tảng một proxy server, request đến sẽ được bóc tách ra thành các thành phần, từ đó sử dụng logic code để áp dụng các chức năng của API gateway như routing, authentication, logging...

Kết

Với vai trò là cửa ngõ của cả hệ thống phần mềm/dịch vụ, vai trò và chức năng của API gateway rất quan trọng đối với toàn bộ hệ thống. Việc lựa chọn một giải pháp API gateway không phù hợp khiến nhà phát triển gặp khó khăn cho các giải pháp quản lý tập trung request về sau.

Nhìn nhận trong kiến trúc hệ thống microservice, với đặc tính phân tán, API gateway là một trong số ít các thành phần mang tính tập trung, giúp người dùng quản lý tập trung được toàn bộ các dịch vụ phía sau. Tổ chức tốt các thành phần API gateway sẽ giúp nhà phát triển có một hệ thống ổn định và an toàn.

Đón đọc bài tiếp theo trong loạt bài về API gateway:

Hướng dẫn xây dựng API gateway với Nodejs

Cache trong kiến trúc phần mềm

Nhuận bút bài này đóng góp cho đồng bào bị ảnh hưởng bởi cơn bão Yagi

Khái niệm cache

Cache không phải là một khái niệm mới mẻ, ngay cả đối với những người dùng internet bình thường. Chắc hẳn các bạn đã nghe đến việc xóa dữ liệu cache của trình duyệt khi gặp một số lỗi hoặc chỉ đơn giản là muốn xóa gợi ý web hay truy cập.

Trong các hệ thống IT và phần mềm, khái niệm cache còn phổ biến hơn nữa, chúng được ứng dụng trong gần như tất cả các thành phần bao gồm cả phần cứng và phần mềm. Chúng ta có thể nghe đến cache DNS, cache IP, cache browser, cache HTTP resource...

Khái niệm Cache nói đến việc lưu trữ dữ liệu vào bộ nhớ đệm hoặc khu vực lưu trữ tạm thời, giúp cho thời gian truy vấn dữ liệu đó nhanh hơn, từ đó tăng hiệu năng và sự ổn định của hệ thống.

Ví dụ trên mô tả việc dữ liệu gốc được lưu trong database, và thay vì đọc trực tiếp và liên tục từ database thì việc truy vấn từ dữ liệu cache ngay trên thiết bị hoặc trình duyệt sẽ cải thiện đáng kể performance. 

Cache sẽ giải quyết được các vấn đề về performance thông qua các strategy

• Rút ngắn khoảng cách: vd truy vấn trên client nhanh hơn so với trên server
• Gia tăng hiệu năng truy vấn: vd truy vấn dữ liệu trên RAM sẽ nhanh hơn dữ liệu trên database hoặc ổ lưu trữ
• Preprocess: Tối ưu cho truy vấn trước khi truy vấn được thực hiện (vd gắn index, tạo view cho database)

Cache tăng hiệu năng hệ thống nói chung thông qua việc tăng tốc độ truy vấn từ phía client và giảm tải cho phía server

Các layer cache trong kiến trúc hệ thống 

Chúng ta cùng quan sát một luồng request dữ liệu cơ bản từ client đi tới server và tới database:

Một request cơ bản sẽ đi từ Client qua internet tới Server và tới Database, sau đó dữ liệu truy vấn sẽ được trả về. Query DB hoặc read dữ liệu từ các ổ lưu trữ là những action ảnh hưởng nhiều đến performance của hệ thống, các action này có thể gây ra nghẽn cổ chai khi có quá nhiều request. Thực tế trên đường đi của request, ta có thể đặt rất nhiều vị trí cache hoặc các giải pháp cache khác nhau để tối ưu performance.

Client Cache

Client Cache là layer cache ngay trên thiết bị đang chạy ứng dụng, có thể là trình duyệt web hoặc thiết bị mobile. Các client này đều hỗ trợ các API cho việc truy cập lưu trữ và truy vấn dữ liệu ngay trên thiết bị. Một số hình thức cache trên client

• Runtime Variable: Đơn giản nhất người dùng có thể request một lần và lưu trữ dữ liệu trên các biến của ứng dụng để sau đó sử dụng lại
• Local storage: Dữ liệu được lưu trữ dưới dạng các vùng nhớ lưu trữ đơn giản, thường là key-value. Ví dụ: Local storage của trình duyệt
• Local Database: Trình duyệt và ứng dụng mobile đều hỗ trợ các API để làm việc với DB đơn giản ngay trên thiết bị, ngay cả với các tập dữ liệu tương đối lớn, người dùng có thể kết hợp bộ nhớ lưu trữ trên thiết bị kết hợp với các Database engine trên local device. Ví dụ IndexedDB trên web browser hoặc H2/SqlLite trên các thiết bị di động 

Server Cache

Server Cache được ứng dụng khá phổ biến và có ưu điểm là có thể khai đa dạng các hình thức cache khác nhau. Các giải pháp cache phía server giúp luồng quản lý dữ liệu được tập trung. Việc refresh cache cũng sẽ dễ dàng hơn so với việc cache dữ liệu ở phía client.

• Runtime Variable/Environment: Các dữ liệu thường xuyên sử dụng như các biến về giá trị hay cấu hình cần cho ứng dụng vận hành được lưu trữ trong các biến của ứng dụng hoặc các biến môi trường của server đang chạy.
• Server File System: Người dùng có thể truy cập đến File System để lấy ra dữ liệu đã cache từ trước mà không cần tính toán/tải lại.
• Ứng dụng cache bên thứ ba: Các ứng dụng này thường tận dụng performance in memory của RAM, kết hợp với công nghệ xử lý/lưu trữ đặc thù, không những đáp ứng nhu cầu cache mà còn cung cấp các tính năng nâng cao như HA và Distributed. Các ứng dụng này đáp ứng nhu cầu cache đa dạng và có thể tích hợp vào nhiều hệ thống cũng như công nghệ khác nhau. Các công nghệ cache phổ biến như Redis, Memcache hay S3

Database Cache

Có thể nhiều developer đã thực hiện những kĩ thuật này mà không nghĩ rằng chúng cũng thuộc phạm vi của cache dữ liệu. Hãy nhớ rằng cache là việc chúng ta lưu trữ dữ liệu vào các khu vực lưu trữ tạm thời nhằm tăng  tốc độ truy vấn/lấy dữ liệu.

• Database View: Các hệ cơ sở dữ liệu quan hệ (RDBMS) đều cung cấp tính năng view hay còn gọi là virtual table. View là sự trình bày dữ liệu được trích xuất sẵn từ các bảng dữ liệu gốc mà người dùng cài đặt. Việc sử dụng View khiến dữ liệu luôn sẵn sàng khi truy vấn mà người dùng không cần thực hiện thao tác join các bảng dữ liệu.
• Indexing: Phía dưới thao tác Set index cho các trường dữ liệu là việc cơ sở dữ liệu đã gắn chỉ mục cho dữ liệu thông qua các giải thuật. Việc này cũng tiêu tốn thêm bộ nhớ, nhưng ngược lại cũng tối đa được tốc độ truy vấn đến các dữ liệu có gắn index
• Preprocess: Tính toán dữ liệu từ trước là việc người dùng sử dụng các schedule function, từ đó định kì làm mới hoặc thực hiện tính toán ra các dữ liệu cần thiết từ dữ liệu hiện có, việc này đưa đến kết quả tương tự database view, nhưng không yêu cầu sự ràng buộc từ các dữ liệu thành phần. Người dùng có thể chủ động trong việc giới hạn độ mới của dữ liệu cũng như nguồn các dữ liệu thành phần.

Other cache

Trên thực tế người ta còn có thể gắn thành phần cache trước cả khi request tới server gốc. Việc này thường được thực hiện dựa trên đường đi của request tới internet. Những giải pháp này dều theo hướng hạn chế request tới server gốc, mà thực hiện cache trên các thành phần của network như proxy hay gateway. Có một giải pháp nữa cũng khá phổ biến và cũng được coi là một giải pháp cache, đó là CDN

Content Delivery Network

CDN hoạt động dựa trên nguyên lý: Thay vì Client request trực tiếp tới server gốc (origin server), thì client sẽ request tới server có location gần mình nhất (edge server - PoPs). Nguyên lý này rất lý tưởng cho các website chứa các static content. Việc phân phối nội dung giữa origin server tới edge server có thể thông qua mô hình pull hoặc push, khi đó dữ liệu có thể chủ động phân phối tới các edge server ngay lập tức (push) hoặc khi client request tới edge server mà không có dữ liệu, lúc này edge server mới đi lấy dữ liệu, cache lại và trả về cho client.

Xem thêm về CDN tại đây

Một số vấn đề lưu ý khi sử dụng cache

Giải pháp cache sẽ thích hợp với các phần dữ liệu được sử dụng để đọc nhiều hơn ghi hoặc với các dữ liệu ít thay đổi. Khi cache lại giá trị của dữ liệu, đồng nghĩa với việc nhà phát triển phải quản lý quan hệ giữa dữ liệu cache và dữ liệu gốc. Dưới đây là một số vấn đề thường gặp khi làm việc với cache

• Cache expiration: Với nhiều giải pháp cache như ở trên đã trình bày, chúng ta sẽ lựa chọn giải pháp nào để đáp ứng vấn đề "Thời gian hết hạn của cache". Thời gian lưu trữ của cache quá dài, dữ liệu có thể trở nên quá cũ, không sử dụng được, còn quá ngắn thì hệ thống cache sẽ không đủ tốt. Hay cơ chế nào để có thể refresh một phần hoặc toàn bộ dữ liệu cache
• Cold start problem: Khi bộ nhớ cache vừa được bật lên, dữ liệu của cache là rỗng, nó cần được load dữ liệu từ nguồn (database...), lượng truy cập tới database tăng đột biến có thể dẫn đến database bị treo. Hoặc trường hợp dữ liệu chưa được đồng bộ hết tới cache, các request có thể không nhận được dữ liệu, do thời gian warm up lâu.
• Cache Capacity: Dữ liệu luôn có xu hướng giãn ra  theo thời gian, nhà phát triển cần có cơ chế quản lý/cảnh báo về lượng dữ liệu lưu trên cache, việc này sẽ đảm bảo thành phần cache luôn hoạt động ổn định.
• Store Sensitive Data: Lưu trữ những dữ liệu nhạy cảm của người dùng(ví dụ token, user session) trên cache có thể tiềm ẩn nguy cơ mất an toàn thông tin cho hệ thống
• HA và Distributed: Các hệ thống Enterprise đòi hỏi giải pháp cache có khả năng chịu tải lớn, độ sẵn sàng cao và có thể horizontal scale. Việc này cần được cân nhắc kĩ trong giai đoạn thiết kế hệ thống

Kết

Chúng ta đã đi qua các phần 

• Khái niệm cache 
• Các layer cache trong kiến trúc phần mềm và ví dụ
• Một số lưu ý khi sử dụng cache

Một cách rõ ràng Cache là thành phần cần thiết để có hệ thống nhanh hơn và hiệu quả hơn. Bằng việc lựa chọn đúng các giải pháp về cache, chúng ta sẽ mang đến cho người dùng trải nghiệm mượt mà và một hệ thống hoạt động ổn định. Qua bài viết này, hi vọng các bạn đã có cái nhìn toàn cảnh và gợi mở thêm về các giải pháp caching.

Cheers,

Ethanol Tran

HTTPS hoạt động như thế nào?

    Ở bài viết cách hoạt động của mạng của Internet, chúng ta đã phần nào hiểu được cách thức giao tiếp giữa trình duyệt trên một máy tính cá nhân tới một máy chủ dựa vào giao thức HTTP và tầm quan trọng của việc có một kết nối an toàn. Có rất nhiều dữ liệu nhạy cảm mà bạn sẽ sử dụng để truy cập các chức năng trên mạng internet như username/password, thông tin thẻ creditcard, các thông tin cá nhân, message, image... Khi website không có https, các dữ liệu này đều có thể bị nghe lén.

    Trong bài viết này chúng ta sẽ đi vào tìm hiểu sâu hơn cách hoạt động của giao thức HTTPS. Làm thế nào để giao thức HTTPS có thể đảm bảo một kết nối an toàn khi truy cập tới một máy chủ.

 HTTPS là gì?

HTTPS viết tắt của Hyper Text Transfer Protocol Secure (Giao thức truyền tải siêu văn bản bảo mật), đây là giao thức cải tiến hơn của HTTP do có thêm layer cho việc bảo mật. Chúng ta cần tới HTTPS bởi 3 lý do:

• Privacy - sự riêng tư: Khi dữ liệu được truyền tải trên mạng internet, không ai có thể đọc được dữ liệu của bạn trong khi truyền tải.
• Integrity - Tính toàn vẹn dữ liệu: Dữ liệu từ điểm này tới điểm khác trên mạng internet cần được đảm bảo tính toàn vẹn, không ai có khả năng chỉnh sửa các dữ liệu này trên đường truyền tải mà không bị phát hiện
• Identification - Định danh: Website mà bạn đang truy cập chính xác là trang web đó, nói cách khác là kết nối đến máy chủ không bị làm giả. HTTPS thông qua chứng chỉ SSL , sẽ đảm bảo bạn đang kết nối đến đúng máy chủ mà bạn mong muốn.

Chứng chỉ SSL này cần hợp lệ và được cấp bởi một số tổ chức Certificate Authority hợp pháp.

HTTPS bảo vệ dữ liệu như thế nào?

    Trong bài viết trước chúng ta cũng đã đề cập đến khái niệm mã hóa dữ liệu và sự khác nhau về nguyên lý của việc mã hóa dữ liệu bằng mã hóa đồng bộ và mã hóa bất đồng bộ. Vậy thực sự thì HTTPS sử dụng SSL certificate mã hóa dữ liệu bất đồng bộ như thế nào?

Theo dõi bài viết trước tại đây//TODO link đến bài how internet work đoạn kết nối an toàn

    Khi sử dụng một trình duyệt để thực hiện request đến một Server chứa website. Private key được lưu trữ ở phía server và Public key được chia sẻ cho trình duyệt. Bất cứ một trong hai phía gửi hoặc nhận dữ liệu sẽ sử dụng key của mình để mã hóa/ giải mã. Nếu trình duyệt gửi message đến server, trình duyệt sử dụng Public key để mã hóa và gửi đi, Server sẽ sử dụng private key để giải mã. Và ngược lại, khi server trả về kết quả cho trình duyệt, server sử dụng private key để mã hóa, và trình duyệt dùng public key của mình để giải mã. Đây là ý tưởng cơ bản của việc sử dụng keys để thực hiện kết nối an toàn sử dụng giao thức HTTPS.

Quá trình kết nối từ trình duyệt tới máy chủ

    Khi bạn sử dụng trình duyệt truy cập tới sunteco.vn , trình duyệt của bạn giao tiếp với máy chủ lưu trữ website và cả hai bên thành lập một kết nối an toàn để trao đổi dữ liệu, nếu việc quá trình thương lượng với nhau thất bại, trình duyệt sẽ báo lỗi hoặc cảnh báo về kết nối không an toàn. Nếu kết nối an toàn được thành lập, trình duyệt sẽ hiển thị hình chiếc khóa trên thanh địa chỉ. Quá trình  này được gọi là handshake. Sau đây là từng bước trình duyệt bắt tay với server:

• Clien Hello: Trình duyệt gửi tới server một danh sách các phiên bản SSL/TLS và các giải thuật mà trình duyệt đang hỗ trợ(cipher suite)
• Server Hello: Server lựa chọn một phiên bản SSL/TLS và giải thuật phù hợp sau đó phản hồi với trình duyệt bằng Certificate, trong đó bao gồm cả Public key, nhờ đó mà trình duyệt có thể xác định định danh của máy chủ có đúng hay không (Identification)
• Client Key exchange: Trình duyệt kiểm tra Certificate để đảm bảo máy chủ hợp lệ. Trình duyệt generate một "pre-master key", key này sẽ được sử dụng để sinh ra một unique key về sau. Trình duyệt mã hóa "pre-master key" bằng Public key và gửi lại cho Server
• Change Ciper spec: Server sử dụng Private key để giải mã "pre-master key"
• Test connection: Trình duyệt sử dụng Public key để mã hóa message và gửi tới server, server sử dụng Private key để đọc message.

Đến đây hai bên đã trao đổi cho nhau các key cần thiết để thực hiện kết nối an toàn và bảo mật. Mọi thứ sẽ được bảo mật cho đến khi kết thúc phiên làm việc

Sự khác nhau giữa HTTPS/SSL/TLS

Nãy giờ chúng ta đã nhắc đến HTTPS, SSL/TLS vậy chúng liện quan tới nhau như thế nào? HTTPS là phiên bản bảo mật của HTTP, trình duyệt và máy chủ sử dụng giao thức HTTP để giao tiếp và trao đổi dữ liệu. Trong khi trao đổi dữ liệu, các dữ liệu được mã hóa bởi SSL/TLS nên giao thức này được gọi là HTTPS, S viết tắt của secured.

    Câu chuyện về SSL/TLS sẽ phức tạp hơn một chút. SSL viết tắt của Secure Sockets Layer. Một giao thức được phát triển bởi Netscape. Phiên bản đầu tiên của SSL không được release, nhưng phiên bản thứ 2 đã được release cùng với trình duyệt Netscape 1.1 vào năm 1995. Sau đó một năm Netscape release phiên bản thứ 3 vì bản thứ hai có một số lỗi nghiêm trọng. Cho đến năm 1999, cuộc chiến về trình duyệt giữa Netscape và Microsoft (internet explore) dẫn đến sự cần thiết của các chuẩn cho trình duyệt. Netscape chuyển giao giao thức SSL cho IETF (Internet Engineering Task Force).

    Cuối năm 1999, IETF release TLS version 1.0 (mà thực ra là SSL 3.1). SSL được đổi tên thành TLS-Transport Layer Security. Dẫn đến việc gây lú cho tới ngày nay. TLS 1.0 kết thúc và bản 1.1 release năm 2006. Vài năm sau TLS 1.2 ra đời để giải quyết một số sai sót. Nhưng đến tận 2013, các trình duyệt mới bắt kịp và hỗ trợ cho TLS 1.2

    Để gây lú x3.14, SSL 3.0 chính thức được release năm 2015. TLS 1.3 được chấp thuận vào tháng 3 năm 2018 và trình duyệt của bạn hiện giờ chắc hẳn đã hỗ trợ. TLS 1.3 cải thiện về bảo mật và loại bỏ một số issue .

Bạn có thể check version TLS của trình duyệt tại đây

Certificate Autorities

Certificate Autority là một tổ chức third-party phục vụ 3 mục đích chính:

• Cấp certificates
• Confirm định danh của chủ sở hữu certificate
• Cung cấp bằng chứng rằng certificate là hợp lệ.

    Chúng ta có thể đã nghe đến Symantec, Comodo, Let's Encrypt, GoDaddy... Trở thành CA là một nhiệm vụ rất khó khăn về yêu cầu bảo mật và kiểm tra. Bạn phải được tin tưởng để có thể được chấp nhận truy cập vào Root store. Root store về cơ bản là cơ sở dữ liệu của các CAs, các CAs sẽ chia sẻ chung với nhau cơ sở dữ liệu này.

    Certificate nào mà bạn nên mua? Về cơ bản bạn có 3 loại cert để lựa chọn:

• Domain validated: Loại certificate này chỉ xác nhận cho tên miền.
• Organization validate: Loại cert này yêu cầu thẩm định và xác minh tổ chức cần cấp chứng chỉ một cách manual
• Extended validation: Cert yêu cầu xác minh đầy đủ về doanh nghiệp.

    Kết quả của các chứng chỉ hợp lệ trên trình duyệt là biểu tượng khóa an toàn trên thanh địa chỉ. Extended validation thường hiển thị thêm công ty đi cùng biểu tượng khóa. Nhưng làm sao để một chứng chỉ hợp lệ?

    Khi CA cấp một certificate, họ sẽ kí vào trong certificate một chữ kí điện tử bằng chứng chỉ gốc của họ đã được cài đặt trước trên root store. Thường là sẽ có một intermediate certificate được kí với bằng root certificate. Và chứng chỉ trung gian này lại được dùng để kí cho các chứng chỉ đầu cuối. 

    Cùng đi qua tiến trình xác minh để hiểu một certificate được xác định hợp lệ như thế nào. Trình duyệt của bạn connect tới một trang web bằng HTTPS và download cert. Cert đó không phải là root cert, trình duyệt tiếp tục download cert mà được dùng để ký cho cert trên trang của bạn truy cập, nhưng cert này vẫn không phải là root cert. Trình duyệt download thêm một lần nữa cert sử dụng để kí cho mid cert. Ya! Đây đúng là root cert rồi. Vậy là tất cả các cert này đều được xác mình và tin cậy. Khi certtificate cuối cùng không phải là root cert, chuỗi xác mình này sẽ thất bại và certificate đầu tiên sẽ không hợp lệ. 

    Vậy tại sao phải sử dụng certificate đến từ Certificate Authotity trong khi bạn có thể tự tạo ra certificate của mình? Một self-sign certificate  cung cấp cùng mức độ mã hóa giống như tổ chức có thẩm quyền. Dữ liệu vẫn được bảo mật khi truyền dẫn và bạn không phải mất phí để gen certificate. Nhưng hầu như các trình duyệt sẽ kiểm tra certificate được cấp bởi các tổ chức có thẩm quyền. Các truy cập vào một website mà cert không phải do CA cấp sẽ bị hiển thị cảnh báo connection insecure.

Self-signed certificate có thể hữu ích cho test và nội bộ, nhưng bạn nên tránh sử dụng cho các trang web public. Do các chứng chỉ tự ký này có thể bị làm giả.

Kết

    Hy vọng bài viết đã làm rõ tầm quan trọng của HTTPS và cách mà một Certificate được sinh ra và được sử dụng để tạo ra một kết nối an toàn trên mạng internet. Trong những bài viết sau, chúng ta sẽ tiến hành thực hiện việc gen certificate để tạo ra một kết nối an toàn cho website đang hosting trên máy chủ.

Tham khảo https://howhttps.works/

Internet hoạt động như thế nào?

     Chúng ta vẫn đang sử dụng mạng Internet hàng ngày, nhưng có bao giờ bạn đặt câu hỏi về việc một mạng thông tin toàn cầu lớn như vậy được tạo nên như thế nào và có ai đang kiểm soát nó hay không?

Bài viết này sẽ giải đáp các vấn đề cốt lõi như: làm cách nào mà Internet được tạo thành và dữ liệu di chuyển trên Internet như thế nào, dữ liệu di chuyển từ máy tính này đến các máy tính khác ở cách đó rất xa mà vẫn đảm bảo tính toàn vẹn và bảo mật dữ liệu.

Internet là gì?

    Internet là một hệ thống rất lớn các networks và kết nối các máy tính trên toàn thế giới. Qua mạng internet, người ta có thể chia sẻ thông tin và giao tiếp từ nơi này đến nơi khác trên thế giới chỉ với kết nối vào mạng Internet. Kết nối này được tuân theo các chuẩn nhất định để bảo vệ dữ liệu của người dùng.

Dữ liệu di chuyển trên mạng internet như thế nào?

   Nói theo một cách khác, Internet là mạng toàn cầu bao gồm cả các cáp vật lý như dây đồng của đường dây điện thoại, cap tivi hoặc cáp quang. Thậm chí gồm cả các kết nối không dây như tín hiệu vệ tinh, wifi và 3G/4G . Khi bạn truy cập một trang web, bạn gửi yêu cầu qua dây cáp đến một server. Server này là nơi lưu trữ website, đây là một máy chủ vậy lý hoạt động tương tự như máy tính cá nhân của bạn nhưng có thể ở cấp độ lớn hơn rất nhiều. Sau đó máy chủ sẽ xử lý request và trả dữ liệu về máy tính của bạn. Nhưng thật kì diệu, quá trình này thường chỉ mất chưa tới một giây, ngay cả khi Server nằm ở đầu kia của trái đất

Các network nói chuyện với nhau bằng cách nào?

    Vậy bây giờ ta đã hiểu về mặt vật lý, vẫn sẽ có những dây dẫn kết nối giữa các thiết bị trên mạng Internet. Vậy về mặt logic, làm sao dữ liệu có thể đi đúng tới máy server và sau đó trả dữ liệu về đúng máy vừa request mà không phải là một máy khác. Lúc này sẽ là việc của IP và DNS. IP có ý nghĩa như địa chỉ duy nhất của một thiết bị trên mạng Internet và nó có dạng của một dãy số xxx.xxx.xxx.xxx . Khi đã biết địa chỉ, các thiết bị sẽ giao tiếp với nhau thông qua việc tuân thủ các Protocol. Protocol là một bộ các quy tắc tiêu chuẩn mà khi các bên đồng ý sử dụng, nó sẽ cho phép họ giao tiếp mà không gặp rắc rối. Nhưng thông thường thì chúng ta sẽ không truy cập trang web bằng địa chỉ IP , nó khá khó nhớ và nhàm chán. Thay vào đó người ta sử dụng các tên miền có nghĩa, đây là các tên đơn giản được cài đặt để đại diện cho các địa chỉ IP. Nhờ vào DNS (Domain Name System) mà các thiết bị có thể biết được địa chỉ IP của máy chủ từ tên miền. DNS hoạt động như một kho lưu trữ các tên miền cùng với các địa chỉ IP mà chúng đại diện, và khi các thiết bị muốn biết IP mà tên miền đại diện, DNS sẽ giải quyết vấn đề này.

Để hiểu thêm về cách thức hoạt động của DNS, xem thêm: DNS hoạt động như thế nào?

Packets, Routing và sự tin cậy

    Khi bạn download dữ liệu, bạn có thể nhìn thấy thanh tiến trình đầy dần cho đến khi tất cả dữ liệu đến được máy tính của bạn. Liệu những dữ liệu này có đến cùng một lúc và di chuyển trên cùng một con đường hay không? Câu trả lời là không. Đây chính là cách truyền tải dữ liệu cơ bản của Internet: dữ liệu gốc được chia nhỏ ra thành các gói tin(Packets) theo các giao thức tin cậy, sau đó được gửi qua mạng internet qua nhiều tuyến đường khác nhau. Giống như cách chúng ta di chuyển giữa các tuyến đường, nếu như biết tuyến đường này bị tắc, ta sẽ chuyển hướng sang một con đường khác, có thể sẽ dài hơn về mặt khoảng cách  nhưng sẽ nhanh hơn về mặt thời gian. Những gói tin này không tự chọn đường đi cho mình, mỗi gói tin sẽ có địa chỉ nơi nó đi và nơi nó cần đến. 

    Một số các máy tính đặc biệt trên mạng internet mang tên định tuyến (Router) đóng vai trò như người điều phối giao thông, đảm bảo các gói tin di chuyển thông suốt trên mạng. Nếu một tuyến đường bị nghẽn, các gói tin đơn lẻ có thể đi đường khác. Mỗi định tuyến sẽ theo dõi nhiều đường dẫn để gửi gói tin và chọn đường dẫn phù hợp, tối ưu nhất cho gói tin dựa trên địa chỉ IP cần đến. Tối ưu ở đây bao gồm cả về chi phí, thời gian, cũng có thể là chính trị hoặc quan hệ giữa các công ty, thậm chí do người quản trị cài đặt điều hướng. 

    Vậy những router này thuộc về ai? Tại mỗi điểm giao nhau giữa các network sẽ có ít nhất một router. Tại những nơi network lớn giao nhau, có rất nhiều router để đảm bảo sự ổn định. Càng nhiều router thì độ ổn định càng cao. Vậy nên router sẽ thuộc về cá nhân/ tổ chức nào quản lý network đó. Ở cấp độ văn phòng hoặc gia đình Router thuộc về chúng ta, tương tự với cấp độ lớn hơn như nhà cung cấp dịch vụ internet (ISP) thì router thuộc về họ, ở cấp độ chính phủ thì router thuộc về chính phủ... 

TCP (Transmission control protocol)

    Các packet bị chia nhỏ và truyền tải phân tán qua mạng internet, vậy làm sao để chắc chắn răng toàn bộ dữ liệu đã được truyền tải và nhận được ở đích đến. It's TCP time! TCP quản lý việc gửi và nhận toàn bộ dữ liệu dưới dạng gói tin. Trách nhiệm của TPC giống như dịch vụ gửi thư đảm bảo. Khi các gói tin đến nơi, TCP sẽ tiến hành kiểm định và confirm đã nhận từng gói tin và ký đã nhận hàng. Nếu một vài gói tin bị thiếu , TCP sẽ không kí hoặc máy chủ chứa dữ liệu sẽ gửi lại các gói tin. Lúc này, máy tính sẽ chấp nhận sử dụng dữ liệu bị thiếu các gói tin (chấp nhận sai sót - fault tolenrance) hoặc đợi cho đến khi máy chủ gửi lại đầy đủ dữ liệu (dự phòng - redundancy). Nhờ những nguyên tắc này mà chúng ta có thể phát triển và mở rộng internet mà không làm gián đoạn dịch vụ của bất kì ai.

HTTP và HTML

    Các trang web và ứng dụng dựa trên nền web vẫn đang là một trong  những hình thức sử dụng internet phổ biến nhất hiện nay. Và để giao tiếp giữa các máy tính cá nhân và các máy chủ chứa website, các máy tính sử dụng giao thức HTTP (Giao thức truyền tải siêu văn bản - Hyper text transfer Protocol), giao thức này cũng dựa trên bộ giao thức TCP/IP. Khi thực hiện yêu cầu một trang web, máy khách  (client) thực hiện một request theo tiêu chuẩn, sau đó máy chủ sẽ nhận request và trả về các mã HTML (Hyper text markup language - Ngôn ngữ siêu văn bản). HTML là một tập hợp các quy tắc mô tả dữ liệu giúp cho phía server và client thống nhất về format dữ liệu hiển thị, sau đó client(trình duyệt) có thể hiển thị trang web dựa trên kết quả trả về. HyperText - Siêu văn bản ở đây nói đến các định dạng dữ liệu hiển thị bao gồm cả text, hình ảnh và video, file...

    Đến đây chúng ta đã hiểu được cách thức truyền tải dữ liệu qua mạng internet cho đến khi được sử dụng bởi một ứng dụng trên máy tính. Nhưng nếu dữ liệu truyền tải chỉ đơn thuần là các gói tin, hacker hoàn toàn có thể đứng ở các đầu router và đọc được các dữ liệu in/out từ network. Vậy làm sao để các gói tin di chuyển trên internet một cách an toàn?

Truyền nhận dữ liệu an toàn (HTTPS/SSL/TLS)

    Để dữ liệu được an toàn trong khi truyền dẫn, cần tuân thủ theo một số giải thuật mã hóa dữ liệu đảm bảo chỉ hai đầu gửi nhận có thể đọc được dữ liệu, các thành phần trung gian trong quá trình truyền tải không thể đọc được những dữ liệu này. Dữ liệu sẽ được được gửi qua một kênh an toàn bằng cách sử dụng Secure Socket Layer (SSL) và Transport Layer Security (TLS). Có thể coi SSL và TLS như một lớp bảo mật bao quanh việc truyền tải thông tin. Dễ nhận thấy nhất là các website đang truy cập có hình một chiếc khóa  ở thanh địa chỉ và tiền tố https (HyperText Markup Language Secure) trước địa chỉ website. Điều này có nghĩa là dữ liệu trang web của bạn đang được bảo vệ.

    Mã hóa dữ liệu sẽ giúp kết nối của chúng ta được an toàn trên Internet. SSL/TLS sử dụng giải thuật Public key/ Private key.

    Đầu tiên ta cần hiểu mục đích của quá trình mã hóa/giải mã (encrypt/decrypt) là gì. Từ hàng trăm năm trước, người ta đã nghĩ ra cách biến đổi nội dung của thư từ trước khi gửi đi, người gửi và người nhận sẽ cùng thống nhất chung với nhau một quy tắc về nội dung. Ví dụ quy tắc này có thể là: mỗi chữ cái được lùi lại 3 kí tự theo thứ tự trong bảng chữ cái: attack => xqqxzh. Nội dung trong thư sẽ là xqqxzh, người đưa tin hoặc quân địch khi phát hiện cũng không thể hiểu được. Chỉ người nhận biết được quy tắc này mới có thể hiểu nội dung.

    Trong khoa học máy tính, bộ quy tắc về mã hóa/giải mã này được gọi là giải thuật, bởi việc nghĩ ra một giải thuật là không hề đơn giản và tăng cường thêm bảo mật, bên cạnh giải thuật người ta còn sử dụng thêm các key. Với cùng một giải thuật nhưng sử dụng kèm các key(salt) khác nhau cũng sẽ cho ra các kết quả khác nhau, dữ liệu của cùng một giải thuật nhưng sử dụng các key khác nhau cũng sẽ được an toàn. Việc sử dụng chung một key để mã hóa/giải mã dữ liệu được gọi là mã hóa đối xứng  (symmetric encryption). Việc này có thể tiện nếu chỉ có hai phía, nhưng trong thế giới internet, các thành phần ở rất xa nhau, không thể nào gặp để thống nhất về giải thuật, ngoài ra với sức mạnh của máy tính hiện nay, việc brute force (thử tất cả key cho đến khi đúng) khiến cho việc mã hóa đối xứng không còn nhiều ưu thế.

    Một hình thức mã hóa khác là bất đối xứng (asymmetric encrytion). Chúng ta sử dụng một cặp Private key - public key để thực hiện mã hóa/ giải mã dữ liệu. Có thể có nhiều Public key hoặc có thể chia sẻ cho bất kỳ ai dùng để mã hóa dữ liệu, còn Private key sẽ được giữ kín để giải mã. Ý tưởng ở đây là chỉ những cặp Private Key/Public key được pair cùng với nhau thì mới có thể thực hiện cùng quá trình mã hóa/ giải mã. Một key dùng để mã hóa thì key còn lại có thể dùng để giải mã. Khi sử dụng một public key không pair với private key phía còn lại, dữ liệu sẽ không thể được giải mã và ngược lại.

    SSL/TLS cũng sử dụng nguyên tắc này để trao đổi dữ liệu. Hiểu một cách đơn giản, khi bạn truy cập một trang web có chứng chỉ hỗ trợ giao thức https, trình duyệt của bạn sẽ nhận được một chứng chỉ SSL (certificate), trình duyệt sử dụng chứng chỉ này như là một Public key để mã hóa/giải mã các dữ liệu khi thực hiện trao đổi với máy chủ. Phía máy chủ cũng giữ một Private key để mã hóa/giải mã các dữ liệu từ client.

Kết

    Hy vọng với bài viết này các bạn đã hiểu cách mà mạng Internet hoạt động, cả về vật lý, tính logic, và khả năng đảm bảo an toàn thông cho dữ liệu khi truyền tải qua mạng Internet. Ở bài viết sau chúng ta sẽ tìm hiểu kĩ hơn cách mà kết nối HTTPS được hình thành và các thành phần khác giúp đảm bảo dữ liệu truyền dẫn được đảm bảo an toàn.

Các thành phần trong kiến trúc Microservices

 

Mở đầu   

 Với kiến trúc microservice chúng ta sẽ triển khai một hệ thống phân tán (distributed system) bao gồm rất nhiều thành phần kĩ thuật xoay quanh các service về business chính. Hệ thống phân tán sẽ có lợi thế về tính linh hoạt giữa các dịch vụ và nhưng sẽ gặp khó khăn khi phân phối các thay đổi. Bài viết này sẽ đi tìm hiểu các thành phần quan trọng của kiến trúc microservice và tầm quan trọng của chúng .

Thành phần trong kiến trúc microservices

Containers và Orschestration

    Container là thành phần compute chính trong kiến microservice, nó có chức năng chạy các ứng dụng tương tự như VM ở các kiến trúc cũ. Sự khác biệt cốt lõi giữa container và VM nằm ở công nghệ ảo hóa: Containerization và Virtualization. Tuy nói Microservice là kiến trúc của ứng dụng, không phân biệt chạy trên Container hay VM, nhưng do giới hạn về khả năng provisioning, scaling và HA nên VM rất ít tương thích với các concept của microservice.

    Container được thiết kế chủ yếu để cách ly các tiến trình hoặc các ứng dụng với nhau và với hệ điều hành. Cài đặt và chạy một ứng dụng trên container rất đơn giản, nhưng sẽ thế nào nếu cần cài đặt những container này cho một hệ thống, lúc này số container sẽ lên tới hàng chục cho tới hàng trăm và hơn nữa. Đi kèm với hệ thống là các cài đặt về mạng, lưu trữ cho database, lưu trữ các biến môi trường, config của ứng dụng, các nhu cầu về scaling tự động, khôi phục tự động... Lúc này sẽ cần một "nhạc trưởng" để quản lý và điều phối(orchestrated) hoạt động của các container và hệ sinh thái đi kèm. Một số container orchestration có thể kể đến như K8S, Google container engine, Amazon ECS.

API gateway

    API gateway là thành phần thiết yếu của kiến trúc microservice. Do trong một hệ thống phân tán có rất nhiều service, hệ thống cần giới hạn lại các entry point để có thể quản lý được các request ra vào hệ thống, đây chính là tác dụng quan trọng nhất của API gateway. Hệ thống microservice thường được tổ chức theo cách chỉ có API gateway được facing ra ngoài internet, còn các dịch vụ bên trong sẽ giao tiếp với nhau qua internal endpoint hoặc messaging system. Do ở vị trí như một cánh cổng trung gian giữa hệ thống, network và system khác, API gateway có thể đảm nhiệm các chức năng:

• Routing:  API gateway hoạt động bằng cách cấu hình mapping giữa địa chỉ của dịch vụ với một pattern URL của request gọi đến. Lúc này, các hệ thống bên ngoài sẽ chỉ nhìn thấy một endpoint duy nhất của API gateway. Gateway sẽ thực hiện forward request và response của request vào và ra khỏi hệ thống, tới các dịch vụ. Do đó nó cũng có tác dụng che giấu kiến trúc các thành phần bên trong.
• Quản lý truy cập tập trung: Hệ thống luôn có nhu cầu thực hiện authentication, auditing, logging...tập trung với các request vào hệ thống. API gateway trở thành bộ phận hoàn hảo để đặt các tính năng này.
• Quản lý quota truy cập: Tính năng này giới hạn tần suất của request đến hệ thống, các yếu tố detect có thể là url, ip, authentication factor, session... Việc này có thể ngăn chặn giúp việc Ddos hệ thống hoặc crawl data.
• Handle request/response: API gateway có thể được sử dụng để detect các metadata của request hoặc status của response để thực hiện các công việc như custom response hoặc redirect.
• Caching: Một vài API thường rất ít  khi thay đổi dữ liệu trả về, việc cache lại ở Gateway và response ngay lập tức mà ko phải request vào nguồn dữ liệu sẽ giảm tải cho hệ thống.
• Load balancing: Chia tải (request) tới các địa chỉ khác nhau để giảm tải cho một instance.
• Api health monitoring: Nhóm chức năng này giúp gateway có thể detect được trạng thái available của dịch vụ, từ đó có thể chuyển hướng request tới các dịch vụ hoặc thực hiện các kịch bản dự phòng

Một số giải pháp gateway: nginx, spring gateway, kong gateway

Service Discovery 

    Service Discovery giúp quản lý các deployment và phân bố tải giữa các dịch vụ trong quá trình vận hành hệ thống. Trên thực tế, các instance của các dịch vụ được triển khai trên khắp các node của hệ thống, các IP/host của instance có thể bị thay đổi trong khi runtime, start một instance mới hay thay đổi instance khi tăng số instance, service request sẽ không biết được địa chỉ cụ thể của các instance để request đến. Service discovery sẽ giúp giải quyết vấn đề này, nó đóng vai trò như một nhà ga trung tâm, luôn quản lý danh sách các instance đang active. Service Discovery hoạt động với 3 thành phần chính

• Service provider: Là service cung cấp dịch vụ
• Service consumer: Là ứng dụng hoặc dịch vụ đang yêu cầu cung cấp địa chỉ của một service để tiến hành request.
• Service registry: Tồn tại như một database giúp lưu trữ địa chỉ các instance đang available của dịch vụ.

    Các hoạt động của Service Discovery:

1. Service provider khi được sinh ra sẽ đăng kí dịch vụ với service registry location/address của instance
2. Service consumer sẽ request đến Server registry để lấy địa chỉ của dịch vụ thông qua tên dịch vụ
3. Service registry trả về địa chỉ của Service provider đang active
4. Service consumer sẽ request đến Service provider theo địa chỉ nhận được

Service discovery bao gồm hai pattern chính là server-side và client-side. Client-side hoạt động tương tự cách mô tả ở trên, còn server-side sẽ hoạt động hơi khác một chút, sau bước 2, sau khi đã định vị được địa chỉ của service provider, router sẽ forward request tới service tương ứng.

    Với một số giải pháp microservice tự xây dựng, người dùng sẽ cần cài đặt riêng thành phần service discorvey. Ngoài ra nếu sử dụng các giải pháp container orchestration thì người dùng không cần phải quan tâm đến thành phần này, hầu hết đã được build in trong giải pháp, người dùng chỉ cần quan tâm đến các container phục vụ business.

Service Mesh

    Thuật ngữ Service mesh xuất hiện trong bối cảnh cùng với cloud application, containers và microservice. Trong hệ thống microservice, khi có nhiều dịch vụ và instance runtime được sinh ra, việc kiểm soát communication giữa các dịch vụ trở nên rất khó khăn, nếu không có giải pháp hay công cụ hỗ trợ, nhà phát triển hoàn toàn phải kiểm soát communication này bằng cách thủ công bắt đầu từ việc liệt kê connection giữa các dịch vụ. Các nhu cầu bao gồm kiểm soát connection giữa các dịch vụ, lượng traffic phát sinh, metric và monitoring.. Service mesh sẽ giải quyết vấn đề này, nhà phát triển chỉ cần tập trung vào các vấn đề của business. Layer quản lý connection trong mạng lưới dịch vụ phân tán se trở nên transparent với code business.

    Service mesh sử dụng sidecar pattern, pattern này hoạt động với nguyên lý tạo ra một proxy-container bên cạnh các container instance của dịch vụ, proxy container này sẽ định tuyến traffic tới các proxy-container của dịch vụ khác, nhờ đó handle được các connection mà không can thiệp tới hoạt động của container chính.

Load Balancing

    Số lượng request đến hệ thống có thể thay đổi theo lượng sử dụng của người dùng, ví dụ như: theo các ngày đặc biệt trong năm, chương trình khuyến mãi hay các sự kiện tập trung nhiều truy cập... Lúc này hệ thống có thể lựa chọn phương án tăng thêm tài nguyên CPU/RAM(Vertical scaling) hoặc sẽ tạo ra thêm các instance(horizontal scaling) để đáp ứng tải. Với phương án horizontal- scaling, hệ thống cần một thành phần để điều phối request tới các instance của cùng một dịch vụ. Việc điều phối này cần phải linh hoạt theo nhiều tiêu chí để đáp ứng được các bài toán thực tế chứ không phải chỉ là lần lượt chia đều tải trên số lượng instance. Load balancer chính là thành phần này, nó giúp tối ưu hóa xử lý compute, tăng tính ổn định và tin cậy, giảm độ trễ của hệ thống. Load balancer có thể phân phối tải đều tới tất cả các instance trên các node đang được triển khai. Thuật ngữ load balancing không chỉ ở trong phạm vi công nghệ container mà với công nghệ Virtual Machine cũng tương tự, ở đây thay vì phân phối tải tới các container thì load balancer sẽ phân phối tải tới các máy vm trong cùng một group.

Circuit Break

    Đây là cơ chế giúp ngăn ngừa các lỗi có thể xảy ra khi request gửi đến một instance mà ko có phản hồi hoặc có tín hiệu unavailable. Service client khi request tới một service khác nên gọi qua một proxy có chức năng tương tự như một cầu dao diện(circuit break). Khi số lượng request thất bại liên tục đạt tới một ngưỡng, kết nối sẽ bị ngắt hoàn toàn ngay từ proxy, khi kết nối bị ngắt, các request tới dịch vụ đích sẽ bị từ chối ngay lập tức. Sau một khoảng thời gian, một số lượng request test nhất định được phép đi qua, nếu những request này thành công thì cầu dao sẽ được đóng lại và khôi phục kết nối, còn ngược lại, một chu kì lỗi timeout sẽ tiếp tục diễn ra. Quá trình này giúp tránh những trường hợp như dịch vụ vừa khôi phục đã phải nhận một lượng lớn request, dẫn đến hệ thống tiếp tục bị treo, không thể phục hồi hoàn toàn.

    Pattern này tạo điều kiện cho dịch vụ tự khôi phục và không xảy ra quá nhiều lỗi trên dịch vụ đích. Quá trình hoạt động của circuit break được tóm tắt qua 3 trạng thái: Closed State(Trạng thái ngắt), Open state (Trạng thái mở), Half-Open State (Trạng thái test)

Centralized Logging

    Logging luôn luôn là yêu cầu cần thiết cho bất cứ hệ thống nào, chức năng phục vụ cho tracing dữ liệu, debugging và troubleshooting ứng dụng. Nhưng với sự phức tạp của hệ thống microservice, log đến từ hàng chục đến hàng trăm instance với các định dạng log của các ngôn ngữ khác nhau, debugging trở nên thật sự khó khăn. Nhà phát triển không thể access vào console log của từng ứng dụng và kéo hàng nghìn dòng log để tìm kiếm thứ mình cần. Khó khăn còn đến từ multiple instance của mỗi dịch vụ, người dùng không thể biết exception vừa bắn ra từ hệ thống đến từ instance nào. Việc logging từ ứng dụng container cũng trở nên khó khăn hơn từ vm do nguồn phát sinh log đã trở nên đa dạng và phức tạp hơn rất nhiều. 

    Ý tưởng cho việc logging cần dễ dàng cho việc truy cập, lưu được theo retention dài, da dạng các chỉ số index cho việc tìm  kiếm từ log(xuất phát từ dịch vụ nào, thời gian, nội dung, token, session, url...). Việc lưu trữ và truy xuất cũng cần tập trung thay vì rải rác trên các dịch vụ hoặc thành phần khác nhau. Các công cụ phổ biến như ELK, EFK hay Splunk là ý tưởng cho việc tìm kiếm, lọc và query log. Trước đó còn cần có bước chuẩn hóa định dạng log trước khi đẩy dữ liệu vào các công cụ tìm kiếm.

Monitoring and Alert

         Các thành phần hạ tầng của một hệ thống bao gồm CPU, RAM, Storage và Bandwidth

    Thành phần này thường không được chú trọng trong thời gian đầu phát triển hệ thống, nhưng khi hệ thống đã đi vào hoạt động thì lại thực sự cần thiết. Monitoring là tính năng cho phép quản trị viên và nhà phát triển có thể theo dõi sức khỏe hệ thống realtime hoặc tổng hợp lại theo các khoảng thời gian  (giờ, ngày, tháng, năm), từ đó có thể tracing các issue của hệ thống như bị tấn công, các function chưa tối ưu, thiếu tài nguyên (cpu/ram/storage/bandwidth). 

    Alert sẽ cho phép người dùng cài đặt các mức cảnh báo hoặc các cài đặt về healthcheck sau đó gửi cảnh báo đến người dùng (email, slack, discord...) cho phép người dùng aware được sớm các vấn đề mà hệ thống đang gặp phải, từ đó đưa ra các quyết định thích hợp để giữ hệ thống hoạt động ổn định. Tránh gặp phải các tính trạng như hệ thống bị treo do hết ram/cpu hoặc quá nhiều người truy cập dẫn đến bottle neck hay database lưu trữ hết dung lượng khiến hệ thống gặp lỗi...

Các giải pháp phục vụ cho Monitoring và Alert có thể kể đến: Prometheus, Grafana

Messaging System

    Messaging phục vụ nhu cầu giao tiếp giữa các dịch vụ. Do kiến trúc microservice dựa trên sự phân tán, giao tiếp point to point sẽ gặp một số issue: các request có thể bị mất do lỗi logic code, network latency, service downtime... Bạn có thể đã từng nghe đến Message queue và Message broker. 

Message queue đảm bảo dữ liệu sẽ không bị mất trong các trường hợp kể trên, ngoài ra chức năng cơ bản nhất của message queue là vận chuyển dữ liệu đến các client/consumer đúng thứ tự như khi chúng được ghi vào queue(FIFO). 

    Message broker được thiết kế để duy trì message cho đến khi consumer/subscribe có thể nhận được dữ liệu. Điều đó có nghĩa là Messaging system giúp giảm effort rất nhiều cho nhà phát triển khi không phải xử lý các vấn đề như message translation, message validation, topic/channel ACL, routing message từ producer đến consummer, đảm bảo tính persistence, vận chuyển và streaming dữ liệu... mà chỉ cần tập trung vào code business. Ngay cả với các hệ thống không dựa trên kiến trúc microservice thì Message broker cũng là một thành phần phổ biến và có nhiều tác dụng.

Các giải pháp cho Messaging trong hệ thống microservice: Kakfa, RabbitMP, Active MQ

Single Page Application 

    Single Page Application ít được chú ý nhưng cũng rất phổ biến trong kiến trúc microservice. Đây là thành phần thuộc lớp ứng dụng frontend. Giống như sự tương thích giữa Container với microservice, thì SPA cũng phát triển và phù hợp với hệ sinh thái microservice. Thay vì render tất cả HTML DOM từ phía server như các công nghệ đã có từ lâu (Spring MVC, PHP, Java Servlet, ASP.NET MVC...), SPA chỉ trả về các resource và code logic, hầu hết được đóng gói trong các file js bundle, từ đó kết hợp với các dữ liệu để render ra HTML theo behavior của người dùng ngay trên client browser (client side rendering)

    SPA được xây dựng dựa trên các component, vừa tăng tính tái sử dụng code, từ đó tăng tốc độ phát triển ứng dụng. Đi cùng với SPA thường là Rest API giúp giao tiếp với phía server. Với SPA, người dùng sẽ có trải nghiệm ứng dụng mượt mà, giảm thời gian tải trang giữa các lần truy cập và cũng giảm tải cho phía server. SPA cũng giúp tách riêng việc phát triển UI ứng dụng và xử lý logic backend phía sau, tăng tốc phát triển của dự án.

Các công nghệ SPA phổ biến: Angular, React, Vuejs

Configuration Server

    Một hệ thống microservice chạy trên rất nhiều container, các container này lại cần rất nhiều cấu hình để phục vụ CI/CD hoặc runtime. Configuration server sẽ có tác dụng lưu trữ tập trung các dữ liệu cấu hình và có thể được truy cập từ các service hoặc các thành phần khác của hệ thống. Giải pháp lưu trữ tập trung cấu hình ngoài việc đảm bảo việc dễ dàng truy cập dữ liệu từ các service còn giải quyết những vấn đề xung quanh như ACL, versioning của dữ liệu, grouping by project/environment...

Kết

    Bài viết đã đề cập đến các thành phần quan trọng của kiến trúc Microservice và tầm quan trọng của mỗi thành phần. Nhìn nhận ở một góc độ khác, hầu hết các thành phần của hệ thống phân tán lại có chức năng quản lý tập trung và kết nối các dịch vụ, đây chính là điểm khác biệt giúp bù đắp lại những issue của kiến trúc microservice so với monolithic. Chúng ta sẽ đi sâu vào mỗi thành phần và cách sử dụng các thành phần trên lý thuyết và cả thực tế ở những bài viết sau.

Những lợi ích của microservices

 Mở đầu

    Microservice đã nhanh chóng trở thành kiến trúc phổ biến cho những công ty, tổ chức tân tiến,  Nó là một kiến trúc xây dựng hệ thống phân tán cho phép nhà phát triển xây dựng, triển khai và co giãn các dịch vụ riêng lẻ một cách độc lập. Điều này cho phép dễ dàng quản lý một ứng dụng lớn và thay đổi business nhanh chóng theo các yêu cầu .

 Ở bài viết trước tôi đã nhắc đến những khó khăn và thách thức khi làm việc với microserivce, nhưng như vậy là không công bằng nếu ko nhìn về mặt lợi ích mà microservice mang lại. Bài viết này sẽ là câu trả lời tiếp theo cho câu hỏi Microservice có phải là miền đất hứa? (Link đến bài Microservice có phải là miền đất hứa)

Những lợi ích của microservices

Easy to develop and maintain

Microservice tương đối nhỏ và đơn giản hơn ứng dụng monolithich nên dễ dàng hơn trong việc phát triển và bảo trì. Các dịch vụ được isolate về business và data nên hoạt động và performance của dịch vụ này sẽ ít hoặc không ảnh hưởng đến toàn hệ thống. Với một trường hợp khi một tính năng cao tải, với hệ thống monolithic thì toàn bộ tài nguyên available của hệ thống sẽ bị sử dụng hết, toàn bộ hệ thống có thể downtime, thậm chí phải cần đến reset toàn bộ, trong khi với microservice, issue không ảnh hưởng tới toàn hệ thống và có thể được giải quyết bằng các giải pháp cục bộ.

Highly available

    Tính sẵn sàng cao nói đến việc service của bạn luôn sẵn sàng trong nhiều điều kiện khác nhau(một instance bị crash, cao tải, không phản hồi...). Theo mô hình tiêu chuẩn, một hệ thống microservice thường được triển khai trên các nền tảng ảo hóa, một service được chạy song song trên nhiều runtime instance(Replica), hệ thống Container Orchestration sẽ kiểm tra tính sẵn sàng và điều  phối request đến các instance đang available, và ngăn các request đến các instance có vấn đề cho đến khi chúng phục hồi.

Scalable

    Khả năng có giãn của service mang lại hiệu quả cả về kinh tế và performance cho cả hệ thống. Tưởng tượng khi hệ thống thấp tải hoặc các service không yêu cầu quá nhiều tài nguyên, có thể giảm cấu hình của từng instance hoặc giảm cả về số lượng instance để tối ưu chi phí. Khi hệ thống yêu cầu tài nguyên lớn để xử lý trong các trường hợp đặc biệt, hệ thống lại sẵn sàng tăng cấu hình từng instance hoặc tăng số lượng lớn các instance để đáp ứng tải. 

Resilient

    Khả năng phục hồi: Các nền tảng ảo hóa thường có cơ chế để kiểm tra sức khỏe từng phần hoặc cả hệ thống từ đó đảm bảo tự động khôi phục hoạt động của ứng dụng và hệ thống khi có vấn đề xảy ra, các vấn đề có thể đến từ nội hàm của dịch vụ  như cao tải, crash ứng dụng, do người dùng delete các instance hoặc các vấn đề lớn hơn như máy chủ vật lý gặp lỗi, cần chuyển sang node khác để hoạt động.

Fault-tolerant

    Khả năng chịu lỗi: Khả năng này khá trừu tượng cho những người mới tiếp cận với microservice. Khả năng chịu  có vẻ tương đồng với khả năng phục hồi, nhưng scope của những tính năng này không giống nhau. Khi các instance gặp lỗi, hệ thống cũng cần có khả năng handle được lỗi này. Nhưng không chỉ có vậy, nếu nhìn một cách tổng quát hơn, bất kì vấn đề nào của hệ thống microservice đều có thể dẫn đến khả năng ảnh hưởng đến business và dữ liệu. Mục đích cuối cùng của khả năng chịu lỗi là đảm bảo business ít hoặc không bị ảnh hưởng bởi các lỗi của hệ thống, bảo gồm các lỗi do logic và các lỗi do hạ tầng, kết nối. Các lỗi của hệ thống có thể kể đến như Slow Network, Service downtime, Connection timeout, Cross service transaction...

Increase Release Cycle

    Do các business domain đã được chia nhỏ theo các service nên tốc độ  phát triển có thể được gia tăng bằng cách triển khai nhiều team cùng phát triển các domain của ứng dụng. Nhưng từ bài viết trước chúng ta cũng thấy được microservice khiến việc duplicate các effort lên là khá thường xuyên, nhưng khi đã có giải pháp để tối ưu thì tính linh hoạt của microservice được thể hiện rõ rệt, do các ứng dụng tương đối nhỏ, ít depend với nhau nên khả năng phát triển độc lập được gia tăng. Quá trình CI-CD được tích hợp liên tục mà không làm gián đoạn cả hệ thống trong thời gian dài

Technology combination

    Trước đây chúng ta thường thấy có những stack thường đi cùng với nhau như XAMMP, LAMP, WAMP vs MAMP trong phát triển ứng dụng web hoặc các giải pháp của .Net, C-sharp thường gắn liền với hệ sinh thái của Microsoft. Nhưng giờ đây với sự phát triển của công nghệ nói chung và microservice nói riêng, các stack tương thích với nhau dễ dàng hơn rất nhiều, nhiều chuẩn giao tiếp, protocol được phát triển và được hỗ trợ bởi nhiều ứng dụng như Rest API, gRPC, Messaging... Cả một hệ thống hoặc ứng dụng lớn có thể được triển khai đơn giản trên công nghệ container khi tất cả source code và các dependency đã được đóng gói trong một image duy nhất, rất tiện dụng. Hệ thống có thể kết hợp nhiều công nghệ, đa dạng ngôn ngữ lập trình cho các mục đích phù hợp, tối ưu hóa hệ thống.

Hardware/Resource Optimization

Nhờ công nghệ container mà chúng ta không cần phải triển khai cả một máy chủ ảo để chạy các ứng dụng theo cách truyền thống, các ứng dụng khi được viết bằng các ngôn ngữ phù hợp có thể chạy trên các cấu hình container nhỏ (0.25CPU/ 0.25 Gb RAM) hoặc thậm chí nhỏ hơn nữa, bao gồm cả các ứng dụng phía backend. Quá trình CI-CD trên các dịch vụ nhỏ cũng giúp tăng tốc và tối ưu về tốc độ phát triển. Do có thể chia nhỏ việc phát triển các dịch vụ trên các team/member nhỏ hơn nên việc phát triển cũng tối ưu về nguồn lực, mỗi team/member chịu trách nhiệm trên service của mình, giảm việc phải hiểu và debug cả project lớn và phải hiểu nhiều tech stack, language khác nhau.

Reusability

Khả năng tái sử dụng cao do các service được đóng gói cả code và dependency cùng với nhau, khi có bất cứ nhu cầu về triển khai lại các version code khác nhau, chỉ cần deploy lại image tương ứng, mà không cần build lại từ đầu. Cùng image đó có thể triển khai trên nhiều hạ tầng khác nhau, với chắc chắn cùng một phiên bản code, stable về business. Write once, run everywhere, chỉ cần máy chủ có triển khai công nghệ container thì microservice có thể triển khai trên bất kì hệ điều hành nào bao gồm cả linux và window.

Security

Các service có thể được tách biệt về code và cả data nên có thể che giấu được business phía sau. Đảm bảo bảo mật về mặt dữ liệu và business. Các dịch vụ cũng không access được đến các secret, config của dịch vụ khác, đảm bảo isolate giữa các teams/members.

Kết

Quả cả hai bài viết, chúng ta đã có cái nhìn khá toàn diện về ưu/nhược điểm của kiến trúc microservices. Điều này sẽ giúp nhà phát triển đưa ra được quyết định tốt nhất khi xây dựng kiến trúc hệ thống

Peace! 

Tác giả: Ethanol Tran