#195 - Giới thiệu về Domain-Oriented Microservice Architecture

Nov 01, 2021

Trong số này, chúng ta sẽ cùng tìm hiểu về: Hệ thống xử lý dữ liệu tại eBay; Kiến trúc microservice Domain-Oriented; A/B testing tại Netflix; Những khái niệm cơ bản về giấy phép mã nguồn mở; Kiến trúc của C-Store; Thử thách lập trình tuần này Clone Graph, và cuối cùng là cùng nghe bài tech talk của Josh Evans là Director of Operations Engineering tại Netflix về các chủ đề xoay quanh microservice.

Chúc các bạn một tuần mới làm việc nhiều niềm vui và đừng quên đón đọc các bài viết hay tại Grokking Newsletter nhé.

Những bài viết hay

Online Analytical Processing Journey with ClickHouse on Kubernetes — tech.ebayinc.com

Để xây dựng một centralized platform, nhằm quản lý các dữ kiện như là logs, metrics, traces hay events là thử thách rất thú vị của các công ty lớn hiện nay, nhất là bối cảnh khi mà các công ty ngày càng tận dụng tối đa về sức mạnh của dữ liệu mang lại.

Ở eBay, các kỹ sư phần mềm đã xây dựng hệ thống có tên gọi là sherlock.io, với khả năng xử lý khoảng 8 triệu metrics/giây, 1 tỷ events/phút và nhiều petabyte logs/ngày. Điều này, giúp họ rất nhiều trong việc nhanh chóng phát hiện các thay đổi trong cơ sở hạ tầng và xử lý các lỗi. Bên cạnh đó, việc xây dựng được một hệ thống như vậy sẽ là nền tảng để xây dựng thêm những data intensive applications. Hệ thống sherlock.io này tất nhiên là cũng có những đặc tính của các hệ thống lớn khác, như là high availability và immense resilience.

Trong bài biết, tác giả thể hiện được hành trình về việc xây dựng sherlock.io, như là việc sử dụng Kubernetes để migrate events theo từng use-cases cụ thể từ OLAP sang ClickHouse. Bài viết cũng làm rõ được vấn đề mà các kỹ sư tại eBay gặp phải trước khi xây dựng một hệ thống này, cách quản lý ClickHouse trên Kubernetes và cách triển khai hệ thống sherlock.io.

Introducing Domain-Oriented Microservice Architecture

Gần đây đã có nhiều cuộc thảo luận xung quanh những mặt trái của kiến trúc SOA và kiến trúc microservice nói riêng. Trong khi chỉ một vài năm trước, nhiều người đã sẵn sàng chấp nhận các kiến trúc microservice do nhiều lợi ích mà chúng mang lại như tính linh hoạt trong hình thức triển khai độc lập, quyền sở hữu rõ ràng, cải thiện độ ổn định của hệ thống và tách biệt các mối quan tâm tốt hơn, trong những năm gần đây mọi người đã bắt đầu chê bai các microservices vì chúng có xu hướng tăng độ phức tạp lên rất nhiều, đôi khi làm cho cả những tính năng đơn giản (trivial) cũng khó xây dựng.

Với khoảng 2200 microservice quan trọng, Uber đã trải nghiệm những đánh đổi này ngay từ đầu, cố gắng giảm độ phức tạp của microservice trong khi vẫn duy trì những lợi ích của kiến trúc đó. Họ phát triển một cách tiếp cận gọi là "Kiến trúc microservice hướng miền" (Domain-Oriented Microservice Architecture - DOMA), với mục tiêu là cung cấp một hướng đi cho các tổ chức muốn giảm độ phức tạp của hệ thống tổng thể trong khi vẫn duy trì tính linh hoạt liên quan đến kiến trúc microservice. DOMA được đúc kết dựa trên các quy tắc và pattern tồn tại từ lâu về cách tổ chức code như Domain-driven Design, Clean Architecture, Service-Oriented Architecture, thiết kế hướng đối tượng và hướng interface. Các quy tắc cốt lõi trong DOMA có thể được tóm tắt như sau:

1. Thay vì định hướng xung quanh microservice nhỏ đơn lẻ, đội ngũ định hướng xung quanh các tập hợp microservice có liên quan với nhau, và gọi chúng là domain (miền)

2. Đội ngũ tiếp tục gộp các domain lại và gọi là layer. Các layer quy định sẵn các dependency mà các microservice bên trong được phép đảm nhận.

3. Đội ngũ cung cấp interface rõ ràng cho các domain và là điểm truy cập duy nhất giữa chúng với nhau, gọi là gateway.

4. Cuối cùng, đội ngũ thiết lập rằng giữa các domain phải tách biệt logic với nhau. Nếu các team thêm logic trong domain của các team khác thì phải thêm bằng các extension (điểm mở rộng) được định nghĩa rõ ràng từ đầu.

