#131 - Multi-Runtime Microservices Architecture
#131 - Multi-Runtime Microservices Architecture
Với sự xuất hiện của ca bệnh mới "Bệnh nhân 416", và những dấu hiệu của Covid-19 lây nhiễm cộng đồng lần đầu sau 99 ngày, mong các độc giả hãy cẩn thận hơn trong thời gian tới.
Sử dụng khẩu trang nơi công cộng, hạn chế đi ra bên ngoài và tiếp xúc nhiều người.
BBT Grokking Newsletter xin kính chúc các quý độc giả khỏe mạnh, đặc biệt là các bạn độc giả ở thành phố Đà Nẵng.
------------------------------------------------------------------------------------------------
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ệ.
Mời các bạn dành 5 phút để thực hiện bản khảo sát tại đây nhé: bit.ly/techinterviewsurvey2020
Chúng tôi sẽ gửi tới quý bạn đọc kết quả phân tích từ khảo sát để 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
Sự kiện nổi bật
Grokking Webinar #06: Working at Tech Startups in the US
Trong tháng 8 này, Grokking hân hạnh tổ chức Grokking Webinar #06: Working at Tech Startups in the US để các bạn có thể tìm hiểu về môi trường, văn hóa tại các công ty khởi nghiệp công nghệ ở Mỹ qua những chia sẻ của những anh chị người Việt đang sống và làm việc tại đây.
Trong webinar lần này, chúng ta sẽ lắng nghe những chia sẻ về:
- Hành trình đến và làm việc tại Mỹ
- Môi trường làm việc của một kỹ sư ở tech startups
- Lựa chọn một công ty để làm việc và ưu nhược điểm khi làm ở công ty khởi nghiệp
- Điều tạo nên thành công trong vai trò kỹ sư ở một công ty startup
________
Agenda: (02/08/2020 - Giờ Việt Nam)
- 20:00 - 21:30: Working at Tech Startups in the US
- 21:30 - 22:00: Q&A
________
1./ Link đăng ký tham gia: bit.ly/GrokkingWebinar06
2./ Click Going/Interested để nhận thông tin cập nhật mới: facebook.com/events/289267535611327/
Những bài viết hay
Multi-Runtime Microservices Architecture
Chúng ta đã khá quen với khái niệm microservice, vậy kiến trúc Multi-Runtime Microservice có nghĩa là gì?
Trong kiến trúc phần mềm, bạn có những logic nghiệp vụ (business logic, hay còn gọi là micrologic) tạo thành cốt lõi của các ứng dụng, và thành phần khác cung cấp các tính năng phân tán, gọi là Mecha. Micrologic kết hợp với các mecha tạo thành multi-runtime microservice.
Có thể hiểu, đây là một mô hình có hai thành phần, tương tự như kiến trúc client-server. Điểm khác biệt ở chỗ, các component được đặt trên cùng một máy chủ. Cả hai thành phần có tầm quan trọng như nhau. Một thành phần là Micrologic, nó giữ tối thiểu các business logic đã được loại ra khỏi các hệ thống phân tán. Thành phần khác là Mecha, cung cấp các tính năng của một hệ thống phân tán.
Chúng ta có thể triển khai mô hình theo hướng 1-1, một Mecha và một Micrologic (gọi là mô hình sidecar). Hoặc 1-n, một Mecha được chia sẻ với nhiều Micrologic. Mô hình 1-1 sẽ thích hợp trên các môi trường như Kubernetes. Mô hình 1-n sẽ thích hợp với edge deployment.
A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
Khi chúng ta chạy một chương trình, nó sẽ được interpreted hoặc compiled theo một cách nào đó. Một compiler/interpreter thường được xem như là những bản implementation của một ngôn ngữ (ngôn ngữ chỉ là đặc tả), và một ngôn ngữ có thể có nhiều implementation. Ví dụ như: "Python là một ngôn ngữ interpreted", điều này thật ra chỉ có nghĩa rằng "standard/default implementation" của Python là một interpreter (CPython), và dĩ nhiên sẽ khả thi để implement một bản compiled Python.
JIT compiler không biên dịch tất cả code thành mã máy lúc build (Ahead-Of-Time) mà biên dịch code thành mã máy lúc runtime (Just-In-Time). Điều này cho phép JIT sự linh hoạt để tối ưu hoá các tính năng của các dynamic languages, ngoài ra JIT còn có thể tận dụng các thông tin chỉ có ở lúc runtime để tối ưu hoá hiệu năng của chương trình (realtime profiling & adaptive optimization).
Bài viết sẽ chia sẻ về cách một JIT Compiler hoạt động, cách nó tối ưu chương trình ở run-time cũng như lí giải vì sao các chương trình được biên dịch với JIT compiler sau khi chạy đều mất một lúc để "làm nóng" trước khi có thể đạt được hiệu năng tối đa.
SSH Agent là một phần của OpenSSH, hầu như các lập tình viên chúng ta đều làm việc với nó mỗi ngày. ssh-agent là một key-manager cho SSH, nó giúp bạn giữ keys và certificates trong memory, unencrypted và sẵn sàng để sử dụng mỗi khi kết nối tới một ssh host, tiết kiệm cho bạn thời gian vì không phải gõ passphrase mỗi lần mở connect ssh tới một server. SSH Agent thường chạy trong nền, và nó khởi động sau khi bạn gõ ssh lần đầu (sau mỗi lần reboot).
Bài viết sẽ giúp bạn có một cái nhìn tổng quát về hơn về SSH Agent, cách nó hoạt động để giữ keys của bạn an toàn, cũng như mô tả về agent forwarding qua đó giúp bạn giảm thiểu rủi ro khi cần sử dụng nó.
Góc Databases
Using Kafka to throttle QPS on MySQL shards in bulk write APIs
Tại Pinterest, hầu hết các chức năng chỉ viết (write) trên một object nhất định trong MySQL như là tạo một cái board hoặc lưu một hình ảnh. Tuy nhiên, cho những chức năng cần phải write cho nhiều objects cùng một lúc như là xóa hình ảnh từ những spam users hoặc là backfill một field mới cho nhiều cụm dữ liệu, việc thi hành những lệnh writes này sẽ được đẩy vào một hệ thống viết không đồng bộ hóa (asynchronous bulk write process) để hạn chế việc quá tải trên hệ thống MySQL.
Hệ thống viết này được chia làm 3 thành phần chính:
Bulk write APIs and Proxy: để thuận tiện cho clients dùng hệ thống này, đội ngũ kỹ sư ở Pinterest đã tạo ra một API interface nhất định cho việc tạo những lệnh viết. Sau đó, những requests này sẽ được proxy ủy quyền tới batching module phù hợp tùy vào mỗi loại objects cần được xử lý
Batching module: ở công đoạn này, các requests sẽ được phân chia thành từng nhóm nhỏ cho mỗi shard ở MySQL. Sau đó, nó sẽ được phân chia nhỏ nữa tùy theo write operations cần được thực hiện trên shard đó
Rate limiter with Kafka: để tránh việc MySQL shard bị quá tải, đội ngũ kỹ sư ở Pinterest đã tận dụng Kafka trong công đoạn này. Sau khi requests được phân chia ra thành từng write operations cho mỗi shard, các operations sẽ được đẩy vô Kafka rồi để được consume từ những hệ thống viết ở một mức nhất định cho mỗi shard
Do Kafka có thể đảm nhận được một mức QPS (queries per second) cao và có thể lưu trữ messages một cách đáng tin cậy, hệ thống asynchronous bulk write process của Pinterest đã giúp tăng hiệu suất viết nhanh hơn tới 4 lần với success rate đến gần 99% thay vì 70% trước đó. Để hiểu rõ hơn Pinterest đã tận dụng Kafka như thế nào, mời bạn đọc bài viết sau đây từ Qi Li, một software engineer từ Pinterest Real-time Analytics team.
Code & Tools
Có thể bạn chưa biết
Có bao giờ bạn tự hỏi, tại sao lại là 192.168.1.1 mà không phải là một địa chỉ IP khác? Địa chỉ này được tạo ra khi nào, do ai và vì sao? Để làm rõ những câu hỏi này, mời các bạn cùng đọc bài viết sau.