Hệ thống Phân tán

Distributed Systems
III. Các công nghệ và tiếp cận
phát triển HT Phân tán
1. Giới thiệu
 Dịch vụ web
 dịch vụ web - web service
 mô hình xây dựng WD phân tán dựa trên các dịch vụ web
 các dịch vụ web cung cấp giao tiếp (service interface) cho phép client giao tiếp
với server theo cách tổng quát hơn
 các yêu cầu và phản hồi trong web service thường đóng gói định dạng XML
truyền bằng giao thức HTTP, và giao thức giao vận khác
 bảo mật đường truyền: kết hợp SSL/TLS
 dịch vụ web trở nên phổ biến trong hệ phân tán, hỗ trợ tích hợp, tương tác dễ
dàng qua Internet
 cho phép phát triển nhanh các ứng dụng, tích hợp các chức năng/dịch vụ từ hệ
thống/tổ chức khác
 SOAP: các hệ thống - thuộc 1 tổ chức
directory service: trong 1 ht có nhiều thành phần và các thực thể( máy tính)
XML: extensible mark up language
HTML: hyper text .....

1. Giới thiệu
các ứng dụng có sử dụng, khai thác dịch vụ web

dv thư mục an ninh an toàn

 Mô hình
phối hợp

 Nền tảng: Web service

đặc tả dịch vụ web

 XML - đóng gói giao thức đặc trung của kiến trúc

 URI - vị trí
 HTTP - giao thức truyền
 Giao thức SOAP: đặc tả quy tắc XML để đóng gói thông điệp >< hiện nay: REST
 web service, có thể xây dựng trên web service khác
 WSDL: mô tả web service
 app: ứng dụng khai thác web service
 một số dịch vụ chung
2. Cơ bản về web service
 Nói chung các web service có thể xử lý thông điệp XML-SOAP
Hiện nay, một lựa chọn phổ biến nữa là REST
 Tổng hợp các service (combination)
 Các web service có thể được kết hợp => ứng dụng cung cấp chức năng mới, đầy
đủ hơn
VD bên
2. Cơ bản về web service
 Truyền thông (communication)
 Phổ biến áp dụng:
 Nếu tác vụ xử lý tốn thời gian => sử dụng các cơ chế thông điệp dị bộ
 Tương tác với client, tác vụ như kiểm tra credit card => sync request-reply
 SOAP:
 xây dựng dựa trên tác vụ gửi từng thông điệp 1 chiều => có thể hỗ trợ các kiểu truyền
thông khác nhau
2. Cơ bản về web service
 Độc lập - loose coupling
 giảm thiểu sự phụ thuộc giữa các service => trong hệ phân tán: có thể xây dựng
các service tổ hợp, cũng như khi thay đổi service - giảm rủi ro ảnh hưởng service
khác
 Biểu diễn thông điệp
 SOAP dựa trên XML - ngôn ngữ tự mô tả, văn bản.
 XML: mặc dù tốn tài nguyên hơn (lưu, xử lý), nhưng dễ đọc, dò lỗi
 Rest (Representational State Transfer): ràng buộc chặt hơn SOAP - url và các
http operation method (get, post, put, delete) => hướng thao tác với đối tượng
dữ liệu hơn là giao diện (interface)
2. Cơ bản về web service
SOAP
 Giới thiệu
 được thiết kế để hỗ trợ cả client-server và tương tác async , thông qua Internet
 sử dụng XML làm khuôn dạng cho cả request và reply
 sử dụng giao thức truyền HTTP (post), nhưng có thể sử dụng các giao thức
truyền khác như TCP, UDP, SMTP
 SOAP API được cài đặt - hỗ trợ trên hầu hết các nền tảng phát triển ứng dụng
như .net, java, php, python, ...
2. Cơ bản về web service
SOAP
 Thông điệp SOAP
 thông điệp được đóng gói trong SOAP envelop
 Header:
 phục vụ xử lý - ngữ cảnh,
 log, audit (có thể cập nhật header)
 Body:
 XML document cho service
 trong client-server: chứa req và res msg
2. Cơ bản về web service
SOAP
 Truyền thông điệp SOAP
 có thể dùng các giao thức khác nhau
 hay dùng HTTP và method POST
 Header:
• URI => end point
• action => operation
 body: SOAP message
2. Cơ bản về web service
SOAP
 Truyền thông điệp SOAP
 Hỗ trợ truyền thông tin cậy, tiêu chuẩn hỗ trợ truyền thông với 1 message:
 At-least-once : thông điệp được truyền ít nhất 1 lần, báo lỗi nếu kh truyền được
 At-most-once: thông điệp được truyền nhiều nhất 1 lần, nếu lỗi không truyền đc =>
không báo lỗi
 Exactly-once: thông điệp đc truyền đúng 1 lần, báo lỗi nếu kh truyền được
3. Đặc tả dịch vụ
 Service descriptions
 Các giao tiếp - interface của dịch vụ cần đc mô tả => để client có thể truyền
thông với service
 Trong dịch vụ web, các định nghĩa interface được mô tả, cùng với
 cách thức truyền thông điệp (vd SOAP over HTTP)
 vị trí của dịch vụ (URI)
 Để hỗ trợ nhiều nền tảng công nghệ khác nhau: mô tả sử dụng ngôn ngữ XML

 Với web service (SOAP), phổ biến sử dụng ngôn ngữ đặc tả Web Services
Description Language (WSDL), V2
3. Đặc tả dịch vụ
 WSDL gồm
 phần mô tả trừu tượng
 các kiểu
 thông điệp
 giao tiếp
 phần cụ thể
 cách gắn kết
 vị trí dịch vụ
4. Dịch vụ thư mục cho dịch vụ web
 Vấn đề
 làm thế nào client biết có dịch vụ nào và ở đâu ?
 phương án:
 lấy thông tin định nghĩa (thủ công) - WSDL
 qua dịch vụ thư mục - UDDI
 Vận hành
 cung cấp dịch vụ: đăng ký với thư mục
 sử dụng dịch vụ:
 truy vấn thư mục
 giao tiếp với cung cấp dịch vụ
