Với anh đã có kinh nghiệm thiết kế, phát triển các hệ thống có áp dụng các nguyên lý thiết kế microservices không còn là điều xa lạ.
Tuy nhiên với các anh em mới bắt đầu, việc áp dụng tốt các nguyên lý thiết kế microservices sẽ giúp anh em phát triển tốt hệ thống. Hệ thống cũng có thể scale up, scale down tốt về sau.
Bản thân các nguyên lý đã được đúc rút ra từ rất rất nhiều các lập trình viên có kinh nghiệm khi họ sử dụng microservices. Chính vì thế, anh em nên bỏ chút ít thời gian đọc và ghi nhớ các nguyên lý thiết kế này.
Các cụ dạy rồi, học từ cái ông đã làm sai, đã gặp vấn đề luôn là cách học tốt mà.


1. Single Responsibility Principle
Với anh em developer đã có kinh nghiệm thì nguyên lý này cũng không phải mới mẻ gì. Single Responsibility Principle là chữ S nằm trong SOLID. Mà SOLID thì quá nổi tiếng trong giới phần mềm.
Nội dung của nguyên lý này nói rằng mỗi microservices mà anh em thiết kế hoặc implement chỉ nên handle một công việc (handle only one thing). Microservices chỉ nên giao tiếp với microservices để hoàn thành task của nó. Nhưng về mặt lý thuyết, bản thân nó vẫn chỉ handle một việc duy nhất. Chính vì chỉ xử lý một việc duy nhất, nó đáp ứng được S trong SOLID.
Ví dụ: Anh em đang thiết kế hệ thống ecommerce. Thương mại điện tử yêu cầu người dùng đăng nhập, cho phép người dùng thanh toán đơn hàng. Trường hợp này ta cần hai microservices, một để xác thực người dùng (Authentication Service), microservice thứ hai dùng để thanh toán (Payment Service). Không nên viết một Service duy nhất mà ở đó xử lý cả việc Authentication và Payment.


2. Decentralized Data Management (Dữ liệu phi tập trung)
Trái ngược với dữ liệu tập trung (Centralized). Nguyên lý này trong thiết kế microservices khuyên ta nên thiết kế sao cho dữ liệu không tập trung ở một nơi (Decentralized).
Mỗi microservices nên quản lý dữ liệu của riêng nó. Việc mỗi microservices tự quản lý được data mà nó cần đảm bảo sự độc lập, khả năng mở rộng và độ tin cậy.
Anh em có thể đặt câu hỏi tại sao lại nói về độ tin cậy? Độ tin cậy ở đây được hiểu là khi một microservices khác down (hoặc gặp bất cứ vấn đề gì), các microservices được tin cậy vẫn có thể hoạt động bình thường (do bản thân không có liên kết gì với các microservices khác).


Như hình trên đây thì 3 microservices User, Messages, Friends. Bản thân mỗi microservices có một database riêng, MessageDB có thể dùng MongoDB, trong khi Users với Friends dùng các RDBMS khác?
Tới đây một số anh em có thể thắc mắc. Ủa rồi keep cho data độc lập ai chả muốn, nhưng nếu cần data ở microservices khác thì sao? Chẳng lẽ cứ giữ khăng khăng như thế? Đây đây, cái số 3 đây sẽ giải quyết vấn đề này.
Tham khảo việc làm PHP hấp dẫn trên TopDev
3. API-Driven Design
Nguyên lý thứ 3 trong nguyên lý thiết kế microservices là API-Driven. Bắt đầu với định nghĩa API-Driven ha.
API-driven development is the practice of designing and building APIs first, then creating the rest of an application around them.
Phát triển API-driven là thực hành thiết kế và xây dựng API trước, sau đó với xây dựng phần còn lại của ứng dụng xung quanh các API đã làm
Nguyên lý này vô cùng hữu ích khi thiết kế, xây dựng và làm việc với mô hình microservices. Theo nguyên lý này, microservices nên thiết kế xung quanh API. Mỗi microservices cung cấp rõ ràng một bộ API để giao tiếp với các microservices khác.


