Microservices địa ngục kiến trúc một khối
Microservices hiện đang nhận được rất nhiều sự chú ý: các bài viết, các blog, các cuộc thảo luận trên phương tiện truyền thông, trên mạng xã hội, và các bài thuyết trình hội nghị. Đâu đâu ta cũng có thể bắt gặp những chủ đề liên quan đến Microservices.
Cùng với đó cũng có những hoài nghi trong cộng đồng phần mềm, những người cho rằng microservices không hề có gì mới mẻ. Những người này cho rằng các ý tưởng về Microservices chỉ là một hình thức làm khác của SOA (Service-Oriented Architecture) hay còn được hiểu là kiến trúc hướng dịch vụ.
Tuy nhiên, bất chấp cả sự cường điệu hóa lẫn những hoài nghi, thì mô hình Microservice mang lại những lợi ích đáng kể trong việc xây dựng những giải pháp phức tạp, đặc biệt là nó tạo điều kiện cho việc áp dụng agile lên project một cách hiệu quả.
Kiến trúc một khối.
Trong quá khứ, người ta xây dựng hệ thống theo một khối (Monolithic Applications).
Thử tưởng tượng bạn đang phải xây dựng một dịch vụ gọi taxi qua di động nhằm cạnh tranh với Uber và Hailo. Sau một số buổi họp thu thập yêu cầu và phân tích thiết kế, bạn sẽ chọn công nghệ (technology stack) rồi tạo dự án bằng các framework đại loại như Rails, Spring Boot, Play, hay Maven. Dự án này sẽ có kiến trúc chia khối lục giác (hexagol architecture) hay tổng quát hơn là khối đa diện. Kiến trúc đa diện giúp ứng dụng chuyên biệt mô hình dữ liệu.
Nhìn vào lõi của ứng dụng, ta thấy business logic được thể hiện bởi các khối dịch vụ (services), đối tượng cho từng vùng nghiệp vụ (domain objects) và các sự kiện (events). Xung quanh lõi là các adapter để kết nối vào cơ sở dữ liệu, gửi nhận message, web service hoặc front-end web application.
Mặc dù có cấu trúc module hóa hợp lý, nhưng ứng dụng kiểu này sẽ đóng gói và cài đặt thành một khối (monolithic). Cách để triển khai gói ứng dụng tùy thuộc vào ngôn ngữ lập trình hay thư viện framework. Ví dụ ứng dụng sử dụng Spring framework, đóng trong file WAR, triển khai trên application server như Tomcat hay Jetty. Dùng framework khác, ví dụ Spring Boot thì ứng dụng Java là một file tự đóng gói để chạy là JAR. Ứng Rails hay Node.js đóng gói theo cấu trúc thư mục phân cấp.
Ứng dụng viết kiểu này cực kì phổ biến. Chúng hoàn toàn dễ phát triển, đặc biệt cùng với sự phát triển của IDE và những tool khác tập trung vào xây dựng những ứng dụng đơn lẻ dựa trên template sẵn có. Tại sao lại vậy? Đơn giản thôi, do họ cần thuyết phục lập trình viên đi theo công nghệ/framework nên nhà sản xuất phải làm sao lập trình chỉ cần New Project, ấn nút Build & Run là ứng dụng chạy được ngay và luôn. Bạn có thể dễ dàng thực hiện testing bằng cách chạy ứng dụng và thực hiện test UI bằng Selenium. Ứng dụng một khối như thế này khá dễ triển khai. Đơn giản là chỉ cần copy gói được build ra lên server. Thêm nữa, những ứng dụng dạng này cũng có thể dễ dàng scale bằng cách chạy nhiều instance được phân tải bằng load balancer. Trong giai đoạn đầu sau khi triển khai, chúng hoạt động vô cùng tốt.
Từng bước xuống địa ngục.
Đáng tiếc rằng, cách tiếp cận kiến trúc một khối tuy dễ dàng nhưng lại bộc lộ nhiều khiếm khuyết.
Ứng dụng của bạn thành công, kéo theo đó số lượng người dùng tăng, yêu cầu tính năng mới tăng, dữ liệu tăng, logic phức tạp hơn, giao tiếp với hệ thống khác tăng, và hàng trăm thứ khác dẫn đến một kết quả là ứng dụng phình to ra một cách khủng khiếp. Sau mỗi sprint, hàng loạt tính năng mới được thêm vào, thêm code, thêm bảng, thêm logic… Chỉ sau một thời gian, ứng dụng đơn giản sẽ trở nên kềnh càng như một con quái vật. Và số lượng effort bỏ ra để phát triển cũng như bảo trì con quái vật này sẽ không hề nhỏ.
Khi ứng dụng phình quá to, mọi nỗ lực tối ưu, áp dụng agile method đều không còn hiệu quả. Chỉ một chỉnh sửa nhỏ, sẽ phải tham chiếu đến những chỗ nó sử dụng để xem xét sự ảnh hưởng của nó lên toàn bộ hệ thống. Nó quá khó để cho một lập trình viên có thể nắm và hiểu toàn bộ code hệ thống. Và như một hệ quả tất yếu, việc fix bug, hay thêm tính năng mới trở nên khó hơn và tốn nhiều thời gian hơn.
Trong ứng dụng một khối, sự chặt chẽ là ưu điểm tự nhiên xuất phát từ kiến trúc, nhưng nó tiềm ẩn nguy cơ ràng buộc cứng nhắc (tight coupling). Chi phí, thời gian, nỗ lực phát triển, sửa lỗi, kiểm thử một chức năng sẽ tăng tỷ lệ cấp số nhân theo độ lớn của ứng dụng.
Khi ứng dụng càng lớn, mỗi lần deploy phiên bản mới cũng sẽ là một cực hình, thậm chí tệ hại nếu thời gian down time cho việc khởi động lại là quá lớn. Điều này cũng ảnh hưởng khi lập trình viên đang debug ứng dụng, tưởng tượng một ứng dụng redeploy mất 10 phút thì trong 10 phút đó lập trình viên sẽ làm gì, rõ rành nó ảnh hưởng rất lớn đến năng suất làm việc.
Gần đây, bạn nghe nói nhiều hơn về khái niệm triển khai đều đặn (continous deployment). Những ứng dụng SaaS (Software application as Service) tiên tiến, cần phải cập nhật vài lần trong một ngày. Quá khó để triển khai lại cả một ứng dụng cực lớn chỉ vì một số nâng cấp nhỏ. Hoạt động bị ngưng trệ, kiểm thử lại sau triển khai sẽ lâu công hơn. Kết quả là việc này sẽ khó mà áp dụng với ứng dụng một khối. Nếu không muốn nói là không thể.
Ngoài ra, thật khó để scale khi mà những module khác nhau, với những nhu cầu về tài nguyên khác nhau nằm chung trong một khối. Ví dụ, triển khai ứng dụng trên AWS (Amazon Web Services), bạn có một module xử lý ảnh, module này tốn tài nguyên CPU khá lớn, thích hợp nêú bạn sử dụng EC2 Compute Optimized instances, ngoài ra, bạn lại có một module sử dụng caching in-memory với nhu cầu tài nguyên về RAM là vô cùng lớn, thích hợp hơn nếu bạn sử dụng EC2 Memory-optimized instances. Tuy nhiên vì là ứng dụng một khối nên chúng ta phải tính toán làm sao cho phù hợp nhất, điều này cũng ảnh hưởng không nhỏ đến chi phí bỏ ra.
Một vấn đề khác với các ứng dụng nguyên khối đó là độ tin cậy.Bởi vì tất cả các module đang chạy trong cùng một quá trình, một lỗi trong bất kỳ module nào, chẳng hạn như một lỗi memory leak, cũng có thể có khả năng làm down toàn bộ quá trình cũng như cả hệ thống.
Cuối cùng, ứng dụng một khối sử dụng một ngôn ngữ, một framework duy nhất vì thế lập trình viên làm việc trong dự án sẽ quen với sự thuận tiện, dễ dàng khi chỉ cần nắm sâu một ngôn ngữ, một công cụ có thể giải quyết hầu hết vấn đề. Họ dần lệ thuộc vào ngôn ngữ đó và trở nên thiên vị, ngại cởi mở, tích hợp với những công nghệ khác của ngôn ngữ khác. Thậm chí khi framework hay ngôn ngữ có nhược điểm cố hữu, vì tính một khối của ứng dụng sẽ bó buộc lập trình viên thử nghiệm đưa vào thay đổi đột phá ngoại lai.
Đơn giản thế này thôi, ứng dụng một khối có hơn 2 triệu dòng code trên framework XYZ nào đó, liệu đội bạn có đủ dũng cảm, nguồn lực để viết lại toàn bộ trên framework ABC mới hơn, tốt hơn. Dù cho bạn có đội ngũ lập trình giỏi, sáng tạo thì họ cũng không hề muốn làm trong dự án bế tắc kiểu này. Hoặc nếu bạn thật sự muốn làm thì chi phí để đập đi xây lại toàn bộ hệ thống là vô cùng lớn. Tình trạng giữ thì khổ, xây thì khó, khiến dịch vụ, sản phẩm của bạn ngày càng khó phát triển.
Tóm lại, bám vào kiến trúc một khối, một vé xuống địa ngục là cao hơn lên thiên đường.
Vậy chúng ta phải làm gì?
Hẹn gặp lại các bạn trong phần tiếp theo, Đơn giản hóa mọi sự phức tạp với Microservices.
Nhiều tập đoàn như Amazon, eBay, Netflix đã giải quyết vấn đề ứng dụng một khối bằng kiến trúc Microservices. Ý tưởng là chia nhỏ ứng dụng lớn ra thành các dịch vụ nhỏ kết nối với nhau.
Mỗi dịch vụ nhỏ thực hiện một số các chức năng chuyên biệt như quản lý đơn hàng, quản lý khách hàng… Mỗi dịch vụ là một ứng dụng nhỏ có kiến trúc đa diện lõi là business logic kết nối ra các adapter khác nhau. Một số dịch vụ nhỏ lộ đưa ra API cho dịch vụ nhỏ khác hay client gọi tới. Khi vận hành, mỗi dịch vụ nhỏ được chạy trong một máy ảo hoặc Docker container.
Mỗi chức năng giờ được thực thị bởi một dịch vụ nhỏ. Ứng dụng web cũng có thể chia nhỏ hơn chuyên cho từng đối tượng người dùng (một cho hành khách taxi, một cho tài xế). Thiết kế giao diện cho từng đối tượng người dùng giúp tối ưu trải nghiệm tốt hơn, tốc độ nhanh hơn, dễ tương thích hơn trong khi chức năng tối giản hơn.
Ứng dụng của người dùng cuối sẽ không được kết nối trực tiếp vào back-end services. Thay vào đó có API gateway đứng giữa.
Có ba khía cạnh để scale một hệ thống sử dụng Microservices, thứ nhất là trục Y với việc chia càng nhỏ dịch vụ ra càng nhiều càng tốt, thứ hai với trục X là việc clone các instance của mỗi services và hứng bằng load balancer, thứ ba với trục Z là data partitioning, bằng cách phân vùng những dịch vụ tương tự.
Biểu đồ dưới mô tả làm thế nào dịch vụ quản lý chuyến đi có thể được triển khai với Docker chạy trên Amazon EC2.
Kiến trúc Microservices ảnh hưởng lớn đến quan hệ ứng dụng và cơ sở dữ liệu. Thay vì dùng chung một cơ sở dữ liệu giữa các dịch vụ, mỗi dịch vụ sẽ có cơ sở dữ liệu riêng. Cách này đi ngược lại việc tập trung hóa cơ sở dữ liệu trong truyền thống. Hệ quả là sẽ có dư thừa dữ liệu, cơ chế foreign key ràng buộc quan hệ dữ liệu không thể áp dụng với bảng ở hai cơ sở dữ liệu tách biệt. Thiết kế này sẽ gây sốc đối với nhiều lập trình đã quá quen với mô hình client – server, ở đó cơ sở dữ liệu luôn là một trung tâm, tập hợp mọi bảng. Việc lưu trữ dữ liệu ở từng dịch vụ rất quan trọng nếu bạn muốn kiến trúc microservice thực sự hiệu quả vì nó đảm bảo loose coupling (ít ràng buộc) giữa các dịch vụ với nhau. Nhưng đây vũng chỉ là khuyến cáo, trong thực tế, vài dịch vụ vẫn có thể dùng chung một cơ sở dữ liệu để đảm bảo tính toàn vẹn dữ liệu được ưu tiên cao nhất.
Sơ đồ dưới đây là ví dụ về kiến trúc cơ sở dữ liệu cho các dịch vụ.
Từng dịch vụ nhỏ có thể tùy chọn công nghệ lưu trữ dữ liệu tối ưu nhất. Ví dụ, dịch vụ điều xe cần phải dùng cơ sở dữ liệu hỗ trợ việc truy vấn theo tọa độ tốt nhất.
Nhìn một cách tổng thể, kiến trúc Microservices tương tự như SOA (kiến trúc hướng dịch vụ). Cả hai đều có một tập các dịch vụ. Điểm khác là Microservices không dùng chuẩn do các tập đoàn lớn như IBM, Microsoft, Oracle đặt ra như web service specifications (WS-*) hay Enterprise Service Bus (ESB). Microservices hướng đến các chuẩn lightweight hơn như Protobuf, Thrift hoặc cởi mở, dễ đọc như JSON. Microservice không áp dụng một số phần của SOA như canonical schema. Có thể thấy Microservices gọn hơn, đa dạng hơn trong giao thức cũng như chuẩn dữ liệu.
Và cũng như mọi thứ khác trên thế gian này, đều có ưu điểm cũng như nhược điểm. Vậy những ưu điểm và nhược điểm của kiến trúc Microservices là gì, mời các bạn đón xem phần tiếp theo, Những ưu nhược điểm của Microservices.
Tạm biệt và hẹn gặp lại.
Có thể bạn quan tâm:
- Điều cần biết về ERP
- Phần lớn doanh nghiệp Việt gần như vô hình với thế giới trực tuyến, bỏ lỡ cơ hội có thể tăng doanh số bán hàng lên đến 4 lần
- Tặng mã nguồn mạng xã hội giống y Facebook
- Tài liệu về lập trình html5
- Quản trị Joomla 1.5 toàn tập
- Lịch sử các Ngôn ngữ lập trình [Inforgraphic]
- Rút tiền từ ATM bằng điện thoại thông minh
- Tài liệu lập trình mạng xã hội với Open Social
- Tài liệu và mã nguồn hệ thống groupon, bán deal, mua hàng theo nhóm
- Tôi code vì tiền?
- Xuất khẩu phần mềm được luật quy định như thế nào?
- Gọi điện lừa đảo, yêu cầu chủ website đăng ký với Bộ Công Thương
DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...
Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…
Quý khách xem Hồ sơ năng lực của DVMS tại đây >>
Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>