5. Web service Security
Web Service Security Basic Picture
 Web Services: tương tác với nhau qua thông
Message
điệp (trước là SOAP) Originator
 Thông điệp có thể đc truyền qua nhiều môi
trường
=> Áp dụng các kỹ thuật mã hóa đường truyền
SSL ?
 Các thông điệp (SOAP) có thể được mã hóa, ký, ..

Message
Recipient
Security Challenges for Web Services
 Sơ đồ trước: mô hình security cơ bản
trong kiến trúc client-server Message
Creator
 SOAP hỗ trợ nhiều mô hình truyền thông
khác nhau:
Node
 Multiple relaying brokers.
 Multiple recipients. Node
=> Mỗi nút kết nối khác nhau =>
 Có thể cần xác thực ở mỗi bước Node
 Các nút có thể tham gia xử lý thông điệp
Message Message Message
Recipient Recipient Recipient
 Kiến trúc phân lớp mạng
 Khái niệm
 Xác thực - Authentication
 Quyền - Authorization
 Tin cậy - Confidentiality
 Khái niệm
 Tính toàn vẹn - Integrity
 Tính duy nhất của thông điệp - Uniqueness
 Ủy quyền - Delegation
 Chuyển tiếp - Federation
Các rủi ro của web service
 Alteration
 Snooping
 Relay
 Man in the middle
 Denial of service
SOAP message security
 Soap message security <?xml version="1.0" encoding="utf-8"?>
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..."
 Thông điệp SOAP hỗ trợ xmlns:ds="...">
<S11:Header>
mã hóa, ký số <wsse:Security xmlns:wsse="...">
 Có thể an ninh tầng giao <ds:Signature>
<ds:SignedInfo>
vận cũng như thông điệp <ds:CanonicalizationMethod Algorithm= ""/>
<ds:SignatureMethod Algorithm=""/>
</ds:SignedInfo>
<ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
 SOAP Header: <ds:KeyInfo>
<wsse:SecurityTokenReference>
 Lưu các thông tin <wsse:Reference URI="#MyID"/>
</wsse:SecurityTokenReference>
metadata về security </ds:KeyInfo>
</ds:Signature>
 SOAP security: dựa trên </wsse:Security>
</S11:Header>
XML security (mã hóa, <S11:Body wsu:Id="MsgBody“>…</S11:Body>
ký số) </S11:Envelope>
 SOAP message security
 Sử dụng chữ ký số và mã hóa để bảo mật thông điệp
 Có thể gửi security token như là 1 phần thông điệp:
 X509 certificate, Kerberos ticket, ...
 Đảm bảo toàn vẹn - signature
 Đảm bảo bí mật - mã hóa
XML Security
 Web: môi trường phổ biến trao đổi thông tin giữa các tổ chức
=> cần mô hình và cơ chế đảm bảo an ninh thông tin trên web
 Tài liệu trao đổi trên web: XML được sử dụng phổ biến

 XML
 ngôn ngữ thẻ
 mô tả cấu trúc
 Ký số trong XML
 Đặc tả XML Signature specification: mô tả cách thức ký số nội dung tài liệu XML
 Các bước ký tài liệu:
 Tính giá trị băm của dữ liệu
 Ký giá trị băm
 Truyền dữ liệu và chữ ký
 Các bước kiểm tra chữ ký

 XML signature: các thẻ => chữ ký và cách thức kiểm tra chữ ký
Cấu trúc vùng thông tin chữ ký
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
SignedInfo
<SignatureMethod/>
(<Reference URI? > Canonicalization
(<Transforms>)?
<DigestMethod> Signature
<DigestValue>
</Reference>)+ Reference
</SignedInfo>
<SignatureValue/> SignatureValue
(<KeyInfo/>)?
(<Object ID?/>)*
</Signature> KeyInfo

ObjectID
Ví dụ chữ ký
<Signature Id="MyFirstSignature" xmlns=http://www.w3.org/2000/09/xmldsig#>
<SignedInfo>
<CanonicalizationMethod Algorithm=“…"/>
<SignatureMethod Algorithm=“…"/>
<Reference URI=“…">
<Transforms>
<Transform Algorithm=“…"/>
</Transforms>
<DigestMethod Algorithm=“…"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue> </DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
 Một số tiêu chuẩn đặc tả
 VD một số Algorithm URI
Canonicalization http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Digest http://www.w3.org/2000/09/xmldsig#sha1
Signature • http://www.w3.org/2000/09/xmldsig#dsa-sha1
• http://www.w3.org/2000/09/xmldsig#rsa-sha1
Encryption •http://www.w3.org/2001/04/xmlenc#tripledes-cbc
•http://www.w3.org/2001/04/xmlenc#aes128-cbc
 Giải thích
Tag Element Purpose
CanonicalizationMethod The name of the method used to create canonical XML.
SignatureMethod Name of the method used to hash and sign the content.
Reference Contains the digest method and the digest value. Can occur multiple
times. URI attribute points to the digested resource.

Transforms (optional) URI list for all the operations (XSLT, canonicalization, etc) that have
been applied before digesting.
SignatureValue The base64 encoded value of the signature.
KeyInfo (optional) Includes the key that can be used to validate the signature.
 XML Canonicalization
 <name>Bob</name>
 Giá trị băm, chữ ký => phụ thuộc giá trị  <name>
dữ liệu - đến bit. Bob
 Khó khăn với định dạng XML: </name>
 <s11:Envelope
 ASCII endlines khác nhau: \r,\n xmlns:xx=“[someurl]”
 Các tài liệu XML khác nhau - nhưng tương ymlns:yy=“[sameurl]”>
<xx:FName>..</xx:FName>
đương nội dung <yy:LName>..</yy:LName>
 Cho phép nhiều namespaces trùng lặp </s11:Envelope>
