Chuyện Chưa Kể Về Microservices

Xưa kia ở nước Việt Nam dân quốc, đất Sài Gòn, có chàng trai họ Khắc tên Tiệp, xuất thân bần hàn gia cảnh nghèo khó. Không cam chịu hoàn cảnh, chàng đã tự xây dựng một startup tên là Venus, chuyên đào tạo chân dài. Rất nhiều cô gái đã được chàng phát hiện và đào tạo để trở thành những hot girl, siêu mẫu chân dài đến nách như Ngọc Trinh, Kỳ Hân…
Do nhu cầu phát triển doanh nghiệp, chàng quyết định thuê một công ty outsourcing là FSOFT build cho chàng một hệ thống ERP (Enterprise Resource Planning) chuyên quản lý các em idols.
Và câu chuyện bắt đầu từ đây….
Chàng Cuder FSOFT nhận được hợp đồng cỡ bự thì mừng lắm, ngày đêm tra cứu các loại Design Pattern, gọi cả BA giỏi nhất FSOFT đều cùng trao đổi tìm hiểu nghiệp vụ của Venus. Và cuối cùng, sắp nhiều đêm thức trắng chỉ có mỳ tôm cầm hơi, chàng đã đưa ra một thiết kế được cho là hết sức vô đối.
Đó là mô hình N-Tier architecture, một mô hình thiết kế khá thông dụng.
Được viết bằng ngôn ngữ Java trên nền tảng Spring MVC, hệ thống Venus gồm nhiều các module và đóng gói với nhau thành một khối (monolithic), giao tiếp bằng method call nên hoạt động khá hiệu quả, performance cao.
Các đại gia như Hoàng Kiều chỉ việc truy cập vào website là có thể view thông tin đầy đủ về các idol hết sức dễ dàng. Hơn nữa bên cạnh việc thanh toán truyền thồng, hệ thống của Venus còn cho phép thanh toán bằng Bitcoin làm khách hàng rất ưng ý.

Venus’s N-Tier architecture

Từ ngày có trang web, Venus ngày càng làm ăn phát đạt. Khách hàng không chỉ có ở nội địa mà còn mở rộng sang cả Japan và USA; Venus mau chóng có nhiều khách hàng “ruột”.
Đúng là nhu cầu con người là vô hạn, các khách hàng của Venus ngày càng đòi hỏi các tính năng mới.
Hệ thống Venus ngày càng trở nên phức tạp, khó maintain và mở rộng. Nó trở nên cồng kềnh, khó quản lý. Đặc biệt, mỗi lần sửa code, developer phải build và deploy lại cả hệ thống rất tốn kém thời gian. Source code đã lên tới cả triệu LOC, mỗi lần load lên IDE là chờ dài cổ.
Rồi một ngày, tổng thống Obama nối hứng chém một câu.
Hệ thống đã được phát triển bằng Java trong bao nhiêu năm, chuyển sang .NET đồng nghĩa với việc viết lại toàn bộ hệ thống. Chàng cuder FSOFT chỉ biết đầu hàng botay.com.
Thế rồi một hôm, chàng tình cờ đọc một bài báo nói về kiến trúc Microservices, chàng trai như tỉnh cơn mơ, như người chết đuối vớ được cọc.
Chàng Cuder FSOFT đã đón nhận những tư tưởng cách mạng của Microservices với niềm phấn khởi và tin tưởng của một người chiến sĩ cách mạng sau nhiều năm nghiên cứu lý luận, khảo sát thực tiễn.
Những luận điểm về Microservices đã trở thành “ánh mặt trời chân lý chói qua tim” đối với chàng Cuder trẻ tuổi.

Microservices là gì??

Microservice là một loại kiến trúc phần mềm với ý tưởng 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 tập 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ộ ra giao tiếp lập trình API cho dịch vụ nhỏ khác hay ứng dụng 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 (virtual machine) hoặc Docker container (ảo hóa tầng ứng dụng).
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 (nhiều dịch vụ nhỏ).

Ưu nhược điểm của Microservices?

Chàng Cuder FSOFT đã tới gặp Martin Fowler, một chuyên gia về Microservices để được tư vấn. Martin Fowler cười nói.
Ưu nhược điểm của Microservices thì chú hỏi anh Gúc Gồ ra cả triệu kết quả. Nhưng anh sẽ mô tả bằng hình tượng thế này để cho chú hiểu.
Có một gia đình gồm hai ông bà cụ và 3 đứa con sống chung trong một căn nhà. Căn nhà đó giống như một kiến trúc đơn khối, các đứa con giống như các module trong kiến trúc đó. Vì sống chung một nhà nên việc communicate giữa ông bà cụ với các con rất dễ dàng. Đêm hôm có gì chỉ cần ới một tiếng là chúng nó qua luôn, nó giống như function call trong kiến trúc đơn khối, performance rất nhanh.
Thế rồi năm tháng qua đi, anh con cả và con thứ lấy vợ, sinh được mấy thằng cu nghịch như quỷ sứ. Cô em út đi lấy chồng nhưng thằng rể thì nghèo nên xin … ở rể.
Ban ngày trẻ con khóc lóc, đùa nghịch ồn ảo. Ban đêm thì vợ chồng thẳng cả ở phòng kế bên lại đá bóng sân hàng chiếu khiến ông bà chịu không nổi. Ông bà tính việc mở rộng căn nhà, nó cũng giống như việc scale up hệ thống monolithic. Nhưng mở rộng bằng cách xây thêm tầng (vertical scale) thì không ổn vì móng nhà toàn bằng cọc tre, mở theo chiều ngang thì sợ lấn chiếm đất đai, a Đoàn Ngọc Hải lại qua “thăm hỏi”.

