Chuyện 18+ về Microservice


Bài viết đc đăng trên Fsoft Potato TechMag

Phần 1: Chuyện chàng Khắc Tiệp và công ty Venus


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 và cung cấp chân dài cho các đại gia. Rất nhiều cô gái đã được chàng phát hiện nhào nặn, nắn bóp để trở thành những hot girl, siêu mẫu chân dài đến nách, điện nước đầy đủ 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 cty 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.


Ngoc trinh khac tiep
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, view thông tin và order 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

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. Từ cụ ông Nhật Bản Shigeo Tokuda cho tới tổng thống Mỹ Barack Obama cũng là khách hàng “ruột” của Venus.
Đú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 Microservice, chàng trai như tỉnh cơn mơ, như người chết đuối vớ được cọc, người bị tiêu chảy gặp WC
Chàng Cuder Fsoft đã đón nhận những tư tưởng cách mạng của Microservice 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ề Microservice đã trở thành “ánh mặt trời chân lý chói qua tim” đối với chàng Cuder trẻ tuổi

Microservice 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.
Kiến trúc monolithic
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 Microservice??

Chàng Cuder Fsoft đã tới gặp Martin Fowler, một chuyên gia về Microservice để được tư vấn. Martin Fowler cười nói.
Ưu nhược điểm của Microservice 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, Microservice cũng có nhược điểm của nó
Nhược điểm của Microservice

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 có điều là buồn. Cụ bà thì đang tuổi hồi xuân, cụ ông thì tuổi già sức yếu. Thế rồi một đêm, cụ ông quyết định dùng một chai Minh Mạng thang để bổ thận tráng dương, tăng cường sinh lực ai ngờ quá liều nên bị Thượng Mã Phong.
Cụ bà hoảng hồn gọi điện cho Microservice 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
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
RPC protocol

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

Microservice 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

Aggregator pattern


Giả sử a Kiều muốn xem info của Ngọc Trinh thì chỉ việc gọi API đến endpoint

  1. Aggregator API sẽ gửi message đến các service để lấy dữ liệu
  2. Microservice sẽ thực hiện việc lấy tên tuổi, tiểu sửa và gia đình của Ngọc Trinh sau đó trả về
  3. Aggregator API 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
Chain pattern


  1. Hoàng Kiều gọi API đến endpoint để order em Ngọc Trinh
  2. Service A check Ngọc Trinh có available không để order
  3. Service B nhận được output của service 1 sẽ process Order
  4. Service C 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 a Kiều order em Ngọc Trinh nhưng không giả tiền Data không đồng nhất. Đó là một nhược điểm của Microservice

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, a Tiệp từ một chàng trai nghèo đã trở thành tỉ phú Forbes. Chàng cưới Ngọc Trinh làm vợ và sống hạnh phúc đến lúc rụng hết răng.

Đón đọc câu chuyện thứ 2

Lời nguyền project số 03

Powered by Blogger.