=> Cần phải có thuật toán chuẩn hóa
(Canonicalization)
Mã hóa tài liệu XML
 Các nguyên tắc
 Tài liệu XML mã hóa cũng vẫn
có định dạng XML
 Có thể mã hóa mức chi tiết <EncryptedData Id? Type? MimeType? Encoding?>
<EncryptionMethod/>?
 Độc lập cơ chế thực hiện <ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
 Schema mã hóa: <ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
 Ví dụ
 Before  After
<?xml version='1.0'?> <?xml version='1.0'?>
<PaymentInfo> <PaymentInfo>
<Name>John Smith</Name> <Name>John Smith</Name>
<CreditCard Limit='5,000' <EncryptedData
Currency='USD'> Type='http://www.w3.org/2001/
<Number>…</Number> 04/xmlenc#Element'
<Issuer>…</Issuer> xmlns='http://www.w3.org/2001
<Expiration>…</Expiration> /04/xmlenc#'>
</CreditCard> <CipherData>
</PaymentInfo> <CipherValue>A23B45C56
</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
 Các thông tin mô tả thêm
 Trường hợp đơn giản: bên nhận có đủ <PaymentInfo>
<Name>John Smith</Name>
thông tin để giải mã offline <EncryptedData>
 thuật toán, khóa giải <EncryptionMethod Algorithm=“[Some URI]”>
<CipherData>
 XML decrypt cho phép mô tả các thông <CipherValue>A23B45C56
tin này ngay trong thông điệp </CipherValue>
</CipherData>
 thông tin Keys </EncryptedData>
</PaymentInfo>
 thuật toán - EncryptionMethod: URI trỏ
tới tiêu chuẩn mã hóa được sử dụng
 Dịch vụ web:
 SOAP
 XML
 Rest
Rest API security
 Tìm hiểu thêm
Kiến trúc hướng dịch vụ SOA
Một số mô hình kiến trúc ứng dụng phân tán
1. Tổng quan về hề thống phần mềm doanh nghiệp
 Enterprise platform
 EJB - Enterprise Java Bean:
 EJB là một kiến trúc thành tố phía máy chủ dùng cho việc phát triển và triển
khai các ứng dụng phân tán hướng đối tượng cỡ vừa và lớn
 Kiến trúc EJB có 3 tầng: tầng trình diễn, tầng xử lý nghiệp vụ, các tài nguyên như
cơ sở dữ liệu
 Ưu điểm: EJB là một kiến trúc tốt cho việc tích hợp các hệ thống
 Nhược điểm:
 không phải là một chuẩn mở, khả năng giao tiếp với các chuẩn khác vẫn còn hạn chế
Tổng quan về hề thống phần mềm doanh nghiệp
 DCOM – Distributed Component Object Model => .Net
 là một mô hình phân tán dễ triển khai với chi phí thấp,
 hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành
 DCOM hỗ trợ kết nối giữa các đối tượng và những kết nối này có thể
được thay đổi lúc đang chạy
 Ưu điểm:
 tính ổn định, không phụ thuộc vị trí địa lý, quản lý
 kết nối hiệu quả và dễ dàng mở rộng
Tổng quan về hề thống phần mềm doanh nghiệp
 Đánh giá:
 Tính tighly - coupled, nghĩa là kiến trúc triển khai cài đặt bên phía nhà cung cấp
dịch vụ và phía sử dụng dịch vụ phải giống nhau
 những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết hợp,
hoạt động với chuẩn khác
Tổng quan về hề thống phần mềm doanh nghiệp
 Các vấn đề phát sinh, nguyên nhân và biện pháp khắc phục
 Ngày nay áp lực đặt lên các doanh nghiệp ngày càng lớn:
 giảm chi phí đầu tư cơ sở hạ tầng,
 khai thác có hiệu quả các công nghệ có sẵn,
 phải cố gắng phục vụ yêu cầu của khách hàng ngày càng tốt hơn,
 đáp ứng tốt các thay đổi nghiệp vụ,
 khả năng tích hợp cao với các hệ thống bên ngoài
 Nguyên nhân: sự không đồng nhất và sự thay đổi
Tổng quan về hề thống phần mềm doanh nghiệp
 Biện pháp:
 Có một cách tiếp cận giải quyết khá toàn diện mọi khó khăn nêu trên và nó đã
được triển khai trong thực tế.
 Cách tiếp cận đó là: triển khai “kiến trúc hướng dịch vụ” Service Orriented
Architecture (SOA).
Kiến trúc SOA
 Khái niệm
 là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ
thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ có
tính lỏng lẻo - loose coupling”, và có khả năng truy cập thông qua môi trường
mạng (Internet).
 là một tập hợp các dịch vụ được chuẩn hoá trên mạng trao đổi với nhau trong
ngữ cảnh một tiến trình nghiệp vụ
 SOA giải quyết các vấn đề tồn tại của các hệ thống hiện nay như:
 phức tạp,
 không linh hoạt và không ổn định
Kiến trúc SOA
 SOA là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm hay chức
năng hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch
vụ có tính kết nối lỏng lẻo” và có khả năng truy cập thông qua môi trường mạng.
 SOA là hướng tiếp cận xây dựng phần mềm dựa trên sự kết hợp các dịch vụ
Kiến trúc SOA
 Sơ đồ cộng tác
Kiến trúc SOA
 Cân bằng

SOA

EAI Project-ware
2. Giới thiệu về kiến trúc hướng dịch vụ
 Nguyên tắc khi xây dựng một hệ thống SOA:

 Các dịch vụ tự hoạt động:

 Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập
mà không lệ thuộc vào một dịch vụ khác.
 Dịch vụ phải có tính bền vững cao.
 để tránh các cuộc tấn công từ bên ngoài (như gửi thông điệp lỗi, hay gửi thông
điệp ồ ạt) bằng cách sử dụng các kỹ thuật về an toàn, bảo mật
2. Giới thiệu về kiến trúc hướng dịch vụ
 Nguyên tắc khi xây dựng một hệ thống SOA:

 Các dịch vụ chia sẻ lược đồ

 Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài,
 hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược
