#133 - Introducing Domain-Oriented Microservice Architecture at Uber

Aug 09, 2020

Grokking Newsletter xin mời bạn tham gia một hoạt động đặc biệt của team Grokking.

Lưu ý, đây là hoạt động có giới hạn cho các thành viên Grokking và chỉ mở rộng cho một số lượng có giới hạn các bạn độc giả của Newsletter tham gia (dưới 10 người), nên các bạn nhanh chóng đăng ký nhé!

Đây là hoạt động online nên các bạn có thể tham gia chỉ với một đường truyền internet ổn định.

-----------------------------------------------------------------

Growth Session #03: "Thảo luận về quản lý dòng tiền và lập kế hoạch tài chính cho cá nhân" với sự chia sẻ của anh Lộc Võ.

Nội dung chính: Trong buổi thảo luận này, chúng ta sẽ cùng thảo luận một vài khái niệm cơ bản như dòng tiền (cashflow), lãi suất, dòng tiền tương lai, tài sản, tiêu sản, ... và vận dụng các khái niệm này trong việc phân tích các lựa chọn quan trọng trong cuộc sống liên quan đến tài chính.

Đối tượng tham gia: các thành viên core-member của Grokking và các bạn độc giả của Grokking Newsletter.

Thời gian: 9h -> 10h30 ngày 15/08

Cách đăng ký: các bạn tham gia group Grokking Newsletter tại facebook: https://www.facebook.com/groups/300419931101401/ để nhận được hướng dẫn đăng ký nhé.

Do số lượng có hạn nên các bạn nhanh chóng đăng ký để nhận được link invite nhé.

Đối với các bạn đăng ký nhưng nếu không nhận được link invite, các bạn sẽ được ưu tiên cho các hoạt động tiếp theo của Growth Session.

Grokking Survey

Với mục đích khai thác cảm nhận và mức độ hiệu quả của các quy trình phỏng vấn, Grokking Vietnam thực hiện Bản Khảo Sát Về Quy Trình Phỏng Vấn Ứng Viên Tại Các Công Ty Công Nghệ,

Thông tin của bạn cung cấp sẽ giúp chúng tôi:

Đưa ra những thống kê tổng quát về quy trình phỏng vấn
Giúp các ứng viên hiểu rõ hơn cho các đợt phỏng vấn
Hỗ trợ các ứng viên chuẩn bị tốt hơn cho những đợt phỏng vấn tiếp theo

Đồng thời, chia sẻ của các ứng viên về quy trình phỏng tại các công ty cũng giúp công ty có những điều chỉnh phù hợp nhằm:

Tạo được ấn tượng và quan hệ tốt với ứng viên
Xây dựng quy trình phỏng vấn đánh giá đúng khả năng ứng viên
Giúp ứng viên thoải mái và thể hiện đúng khả năng trong quá trình phỏng vấn

Tham gia khảo sát: bit.ly/techinterviewsurvey2020

Thời gian thực hiện: 5 - 7 phút

Đọc Grokking Survey #1 - Chuyển việc: online.grokking.org/articles/44/grokking-survey-1-chuyen-viec

Những bài viết hay

Introducing Domain-Oriented Microservice Architecture — eng.uber.com

Tại Uber hiện nay, hệ thống của họ đang có hơn 2,200 micro services quan trọng sau thành quả của việc chuyển đổi code từ một hệ thống monolith tới một hệ thống micro service vào những năm 2012 và 2013. Việc chuyển đổi này đã giúp hệ thống của họ đạt được hiệu suất và độ tin cậy cao hơn. Tuy nhiên, việc có nhiều micro services như thế này đã làm cho hệ thống Uber ngày càng trở nên phức tạp hơn. Một ví dụ điển hình là các kỹ sư Uber đã phải làm việc với hơn 50 micro services khác nhau thông qua 12 teams để debug một lỗi trên hệ thống.

Do đó, các đội ngũ kỹ sư tại Uber đã và đang bắt đầu dời code của họ theo sang hướng Domain-Oriented Microservice Architecture (viết tắt là DOMA). Với DOMA, hệ thống của họ được phân bố và thành lập một cách hợp lý hơn để giảm độ phức tạp từ những ràng buộc của từng micro service. DOMA được thiết kế theo 4 nguyên lý chính:

