ĐẠI HỌC BÁCH KHOA HÀ NỘI

TRƯỜNG CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

HỆ PHÂN TÁN

Đề tài:
XÂY DỰNG HỆ THỐNG ATM

Nhóm sinh viên thực hiện:

Hoàng Quốc Bảo 20187221
Phan Đức Hoàng
Long 20187259
Nguyễn Tấn Nam
Anh 20187215
Bùi Đức Kiên 20180785
ThS. Đặng Tuấn
Giảng viên hướng dẫn: Linh

Hà Nội, tháng 07 năm 2022

Lời nói đầu
Lời đầu tiên , cả nhóm em xin gửi lời cảm ơn đến thầy Đặng Tuấn Linh ,
thầy đã nhiệt tình giảng dạy trên lớp , hỗ trợ những thông tin cần thiết và giải đáp
các thắc mắc cho nhóm và các bạn đang thực hiện đề tài . Thông qua những bài
giảng trên lớp về môn học của thầy , các thành viên trong nhóm em đã tiếp thu
được nhiều kiến thức hữu ích liên quan . Qua đó giúp chúng em có thể hiểu và nắm
bắt được quy trình làm bài
Đề tài “Xây dựng hệ thống ATM” hoàn thành là kết quả  của quá trình
nghiên cứu nghiêm túc của các thành viên của cả nhóm trong quá trình học tập và
tiếp thu kiến thức dưới sự hướng dẫn tận tình của giảng viên hướng dẫn và các tài
liệu được giảng viên hướng dẫn chia sẻ qua các kênh giao tiếp trong trong suốt
quá trình thời gian giảng dạy của học kỳ .. Với những kiến thức học được từ môn
Thiết kế và xây dựng phần mềm, bài toán của em đi giải quyết
các vấn đề thiết kế và xây dựng hệ thống ATM.
Tuy nhiên do điều kiện thời gian cũng như kiến thức còn hạn chế nên
không tránh khỏi những thiếu sót, rất mong được sự góp ý nhiều hơn của thầy. Em
xin chân thành cảm ơn!
 Chương 1. Khảo sát hệ thống
Lí do chọn đề tài :
Hiện nay, hệ thống ATM giao dịch ngân hàng là một trong những giải pháp quản
lý và trao đổi tài chính phổ biến nhất hiện nay với số lượng người dùng rất lớn, đặt ra
một bài toán hóc búa cho cơ chế bảo mật, độ chịu tải và tính toàn vẹn thông tin.
Qua thăm dò những chức năng đó, chúng em đã áp dụng những kiến thức đã học và
thực tiễn tại các hệ thống ATM. Chúng em xây dựng mô phỏng hệ phân tán &
microservices cho hệ thống giao dịch ATM.
1.1. Mô tả hệ thống
1.1.1. Nhiệm vụ cơ bản
Hệ thống rút tiền ATM với các tính năng cơ bản cho người dùng như
sau:
- Kiểm tra thông tin & số dư
- Rút, chuyển tiền
- Đổi mã PIN
- Khoá thẻ
- Gửi thông báo về Email
1.1.2. Hệ thống
- Hệ thống Log lỗi, message từ Queue
- Worker gửi Email từ Queue
- Phân giải hệ thống tránh tắc nghẽn

1.2. Phân tích hệ thống

Qua phân tích chức năng, nhóm chúng em tiến hành thiết kế hệ thống với 4
Service chính:
- Email Service: Dùng để gửi email sau khi người dùng biến động số dư.
- Account Service: Dùng để xác thực người dùng và quản lý phiên đăng
nhập.
- Bank Service: Dùng để xử lý các vấn đề về tiền trong tài khoản người
dùng.
- Log Service: Dùng để thông báo, ghi lại các bản ghi nhằm soát lỗi ở hệ
thống microservices.
Cơ sở dữ liệu sử dụng: MongoDB (Thực ra để xây dựng hệ thống bank tối ưu
cần phải dùng Oracle, tuy nhiên trong phạm vi môn học, chúng em sử dụng
mongoDB để dễ dàng demo và triển khai)
 Chương 2. Thiết kệ hệ thống
2.1. Account Service
Service này chủ yếu phục vụ việc xác thực người dùng và tạo phiên với 2 api
chính là:
- [POST: /auth]: Login hệ thống
Request Body: (application/json)
{
"stk":"4012555541213654",
"password":"rsapass"
}
 Mô tả Body
Tên thuộc tính Mô tả
Stk Số tài khoản người dùng
password Bản mã của mật khẩu người dùng
với mã công khai RSA
 Mô tả response
{
"code": 200,
"message": "Dang nhap thanh cong!",
"data": {
"name": "HOANG QUOC BAO",
"balance": 997000000,
"accessToken":
"1wJ07Q0PgnJf3wKUFOXrIgu65ddsp5ZA9YqbfMqz/i0="
}
}
- [Get: /checkUser]:
- Mô tả params:
Tên params Mô tả
stk Stk người cần nhận
accessToken Token người dùng
 Mô tả response
{
"code": 200,
"message": "Kiem tra thanh cong!",
"data": {
"name": "HOANG QUOC BAO"
}
}