đồ dữ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.).
 hệ thống sẽ có tính liên kết và khả năng dễ mở rộng.
2. Giới thiệu về kiến trúc hướng dịch vụ
 Nguyên tắc khi xây dựng một hệ thống SOA:

 Tính tương thích của dịch vụ dựa trên chính sách

 Một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính
sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là mã hóa, bảo mật, vv.
 Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính
sách đó
2. Giới thiệu về kiến trúc hướng dịch vụ
 Ưu điểm của SOA
 Sử dụng lại những thành phần hoặc dịch vụ có sẵn giúp tiết kiệm chi phí và thời
gian xây dựng ứng dụng
 Cung cấp giải pháp ứng dụng tổng hợp cho doanh nghiệp (tích hợp các ứng dụng
rời rạc thành hệ thống đồng nhất)
 Tính loose coupling (kết nối lỏng lẻo) giúp tăng tính linh hoạt và khả năng triển
khai cài đặt
 Thích ứng với những thay đổi trong tương lai (giảm rủi ro do có thay đổi hoặc lỗi
trong thiết kế hệ thống)
 Hỗ trợ đa thiết bị và đa nền tảng
 Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp
2. Giới thiệu về kiến trúc hướng dịch vụ
 Ưu điểm của một hệ thống SOA:

 Loose coupling
 Các module có tính loose coupling khi có một số ràng buộc được mô tả rõ ràng
 Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các
module.
 Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh
sửa hệ thống của chính nó
2. Giới thiệu về kiến trúc hướng dịch vụ
 Ưu điểm của một hệ thống SOA:

 Sử dụng lại dịch vụ

 Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi
nhất định (service registry) nên chúng dễ dàng được tìm thấy và tái sử dụng
 Tái sử dụng lại các dịch vụ giúp loại bỏ những thành phần trùng lắp, tăng độ
vững chắc trong cài đặt, đơn giản hoá việc quản trị
 Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ thống SOA
gọi là những shared infrastructure service
2. Giới thiệu về kiến trúc hướng dịch vụ
 Ưu điểm của một hệ thống SOA:

 Khả năng cộng tác

 các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau.
 Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối.
 Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ
liệu mà mỗi client kết nối đến nó đều hiểu
2. Giới thiệu về kiến trúc hướng dịch vụ
 Ưu điểm của một hệ thống SOA:
 Tự phục hồi là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần
sự can thiệp của con người.
 Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế
nao trong tình trạng hỗn loạn; phụ thuộc vào khả năng phụ hồi của phần cứng
sau khi bị lỗi
 Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có
thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. Đây là một
trong những tình chất cơ bản của các hệ thống hướng dịch vụ.
Các tầng của SOA
Các tầng của SOA
 Tầng 1: Tầng hệ thống. Tầng này bao gồm hệ điều hành, các phần mềm
hệ thống, cho phép các ứng dụng sẵn có hoặc các dịch vụ chạy trên đó

 Tầng 2: Tầng thành phần, bao gồm các ứng dụng thành phần của doanh
nghiệp hoặc tổ chức, chạy trực tiếp trên nền hệ điều hành
Các tầng của SOA
 Tầng 3: Tầng dịch vụ, chứa các dịch vụ đơn hoặc các dịch vụ tích hợp
(dịch vụ tạo thành từ nhiều dịch vụ đơn). Các dịch vụ được xây dựng
trên cơ sở tầng thành phần của doanh nghiệp và cung cấp dịch vụ cho
tầng qui trình nghiệp vụ. Các dịch vụ được cung cấp thông qua giao diện
của chúng. Trong tầng này, các giao diện được thể hiện ra ngoài thông
qua các đặc tả dịch vụ
Các tầng của SOA
 Tầng 4: Tầng qui trình nghiệp vụ, cho phép kết hợp các dịch vụ từ tầng
dịch vụ theo các qui trình nghiệp vụ để phục vụ cho việc thực hiện các
chức năng của ứng dụng.

 Tầng 5: Tầng giao diện (trình diễn) thường nằm ngoài phạm vi của một
kiến trúc hướng dịch vụ. Cho phép tạo ra các giao diện người dùng
tương tác với các dịch vụ
Các tầng của SOA
 Tầng 6: Đảm bảo việc tích hợp các dịch vụ. Cho phép các dịch vụ giao
tiếp với nhau thông qua việc định tuyến tin cậy và thông minh các
thông điệp, cung cấp các giao thức trung gian, và một số cơ chế
chuyển đổi khác, thường đựơc mô tả như là một tuyến dịch vụ doanh
nghiệp (ESB- Enterprise Services Bus).

 Tầng 7: Đảm bảo chất lượng dịch vụ và kiểm soát các ứng dụng SOA.
Khó khăn khi xây dựng mô hình SOA
 Khó khăn trong xác định, phân tích và thiết kế dịch vụ
 Khó khăn trong tích hợp các dịch vụ
 Khó miêu tả dữ liệ u không cau trú c trong header củ a message.
 Vấn đề bảo mật do các dịch vụ có thể đa nền tảng và quản lý bởi các chủ sở hữu
khác nhau. Khi xây dựng ứng dụ ng tong hợp từ nhieu dịch vụ với tı́nh tá i sử
dụ ng cao thı̀ van đe bả o mậ t như: xá c thực, phân quyen, bı́ mậ t và an toà n vẹ n dữ
liệ u, bả o ve quyen riêng tư… trở thà nh mộ t bà i toá n phức tạ p và đò i hỏ i giả i
quyet bang những hướng tiep cậ n bả o mậ t hoà n toà n mới so với cá c phương
phá p bả o mậ t truyen thong.
 Băng thông mạng phải đảm bảo, do các dịch vụ giao tiếp và triệu gọi nhau thông
qua hình thức gửi thông điệp XML
 Một bài tập nhỏ:
 Thử phân tích => phân hoạch các dịch vụ và mô hình phân lớp dịch vụ cho bài