Bằng cách cung cấp một kiến trúc có hệ thống, các domain gateway và các điểm exstension được xác định trước, DOMA có mục đích chuyển đổi các kiến trúc microservice từ một thứ phức tạp thành một thứ dễ hiểu: một tập hợp có cấu trúc gồm các thành phần linh hoạt, có thể tái sử dụng và phân layer.

Bài viết gốc đào sâu về cách Uber thực thi DOMA, các lợi ích đã gặp, và những lời khuyên thực tế cho các công ty startup, vừa, và lớn nếu muốn áp dụng phương pháp này, mời các bạn đọc để hiểu chi tiết hơn nhé.

What is an A/B Test?

Kiểm thử A/B là một phương pháp kiểm thử có kiểm soát đơn giản. Giả sử rằng Netflix muốn kiểm tra xem việc đảo ngược các box-art trên giao diện TV là tốt hay không.

Để thực hiện kiểm thử, đầu tiên họ chọn ra một tập người dùng bằng phương pháp lấy mẫu ngẫu nhiên đơn. Sau đó tiếp tục chia tập người dùng này làm 2 nhóm ngẫu nhiên A và B. Nhóm A được tiếp tục sử dụng giao diện hiện có, còn nhóm B được sử dụng giao diện mới.

Tiếp theo, họ sẽ thu thập và phân tích dữ liệu về một số thông số đo lường (metric) nhất định. Việc lựa chọn các thông số này là rất quan trọng. Ví dụ với thông số "tỷ lệ người click", nhiều người sẽ lầm tưởng rằng việc tỷ lệ người click cao có nghĩa là việc thay đổi UI đem lại lợi ích tốt, tuy nhiên thực tế người dùng có thể click vào nhiều hơn chỉ vì việc đảo ngược các boxart khiến họ khó đọc nội dung và cần phải click vào để xem nội dung chi tiết chứ không phải vì thực sự muốn xem một bộ phim.

Kiểm thử A/B, giúp xác định mối quan hệ nhân quả về việc có hay không nên thực hiện các thay đổi đối với sản phẩm. Trong bài viết, tác giả đã trình bày 3 nội dung chính:

- Cơ bản về kiểm thử A/B

- Tại sao việc thực hiện kiểm thử A/B lại quan trong hơn so với việc kiểm thử bằng cách cho toàn bộ người dùng sử dụng chức năng mới và so sánh kết quả trước/sau khi thay đổi

- Cách họ biến một ý tưởng thành một giả thuyết có thể kiểm thử được.

Mời các bạn đọc bài viết chi tiết để hiểu hơn cách Netflix đã làm thế nào để đem đến cho người dùng các chức năng tối ưu nhất bằng kiểm thử A/B.

Open Source Licenses Explained

Chúng ta thường nghe nhiều đến từ khóa Giấy phép mã nguồn mở (Open Source License) nhưng thường ít khi tìm hiểu cụ thể về nó. Vậy thực sự Giấy phép mã nguồn mở là gì?

Giải thích một cách đơn giản thì Giấy phép mã nguồn mở là một hợp đồng hợp pháp ràng buộc giữa tác giả và người sử dụng mã nguồn (hoặc một phần của mã nguồn), đảm bảo rằng mã nguồn sẽ được sử dụng trong các ứng dụng thương mại trong một điều kiện cụ thể nhất định. Nếu không có giấy phép mã nguồn mở, mã nguồn sẽ không được phép sử dụng bởi người khác, kể cả khi nó được public trên GitHub.

Mỗi giấy phép nguồn mở nêu rõ người dùng được phép làm gì, nghĩa vụ của họ và những gì họ không được làm theo các điều khoản và điều kiện nhất định. Điều này nghe có vẻ khá dễ hiểu, nhưng hiện có hơn 200 giấy phép nguồn mở, tùy thuộc về mức độ phức tạp và yêu cầu, cần lựa chọn giấy phép phù hợp để đảm bảo rằng mã nguồn được sử dụng một cách hợp lệ.

Có 2 loại Giấy phép mã nguồn mở chính:

- Copyleft: (một cách chơi chữ của từ copyright) nói một cách ngắn gọn, khi một người sử dụng mã nguồn mở với loại giấy phép này, thì họ cũng phải mở mã của mình để người khác sử dụng. Một số giấy phép mã nguồn mở thuộc loại này bao gồm GNU GPL, Eclipse Public License, CDDL...

- Permissive: là một loại giấy phép mã nguồn mở không thuộc nhóm copyleft. Loại giấy phép này đặt ra những hạn chế tối thiểu về cách chúng ta có thể sử dụng các thành phần mã nguồn mở, cho phép sử dụng nó trong các mã nguồn đóng (mã nguồn được viết dựa trên các mã nguồn mở) và hầu như không yêu cầu gì liên quan đến các nghĩa vụ trong tương lai. Một số giấy phép mã nguồn mở loại này bao gồm Apache, MIT, BSD,...