Domains = thay vì dựa theo từng micro service để định hướng, họ gộp nhiều micro services lại với nhau để tạo thành một domain nhất định
Layer design = các domains sẽ được gộp lại với nhau để tạo thành một layer như là infrastructure layer, business layer, product layer, …
Gateways = giống như micro service, gateway là nơi để các domain giao tiếp với nhau
Extension architecture = do một domain đôi khi phải tích hợp với một domain khác, DOMA có 2 models chính để các domain này kết nối với nhau dễ dàng hơn: logic extension và data extension

Bài viết sau đây nói rõ hơn cách mà đội ngũ kỹ sư Uber đã sử dụng DOMA cho hệ thống của họ sau khi gặp phải khó khăn từ micro service architecture.

How We Designed for Performance & Scale — www.nginx.com

NGINX hiện tại đang là web server dẫn đầu về tốc độ xử lý requests và khả năng mở rộng hệ thống web applications tại nhiều công ty lớn. NGINX đạt được những thành quả này nhờ vào kiến trúc event-driven phức tạp của họ so với những web server khác. Hiện tại, mỗi lần bạn khởi động NGINX, hệ thống sẽ tạo ra 4 processes chính:

1) Master process = là process thực hiện những câu lệnh cần thiết để đọc NGINX configurations và tạo ra những processes phụ còn lại

2) Cache loader process = là process thực hiện việc đọc dữ liệu từ ổ đĩa cứng lên bộ nhớ để cải thiện việc đọc dữ liệu trở nên nhanh hơn

3) Cache manager process = là process được chạy định kỳ để quản lý dữ liệu caches trong phạm vi được đặt ra

4) Worker processes = là những process chính để thực hiện việc xử lý thông tin khi một request được gửi tới máy chủ của bạn. Các process này sẽ làm tất cả mọi thứ từ việc thành lập network connection tới việc viết và đọc dữ liệu để giao tiếp tới những máy chủ khác

Bài viết sau đây được các nhân viên ở NGINX viết ra để giải thích rõ hơn cách NGINX hoạt động như thế nào

Bridging batch and stream processing for the Recruiter usage statistics dashboard

Nếu bạn đã dùng LinkedIn thì chắc lâu lâu bạn cũng sẽ nhận được vài email từ một số nhà tuyển dụng trên LinkedIn. Các nhà tuyển dụng có thể làm được việc này nhờ một công cụ mà LinkedIn cung cấp, đó là InMails. Với tính năng này, nhà tuyển dụng có thể gửi email đến nhiều profile ứng viên phù hợp với nội dung được cá nhân hoá.

Một trong những tính năng quan trọng mà InMails cần có đó là Dashboard theo dõi các kết quả thống kê, bao gồm thống kê lượt phản hồi, lượt profile views của ứng viên, ...

Trong quá trình xây dựng dashboard này, đội ngũ kỹ sư ở LinkedIn đã đưa ra những yêu cầu cho mình như:

Độ "tươi" của dữ liệu (data freshness): người dùng sẽ luôn muốn thông tin mà mình nhận được là kịp thời và mới nhất có thể. Mục tiêu đề ra là dữ liệu cần được cập nhật trong dưới 10 phút. Với quy mô của LinkedIn thì để đạt được độ tươi dữ liệu thế này cho mỗi người dùng, họ sẽ cần sử dụng stream engine.
Có khả năng tính toán lại dữ liệu quá khứ: mặc dù người dùng sẽ luôn muốn dữ liệu mới nhất. Nhưng họ cũng sẽ cần xem lại dữ liệu cũ, đồng thời, hệ thống cũng sẽ cần phải có khả năng tính toán lại các kết quả thống kê trong quá khứ.
Dữ liệu nhất quán: rõ ràng, chúng ta sẽ không muốn người dùng mở dashboard ngày hôm nay thấy kết quả khác, và nhìn thấy kết quả khác cũng cho ngày hôm nay nhưng khi mở dashboard xem vào tuần sau?
Hỗ trợ cả metrics dạng "additive" và "non-additive": additive metrics là những metrics được tính toán thông qua thao tác như Sum, Max, Min, ... còn non-additive metrics là các metrics tính toán kiểu Count Distinct, Group By, ... và hệ thống cần phải hỗ trợ cả 2 kiểu metrics này.