toán nào đó, ví dụ:
một trường học (DHBK), có thể giới hạn ở một lĩnh vực nghiệp vụ (vd hoạt động
đào tạo)
một doanh nghiệp bán lẻ, có thể giới hạn ở một lĩnh vực nghiệp vụ (vd hoạt động
quản lý kho và bán hàng)
Điện toán đám mây &
Ứng dụng thân thiện đám mây
Khái niệm điện toán đám mây
 Cloud Computing
 Nhiều định nghĩa
 NIST (National Institute of Standards and Technology)
 Cloud computing is a model for enabling convenient, on-demand network
access to a shared pool of configurable computing resources (e.g., networks,
servers, storage, applications, and services) that can be rapidly provisioned and
released with minimal management effort or service provider interaction.
 Cho phép truy cập (theo nhu cầu) đến kho tài nguyên chia sẻ, có thể cấu hình
tăng giảm dễ dàng
 Đặc điểm
 co dãn
 sẵn sàng, ổn định
 tối ưu
 truy cập
 quản trị & tích hợp
Lợi ích
 Nhiều lợi ích
 Đối với doanh nghiệp
 giảm chi phí đầu tư ban đầu, rủi ro đầu tư
 giảm chi phí về nguồn lực
 tăng hiệu quả sư dụng tài nguyên
 Đối với người dùng cá nhân
 giảm nhu cầu phần cứng
 giảm phần cứng lưu trữ
 kết nối trên nhiều thiết bị
 Hình dung từ người dùng
 Không quan tâm đc thực hiện thế nào
mà nhận được gì
 Không quan tâm nhà cung cấp làm gì
mà quan tâm chất lượng dịch vụ nhận được
 Không muốn sở hữu, vận hanh phần cứng thiết bị
mà muốn chỉ trả tiền cho tài nguyên thực sự dùng
Dịch vụ
 Chức năng được cung cấp bởi dịch vụ
 định nghĩa rõ ràng
 trọn gói
 không phụ thuộc (ngữ cảnh/trạng thái) dịch vụ khác
 Chất lượng dịch vụ
Các mô hình dịch vụ
 Infrastructure as a Service
 Platform as a Service
 Software as a Service
 XaaS
IaaS
 Infrastructure as a service
 Khả năng cung cấp cho khách hàng các tài nguyên tính toán (như processing,
storage, network) => cho phép họ có thể triển khai cài đặt và thực thi các phần
mềm khác nhau (bao gồm hdh và ứng dụng)
 Khách hàng kh kiểm soát các hạ tầng, nhưng có thể kiểm soát về hdh, dung
lượng lưu trữ, cài đặt phần mềm, kiểm soát phần nào mạng
 Ví dụ
 Amazon EC2
IaaS
 Công nghệ phổ biến: ảo hóa
 lớp tài nguyên trừu tượng độc lập tài nguyên vật lý
 Một số loại tài nguyên
 máy ảo
 lưu trữ ảo hóa
VM1 VM2 VM3
 mạng ảo hóa
PaaS
 Platform as a service
 khả năng khách hàng có thể cài đặt triển khai các phần mềm trên nền PaaS, sử
dụng framework, ngôn ngữ lập trình hỗ trợ bởi nhà cung cấp
 khách hàng không kiểm soát hạ tầng như mạng, máy chủ, hdh,... Mà kiểm soát
cài đặt phần mềm, cấu hình môi trường vận hành
 Vd
 MS Azure
 Google app engine
PaaS
 Công nghệ nền tảng
 thiết kế môi trường vận hành - Runtime Environment Design
 tập hợp các dịch vụ phần mềm, thư viện được cung cấp
 Một số đặc điểm
 quản trị được, tương tác được
 thực thi và tối ưu hiệu năng
 tính sẵn sang, ổn định
 khả năng mở rộng, co dãn
SaaS
 Software as s service
 Khả năng cung cấp cho khách hàng sử dụng các phần mềm, chạy trên nền đám
mây, truy cập từ mọi nơi với các client nhỏ gọn, trên các thiết bị (pc, phone)

 Vd
 google app (mail, calendar,..)
 saleforce.com
 MS office365
SaaS
 Công nghệ nền tảng
 dịch vụ web
 ứng dụng nền web
 portal
 micro service
Mô hình triển khai
 Public cloud
 Private cloud
 Hybrid cloud
public cloud

 các nhà cung cấp thuộc bên thứ 3 sẽ cung cấp các dịch vụ như tài nguyên,
platform, hay các ứng dụng lưu trữ trên đám mây thông qua internet.
private cloud
 Các dịch vụ đám mây riêng sẽ được
phân phối từ trung tâm dữ liệu của
doanh nghiệp đến người dùng nội bộ và
đứng đằng sau firewall

Public Cloud Private Cloud

Infrastructure Homogeneous Heterogeneous
Policy Model Common defined Customized & Tailored
Resource Model Shared & Multi-tenant Dedicated
Cost Model Operational expenditure Capital expenditure
Economy Model Large economy of scale End-to-end control
Hybrid cloud
 Đám mây lai là sự kết hợp giữa dịch vụ
đám mây công cộng và dịch vụ đám mây
riêng theo yêu cầu với sự giao thoa và
tự động hóa
 Doanh nghiệp có thể điều hành các công
việc quan trọng hoặc các ứng dụng nhạy
cảm trên đám mây riêng và sử dụng
đám mây công cộng để xử lý khối lượng
công việc đồ sộ hoặc các nhu cầu tăng
đột biến
Ứng dụng thân thiện đám mây
Yêu cầu kỹ thuật công nghệ
 Cung cấp dạng SAAS
 Sẵn sàng cho cloud: cloud based
 Dễ dàng triển khai, nâng cấp
 Hoạt động ổn định
 Khả năng quản trị vận hành

 Multi ternance
 Self service
 Security
