24/08/2019
Hi all, lâu nay lại chểnh mảng quá, từ nay, mình sẽ cố gắng siêng chia sẻ về mọi thứ mà mình đã trải qua, cũng như các công nghệ mới mình được tiếp cận hoặc tìm hiểu qua.
Microservice architecture là architecture pattern được sử dụng rộng rãi trong rất nhiều những hệ thống lớn ngày nay nhờ vào những ưu điểm của nó so với monolithic architecture.
Mô tả một cách sơ lược thì Microservice là việc chia nhỏ ứng dụng lớn thành nhiều service riêng biệt chạy độc lập với nhau, ko ảnh hưởng đến nhau và có thể giao tiếp với nhau qua nhiều cách trong đó phổ biến nhất vẫn là thông qua API.
Martin Fowler - developer gạo cội với nhiều đầu sách rất nổi tiếng như: Clean Code, Patterns of Enterprise Application, ... đã tóm lược lại những kiến thức cơ bản cần có để chuẩn bị chuyển đổi kiến trúc hệ thống từ monolithic sang kiến trúc microservice.
1. Componentization via Services:
- Ngành công nghiệp phần mềm ngày càng phát triển, đi kèm với đó là những ứng dụng lớn với những business phức tạp được ra đời để giải quyết những bài toán cụ thể.
- Việc các ứng dụng ngày càng lớn và phức tạp dẫn đến việc maintain ngày càng trở nên khó khăn nếu không có 1 kiến trúc tốt. Do đó việc chia nhỏ 1 ứng dụng ra thành nhiều service nhỏ mang lại rất nhiều ưu điểm, ví dụ các service có thể viết bằng bất kì ngôn ngữ hoặc sử dụng bất kì database nào phù hợp, hoặc là nếu trước đó việc thêm 1 tính năng mới sẽ phải deploy lại toàn bộ project thì việc tách ứng dụng ra thành nhiều service nhỏ sẽ rất dễ dàng cho việc thêm tính năng mới mà không cần phải deploy lại toàn bộ project.
- Nhưng nó cũng có 1 vài nhược điểm: 1 tính năng muốn lấy dữ liệu ở service khác đều phải gọi qua API, trước đó thì chỉ cần gọi 1 function là lấy được.
2. Organized around Business Capabilities:
- Thông thường, 1 ứng dụng lớn sẽ bao gồm nhiều team chịu những phần khác nhau như: UI-UX team, server-side logic team, database team ... điều này dẫn đến khi có 1 thay đổi hoặc thêm 1 tính năng mới sẽ mất nhiều thời gian và chi phí hơn. Với cách tiếp cận của microservice, việc chia nhỏ ra thành nhiều các service team phù hợp với yêu cầu về business sẽ giúp cho các team trở lên linh hoạt hơn rất nhiều.
3. Products not Projects:
- 1 Model rất phổ biến trong ngành phát triển phần mềm là cố gắng hoàn thành xong các chức năng trong sản phẩm, sau đó sản phẩm sẽ được bàn giao để maintain, điều này góp phần làm cho các thành viên trong team thiếu sự gắn kết và dần tan rã.
- Cách tiếp cận của microservice sẽ tránh được điều này, mỗi team nên có 1 product riêng có đẩy đủ vòng đời phát triển sản phẩm. 1 khái niệm rất nổi tiếng từ Amazon: "you build, you run it", nghĩa là các team phải chịu trách nhiệm từ lúc phát triển sản phẩm đến lúc sản phẩm chạy trên production, và team đó sẽ phải chịu trách nhiệm giúp cho user hiểu được sản phẩm của mình hơn.
4. Smart endpoints and dumb pipes:
- Ứng dụng đc xây dựng theo microservice architecture mục đích là để tách rời ứng dụng lớn ra thành nhiều phần nhỏ và làm cho chúng gắn kết nhất có thể (decoupled and as cohesive as possible)
- Và cách phổ biến để giao tiếp giữa các service là dùng RESTful API, và cách tiếp cận thứ 2 là dùng 1 số tool như: RabbitMQ hay ZeroMQ để build 1 hệ thống bất đồng bộ
- Trong monolithic architecture, việc gọi qua nhau để lấy dữ liệu đơn giản chỉ là gọi qua các function
5. Decentralized Governance
- 1 nhược điểm của việc quản lý tập trung là chỉ áp dụng được 1 công nghệ duy nhất trên nền tảng đó, và không phải mọi vấn đề đều được giải quyết tốt nhất khi dùng công nghệ đó.
Hãy dùng đúng công cụ để giải quyết đúng vấn đề đang gặp phải,
- Việc chia ra thành các service nhỏ làm việc sử dụng linh động các ngôn ngữ, database khác nhau rất dễ dàng
- Hãy cùng ngồi lại với team, trao đổi những vấn đề đang gặp phải, viết chúng ra giấy và tìm kiếm các công cụ giải quyết vấn đề đang gặp phải
6. Decentralized Data Management:
- Microservice architecture đc chia ra thành nhiều service nhỏ, mỗi service sẽ có 1 database độc lập với các service khác, điều này khác hoàn toàn với monolithic architecture thường chỉ sử dụng duy nhất 1 database.
- Việc chia tách ra thành nhiều service dẫn đến 1 vài vấn đề về việc đảm bảo toàn vẹn dữ liệu, và việc sử dụng transaction là 1 giải pháp hữu hiệu. Nhưng việc này cũng có nhược điểm là phải khi 1 service xảy ra vấn đề sẽ phải gọi lại các service khác để đảm bảo toàn vẹn dữ liệu
7. Infrastructure Automation
- Hiện nay, việc áp dụng CI-CD vào hệ thống của mình cũng không còn quá xa lạ trong những năm gần đây khi cloud phát triển rất nhanh chóng, và việc áp dụng automation cho microservice architecture sẽ giảm thiểu đi sự phức tạp khi build, deploy các service.
8. Design for failure
- Việc chia tách ứng dụng ra thành nhiều service có nhược điểm: khi có quá nhiều service, việc quản lý chất lượng của 1 service hay làm sao để 1 service có khả năng chịu lỗi cao nhất khi có 1 lượng lớn request đến thực sự là 1 thách thức. Và khi 1 service bị down, làm thế nào để detect và restore service đó nhanh nhất có thể để không ảnh hưởng quá nhiều đến trải nghiệm của user.
- Việc Automation Testing, Monitoring, Logging các service trên môi trường production là thứ cần phải có để detect được vấn đề nhanh nhất có thể
9. Evolutionary Design
- Khi quyết định chuyển đổi từ monolithic architecture sang microservice architecture, bạn sẽ phải đối mặt với 1 vài câu hỏi: làm sao để tách ứng dụng thành nhiều các service nhỏ, làm thế nào để khi viết lại 1 service không ảnh hưởng đến các service khác, .. và website Guardian là ví dụ điển hình về việc chuyển từ kiến trúc monolithic sang microservice, phần lõi của họ vẫn là monolithic, nhưng các tính năng mới đều đc chia nhỏ ra các service khác nhau.
- Với microservice architecture, các service được deploy độc lập với nhau nhưng phải lưu ý, khi có 1 service thay đổi, liệu các service khác có bị ảnh hưởng không?. Cách giải quyết phổ biến sử dụng versioning cho service này.
Các bạn có thể tham khảo chi tiết bài viết ở đây: https://martinfowler.com/articles/microservices.html
