1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. Quản trị mạng >

Phát triển điện toán đám mây tại Việt Nam – còn nhiều thách thức

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.54 MB, 58 trang )


Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



quá nhiều cho cơ sở hạ tầng hoặc nâng cấp ứng dụng, không đòi hỏi nguồn nhân lực lớn và có thể dễ

dàng thay đổi quy mô khi cần.

Ông Hoàng Lê Minh, Viện trưởng Viện công nghiệp phần mềm và nội dung số Việt Nam

(NISCI), khẳng định điện toán đám mây là mục tiêu mà thế giới cũng như ngành công nghệ thông tin

trong nước hướng tới và đây chính là nhân tố thúc đẩy các quá trình chuyển đổi kinh doanh.

Tuy nhiên, theo các chuyên gia của Intel nhận định thì điện toán đám mây chắc chắn không phải

dành cho tất cả mọi người và cho mọi nhu cầu. Mặc dù lợi ích của điện toán đám mây là không thể phủ

nhận, nhưng các doanh nghiệp cần cân nhắc đến các yếu tố khác nhau khi tính đến chuyện ứng dụng

điện toán đám mây, cụ thể như: rào cản kỹ thuật, an toàn thông tin, nguồn vốn để hiện đại quy trình

kinh doanh bằng việc ứng dụng công nghệ thông tin, giảm chi tiêu cho phần cứng, phần mềm, an toàn

bằng thuê ngoài phần mềm cơ sở hạ tầng, tính linh hoạt và khả năng mở rộng của nguồn lực công nghệ

thông tin trước khi quyết định ứng dụng điện toán đám mây vào sản xuất kinh doanh. Việt Nam cũng

không phải là một ngoại lệ.

Bên lề hội nghị “Ngày Điện toán đám mây Việt Nam 2011”, ông Phan Thanh Sơn, Giám đốc

công nghệ của công ty Cisco, chia sẻ còn nhiều khó khăn trong việc triển khai điện toán đám mây tại

Việt Nam. Theo ông, vấn đề chính sách, đường truyền băng thông và nhận thức của doanh nghiệp là

những thách thức lớn nhất với công nghệ mới này.

Đồng thời, một số doanh nghiệp cho biết họ đã và đang sử dụng các dịch vụ đám mây miễn phí

như Google Apps, nhưng vẫn cần thời gian để tìm hiểu nhiều hơn những lợi ích cũng như rủi ro về tính

an toàn dữ liệu. Ông Nguyễn Thiện Tâm, Giám đốc khách hàng của Công ty Sutrix Media Việt Nam,

cho biết nếu sử dụng các dịch vụ điện toán đám mây thì đòi hỏi mỗi nhân viên phải có kỹ năng nhất

định về công nghệ thông tin. Hiện công ty có sử dụng Google Docs, nhưng chỉ dừng ở mức độ trao đổi,

chia sẻ tài liệu.

Không chỉ có vậy, Ông Lê Đức Quyết, Phó giám đốc Công ty cổ phần Thế giới vận tải, cho biết

ông vẫn còn e ngại khi đưa những thông tin liên quan đến tài chính của công ty lên dịch vụ điện toán

đám mây vì không biết được dữ liệu của mình ở đâu đó trên mạng. Ông Quyết cũng nói mô hình ứng

dụng điện toán đám mây phụ thuộc nhiều vào Internet mà chưa chắc lúc nào cũng có thể truy cập vào

Internet.

Bản chất của điện toán đám mây là sự hội tụ các thành tựu về nghiên cứu phát triển các công

nghệ mới; các quan điểm về ứng dụng CNTT hiện nay ở trên thế giới cũng như Việt Nam. Điện toán

đám mây cũng là một trong những khái niệm mơ hồ nhất từ trước đến nay chúng ta gặp phải. Nó cũng

giống như cái gì ở trên cao, ở trong mây, chúng ta không thể nhận biết được. Nhưng đó cũng chính là

mục tiêu mà hiện nay ngành CNTT truyền thông đang hướng tới.

Có thể nói điện toán đám mây đang tạo cơ hội cho các doanh nghiệp hoạt động hiệu quả, thông