Yêu cầu kỹ thuật công nghệ
 Khả năng quản trị vận hành
Thế nào là Cloud native app
 Là ứng dụng được thiết kế và xây dựng để thực thi trên cloud, PaaS - khai
thác đặc điểm mở rộng và co dãn
 Tiếp cận về cách thức (how) xây dựng, triển khai, thực thi ƯD khai thác
đc các ưu thế của điện toán đám mây (khả năng cung cấp tài nguyên kh
giới hạn, theo yêu cầu)
 Tiếp cận về cách thức xây dựng ƯD >< Nơi triển khai cài đặt ứng dụng
Thế nào là Cloud native app
 Ứng dụng thân thiện đám mây:
 devops, agile
 CD, CI
 microservice,
 container
Lợi ích của cloud native app
 Một nền tảng code cho tất cả khách hàng
 Thay đổi nhanh chóng (theo từng phần nhỏ, các khách hàng độc lập)
 Đáp ứng hiệu năng. Mở rộng chiều ngang đáp ứng tải, sẵn sàng/tự
phục hồi, khả chuyển
 Chi phí giảm
Thách thức khi xây dựng cloud native app
 Downtime - ảnh hưởng, hậu quả lớn
 Tấn công bảo mật
 Tính riêng tư
 Công nghệ phức tạp
 infrastructure services,
 automation/orchestration,
 virtualization and containerization,
 microservices architecture,
 and observability
 Phương pháp phát triển:
 Water fall - Không phù hợp
 Agile: chưa đủ.
 Minimum viable product (MVP) development, multivariate testing, rapid iteration, devops
Monolith >< Microservice
Mô hình ứng dụng monolithic "truyền thống"
 Mặc dù
 Nhiều lớp
 SOAP
 Web/mobile
 Service
 Business implementation
 Data
 Vẫn có tính monolithic
 Phụ thuộc nhau
 DB tập trung
 Vấn đề
 Thay đổi, cải tiến ?
Kiến trúc một khối truyền thống (Monolithic Architecture)

 Một số tính chất của kiến trúc một khối:

 Được thiết kế, phát triển và triển khai theo một khối duy nhất
 Ứng dụng monolithic phức tạp và to gây khó khăn cho việc bảo trì, nâng cấp và
thêm tính năng mới
 Khó áp dụng phát triển kiểu agile
 Phải triển khai lại toàn bộ hệ thống dù chỉ cập nhật hay nâng cấp một phần
 Mở rộng: phải mở rộng cả khối ứng dụng, gặp khó khăn nếu có các yêu cầu về tài
nguyên khác nhau (ví dụ một service yêu cầu thêm CPU, service khác lại yêu cầu
nhiều memory)
 Độ tin cậy: một service không ổn định có thể sập cả hệ thống
 Khó đổi mới: ứng dụng monolithic phải sử dụng chung công nghệ nên khó thay
đổi hay áp dụng công nghệ mới
Microservices Architecture
 Khái niệm
 Nền tảng cả kiến trúc microservices là xây dựng một ứng dụng được tạo thành
từ nhiều services nhỏ và độc lập có thể chạy riêng biệt, phát triển và triển khai
độc lập.
Thiết kế Microservices: kích cỡ, phạm vi và tính năng

 Một số vấn đề thực tế và những hiểu sai về kích cỡ, phạm vi và chức
năng của microservices.
 Số dòng code/ kích cỡ của một đội lập trình là chỉ số tồi: có vài cuộc bàn luận về
kích thước của một service dựa vào số lượng dòng code hay kích thước của đội
phát triển service đó (ví dụ two-pizza team)
 "Micro" là một từ khóa dễ gây nhầm lẫn. Một số lập trình viên nghĩ rằng họ nên
tạo ra services nhỏ hết mức. Điều này là một cách hiểu sai.
 Trong SOA, services thường trở thành các cục monolithic với nhiều hàm, chức
năng khác hỗ trợ. Vì vậy, chỉ phát triển services kiểu SOA rồi dán nhãn
microservices hoàn toàn lạc hướng và không mang lại bất kì lợi ích nào của kiến
trúc microservices.
Thiết kế Microservices: kích cỡ, phạm vi và tính năng

 Một Số Chỉ Dẫn Khi Thiết Kế Microservices

 Single Responsibility Principle (SRP): một service với phạm vi và chức năng giới
hạn, tập trung vào một nhiệm vụ giúp quá trình phát triển và triển khai dịch vụ
trở nên nhanh chóng hơn.

 Trong quá trình thiết kế, ta nên xác định và giới hạn các services theo chức năng
nghiệp vụ thực tế (theo Domain-Driven-Design)

 Đảm bảo microservices có thể phát triển và triển khai độc lập

 Mục tiêu của thiết kế là phạm vi của microservices phục vụ một nghiệp vụ chứ
không chỉ đơn giản làm các dịch vụ nhỏ hơn. Kích thước hợp lý của một service
là kích thước đủ để đáp ứng yêu cầu của một chức năng trong hệ thống.
Thiết kế Microservices: kích cỡ, phạm vi và tính năng

 Một Số Chỉ Dẫn Khi Thiết Kế Microservice

 Khác với services trong SOA, một microservice không nên có quá nhiều hàm hay
chức năng hỗ trợ xung quanh và định dạng thông báo/ gửi tin (messaging) đơn
giản.

 Một cách tốt là có thể bắt đầu với services to có phạm vi rộng rồi chia nhỏ dần
(dựa theo nghiệp vụ thực tế của hệ thống)
Kiến trúc microservice
 API:
 Có thể trong Service 1 Remote service

 Có thể ngoài tổ chức

(từ google, MS, …) Client app
Service 2

Service 3

identity Managerment Service discovery

Microservice
 Hệ thống được xây dựng quanh microService

Service 1 Remote service

Client app
Service 2

Service 3

identity Managerment Service discovery

Service Registry & Service Discorvery (Truy Tìm Dịch Vụ)

 Client Side Discorvery : client hay API Gateway lấy thông tin địa điểm
