Bài giảng Dạng kiến trúc (Architectural Styles)

Chương 2: KIẾN TRÚC Các dạng kiến trúc (Architectural Styles) - Các hệ kiến trúc quan trọng nhất (1). Kiến trúc phân tầng (layered) Là kiến trúc mà các component ở mỗi tầng chỉ được phép gọi các component ở các tầng cận (cạnh) với nó. (2). Kiến trúc dựa trên đối tượng (object-based) Các object được định nghĩa tương ứng với các component. Mô hình client-server cũng theo kiến trúc này. (3). Kiến trúc tập trung dữ liệu (data-centered) Các tiến trình giao tiếp (chủ động hay bị động) thông qua các kho chung (common repository) (4). Kiến trúc dựa trên sự kiên (Event-based) Các giao tiếp cơ bản dựa trên quá trình truyền của các event. Ưu điểm của mô hình này chính là sự gắn kết lỏng lẻo. Kiến trúc (3) và (4) kết hợp với nhau sẽ sinh ra kiến trúc shared data space Các tiến trình sẽ rời rạc về mặt thời gian. Các kiến trúc hệ thống (System Architectures) Kiến trúc tập trung Một ví dụ kinh điển nhất là mô hình Client – Server Giao tiếp giữa Client – Server có thể dựa trên các giao thức không kết nối, đơn giản (Không có thiết lập phiên, không tin cậy, là quá trình truyền các datagram) hoặc các giao thức hướng kết nối, tin cậy. Phân tầng ứng dụng Trong mô hình Client – Server, cơ bản không thể phân biệt rạch ròi đâu là client, đâu là server. Lấy một ví dụ thế này, một server của một hệ CSDL phân tán có thể lại hoạt động như 1 client khi server đó forward các yêu cầu tới một server chứa các dữ liệu tương ứng, trong trường này, data server đó tự bản thân nó không làm gì hơn là thực thi các yêu cầu. Kiến trúc của mô hình này có thể được chia làm 3 lớp (level) Lớp giao diện (user-interface level) - Gồm tất cả những gì cần thiết để tạo nên giao diện cho người dùng (trình quản lý hiển thị,…) - Client thường có lớp này như: X-Windows trong Unix, MS-DOS, các GUI trong các ứng dụng hiện đại. Lớp xử lý (processing level) - Chứa các ứng dụng (application) - Lớp này ngăn giữa lớp giao diện (front end) và lớp data (back end) Lớp dữ liệu (data level) - Chứa dữ liệu được thao tác - Chứa các chương trình để duy trì dữ liệu khi các ứng dụng thực thi. Một thuộc tính quan trọng của lớp này là dữ liệu phải luôn luôn được duy trì. Nếu không có ứng dụng nào được chạy, dữ liệu sẽ được lưu ở đâu đó để có thể dùng tiếp ở các lần sau. - Ở dạng đơn giản nhất, lớp này gồm một file hệ thống, nhưng vẫn thường là các bộ dữ liệu đầy đủ. - Trong mô hình client-server, lớp dữ liệu thường được đặt “ở phía” server (server side) - Bên cạnh việc lưu trữ dữ liệu, lớp này cũng chịu trách nhiệm giữ cho dữ liệu thống nhất qua các ứng dụng khác nhau. Khi các cơ sở dữ liệu đang được sử dụng, việc duy trì thống nhất có nghĩa là: metadata (siêu dữ liệu) gồm các bảng mô tả, các ràng buộc, và các metadata đặc trưng của ứng dụng đều được lưu trữ tại lớp này. Ví dụ, trong trường hợp của một ngân hàng, chúng ta muốn sinh một thông báo khi một khách thẻ tín dụng của khách hàng nợ đến một mức nào đó. Loại thông tin này có thể được duy trì thông qua một trigger của cơ sở dữ liệu- nó sẽ active tại các thời điểm tương ứng. Lấy ví dụ với một search engine, không quan tâm tới tất cả các banner động, ảnh và các thứ trang trí khác. Giao diện của search engine rất đơn giản, người sử dụng gõ vào một chuỗi khóa. Back end được tổ chức là một cơ sở dữ liệu lớn đã được index và tìm nạp trước. Core của search engine là một chương trình chuyển chuỗi ký tự của người sử dụng thành một số câu query. Sau đó, kết quả được sắp xếp vào list và chuyển list tới các các trang HTML. Trong mô hình client-server, phần thông tin thu được đặt tại lớp processing. Đa kiến trúc (xét trên khía cạnh vật lý) - Xét về mặt vật lý, khi phân phối một ứng dụng phân tán, khả năng tổ chức của ứng dụng đấy có thể như sau : Mô hình phân tách máy khách (client machine) và máy phục vụ (server machine) được gọi là kiến trúc 2 tầng (two-tiered architecture). Kiến trúc này có tới 5 tình huống khác nhau. Tình huống (a) là khi máy khách có một phần của lớp giao diện, được sử dụng như một remote, còn máy phục vụ chứa phần còn lại của ứng dụng. Tình huống (e) là một tình huống rất phổ biến hiện nay nhất là ở các ngân hàng, khi mà máy khách là một PC hay máy trạm, kết nối thông qua mạng tới một hệ thống file hoặc cơ sở dữ liệu phân tán. Khi đó, ứng dụng chạy chủ yếu trên máy khách nhưng mọi thao tác đến các file và cơ sở dữ liệu đều phải thực hiện trên server. - Kiến trúc tiếp theo là kiến trúc 3 tầng (three-tiered architecture), kiến trúc này mô tả khi server lại hoạt động như một client Kiến trúc phi tập trung - Trong nhiều doanh nghiệp, việc phân phối các tiến trình tương đương với việc tổ chức các ứng dụng Client-Server như một đa kiến trúc. Hệ thống phân tán này gọi là phân tán theo chiều dọc (vertical distribution). Đặc trưng của kiến trúc này là đặt các thành phần logic khác nhau trên các máy khác nhau. Thuật ngữ này liên quan đến khái niệm phân mảnh dọc (vertical fragmentation) được sử dụng trong cơ sở dữ liệu quan hệ phân tán, khi mà các bảng (table) được chia thành các cột rồi được phân phối tới nhiều máy. - Đứng về mặt quản lý hệ thống, việc phân phối dọc có thể giúp phân chia các chức năng (cả logic lẫn vật lý) trên nhiều máy khác nhau, mỗi máy được điều chỉnh đảm nhận một nhóm các chức năng cụ thể. - Ở các kiến trúc hiện đại, người ta phân phối theo kiểu phân phối ngang (horizontal distribution), khi đó client và server có thể được chia trên các thành phần vật lý tương đương nhau (logical equivalent part), mỗi phần lại hoạt động trên chính tập dữ liệu của chúng, do đó cân bằng tải. Một lớp kiến trúc hệ thống hỗ trợ phân phối ngang là hệ thống peer-to-peer. Các kiến trúc Peer-to-peer có cấu trúc Ở mô hình kiến trúc này, mạng overlay (overlay network) được cấu trúc bởi một thủ tục (procedure) có tính quyết định. Thủ tục được sử dụng nhiều nhất là tổ chức tiến trình thông qua bảng băm phân tán (distributed hash table-DHT) Trong hệ DHT (tạm gọi như vậy), các mục dữ liệu (data items) được gán một khóa ngẫu nhiên trong một không gian định danh lớn (from a large indentifier space), ví dụ như định danh bởi 128-bit hoặc 160-bit. Cũng như vậy, các nút (node) trong hệ thống cũng được gán một số ngẫu nhiên với cùng một không gian định danh (same identifier space). Vấn đề của tất cả các hệ thống DHT là cài đặt một một thiết kế hiệu quả và tất định (an efficient and deterministic scheme) sao cho ánh xạ duy nhất khóa của mục dữ liệu tới định danh của nút dựa trên sự khác biệt về metric (some distance metric) Quan trọng nhất, khi tìm kiếm một mục dữ liệu, địa chỉ mạng của node chịu trách nhiêm đối với dữ liệu đó được trả về. Thực tế, nó được thực hiện bằng cách định tuyến một yêu cầu về 1 mục dữ liệu tới nút chịu trách nhiệm. Ví dụ với hệ thống Chord, các nút được tổ chức logic dưới dạng vòng, một mục dữ liệu với khóa k được ánh xạ tới các nút với định danh nhỏ nhất id>=k, nút này được tham chiếu như là phần tử tiếp theo của khóa k, và được ký hiệu là succ(k). Khi tìm kiếm một mục dữ liệu, một ứng dụng chạy trên một nút bất kỳ sẽ gọi tới hàm LOOKUP(k), hàm này sau đó trả về địa chỉ mạng của succ(k). khi đó, ứng dụng có thể liên lạc tới nút để sao chép dữ liệu cần thiết. Ở chương này chúng ta ko đi vào giải thuật tìm kiếm khóa, vấn đề này sẽ được bàn trong chương 5: Naming. Chúng ta sẽ tập trung vào việc các nút được tổ chức như thế nào trong mạng overlay. Khái niệm này được gọi là membership management. Quá trình tìm kiếm khóa tất nhiên không không theo cách tổ chức logic dạng vòng như trên. Thay vào đó, mỗi nút sẽ duy trì các shortcut tới các nút khác theo cách tìm kiếm lần lượt trên tất cả các nút (O(log(N)) bước tối đa–N là số nút mạng). Khi một nút muốn join vào hệ thống, nó sinh bắt đầu bằng việc sinh một định danh-id ngẫu nhiên. Chú ý rằng, nếu không gian định danh đủ, hàm sinh số ngẫu nhiên tốt (is of good quality), xác suất của việc sinh một định danh đã gán cho một nút nào đó là rất nhỏ (tiến dần tới 0 – close to zero). Sau đó, nút đấy có thể thực hiện tìm kiếm trên trường id, địa chỉ mạng của succ(id) sẽ được trả về. Khi đó, nút đấy có thể liên hệ với phần từ tương ứng succ(id) và phần tử liền trước của nó (succ(id)) rồi tự gắn mình vào mạng. Cách này yêu cầu các nút phải lưu các thông tin về phần tử liền trước của nó. Việc chèn thêm nút vào cũng mang lại việc: khóa của mỗi mục dữ liệu bây giờ tương ứng với định dạnh của nút, được truyền từ succ(id). Nói một cách đơn giản: Id của nút cho biết độ lệch của nó tới nút liền trước và liền, và truyền các mục dữ liệu của chúng (its data item) tới succ(id) Các kiến trúc Peer-to-peer phi cấu trúc Hệ thống peer-to-peer phi cấu trúc phần lớn dựa vào các giải thuật ngẫu nhiên để xây dựng mạng overlay (overlay network). Ý tưởng chính ở đây là mỗi nút duy trì một danh sách các nút hang xóm, list này được tạo nên theo một cách ngẫu nhiên. Các mục dữ liệu cũng được đặt ngẫu nhiên vào nút. Kết quả là, khi một nút muốn xác định vị trí của một mục dữ liệu cụ thể, điều duy nhất có hiệu quả là flood mạng với 1 truy vấn tìm kiếm. Chương 5 chúng ta sẽ bàn thêm về mạng overlay phi cấu trúc, bây giờ chúng ta sẽ tập trung vào membership management. Một trong những mục đích của rất nhiều hệ thống peer-to-peer phi cấu trúc là tạo nên mạng overlay tương đồng với một random graph. Mô hình cơ bản là mỗi nút duy trì một list c các nút lân cận, mỗi một nút lân cận đó lại là kết quả của việc chọn ngẫu nhiên một nút đang “sống” (live node) từ tập các nút hiện tại. List đó được gọi là partial view (khung nhìn cục bộ). Có rất nhiều cách để xây dựng khung nhìn cục bộ. Jelasity et al. (2004, 2005) đã phát triển một framework cho phép capture rất nhiều giải thuật khác nhau dành cho kết cấu overlay (overlay construction) cho phép định giá và so sánh. Ở framework này, các nút định kỳ thay đổi các entry trong partial view, mỗi một entry xác định một nút trong mạng và có tuổi tương ứng để chỉ ra tuổi của quá trình tham chiếu tới nút đó. Hai luồng thường được sử dụng, xem hình minh họa 2-9 Active thread dùng để khởi động quá trình truyền thông với nút khác. Nó chọn nút đó từ partial view hiện tại. Các entry cần bị đẩy (to be pushed) vào các peer đã được chọn, nó tiếp tục bằng cách xây dựng bộ đệm chứa c/2 +1 entry, gồm cả định danh của các entry. Các entry khác được chọn từ partial view hiện tại. Nếu một nút ở chế độ pull (pull mode). Nó sẽ chờ phản hồi từ peer đã được chọn. Peer đó, trong lúc đấy cũng xây dụng bộ đệm bằng cách sử dụng passive thread (2-9.b) Điểm cốt yếu ở đây là cấu trúc của một partial view mới. Khung nhìn này, ban đầu cũng như contacted peer, đều chứa chính xác c entry. Có 2 cách để tạo một khung nhìn mới. Cách đầu tiên, 2 nút có thể quyết định loại bỏ các mục mà chúng đã send cho nhau. Ở phương pháp này, chúng sẽ hoán đổi một phần khung nhìn ban đầu. Các tiếp cận thứ 2 là loại bỏ các càng nhiều càng tốt các nút “già”. Nói đến vấn đề membership managament, khi một nút muốn join, nó liên hệ với một nút bất kỳ,có thể từ một list các điển truy nhập (a list of well-known points). Điểm truy nhập này là một thành viên bình thường của mạng overlay. Khi đó, nó gọi ra (turn out) các giao thức chỉ sử dụng push mode hoặc chỉ pull mode có thể dẫn điễn việc disconected overlay. Nói cách khác, các nhóm nút sẽ bị cô lập và không bao giờ có khả năng liên lạc với các nút khác trong mạng. Rõ ràng, đây là một đặc tính không mong muốn, vì lý do đó nó làm cho sự trao đổi entry giữa các nút có ý nghĩa hơn. Topology managemnt of Overlay Networks. Một quá trình quan sát một cách thận trọng sự chuyển và chọn các entry từ các partial view, hoàn toàn có khả năng để xây dựng và duy trì một topo cụ thể cho mạng overlay, mặc dù peer-to-peer có cấu trúc và phi cấu trúc có vẻ như được tạo từ những lớp hoàn toàn độc lập với nhau. Cách thức tổ chức topo này đạt được thông qua mô hình 2 lớp Lớp thấp nhất tạo nên một hệ thống peer-to-peer phi cấu trúc mà trong đó các nút định kỳ trao đổi các entry trong partial view của chúng hướng đến việc duy trì một random graph “đúng đắn” (accurate). “Đúng đắn” ở đây ý nói đến việc partial view sẽ được lấp đầy bởi việc chọn ngẫu nhiên các nút sống (live nodes). Lớp thấp nhất chuyển partial view của nó tới lớp cao hơn, nơi xẩy ra việc lựa chọn thêm các entry. Việc này làm cho xuất hiện danh sách thứ 2 của các nút lân cận tương ứng với topo muốn có. Jelasity và Babaoglu (2005) đã sử dụng 1 hàm sắp xếp (a ranking function) mà các nút được xếp theo một vài tiêu chuẩn, như là khoảng cách tới một nút P nào đó,… Như minh họa ở trên, coi như lưới logic là NxN và các nút được đặt ở mỗi điểm của lưới. Tất cả các nút đều được yêu cầu duy trì danh sách các nút lân cận gần nhất. Khoảng cách giữa một nút (a1, a2) và (b1, b2) được định nghĩa là d1 + d2 trong đó di = min(N - |ai - bi|, |ai – bi|) Nếu lớp thấp nhất định kỳ thực hiện giao thức (protocol) như đoạn code phía trên, mô hình sẽ tiến hóa thành hình xuyến (như trên) Quan trọng là, các giải thuật này có liên quan đến việc giữ lại các liên hệ gần gũi về ngữ nghĩa (capturing the semantic proximity) của dữ liệu được lưu trữ ở mỗi nút. Sự gần này cho phép xây dựng nên mạng overlay theo ngữ nghĩa – cho phép các giải thuật tìm kiếm hiệu năng cao trên hệ thống phi cấu trúc peer-to-peer. Ở chương 5, chúng ta sẽ thảo luận về định danh dựa trên thuộc tính (attribute-based naming) Superpeers Đáng chú ý ở hệ thống phi cấu trúc peer-to-peer, định vị đối tượng dữ liệu có thể trở thành một vấn đề nan giải khi mà mạng mở rộng thêm. Lý do cho vấn đề linh hoạt này rất đơn giản: Khi định tuyến đến các phần tử dữ liệu (data item) không có các đường định trước. Chỉ có một kỹ thuật mà một nút có thể dùng đến là flooding các yêu cầu. Có nhiều cách để chặn flooding, sẽ được bàn đến ở chương 5, như nhiều hệ thống peer-to-peer đều sử dụng 1 nút để duy trì index tới các đơn vị dữ liệu Có nhiều trường hợp mà hệ thống peer-to-peer mất đi tính cân bằng tự nhiên của nó. Ví dụ như trong mạng cộng tác phân phát nội dung (collaborative content delivery network – CDN), các nút có thể hỗ trợ lưu trữ cho các bản sao hosting (hosting copies) của trang web, cho phép các web client truy cập gần hơn và vì thế nhanh hơn. Trong trường hợp này, nút P có thể cần để tìm kiếm tài nguyên, trong trường hợp khác, nó hoạt động như một trung gian môi giới, tập trung các tài nguyên cần thiết cho một số nút Superpeer là nút duy trì index, hoặc hoạt động như một nút trung gian. Ở mô hình trên, tất cả các peer bình thường đều kết nối như một client tới một superpeer nào đó. Tất cả các quá trình truyền thông đến và đi đều thông qua superpeer. Trong nhiều trường hợp , mối lên kểt superpeer-client gần như là cố định, mỗi 1 peer khi tham gia vào mạng đều được gắn vào 1 superpeer cho tới khi nó rời khỏi mạng. Hiển nhiên là, superpeer có tuổi thọ dài hơn các peer thông thường. Để phòng superpeer có những hành vi bất thường, kế hoạch backup có thể được triển khai, như là ghép đôi tất cả superpeer tới 1 cái khác (superpeer khác ?) rồi yêu cầu client kết nối đến cả 2. Cố định các liên kết tới superpeer không phải lúc nào cũng là giải pháp tốt nhất. Ví dụ, trong một mạng chia sẻ file, sẽ là tốt hơn nếu client kết nối tới superpeer – superpeer này duy trì index của các file mà client quan tâm. Trong trường hợp đó, khả năng tìm kiếm thành của client khi cần thiết sẽ lớn hơn. Như chúng ta đã thấy, mạng peer-to-peer hỗ trợ một phương pháp linh hoạt cho các nút tham gia/ rời khỏi mạng. Tuy nhiên, với các mạng superpeer, một vấn đề mới đã được nêu ra, cụ thể là làm sao để chọn được các nút thích hợp để làm superpeer. Vấn đề này liên quan gần đến vấn đề chọn leader (leader-election problem) sẽ được đề cập ở chương 6. Kiến trúc lai Chúng ta đã tiếp cận kiến trúc client-server và vài kiến trúc peer-to-peer. Rất nhiều hệ phân tán kết hợp các đặc trưng kiến trúc như là mạng superpeer. Ở chương này, chúng ta sẽ xem xét 1 vài lớp cơ bản của hệ phân tán mà trong đó, giải pháp client-server kết hợp với kiến trúc phi tập trung dữ liệu. Hệ thống server biên (Edge-server system) Một lớp cơ quan trọng của hệ phân tán là được tổ chức theo kiến trúc phân tầng dưới dạng các hệ thống server biên (Edge server systems). Hệ thống này được triển khai trên Internet-nơi các server đặt tại biên của mạng. Biên này được tạo bởi ranh giới giữa các mạng doanh nghiệp và mạng Internet. (ví dụ, được cung cấp bởi 1 ISP-Internet Service Provider. Tương tự như thế, Các end user kết nối tới internet thông qua ISP của họ, ISP khi đó coi như là ở biên của mạng Internet. End user hay client, kết nối internet gián tiếp qua Edge server. Edge server có nhiệm vụ đáp ứng nội dung, có thể sau khi áp dụng lọc (filtering) và chuyển mã. Tập các Edge server có thể được dùng để optomize nội dung và các ứng dụng phân tán. Chúng ta sẽ trở lại với hệ thống Edge server tại chương 12, khi bàn về các giải pháp web-based. Hệ thống cộng tác phân tán (collaborative distributed system) Kiến trúc phân tầng được đặc biệt triển khai ở hệ thống cộng tác phân tán. Để cụ thể hóa, chúng ta sẽ thảo luận về các hệ thống chia sẻ file BitTorrent. BitTorrent là hệ thống tải file theo kiểu peer-to-peer. Ý tưởng cơ bản là, khi một end user tìm kiếm 1 file, anh ta download các chuck (?) của file từ các user khác, cho tới khi các chuck download được có thể được gắn lại với nhau thành một file hoàn chỉnh. Mục đích quan trọng khi thiết kế chính là đảm bảo được sự cộng tác. Để download 1 file, user phải truy nhập vào globle directory – một vài website. Nó như một thư mục lưu trữ các tham chiếu tới các file .torrent. Một file torrent chứa các thông tin cần thiết để download một file cụ thể. Trong thực tế, chúng tham chiếu tới các tracker, là một server giữ các nút active có các chuck của file được yêu cầu. 1 nút Active khi đang download 1 file khác. BitTorrent là giải pháp kết hợp giữa tập trung và phi tập trung Mô tả kiến trúc phần sụn (middleware) Middleware có dạng như một layer nằm giữa các ứng dụng phân tán và nền tảng (platform) phân tán. Mục đích chính của lớp này là làm trong suốt tính phân tán, cụ thể là mức độ che dấu tính phân tán của dữ liệu, tiến trình, và các điều khiển từ lớp ứng dụng. Trong thực tế, hệ thống middleware thường theo một dạng kiến trúc cụ thể. Ví dụ như CORBA (OMG, 2004a) là kiến trúc đối tượngect-based, trong khi TIB/Rendezvous(TIBCO, 2005) xây dựng theo kiến trúc event-based. Một khi khuôn dạng của middleware đã theo một dạng kiến trúc nào đó, việc thiết kế ứng dụng sẽ đơn giản hơn. Tuy nhiên, có một nhược điểm rất rõ ràng là: middleware không được tối ưu cho việc phát triển các ứng dụng bên trong nó nữa. Lấy ví dụ với CORBA, ban đầu nó chỉ hỗ trợ cho các đối tượng được gọi bởi remote client. Nhưng cách tương tác này có rất nhiền hạn chế, do đó một mô hình tương tác (interaction pattern) như gửi thông báo (messaging) được thêm vào. Việc thêm các tính năng mới lại làm phình ra các giải pháp dành cho middleware (middleware solution). Thêm nữa, mặc dù middleware được sử dụng để làm cho việc phân tán trở nên trong suốt (tính thích nghi giữa 2 lớp trên và dưới, middleware cung cấp một interface cho ứng dụng và platform giao tiếp với nhau mà không bị ảnh hưởng bởi kiến trúc riêng của mỗi lớp). Trên thực tế, một giải pháp (thiết kế middleware) cụ thể sẽ chỉ thích nghi với các yêu cầu của ứng dụng (application requirements – của một ứng dụng, hay của một lớp ứng dụng nào đó). Một giải pháp cho vấn đề này là tạo ra vài phiên bản của miiddleware. Mỗi phiên bản được thiết kế riêng cho một lớp các ứng dụng cụ thể. Một cách tiếp cận tốt hơn là tạo nên một hệ thống middleware mà chúng ta có thể dễ dàng conf, customize, adapt (chỉnh sửa) khi nào ứng dụng cần. Giờ đây, các hệ thống đang được phát triển theo cách mà phần chính sách (policies) và phần cơ chế (mechanisms) luôn được tách biệt rõ ràng. Nên một vài cơ chế có thể bị chỉnh sửa bởi các hoạt động (behavior) của middleware. Chúng ta sẽ xem xét qua một vài cách tiếp cận phổ biến. Interceptors Interceptor có thể coi là một phần mềm, tác dụng của nó là ngắt (break) một luồng điều khiển thôn