- [Get: /checkAccessToken]:
 Mô tả params:
Tên params Mô tả
accessToken Access Token người dùng

 Mô tả response
{
"code": 200,
"message": "Dang nhap thanh cong!",
"data": {
"name": "HOANG QUOC BAO",
"balance": 997000000
}
}
- [Get: /logOut]:
 Mô tả params:
Tên params Mô tả
 accessToken Access Token người dùng

 Mô tả response
{
"code": 200,
"message": "Dang xuat thanh cong!",
"data":null
}
2.2. Email Service
Email service sẽ đọc thông báo gửi email từ Email Queue và gửi email theo yêu
cầu đó.
2.3. Bank Service
- [POST: /withdraw]: Rút tiền

/withdraw /checkAccessToken
(Bank Service) (Account Service)

Email Queue Log Queue

 Mô tả API body:
{
"stk": "4012555541213654",

"accessToken":"y1UqnLTjhQMpth4ctf2FddQCQXCjdbj2ARZ9Z86eg5I="
,
"money":1000000
}

 Mô tả body:
Tên params Mô tả
accessToken Access Token người dùng
stk Stk người dùng
money Số tiền cần rút
  Response:
{
"code": 200,
"message": "Rut tien thanh cong!",
"data": null
}
- [POST: /sendMoney]: Chuyển tiền

/sendMoney /checkAccessToken
(Bank Service) (Account Service)

/checkUser
(Account Service)
Email Queue Log Queue

 Mô tả body:
{
"stk": "4012555541213654",
"stkNhan": "40125555412136121",

"accessToken":"c1x9tLlzD64R3szPUAD9MAqEXC18iYepMarAc6mgiRw
=",
"money":1000000
}
Tên params Mô tả
accessToken Access Token người dùng
stk Stk người dùng
money Số tiền cần chuyển
stkNhan STK người nhận

 Mô tả response:
 {
"code": 200,
"message": "Chuyen tien thanh cong!",
"data": null
}
2.4. Log Service:
Log Service đọc message log từ queue rồi thông báo lên các nền tảng log như
ELK,…

Chương 3. Triển khai hệ thống

3.1.1. Triển khai hệ thống
Hệ thống được triển khai backend với linux/docker, người dùng sẽ dùng WindowApp thông qua .Net
Framework.

Màn hình sau khi Login

 Màn hình chuyển tiền

3.2. Tính mở rộng & nhân bản

- Các Service có thể mở rộng là service Log và Email service, chỉ cần nhân bản worker là
Service tự đọc các message ở Queue của mình và làm việc.
- Các Service giao tiếp bằng Rest cần xây dựng hệ CSDL phân tán với tính đồng bộ cao
để đồng bộ CSDL khi phân tán dữ liệu vào những server khác nhau. Khi CSDL thay đổi
thì sẽ đẩy một luồng queue thông báo thay đổi cho hệ server cập nhật dữ liệu, trong thời
gian cập nhật dữ liệu thì người dùng không thể tiến hành giao dịch số tiền Chết.
3.3. Tính chịu lỗi
Khả năng chịu lỗi là một đặc điểm thiết yếu của mọi kiến trúc microservice. Lý do
đằng sau điều này rất rõ ràng và đơn giản: Sau khi các điểm tích hợp trong hệ thống của
chúng tôi đạt đến một con số nhất định, lỗi sẽ xảy ra hàng ngày. Các lý do chỉ đơn giản là
thống kê. Như tôi sẽ trình bày, chúng ta không thể bất chấp các định luật toán học.

Đó là lý do tại sao chúng ta cần hiểu các động cơ chính của thất bại từ một góc độ cao
hơn. Cần phải đưa ra các quyết định chiến lược một cách hiệu quả. Nếu không có những
quyết định này, chúng ta không thể đạt được mức độ chịu lỗi mà chúng ta hướng tới.

3.4. Kiến trúc của hệ thống & giao tiếp, trao đổi thông tin

Hệ thống sử dụng kiến trúc Microservice giao tiếp với nhau thông qua message Queue và
RestAPI.
3.5. Đồng bộ hoá

Khi triển khai hệ thống phân tán, việc phải đồng bộ hoá dữ liệu là rất quan trọng, ví dụ
ATM kết nối với máy chủ A với CSDL A, nhưng ATM B lại kết nối với CSDL B, khi
Client rút tiền ở máy chủ A nếu không đồng bộ thì ở CSDL B vẫn giữ nguyên số dư. Vì
vậy cần có tính đồng bộ trong hệ thống phân tán. Ở đây chúng em đẩy qua message
Queue khi khân bản bệ thống máy chủ.