của một thực thể service bằng cách truy vấn Service Registry.
Service Registry & Service Discorvery (Truy Tìm Dịch Vụ)

 Server Side Discorvery : client hay API Gateway gửi yêu cầu lên một
component (có thể là một Load Balancer). Component này sẽ gọi
Service Registry và quyết định địa điểm của các microservices.
Microservice pattern
API gateway
Kiến trúc dịch vụ nhỏ (Microservices Architecture)

 Poin to Point
Kiến trúc dịch vụ nhỏ (Microservices Architecture)

 Point to Point : kiểu giao tiếp trực tiếp.

 Vấn đề :
 Những yêu cầu như xác thực người dùng, điều tiết, giám sát,...phải được xây dựng tại
tất cả microservices.
 Việc trên dẫn đến lập các tính năng chung, mỗi microservices có thể trở nên phức tạp.
 Không có cách quản lý, kiểm soát giao tiếp giữa các services
 Thường việc kết nối trực tiếp trong microservices được coi là anti-pattern khi áp
dụng cho ứng dụng to.
 => Vì vậy, với những trường hợp phức tạp hơn, thay vì kết nối trực tiếp hay một ESB
trung tâm, chúng ta có thể sử dụng 1 messaging bus trung tâm gọn nhẹ. Nó cung cấp
một lớp trừu tượng hóa các microservices (an abstraction layer). Cách này được gọi là
API Gateway.
Kết Nối Microservices (Giao Tiếp Giữa Các Services)

 API-Gateway
Kết Nối Microservices (Giao Tiếp Giữa Các Services)

 API-Gateway : Sử dụng một cổng truyền tin gọn nhẹ như một điểm
vào chính cho tất cả khác hàng, người dùng và triển khai những chức
năng chung mà không liên quan đến nghiệp vụ đặc thù ở cấp Gateway
này.
Kết Nối Microservices (Giao Tiếp Giữa Các Services)

 API-Gateway
 API Gateway cung cấp các lợi thế dưới đây:

 Cung cấp một lớp trừu tượng hóa các microservices. Ví dụ thay vì cung cấp một API
cho tất cả khách hàng, API gateway có thể xuất ra hay hiển thị API khác nhau cho mỗi
khách hàng.

 Định tuyến và chuyển đổi tin nhắn gọn nhẹ ở cấp gateway.

 Một điểm tập trung cho các chức năng chung không mang tính nghiệp vụ kinh doanh
như bảo mật, giám sát và điều tiết.

 Với API Gateway. microservices trở nên càng gọn nhẹ vì các chức năng chung không
mang tính nghiệp vụ đều chuyển sang Gateway.
interservice communication
 Giao tiếp giữa các service
 Đồng bộ ? Dị bộ ?
 Text based message >< Binary

 Giao thức
 Đồng bộ: REST, Thrift, gRPC
 Dị bộ: AMQP, MQTT, STOMP,..

 Service contract: Swagger

Saga pattern
 Vấn đề:
 Giao dịch trải trên nhiều dịch vụ, và cơ chế 2PC không đc cài đặt
 Giải pháp
 Choreography-based saga
 Orchestration-based saga
 Lưu trữ dữ liệu trong microservice
 Nguyên tắc cơ bản: Mỗi microservice
quản trị dữ liệu (data) của mình. Các
servide không chia sẻ lưu trữ dữ liệu
 Thách thức: dư thừa, nhất quán,
transaction
 Tiếp cận
 Lưu dữ liệu cần trong subdomain/service
 Lưu ý tránh tình huống các service trao đổi
thông tin quá nhiều
 Nhất quán cuối cùng-Eventual consistency
 Nguồn tin cậy-Truth of source
 Transaction: Scheduler Agent Supervisor và
Compensating Transaction
 Dùng event driven
DB per service pattern
 Vấn đề:
 kiến trúc CSDL trong microservice
 Giải pháp
 CSDL độc lập
DB: Command Query Responsibility Segregation (CQRS)

 Vấn đề: truy vấn dữ liệu từ

nhiều service
 Giải pháp: tạo view db chỉ
đọc, và query trên db này
DB: Shared database
 Vấn đề: kiến trúc CSDL
 Giải pháp: nhiều service dùng chung DB. service có thể truy cập DB
của service khác
Kiến trúc
API manager Service discovery

Data

API

API
cache Service 1 Data service
store

Sync: REST,
API Thrift
Client app
gateway
Client friendly
protocol: Cache Async:
REST Log Event source,
Authent
secure
Queue,..
Load leveling
Queue Data

API
cache Service 4
store

API
Service 2

Data

API
Service 3
Async: store
queue

Compensating
supervisor
transaction

CDN: static
IAM Config Log
content
Security - Bảo Mật
 Chúng ta có thể tận dụng các API bảo mật tiêu chuẩn như OAuth2 và
OpenID Connect
 OAuth2 - một phương thức chứng thực kiểu ủy quyền. Client xác thực với server
cấp quyền (authorization server) và nhận một token gọi là "Access token".
Access token không chứa bất kì thông tin gì về client. Nó chỉ là một tấm vé tham
chiếu đến thông tin người dùng mà server cấp quyền có thể truy xuất đến. Do đó,
đây cũng được gọi là token kiểu tham chiếu "by-reference token" và an toàn để
sử dụng trên mạng lưới mở và internet
 OpenID Connect hoạt động tương tự OAuth nhưng ngoài Access Token, server
cấp quyền còn phát một ID token chứa thông tin người dùng. Token này thường
dạng JWT (JSON Web Token) và được kí bởi server cấp quyền. JWT token do đó
được coi là token kiểu tham trị "by-value token" bởi vì nó chức thông tin về
người dùng và có thể trở nên không an toàn.
Security - Bảo Mật
Security - Bảo Mật
 Như hình trên, các bước chính để thực hiện bảo mật microservices