Khi nghe cả 4 yêu cầu trên, có thể bạn có thể nghĩ đến kiến trúc Lambda, phối hợp cả stream và batch engines lại với nhau. Tuy nhiên đối với các kỹ sư ở LinkedIn, phương án này chưa phải là tốt nhất vì họ muốn có thêm một yêu cầu là "dễ bảo trì". Thật vậy, với kiến trúc Lambda, chúng ta phải bảo trì logic ở cả 2 phần stream và batch độc lập với nhau, dẫn đến khi điều chỉnh business, logic phải sửa ở nhiều nơi.

Thế để đáp ứng cả 5 yêu cầu được đề ra, đội ngũ LinkedIn đã xây dựng kiến trúc như thế nào?

Góc Database

Google là một trong những công ty Internet lớn nhất hiện nay, vì vậy họ thường phải xử lý một lượng lớn dữ liệu được phân tán trên nhiều nơi trên thế giới. Để xử lý vấn đề đó, Google có nhiều nền tảng khác nhau để tập trung vào từng bài toán cụ thể của truy vấn dữ liệu. Ý tưởng F1 Engine được ra đời với tham vọng tập trung tất cả những phương pháp truy vấn phân tán ấy vào chung một hệ thống duy nhất.

Là nền tảng độc lập (standalone) xử lý query SQL giữa các nền tảng lưu trữ và xử lý dữ liệu lớn khác nhau, bao gồm OLAP DB, Key-Value DB (BigTable), OLTP DB (Spanner) và ETL pipeline.
Tự động xử lý phân tách query để xử lý độc lập (tách rời với storage layer) và hiệu quả nhất cho những dữ liệu phân tán ở nhiều Data Center hay Data Source => Giải pháp “one-size-fit-all” cho xử lý dữ liệu lớn trong các hệ thống distributed system.

Hiện nay F1 Engine đang là một lựa chọn được sử dụng trong các dự án Advertising, Shopping, Analytics, và Payments của Google.

Design goal của Google F1 Engine:

Data Fragmentation: Tập trung giải quyết vấn đề của việc dữ liệu phân tán trên nhiều data center và data source, đảm bảo consistency và giảm thiểu độ trễ và chi phí.
Datacenter Architecture: Được thiết kế để chạy trên nhiều cụm datacenter với các thành phần hoạt động độc lập với nhau.
Scalability: phân tích để lựa chọn cơ chế thực thi tốt nhất cho query, giảm thiểu tối đa latencies nhờ vào cơ chế tính toán song song.
Extensibility: hỗ trợ user-defined functions (UDP), user-defined aggregate functions (UDAs) và Table-Valued functions (TVFs) để đáp ứng nhu cầu xử lý dữ liệu đa dạng.
Query Language: F1 sử dụng chuẩn SQL-2011, hỗ trợ đầy đủ left/right/full outer joins, aggregation, table và expression subqueries, WITH clauses, cũng như analytic window functions (và nhiều datatype khác nữa).
F1 Server và F1 Worker đều là stateless, không chứa dữ liệu nhằm dễ dàng scale và giảm cost.

Mời bạn cùng đọc thêm nội dung paper này để hiểu thêm về F1: link

Code & Tools

Có thể bạn chưa biết

content-visibility: the new CSS property that boosts your rendering performance — web.dev

content-visibility là một thuộc tính CSS mới sắp được các trình duyệt hỗ trợ để tăng tốc độ tải trang bằng cách bỏ qua việc render các thành phần offscreen

Tin tức khác

Intel bị hack, 20 GB dữ liệu bị rò rỉ | WhiteHat.vn — whitehat.vn

Mới đây, một tin tặc đã chia sẻ liên kết tải về 20 GB dữ liệu bí mật liên quan đến kỹ thuật chip của Intel. Theo Appleinsider, những nội dung này có chứa thông tin BIOS và mã nguồn liên quan đến công nghệ độc quyền của Intel, có thể bị lợi dụng để tạo ra phần mềm độc hại.

Quotes

Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday’s code

- Dan Salomon