4. Stateless
Để hiểu được nguyên lý này, anh em cần phân biệt được sự khác nhau giữa Stateful và Stateless.


Trong các điểm khác biệt, có một điểm anh em cần lưu ý. Stateless sẽ không quan tâm tới state hiện tại của request. Nếu một microservices xử lý giỏ hàng của khách hàng trong hệ thống ecommerce, services đó sẽ không quan tâm trạng thái hiện tại của request là gì. Bản thân nó sẽ luôn xử lý request bằng cách lấy toàn bộ giữ liệu giỏ hàng và tiến hành bước tiếp theo.
Chính sự không quan tâm tới state hiện tại giúp bản thân microservices độc lập, có thể scale up và có độ ổn định cao.
Nhưng trong quá trình phát triển microservices. Giữ cho stateless không phải là dễ nha anh em.
5. Loose Coupling
Loose Coupling trong nguyên lý thiết kế microservices cũng giống như Loose Coupling trong hướng đối tượng (Object Oriented Design). Nguyên lý này nhắm tới việc loại bỏ một vài class, package và module.
Loose Coupling cũng mang ý nghĩa lỏng lẻo. Nguyên lý này nói rằng các microservices nên được liên kết lỏng lẻo với nhau, không nên liên kết chặt chẽ với nhau. Việc không có mối liên kết chặt chẽ giữa các microservice đảm bảo khả năng scale cho các microservices.


Như hình bên trái, các microservices có mối liên hệ chặt chẽ với nhau. Việc này dẫn tới các microservices bị phụ thuộc vào nhau, khó trở nên độc lập. Ngược lại, Loosely Coupled cho phép các microservices chỉ có một vài liên kết giữa các microservices.
6. Auto scaling
Nguyên lý cuối được đều cập liên quan tới nguyên lý thiết kế microservices là Auto-scaling (tự động mở rộng).
Thực chất một hệ thống khi lựa chọn áp dụng microservices, bản thân hệ thống đó đã cân nhắc hoặc ít nhất là có nhu cầu về scale (mở rộng). Bản thân mỗi microservices phải có thể tự mở rộng khi có nhiều hơn các request. Giảm bớt các instance đi trong trường hợp chỉ có số ít các request.
Ví dụ: nếu số lượng user truy cập tới microservices tăng, bản thân microservices phải tự mở rộng được. Khi user giảm truy cập, các instance trước đó phải được xoá bớt đi.
Hiện nay, Kubernetes có thể đáp ứng yêu cầu này. Nên lúc thiết kế anh em nhớ cân nhắc yếu tố Scaling để tận dụng tối đa Cloud, các công cụ như Kubernetes


Cụ thể như thế nào sẽ viết rõ cho anh em trong bài viết khác ha. Bài viết này chỉ nói về các principles (nguyên lý thôi)
7. Tham khảo thêm về thiết kế microservices
Một số cuốn sách cũng như tài liệu hay về nguyên lý thiết kế microservices anh em có thể tham khảo
- Stateful vs. Stateless: Understanding the Key Differences
- Pattern: Microservice Architecture
- Atomic design – Ưu nhược điểm từ kinh nghiệm thực tế
Cảm ơn anh em đã dành thời gian cho bài viết – Thank you for your time for article – Happy coding!
Tác giả: Kiên Nguyễn
Xem thêm:
- Building Microservices Application – Phần mở đầu: Bức tranh tổng thể
- Truy vấn dữ liệu MongoDB
- Software engineer phát triển bản thân như thế nào?
Xem thêm Việc làm Developer hấp dẫn trên TopDev




















































