gồm:
 Chuyển việc xác thực cho server dạng OAuth và OpenID Connect (Authorization
server)
 Sử dụng API Gateway để có một điểm đầu vào duy nhất cho yêu cầu từ clients
 Client kết nối với server cấp quyền và nhận Access token. Sau đó gửi token này
đến API Gateway cùng với yêu cầu
 Dịch token tại Gateway - API Gateway lấy ra access token và gửi đến server cấp
quyền để lấy JWT
 Gateway truyền JWT cùng với yêu cầu đến microservices
 JWT chứa thông tin người dùng cần thiết để lưu user sessions,....
 Ở mỗi lớp microservice, bạn có thể có một component xử lý JWT, việc này khác
đơn giản
 Stack công nghệ
Thành phần Stack dựa trên opensource Ghi chú Thành phần Stack dựa trên opensource Ghi chú
Client framework: React React native: coi là bộ thư viện => mobile Event source/ Kafka ? Cho các cơ chế cần xử lý sự kiện bất đồng
web, mobile OK, làm quen nhanh hơn, load leveling bộ, lưu lượng lớn, serialize
Angular 2+: coi là 1 framework => Learning Queue rabbitMQ Dynomite & Redis for building queues;
curv cao Disque; Kafka; activeMQ
Quản lý mã Gitlab ? Github => cloud, public (private: mất tiền)
Load balancing Bộ spring cloud với Netflix OSS Nginx (plus), HAproxy nguồn Gitlab => có on-premise-community
(zuul, ribbon) edition free
API gateway Bộ spring cloud với Netflix OSS Haproxy ? Nginx ? SVN ; MS: Team foundation;Bitbucket
(zuul) Kong API Tự động build & Jenkins Jenkins hỗ trợ SVN, git, file system
deploy lên các Redhat Ansible (đánh giá cao hơn Jenkins
Zuul => tích hợp trong spring cloud
API manager Chưa xét môi trường 1 chút, bản cao cần mua Ansible tower)
Phát triển Spring boot, mavel Với Microsoft: .Net core Testing Unit test: jmetter ? Load/performance
microservice test; Functional test; API test
JPA/hibernate Entity framework
Data store Phụ thuộc ứng dụng, có nhiều Microsoft: SQL, cosmoDB Service Prometheus Prometheus is an open source tool used
lựa chọn monitoring primarily for Docker monitoring
https://www.predictiveanalyticstoday.com
Platform https://stackify.com/cloud-monitoring-
RDBMS: /top-free-graph-databases/
monitoring tools/
MariaDB/MySQL/Oracle
Container Docker
Cache Redis Nhìn chung redis đc đánh giá cao hơn trong
Container Kubernetes Kubernetes: khả năng quản lý quy mô lớn
Memcached nhiều trường hợp
orchestration Docker composer: đơn giản hơn
Memcached: đơn giản, string type, static
PaaS Redhat Openshift hay Paas: + Redhat openshift => hybrid cloud
Redist: nhiều tính năng, nhiều data type OpenStack
IaaS + Pivotal: cloudFoundry
Service registry Bộ spring cloud với Netflix OSS: https://dzone.com/articles/microservices-
part-3-spring-cloud-service-registry + Openstack => CMC telecom dùng
Service discovery Eureka & ribbon
Logging & log ELK: elasticsearch, logstash,
Service Spring cloud config Để service đọc config của mình mỗi khi
analytic kibana
configuration Có thể viết 1 microservice cho restart
configuration ?
Security, authen Spring boot, security Chuẩn: JWT, oauth2/open id connect
Triển khai: container
Container

Traditional
shared
Virtual
system isolation
Container
process isolation

APP A APP B APP C Container Container Container

APP A APP B
LIBS A LIBS B LIBS C APP A APP B APP C
LIBS A LIBS B LIBS.. Guest OS Guest OS Guest OS LIBS A LIBS B LIBS C
Host OS Hypervisor Host Minimal OS
Hardware Hardware Hardware
 Docker container
 Docker cung cấp một công cụ triển
khai microservices. Các bước chính
gồm:
 Đóng gói mỗi microservice thành một
docker image
 Triển khai mỗi thực thể của service là
một Docker container
 Mở rộng dựa vào số lượng thực thể
 Phát triển, triển khai và khởi động
microservices trở nên nhanh hơn với
Docker
Container orchestration
 Tạo sao cần
Container orchestration
 Container
orchestration tự động
hóa quá trình
 giám sát/provisioning
 triển khai/deployment
 mở rộng/scaling
 ql vòng đời/lifecycle
management
của các container
Orchestration với Kubernetes
 Kubernetes là một mã nguồn mở được dùng để tự động triển khai hệ
thống, scaling/mở rộng, quản lý các container

 Container
 Pod
 Node
DevOps
Traditional Development and Operations
DevOps là gì ?
Devops là một công việc ?
DevOps là gì ?
Devops là sản phẩm ?
DevOps là văn hóa, quy trình, con người
DevOps is a term used to refer to a set of practices that emphasizes the
Wikipedia (2017)
collaboration and communication of both software developers and other
information-technology (IT) professionals while automating the process
of software delivery and infrastructure changes.
DevOps represents a change in IT culture, focusing on rapid IT service delivery
through the adoption of agile, lean practices in the context of a system-oriented
Gartner
approach. DevOps emphasizes people (and culture), and seeks to improve
collaboration between operations and development teams. DevOps implementations
utilize technology — especially automation tools that can leverage an increasingly
programmable and dynamic infrastructure from a life cycle perspective.
DevOps is the union of people, process, and products to enable
continuous delivery of value to our end users.
Microsoft (Donovan Brown)
132
Các Nguyên tắc của DevOps
 Tự động hóa vòng đời phát triển phần mềm
 automation test, build, ..
 Truyền thông và Hợp tác
 Liên tục cải tiến, giảm thiểu các dư thừa
 Tập trung vào nhu cầu người dùng với phản hồi nhanh, lặp
Lợi ích của DevOps

https://puppetlabs.com/
 Một số công cụ