minh và tiết kiệm chi phí hơn. Các doanh nghiệp Việt Nam đang có điều kiện thuận lợi để sử dụng

những tiện ích này. Vấn đề là bản lĩnh của doanh nghiệp có dám ứng dụng công nghệ mới vào quản lý

điều hành sản xuất kinh doanh hay không mà thôi. Vì vậy, dù công ty ở quy mô lớn hay nhỏ, bạn cũng

nên thử dùng dịch vụ này, nếu không có thể bạn đã bỏ lỡ một cơ hội kinh doanh trong tương lai.



9. Mô hình hướng dịch vụ

4.1.17.



9.1. Khái niệm



Mô hình hướng dịch vụ (Service Oriented Architechture –SOA) là một khái niệm về kiến trúc

hệ thống nhằm đem lại một cách thuận tiện nhất những chức năng nghiệp vụ, hoặc là những quy trình

ứng dụng, tới người sử dụng dưới dạng các dịch vụ hoạt động trên môi trường mạng có khả năng chia

20



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



sẻ và sử dụng lạị. Dịch vụ ở đây được hiểu là những mô-đun nghiệp vụ hoặc chức năng ứng dụng với

giao diện được thiết kế theo quy định và được tương tác bằng cách gửi nhận thông điệp.

4.1.18.



9.2. Kiến trúc mô hình hướng dịch vụ