Ép Kiểu & Comment Source Code trong Java
Bài viết được sự cho phép của tác giả Nhựt Danh
Bài hôm nay chúng ta sẽ nói về 2 vấn đề “nhỏ”, đó là ép kiểu và comment source code. Bạn cũng nên biết nhỏ ở đây là nhỏ về tổng số chữ viết, chứ thực ra hai vấn đề hôm nay đều rất quan trọng cho các bài học kế tiếp đấy nhé. Với kiến thức về ép kiểu, chúng là kiến thức nền để bạn hiểu rõ cách sử dụng các kiểu dữ liệu khác nhau trong các ứng dụng của bạn. Còn comment source code sẽ trở thành phong cách viết code sao cho có đầy đủ chú thích dễ hiểu cho chính bạn và những người khác đọc source code của bạn sau này.
Nào để hiểu nó là gì, mời bạn đến với bài học.
Khái Niệm Ép Kiểu
Trước khi đi sâu vào tìm hiểu về ép kiểu, mình cũng xin nhắc lại một chút, là chúng ta đã từng làm quen với việc khai báo một biến (hoặc hằng), khi đó bạn cần chỉ định một kiểu dữ liệu cho biến hoặc hằng đó trước khi sử dụng. Việc khai báo một kiểu dữ liệu ban đầu như vậy mang tính tĩnh. Có nghĩa là nếu bạn định nghĩa biến đó là kiểu int, nó sẽ mãi là kiểu int, nếu bạn định nghĩa nó là kiểu float, nó sẽ mãi là kiểu float. Có bao giờ bạn thắc mắc nếu đem hai biến có kiểu dữ liệu khác nhau này vào tính toán với nhau, liệu nó sẽ tạo ra một biến kiểu gì? Và liệu chúng ta có thể thay đổi kiểu dữ liệu của một biến, hay một giá trị đã được khai báo hay không?
Câu hỏi trên cũng chính là nội dung của bài ép kiểu hôm nay. Cụ thể có thể mô tả ép kiểu như sau, ép kiểu là hình thức chuyển đổi kiểu dữ liệu của một biến sang một biến mới có kiểu dữ liệu khác. Vậy việc ép kiểu này không làm thay đổi kiểu dữ liệu của biến cũ, nó chỉ giúp bạn tạo ra một biến mới với kiểu dữ liệu mới, và mang dữ liệu từ biến cũ sang biến mới này. Khái niệm là vậy, còn mục đích là gì các bạn hãy đọc tiếp bài học hôm nay nhé.
Nên nhớ là vì các bạn chỉ mới làm quen với kiểu dữ liệu nguyên thủy, nên ép kiểu hôm nay cũng chỉ nói đến ép kiểu dữ liệu nguyên thủy mà thôi.
Phân Loại Ép Kiểu
Nếu phân loại ép kiểu dựa vào khả năng lưu trữ của biến, thì chúng ta có hai loại ép kiểu sau.
Tham khảo việc làm Java hấp dẫn trên TopDev
Kiểu phân loại thứ hai được chia làm hai dạng, đó là ngầm định và tường minh như mình có nhắc đến trên đây. Việc chia thành hai dạng này mang tính đặt tên để gọi đến, với lại để cho bạn nắm được cách gọi phòng khi bạn đọc tài liệu đâu đó có dùng đến các từ này, bản chất của nó vẫn tương ứng với phân biệt theo khả năng lưu trữ trên kia.
Bài Thực Hành Số 1
Bài thực hành này sẽ giúp bạn làm quen với dạng ép kiểu ngầm định. Với cách ép kiểu này bạn chú ý là chúng ta không cần làm gì cả, cứ code đi rồi hệ thống sẽ tự thực hiện việc ép kiểu thôi. Bạn hãy nhìn code sau.
Bạn thấy với b ban đầu được khai báo là kiểu byte với giá trị 50. Sau phép gán cho biến s (giá trị là short) thì giá trị 50 trong biểu thức này được chuyển tự động thành kiểu giữ liệu short cao hơn và gán vào biến s. Tương tự cho các phép gán vào i, l, f, d.
Dòng cuối cùng in ra “What type is it?” cho thấy một dạng ép kiểu ngầm định khác của hệ thống. Khi này bạn không khái báo trước một kiểu dữ liệu nào cả mà dùng hai biến có các kiểu int và float vào biểu thức. Bạn thấy hệ thống sẽ tự ép kiểu dữ liệu nhỏ hơn về kiểu lớn hơn, cụ thể lúc này là ép int về float và thực hiện phép cộng với hai số float. Kết quả chúng ta có một kiểu float in ra màn hình.
Bạn hãy so sánh kết quả in ra như hình sau.
Nhưng nếu bạn thử trắc nghiệm bằng cách kêu hệ thống ép một kiểu dữ liệu lớn hơn về kiểu nhỏ hơn xem. Hệ thống sẽ báo lỗi ngay. Và vì vậy bạn cần phải can thiệp mục kế tiếp dưới đây.
Bài Thực Hành Số 2
Quay lại ví dụ báo lỗi trên đây, hệ thống đã từ chối tự động ép kiểu ngầm định, vậy nếu vẫn có nhu cầu muốn ép kiểu thì bạn hãy ép kiểu tường minh cho nó, lúc này bạn cần dùng đến cấu trúc ép kiểu tường minh mà mình có đưa ra ở trên kia, như vầy.
Bạn hãy nhìn vào dòng
short s = (short) i;, dòng này sẽ ép kiểu giá trị của i về short và gán cho biến s. Việc bạn chỉ định ép kiểu với (short) nhìn vào là biết ý đồ ngay, vì vậy mới có cái tên là tường minh.
Bạn hãy xem một ví dụ nữa thực tế hơn, có một số trường hợp bạn muốn bỏ dấu thập phân của một kiểu số thực, cách nhanh nhất để làm điều này là ép kiểu số thực này về một kiểu số nguyên. Cách ép kiểu này thực chất là làm mất giá trị của biến một cách… cố tình.
Kết quả của việc ép kiểu này được in ra như sau, bạn chú ý dòng in ra kiểu int nhé, mất tiêu phần thập phân rồi.
Comment Source Code
Vì kiến thức về ép kiểu ngắn quá, nên mình nói luôn về comment source code ở bài này. Hai kiến thức này không ăn nhập gì với nhau hết, nhưng nó sẽ giúp bổ trợ tốt cho bạn trong quá trình code đấy.
Sở dĩ mình dùng từ comment chứ không dịch sang tiếng Việt là vì để tránh hiểu lầm thôi, vì đa số các bạn đều biết comment nghĩa là “bình luận”, nhưng thực ra mục đích của comment trong việc code lại chính là “ghi chú” hay “chú thích”. Nó giúp bạn giải nghĩa cho một số dòng code, bạn có thể comment thoải mái ở bất kỳ đâu trong source code, trình biên dịch sẽ bỏ qua các comment này khi build, do đó sẽ không có lỗi xảy ra với chúng.
Cách Thức Comment
Bạn có 3 cách comment như sau.
. Khi trình biên dịch gặp ký hiệu //, nó sẽ bỏ qua tất cả các ký tự từ // đến ký tự cuối cùng của dòng đó. Như vậy với mỗi // sẽ giúp bạn comment được 1 dòng.
. Khi trình biên dịch gặp ký hiệu /*, nó sẽ bỏ qua tất cả các ký tự từ /* đến hết */. Cách comment này có thể giúp bạn comment được nhiều dòng cùng lúc.
. Tương tự như trên nhưng bạn chú ý có hai dấu * khi bắt đầu. Cách comment này giúp trích xuất ra các tài liệu hướng dẫn. Người ta gọi là document. Cách comment này mình đã nói rõ hơn ở bài viết này.
Bài Thực Hành Số 3
Với bài thực hành này bạn hãy tiến hành gõ comment tổng hợp “3 trong 1” sau đây, mình đã gộp cả ba cách comment được nói ở trên vào một chương trình. Thực ra thì bạn không cần phải comment quá nhiều như ví dụ, bạn nên comment khi cần thiết phải giải nghĩa cho một dòng code lạ nào đó, hoặc ghi chú tác giả dòng code đó là bạn, hoặc ngày sửa chữa dòng code này,…
Kết Luận
Bạn vừa xem qua các cách thức ép kiểu trong Java, và các cách thức comment source code. Bài học này tuy nhẹ nhưng rất quan trọng nhé, bạn sẽ sử dụng việc ép kiểu và thực hiện việc comment thường xuyên trong các project của mình.
Bài viết gốc được đăng tải tại yellowcodebooks.com
Xem thêm:
Tìm việc làm IT mọi cấp độ tại TopDev