Bài viết cũng trình bày sơ lược về đặc điểm của một số loại giấy phép mã nguồn mở phổ biến như GNU GPL, Apache, MIT,... Mời bạn đọc bài viết gốc để hiểu rõ hơn về giấy phép mã nguồn mở.

Góc Database

C-Store: A Column-oriented DBMS

Hiện nay các databases thuộc nhóm column-store đã không còn quá xa lạ với chúng ta. Các databases này đặc biệt phù hợp và được ứng dụng rộng rãi trong các bài toán về analytical processing. Ngược dòng thời gian khoảng gần hai chục năm về trước, mặc dù ý tưởng về việc tổ chức dữ liệu theo column-based thay vì row-based đã xuất hiện từ sớm nhưng lại rất ít nghiên cứu trong cộng đồng về chủ đề này. C-Store được xem là bản “research prototype” đầu tiên hiện thực hoá một column-store. Tác giả của C-Store không phải ai quá xa lạ, là Michael Stonebraker, cha đẻ của PostgreSQL. Lấy cơ sở nghiên cứu từ C-Store, sau này hàng loạt các databases khác ra đời, từ open source cho tới thương mại, hình thành làn sóng phát triển và áp dụng column-oriented storage vào thực tế như đã thấy

Kiến trúc high-level của C-Store gồm 2 thành phần chính, Writeable-store (WS) và Read-optimized store (RS). RS, như chính cái tên của nó, được tối ưu cho quá trình đọc dữ liệu. RS tổ chức lưu dữ liệu trên ổ đĩa theo nhiều file, mỗi file chứa chuỗi dữ liệu của duy nhất một cột cụ thể. RS định nghĩa 4 encoding-schemas khác nhau để nén (compress) dữ liệu trên mỗi file tuỳ theo đặc điểm dữ liệu. WS thì chứa dữ liệu uncompressed và tối ưu cho quá trình ghi. Định kỳ, dữ liệu từ WS sẽ được đồng bộ (nén, sắp xếp, tổ chức lại dữ liệu trên ổ đĩa) sang RS thông qua tiến trình chạy ngầm gọi là “tuple mover”.

Ngoài ý tưởng chính về cách tổ chức dữ liệu theo dạng cột, C-Store còn giải quyết các bài toán của một DBMS như:

- Hỗ trợ transaction.

- Hỗ trợ isolation ở mức Snapshot-isolation.

- Chiến lược query execution và query optimization cho column store.

Bạn đọc có thể tìm hiểu thêm về C-Store qua paper gốc được xuất bản năm 2005.

Góc Lập Trình

Đề tuần này:

https://leetcode.com/problems/clone-graph/

Lời giải tuần trước:

Đề bài: https://leetcode.com/problems/time-needed-to-inform-all-employees/

Lời giải

Đề bài đã cho ta gợi ý về cấu trúc dữ liệu để lưu trữ tổ chức của công ty, ta có thể sử dụng n-ary tree để giải bài này. Một nút của cây chính là ID của nhân viên, quan hệ cha con giữa các nút thể hiện mối quan hệ quản lý - cấp dưới (manager - subordinate). Sau khi mô hình hoá tổ chức công ty dưới dạng cây, ta có thể dễ dàng nhận thấy thời gian cần thiết để một quản lý managerID i thông báo cho toàn bộ cấp dưới là max(informTime[subordinate j]) với tất cả subordinate j là cấp dưới của managerID i.

Vì vậy ta có giải thuật đệ quy như sau: https://pastebin.com/qWxP6tCh

Tech Talks

Mastering Chaos - A Netflix Guide to Microservices

Josh Evans là Director of Operations Engineering tại Netflix, có kinh nghiệm trong lĩnh vực ecommerce, testing và operation. Trong ba năm từ 2014, ông đã lãnh đạo một tổ chức tạo ra, tích hợp và truyền bá các giải pháp và kỹ thuật thực tiễn đã được chứng minh như continuous delivery, operation insigh theo thời gian thực và chaos engineering để đạt được nhiều thành tựu xuất sắc về operation ở quy mô lớn

Trong buổi chia sẻ, Josh Evans nói về thế giới hỗn loạn và sôi động của microservices tại Netflix. Anh ấy bắt đầu với những điều cơ bản - cấu trúc của một microservice, những thách thức và lợi ích xung quanh các hệ thống phân tán. Từ nền tảng đó, anh ấy xây dựng và khám phá các phương pháp liên quan đến kiến trúc, operation và văn hoá trên con đường hướng đến sự thành thạo và làm chủ microservice

Code & Tools

Pre-commit: A framework for managing and maintaining multi-language pre-commit hooks.
NFS Ganesha server and external provisioner: is an out-of-tree dynamic provisioner for Kubernetes 1.14+. You can use it to quickly & easily deploy shared storage that works almost anywhere. Or it can help you write your own out-of-tree dynamic provisioner by serving as an example implementation of the requirements detailed in the proposal.

Quotes

“That's the thing about people who think they hate computers. What they really hate is lousy programmers.”

― Larry Niven