Kiến trúc hướng dịch vụ (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, 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

loose coupling”, và có khả năng truy cập thông qua môi trường mạng. Hiểu một cách đơn giản thì một

hệ thống SOA là một tập hợp các dịch vụ được chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh

một tiến trình nghiệp vụ. Trong SOA có ba đối tượng chính



Hình 1.10. Sơ đồ cộng tác trong SOA

Nhà cung cấp dịch vu (service provider) cần cung cấp thông tin về dịch vụ của mình cho một

dịch vụ lưu trữ thông tin(service registry). Người sử dụng (service consumer) thông qua service registry

sẽ tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung

cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: sự phức

tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô hình SOA có khả năng mở

rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên

hiện có của hệ thống.

4.1.19.



9.3. Các tính chất của một hệ thống hướng dịch vụ



Liên kết lỏng (Loose coupling)

Mọi kiến trúc phần mềm đều hướng đến liên kết lỏng 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 và mở rộng của chính nó. Kết dính càng chặt

bao nhiều thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi có sự thay

đổi nào đó xảy ra. quả về thông tin qua một “kênh thông điệu”, bên gọi không phải chờ cho đến khi

thông điệp được sử lý xong. Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về

nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất động, bất đồng bộ

Quản lý các chính sách

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng

gọi là policy. Các policy cần được quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn thực thi

trong thời gian thực thi.

Khả năng cộng tác

21



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác, khả năng mà 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 qua một dạng kết nối.

Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm về truy tìm dịch vụ (service discovery). Một người sử dụng cần đến một

dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên các số tiêu chuẩn khi cần. Người sử dụng chỉ cần hỏi

một registry về dịch vụ nào thỏa yêu cầu tìm kiếm. Registry trả về một tập các entry thỏa yêu cầu.

Tự hồi phục

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một

hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. mỗi hệ thống tự hồi phục (self- healing) là một

hệ thống có khả năng tự hồi phụ sau khi bị lỗi mà không cần sự can thiệt của cong người.

4.1.20.



9.4. Lợi ích và hạn chế của việc sử dụng mô hình SOA



Lợi ích

Việc sử dụng mô hình hướng dịch vụ SOA đem lại các lợi ích sau:

- Cho phép hướng sự tập trung vào xây dựng các tính năng nghiệp vụ trong quá trình phát triển

phần mềm

- Giảm thiểu chi phí trong quá trình phát triển

- Giảm thiểu yêu cầu về đào tạo và kỹ năng

- Chi phí bảo trì thấp

- Chu trình phát triển phần mềm nhanh chóng hơn

- Độc lập hệ thống: những service không phụ thuộc vào hệ thống và mạng cụ thể

- Có khả năng tái sử dụng

- Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về yêu cầu giao dịch

- Cho phép dễ dàng triển khai chương trình, môi trường chạy và quản lý service dễ dàng hơn

- Những sự xác nhận và chứng minh của Service consumer về những tính năng security dựa

trên giao tiếp Service tốt hơn cơ chế kết nối chặt chẽ

- Kiến trúc kết nối lỏng lẻo cho phép dễ dàng tích hợp thành phần những chương trình, tiến

trình hay những service phức tạp từ những service đơn giản

- Cho phép Service Consumers tìm kiếm và kết nối với những service động khác

Hạn chế

- Hệ thống phức tạp

- Khó miêu tả dữ liệu không cấu trúc trong header của message

4.1.21.



9.5. So sánh mô hình SOA với các mô hình truyền thống



Mô hình SOA có ưu thế hơn các mô hình truyền thống (như mô hình hướng ứng dụng hoặc mô

hình hướng lập trình) ở điểm mô hình SOA chủ yếu tập trung nguồn lực phát triển vào các chức năng

22



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



và tính năng phục vụ hoạt động và quy trình nghiệp vụ. Điều này cho phép nhà quản lý chỉ cần dựa trên

đặc điểm mang tính nghiệp vụ rà soát, xác định rõ chi tiết, thành phần cần thêm, sửa đổi hoặc loại bỏ.

Do đó, các hệ thống phần mềm phát triển phía sau có thể được thiết kế nhằm đáp ứng những quy trình

nghiệp vụ (thay vì quy trình nghiệp vụ phải thay đổi để tận dụng những tính năng phần mềm như trong

các mô hình thường thấy ở nhiều cơ quan tổ chức với hạ tầng ứng dụng Công nghệ thông tin được phát

triển từ trước).

Mô hình SOA và OOP (mô hình hướng đối tượng)

SOA sử dụng cùng một số nguyên lý như OOP, tuy nhiên triết lý SOA có khác biệt đáng kể so

với OOP. SOA có thể thực hiện với cả chương trình theo hướng đối tượng (OO) và chương trình không

hướng đối tượng. SOA hỗ trợ việc kết nối lỏng lẻo các service. OOP dựa nhiều trên các lớp đựoc định

nghĩa sẵn, kết quả là các đối tượng kết nối chặt chẽ với nhau. Service oriented sử dụng các message để

miêu tả thông tin về service để thực hiện chức năng của mình OOP lại sử dụng các hàm APIs để miêu

tả các đối tượng của mình. Phạm vi hoạt động của các service trong SOA rộng lớn hơn là các đối tượng

của OOP. SOA khuyến khích các service được thiết kế phi trạng thái càng nhiều càng tốt còn OOP thì

lại liên kết dữ liệu một cách logic từ đó tạo ra các đối tượng có trạng thái. SOA hỗ trợ việc kết nối lỏng

lẻo các service với nhau, còn OOP thì khuyến khích việc kế thừa các đối tượng từ đó các đối tượng liên

kết với nhau một cách chặt chẽ.

Mô hình SOA và Web

Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Điều này có thể

làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: Dịch vụ web. Dịch vụ web cho phép

truy cập thông qua định nghĩa giao thức-và-giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau

nhưng chúng không phải là một. Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao

tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và

phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi 'kiến

trúc định hướng giao tiếp' thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy

cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ 1 chiều

thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương

tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng

dịch vụ.

4.1.22.



9.6. Kết luận



Xây dựng hệ thống sử dụng mô hình hướng dịch vụ SOA đưa lại những hiệu quả:

- Tập trung vào xây dựng các tính năng nghiệp vụ trong quá trình phát triển phần mềm

- Giảm thiểu chi phí trong quá trình phát triển

- Giảm thiểu yêu cầu về đào tạo và kỹ năng

- Chi phí bảo trì thấp

- Chu trình phát triển phần mềm nhanh chóng hơn

- Có khả năng tái sử dụng

- Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về yêu cầu giao dịch

- Cho phép dễ dàng triển khai chương trình, môi trường chạy và quản lý service dễ dàng hơn.



23



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



10. Công nghệ ảo hóa

4.1.23.



10.1 Ảo hóa là gì?



Ảo hóa là một thiết kế nền tảng kỹ thuật cho tất cả các kiến trúc điện toán đám mây. Điện toán

đám mây đề cập chủ yếu đến nền tảng ảo hóa. Ảo hóa là công nghệ được thiết kế để tạo ra tầng trung

gian giữa hệ thống phần cứng máy tính và phần mềm chạy trên nó. Ảo hóa cho người dùng thấy các

máy chủ, thiết bị lưu trữ, và phần cứng khác được coi là một khối tổng thể các nguồn lực hơn là các hệ

thống rời rạc, do đó những nguồn tài nguyên này có thể được phân bổ theo yêu cầu. Trong điện toán

đám mây, công nghệ ảo hóa máy chủ được quan tâm hàng đầu, ở đó một máy vật lý đơn lẻ có thể tạo

thành nhiều máy ảo độc lập. Mỗi một máy ảo đều có một thiết lập nguồn hệ thống riêng rẽ, hệ điều

hành riêng và các ứng dụng riêng.

4.1.24.



10.2 Lợi ích từ ảo hóa



Ảo hóa giải quyết các thách thức của việc quản lý trung tâm dữ liệu và cung cấp một số lợi thế

như sau:

Tỷ lệ sử dụng cao hơn

Hợp nhất tài nguyên

Sử dụng điện năng thấp hơn

Tiết kiệm không gian

Khắc phục rủi ro

Giảm chi phí hoạt động

4.1.25.



10.3 Các phương pháp ảo hóa phổ biến



Ảo hóa máy chủ (Server Vitualization)

Ảo hóa ứng dụng (Application virtualization)

Ảo hóa lưu trữ

4.1.26.



10.4. Ảo hóa máy chủ với Hyper-V (Tự tìm hiểu và báo cáo)



Tổng quan, kiến trúc

Các tính năng

Lợi ích khi triển khai Hyper -V

Triển khai

Kết luận

Công nghệ ảo hóa thực ra là việc chia nhỏ mỗi công việc cụ thể trên một Server thành các

Server khác nhau từ đó làm tăng khả năng vận hành của một hệ thống máy tính đảm bảo tính thống

nhất và lưu trữ, truy cập của hệ thống. Tìm hiểu về công nghệ ảo hóa chúng ta có thể nhận thấy ưu

nhược điểm của công nghệ này từ đó đưa ra cách tiếp cận công nghệ một cách phù hợp với nhu cầu của

mình. Việc áp dụng công nghệ ảo hóa tại Việt nam còn rất dè dặt. Theo đánh giá ban đầu, nguyên nhân

chủ yếu là do các nhà quản lý tại Việt Nam chưa nhận thức được sự cần thiết của việc tiết kiệm không

gian, điện năng và nhân công trong việc ứng dụng công nghệ ảo hóa. Thêm vào đó, một nguyên nhân

24



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



nữa khiến các nhà quản lý công nghệ thông tin tại Việt Nam còn e ngại chính là tính bảo mật của những

hệ thống ảo này. Tuy nhiên, nếu không ảo hóa, Việt Nam sẽ tốn chi phí không nhỏ cho việc bảo dưỡng

và sửa chữa những hệ thống cồng kềnh. Do đó, cần quảng bá cho các doanh nghiệp biết được những ưu

thế và lợi ích mà ảo hóa đem lại để áp dụng rộng rãi công nghệ này tại Việt Nam, bắt nhịp với xu thế

phát triển của thế giới.

11. An ninh trên cloud

11.1 Những thách thức

Bảo mật cho SaaS Các nhà phân tích và công ty tư vấn công nghệ Gartner đã liệt kê ra 7 vấn

đề về bảo mật cần được thảo luận với một nhà cung cấp ĐTĐM SaaS, gồm các nội dung sau:

Việc truy cập của người dùng được ưu tiên: yêu cầu ai là người chuyên về truy cập dữ liệu,

thuê hay quản lý các quản trị viên?

Việc tuân theo các quy tắc: Đảm bảo rằng nhà cung cấp sẵn sàng chịu sự kiểm nghiệm bên

ngoài và các xác nhận về vấn đề bảo mật?

Vị trí dữ liệu: nhà cung cấp có cho phép bất kỳ ai kiểm soát vị trí của dữ liệu không?

Tách dữ liệu: Đảm bảo quyền truy cập thích hợp trong tất cả các công đoạn và những chiến

lược mã hóa này phải được những chuyên gia giàu kinh nghiệm thiết kế và kiểm duyệt?

Khả năng phục hồi: Phát hiện chuyện gì sẽ xảy ra với dữ liệu khi gặp tai họa. Liệu chúng có

khả năng phục hồi hoàn toàn không? Nếu có thì sẽ mất thời gian bao lâu?

Hỗ trợ điều tra: Nhà cung cấp có thể phát hiện những hành vi không thích hợp hoặc phạm pháp

không?

Khả năng tồn tại lâu dài: Chuyện gì sẽ xảy ra với dữ liệu khi công ty không còn kinh doanh

nữa? Dữ liệu sẽ được trở lại như thế nào và theo định dạng gì?

Việc thực hành an ninh cho môi trường SaaS được xây dựng như hiện nay được thảo luận trong

các phần sau.

Quản trị an ninh

Quản lý rủi ro

Đánh giá rủi ro

Chính sách, tiêu chuẩn và chỉ dẫn

Chu trình phát triển phần mềm an toàn Chu trình tạm thời có thể chia thành 6 giai đoạn

chính sau:

Nghiên cứu: xác định mục tiêu và quy trình của dự án, tài liệu về chính sách bảo mật chương

trình.

Phân tích: Phân tích các chương trình, chính sách, các mối đe dọa hiện hành, kiểm tra lợi tức

hợp pháp và phân tích độ mạo hiểm.

Thiết kế logic: Phát triển một sơ đồ chi tiết về bảo mật, lập kế hoạch đối phó với những trường

hợp xấu, các biện pháp kinh doanh trước thảm họa và xác định tính khả thi của việc tiếp tục dự án hay

thuê ngoài.



25



Bài giảng Điện toán đám mây



Khoa CNTT trường đại học Quy Nhơn



Thiết kế vật lý: Chọn các công nghệ để hỗ trợ cho một bản thiết kế chi tiết về bảo mật, đưa ra

một hướng giải quyết hợp lý, các tiêu chuẩn bảo mật vật lý để hỗ trợ các biện pháp kỹ thuật và kiểm

tra, nâng cấp kế hoạch.

Thi hành: Mua hoặc phát triển các biện pháp bảo mật. cuối giai đoạn này, cần phải đưa ra một

gói hoàn chỉnh đã được thử nghiệm để có được sự phê duyệt của nhà quản lý.

Duy trì: Ổn định việc quản lý, kiểm nghiệm, điều chỉnh, nâng cấp và sửa đổi để có thể ứng phó

với sự thay đổi của các mối đe dọa.

Giám sát bảo mật và đối phó với các tình huống bất ngờ

Thiết kế cấu trúc bảo mật

An ninh Vật lý



CHƯƠNG 2. XÂY DỰNG ỨNG DỤNG CLOUD COMPUTING TRÊN NỀN TẢNG

GOOGLE APP ENGINE

2.1. Công nghệ Google App Engine

4.1.27.



2.1.1. Tổng quan về Google App Engine



Google App Engine (GAE) là một nền tảng hosting bao gồm web server, cơ sở dữ liệu BigTable

and kho lưu trữ file GFS. GAE cho phép bạn viết ứng dụng web dựa trên cơ sở hạ tầng của Google.

Nghĩa là bạn không cần quan tâm là trang web bạn được lưu trữ như thế nào (kể cả database đi kèm),

mà chỉ cần quan tâm đến việc phát triển ứng dụng theo các API do Google cung cấp. Với App Engine,

bạn chỉ cần tải lên các ứng dụng của bạn, và nó sẵn sàng để phục vụ người dùng của bạn. Bạn có thể sử

dụng tên miền riêng của mình (chẳng hạn như http://www.example.com/ ) thông qua google apps. Hoặc

bạn có thể dùng sub-domain miễn phí của appspot.com. GAE cho phép được host miễn phí với dung

lượng 1GB lưu trữ và cho phép 5 triệu pageview hàng tháng, vượt qua mức này bạn sẽ phải trả phí.

Dùng GAE, chúng ta khỏi phải thiết kế database, viết SQL để truy vấn data, map data với object.

Chúng ta chỉ cần design các class và GAE tự động lo phần làm việc với database. Tóm lại, giờ đây bạn

chỉ cần phải nghĩ ra và viết những ứng dụng tuyệt vời nhất rồi kêu gọi cả thế giới vào dùng. Tuy nhiên,

mặt trái của việc xây dựng ứng dụng trên GAE là bạn sẽ phụ thuộc hoàn toàn vào các công nghệ của

Google và rất khó có thể tách ra thành một ứng dụng độc lập. Yahoo hay Microsoft sẽ chẳng bao giờ

mua một ứng dụng xây dựng trên nền tảng của đối thủ. Còn các nhà đầu tư cũng rất e ngại khi tài sản

của công ty bạn đặt hết vào tay người khác, dù cho đó là Google.

GAE được Google cho ra mắt vào tháng 4 năm 2008 hỗ trợ ngôn ngữ Python. Đến tháng 4 năm

2009, GAE đã công bố hỗ trợ ngôn ngữ chính thức thứ hai là Java, đánh dấu một sự thay đổi lớn trong

cách xây dựng ứng dụng. Một số ngôn ngữ khác như PHP cũng có thể chạy được nếu cài cùng với bộ

chuyển từ PHP sang Java. GAE là nền tảng ĐTĐM theo mô hình PaaS. GAE cho phép khách hàng

triển khai các ứng dụng web để chạy trên cơ sở hạ tầng của Google. Với các đặc trưng dễ dàng xây

dựng, bảo trì và khả mở, GAE đã được các nhà phát triển và các doanh nghiệp triển khai sử dụng. Với

chi phí xây dựng và triển khai ứng dụng ban đầu gần như bằng 0, khách hàng dễ dàng xây dựng các

ứng dụng theo yêu cầu. Khi ứng dụng đã thu được lợi nhuận và vượt qua mức sử dụng thì khách hàng

chỉ phải trả khoản phí tài nguyên mà mình đã sử dụng.

26



Bài giảng Điện toán đám mây

4.1.28.



Khoa CNTT trường đại học Quy Nhơn



2.1.2 Môi trường phát triển



Một ứng dụng App Engine đáp ứng các yêu cầu web. Một yêu cầu web sẽ bắt đầu khi có một

người dùng hay điển hình là các trình duyệt web của người dùng gửi một yêu cầu truy cập vào ứng

dụng thông qua giao thức HTTP. Khi App Engine nhận được yêu cầu, nó sẽ xác định ứng dụng dựa vào

tên miền, hoặc tên miền con của .appspot.com (cung cấp miễn phí mỗi ứng dụng) hoặc là một tên miền

riêng của chúng ta đã được đăng kí và thiết lập với Google Apps. App Engine lựa chọn một máy chủ từ

nhiều máy chủ để xử lý các yêu cầu đó. Sau đó, App Engine sẽ gửi các yêu cầu đã nhận được từ người

dùng đến ứng dụng phù hợp để xử lý, sau khi đã xử lý xong các ứng dụng này sẽ gửi dữ liệu trả về cho

App Engine, App Engine sẽ nhận dữ liệu phản hồi từ các ứng dụng và trả về cho người dùng thông qua

trình duyệt web. Theo góc nhìn của ứng dụng, môi trường thực thi chỉ xuất hiện và tồn tại khi bắt đầu

một yêu cầu và sẽ biến mất khi yêu cầu đó được đáp ứng xong. App Engine cung cấp tối thiểu 2 cách

thức lưu trữ dữ liệu tồn tại giữa các yêu cầu , nhưng các cơ chế này tồn tại bên ngoài môi trường thực

thi. Môi trường thực thi sẽ không duy trì trạng thái giữa các yêu cầu, hoặc ít nhất không mong muốn

các trạng thái sẽ được duy trì giữa các yêu cầu. App Engine có thể phân phát lưu lượng truy cập trong

nhiều server, vì nó cần phải đáp ứng cho nhiều yêu cầu xử lý như nhau, bất kể có bao nhiêu lưu lượng

truy cập nó sẽ xử lý cùng một lúc. Bản thân GAE có cơ chế để quản lý các trạng thái của từng yêu cầu

trong mỗi ứng dụng dưới dạng Sandbox (người phát triển không biết rõ cơ chế bên trong nhưng hỗ trợ

người phát triển những dịch vụ cần thiết). Điều này cho phép App Engine xử lý một yêu cầu với một

máy chủ mà nó mong muốn trong ước tính của nó để trả về phản hồi nhanh nhất. Không có cách nào để

đảm bảo rằng phần cứng trên cùng một máy chủ sẽ xử lý hai lần yêu cầu, ngay cả khi các yêu cầu đến

cùng từ một client, và đến khá nhanh chóng. Sandboxcho phép App Engine chạy nhiều ứng dụng trên

cùng một máy chủ, trong đó hành vi của một ứng dụng không làm ảnh hưởng đến các ứng dụng khác.

Ngoài ra để giới hạn quyền truy cập đến hệ điều hành, môi trường thực thi cũng giới hạn việc sử dụng

CPU và bộ nhớ . App Engine giữ các giới hạn này linh hoạt và chặt chẽ hơn các giới hạn này để các

ứng dụng sử dụng nhiều tài nguyên hơn để bảo vệ tài nguyên được chia sẻ từ những ứng dụng “không

mong muốn”. Mỗi yêu cầu có tối đa 30s để trả về phản hồi cho client. Mặc dù thời gian này có vẻ đáp

ứng tốt cho một ứng dụng web, nhưng App Engine được tối ưu hóa cho các ứng dụng đáp ứng chưa

đầy một giây. Ngoài ra nếu một ứng dụng sử dụng nhiều CPU, App Engine có thể làm chậm nó xuống,

nên các ứng dụng không trì hoãn bộ vi xử lý trên một máy phục vụ đa ứng dụng. Một CPU tập trung xử

lý yêu cầu có thể mất nhiều thời gian để hoàn thành, khi App Engine dò tìm các mô hình theo cách sử

dụng CPU và phân bổ cho phù hợp. Google App Engine cung cấp hai môi trường thực thi chính cho

các ứng dụng. Đó là Java và Python, hiện đang thử nghiệm trên Go. Môi trường chúng ta chọn sẽ phụ

thuộc vào ngôn ngữ và những công nghệ liên quan khi chúng ta dùng để phát triển ứng dụng. Môi

trường Java thực thi các ứng dụng được viết cho JVM6. Ứng dụng có thể được phát triển dựa vào ngôn

ngữ lập trình Java hoặc hầu hết các ngôn ngữ có thể biên dịch và chạy trên JVM: ví dụ PHP (dùng

Quercus), Ruby (dùng JRuby), Javascript (dùng Rhino), Scala, Groovy. App Engine cũng hỗ trợ

Google Web Tootkit (GWT). Môi trường Python thực thi các ứng dụng được viết dựa vào ngôn ngữ lập

trình Python bản 2.5. App Engine gọi các ứng dụng Python nhờ vào CGI. Ứng dụng có thể dùng hầu

hết các thư viện của Python, các framework của Python như Django, web2py, Pylons. Cả hai môi

trường Java và Python đều sử dụng chung một mô hình: một yêu cầu gửi đến ứng dụng trên server, ứng

dụng được kích hoạt (nếu cần thiết), gọi bộ phận xử lý yêu cầu và trả về kết quả cho client. Mỗi môi

trường sử dụng bộ tiền xử lý (interpreter) cho riêng mình (JVM hay Python).

4.1.29.



2.1.3. Mô hình kiến trúc và các dịch vụ của GAE



Trong mô hình kiến trúc này cho thấy được hoạt động của GAE. Một yêu cầu từ trình duyệt của

máy bàn, máy xách tay, điện thoại, … được gửi tới GAE thông qua lối vào (Front End). Một ứng dụng

27



Xem Thêm
Tải bản đầy đủ (.docx) (58 trang)

×