Scaling and Ease of Deployment

Ông cụ quyết định cho tiền để các con đi ở riêng, mối đứa một căn. Communication với các con bằng điện thoại, facebook message. Nó giống như chia hệ thống thành microservice, điện thoại, facebook message chính là communication giữa các service. Nếu cụ có đẻ thêm con thì chỉ việc mua cho nó một căn nhà mới mà không ảnh hưởng gì đến căn nhà cũ→ Microservice có khả năng Scale tốt và dễ deploy.

Resilience

Nếu nhưng một trong các căn nhà của đứa con bị cháy (Service fall) cũng không ảnh hưởng gì đến các nhà còn lại → khả năng Resilience

Organizational Alignment

Mỗi đứa một căn nhà, nhà nào thì thằng đấy lo, không ảnh hưởng đến ai. Giống như mỗi team in charge một service của riêng mình, không ảnh hưởng tới ai → khả năng Organizational Alignment
Tất nhiên đồng xu thì cũng có mặt sấp mặt ngửa, người cũng có chỗ trắng chỗ đen, Microservices cũng có nhược điểm của nó.
Hãy tiếp tục bằng câu chuyện trên, từ ngày các con đi ở riêng, ông bà sống thoải mái hẳn; nhưng rồi một đêm, cụ ông bị bệnh. Cụ bà hoảng hồn gọi điện cho Microservices anh con cả. Tuy nhiên đêm hôm khuya anh cả không nghe máy → service not available. Đó là một nhược điểm của kiến trúc này.
Không gọi được cho con cả, cụ gọi cho con thứ. Lần này thì service anh con thứ có hoạt động, nhưng mà … vợ nghe máy. Cô vợ vốn không ưa bà mẹ chồng nên bơ luôn, không reply lại → service takes too long time to respond.
Cuối cùng thì cụ bà nhắn message cho con gái út qua FB, ngờ đâu đúng ngày cá mập cắn cáp nên không gửi msg được → issue in communication.
Cuối cùng khi các con được tin đến nơi thì bố đã về chầu trời.

Communication trong Microservice

Restful API
Rest API là phương thức communication khá phổ biến trong Microservicem sử dụng HTTP protocol, đơn giản tuy nhiên có nhược điểm là giữa client và server phải luôn luôn ready. Gửi phải có trả lời.
RPC (Remote procedure call).
Phương thức gọi hàm từ xa, tương tự như gọi hàm trong hệ thống đơn khối. Tuy nhiên giao thức này có issue về performance.
Message
Communication bất đồng bộ qua hệ thống message queue, phương pháp này có nhiều ưu điểm hỗ trợ 1:N, các service không nhất thiết phải luôn available. Tuy nhiên cũng có nhược điểm là message gửi đi thì không acknowledge được đã dc nhận chưa.
Microservices Design Pattern
Chàng Cuder sau khi được cao nhân giảng giải như vén mây mù thấy trời xanh. Chàng đã áp dụng một số design pattern để build hệ thống Venus bằng Microservice
Aggregator pattern
Trong pattern này, các service publish và subcribe 2 Message Queue là Request Queue và Response Queue để gửi nhận message.
Giả sử anh Kiều muốn xem thông tin của Ngọc Trinh thì chỉ việc gọi API đến endpoint.
  • Aggregator API sẽ gửi message đến request Queue.
  • 3 Microservice sẽ thực hiện việc lấy tên tuổi, tiểu sử và gia đình của Ngọc Trinh sau đó trả về response queue.
  • Aggregator API subscribe trên queue này tổng hợp dữ liệu và trả về cho Hoàng Kiều.
Chained Single Responsibility Services
Đây là loại pattern trong đó các service gọi lẫn nhau, output của service này là input của service kia.
  1. Hoàng Kiều gọi API đến endpoint để order em Ngọc Trinh
  2. Service 1 check Ngọc Trinh có available không để order
  3. Service 2 nhận được output của service 1 sẽ process Order
  4. Service 3 thực hiện payment và trả về kết quả cho anh Kiều
Như vậy, nếu như service Payment vì lý do nào đó mà không available thì sẽ dẫn tới việc khách hàng order mặt hàng nào đó nhưng không giả tiền → Data không đồng nhất. Đó là một nhược điểm của Microservices.
Từ ngày Venus được build thành Microservice, hệ thống đã có thể handle được hàng triệu người dùng, dễ mở rộng. Venus ngày càng phát triển, anh Tiệp từ một chàng trai nghèo đã trở thành tỉ phú Forbes. 

No comments:

Post a Comment

The Ultimate XP Project

  (Bài chia sẻ của tác giả  Ryo Amano ) Trong  bài viết  số này, tôi muốn viết về dự án phát triển phần mềm có áp dụng nguyên tắc phát triển...