#214 - Các phương pháp Migration điển hình
#214 - Các phương pháp Migration điển hình
Chào bạn đọc,
Trong số này, chúng ta tìm hiểu về:
Các phương án migration tiêu biểu;
Tầm quan trọng của Domain-Driven Design (DDD);
15 điều cần nhớ để viết API tốt hơn;
Cách Cockroach xây dựng serverless database;
Lời giải đề bài tuần trước: Reverse Integer;
Đề bài tuần này: Maximum Frequency Stack;
Ngoài ra, Grokking xin chia sẻ về trường hợp của bạn Phạm Hoàng Vũ, một kỹ sư CNTT không may gặp nhiều khó khăn trong cuộc sống. Grokking mong bạn Vũ sẽ nhận được sự hỗ trợ của các bạn đọc gần xa.
Những bài viết hay
Migrations Done Well: Typical Migration Approaches — blog.pragmaticengineer.com
Khi các công ty phát triển, hệ thống và phương pháp tiếp cận cũ có thể sẽ không còn phù hợp nữa, cần phải chuyển sang hệ thống hoặc phương pháp tiếp cận mới. Đây cũng chính là lúc xảy ra nhiều câu chuyện thú vị mà tác giả sẽ kể lại trong bài viết:
1. Ngân hàng TSB tại Anh đã thực hiện migration vào năm 2018 khi đang có 5 triệu khách hàng, và migration xong thì 2 triệu khách hàng không thể rút tiền mặt từ tài khoản. Quá trình khắc phục kéo dài suốt nhiều tháng, thậm chí 5 tháng sau đó vẫn còn một số khách hàng bị khóa tài khoản và CEO phải nghỉ việc.
Mặc dù nguyên nhân vẫn chưa rõ ràng, nhưng có vẻ như sự cố này xảy ra do nhiều yếu tố. Ngân hàng TSB đã phải trả hơn 480 triệu đô la, chưa kể các thiệt hại về uy tín.
2. Vào năm 2016, tại Uber có hai hệ thống thanh toán: Một hệ thống để xử lý các khoản thanh toán từ khách hàng, hệ thống còn lại xử lý thanh toán cho đối tác. Họ đã bắt đầu xây dựng một hệ thống thanh toán mới duy nhất để thay thế cho hai hệ thống độc lập này. Vào năm 2017, họ chuyển sang hệ thống mới có tên là Gulfstream. Việc chuyển đổi này chỉ diễn ra bên trong, từ bên ngoài không nhìn thấy được, và quá trình migration được thực hiện với zero downtime.
Tại thời điểm đó, hầu như không xảy ra sự cố nào nghiêm trọng. Tuy nhiên những ảnh hưởng của việc migration này kéo dài tới nhiều năm sau, và gây ra nhiều vấn đề nhức nhối. Mặc dù Gulfstream là hệ thống thanh toán chính, nhưng vẫn còn rất nhiều hệ thống nội bộ còn đang phụ thuộc vào hai hệ thống thanh toán cũ. Tiêu biểu, vào năm 2018 có thời điểm các tài xế Uber không thể dùng Instant Pay trong suốt vài ngày.
Trong phần tiếp theo, tác giả định nghĩa các phương pháp migration điển hình như: Service replacement, Service integration, Service extraction, Code migration, Data migration, Infrastructure migration.
Mời các bạn cùng đọc.
(by lpv)
The Importance of Domain Driven Design — simpleprogrammer.com
Chúng ta thường rất rất hào hứng tham gia vào một dự án, bắt đầu code và phát triển phần mềm. Tuy nhiên, ta không thể xây dựng phần mềm tốt mà không hiểu nhu cầu của khách hàng trước. Domain Driven Design (DDD) là một phương pháp thiết kế, nhấn mạnh vào việc phải hiểu được khách hàng muốn gì, và yêu cầu làm việc với khách hàng trong dự án như một người đồng hành. Mục tiêu cuối cùng không chỉ là tạo ra phần mềm, mà phần mềm đó phải thật sự giải quyết được vấn đề đã đặt ra.
DDD được tạo ra để đưa domain (nghiệp vụ) trở thành trọng tâm của thiết kế. Được giới thiệu bởi Eric Evans qua ấn phẩm "Domain-Driven Design: Tackling Complexity in the Heart of Software" (2004), DDD có một số thuật ngữ như:
Context (ngữ cảnh): Phát biểu về một model chỉ có thể được hiểu khi có ngữ cảnh đầy đủ.
Model (mô hình): một hệ thống các trừu tượng (abstraction) mô tả các khía cạnh của một nghiệp vụ, và có thể được sử dụng để giải quyết các vấn đề liên quan đến nghiệp vụ đó.
Ubiquitous Language (ngôn ngữ phổ biến): Một ngôn ngữ được cấu trúc quanh mô hình nghiệp vụ, và được tất cả các thành viên trong nhóm phát triển sử dụng như một công cụ giao tiếp giữa yếu tố kỹ thuật ( software) và nghiệp vụ thực tế.
Bounded Context (ngữ cảnh có ranh giới): Mô tả một ranh giới (thường là một hệ thống con hoặc công việc của một nhóm cụ thể) mà trong đó mô hình được xác định và áp dụng.
Mời bạn đọc tham khảo bài viết gốc để tìm hiểu thêm về DDD.
(by ndaadn)
Có lẽ tất cả các kĩ sư phần mềm đều không còn lạ lẫm gì với API. Nhưng không phải ai cũng có thể thiết kế được một API tốt, vì việc này không đơn giản như chúng ta nghĩ. Một API tốt đòi hỏi nhiều yếu tố, như bảo mật cơ bản, phương thức HTTP phù hợp, tiến hành xác thực (authentication), quyết định request/response nào chúng ta nên accept/return...
Trong bài viết này, tác giả chia sẻ 15 gợi ý giúp chúng ta viết được API tốt hơn:
Nhất quán với cấu trúc endpoint;
Sử dụng chuẩn ISO 8601 UTC cho các giá trị thời gian;
Cho phép unauthorized requests với public endpoint;
Cung cấp health check endpoint;
Version API;
Hỗ trợ API key authentication;
Sử dụng HTTP status code phù hợp;
Sử dụng phương thức HTTP phù hợp;
Sử dụng các tên đơn giản, tường minh dễ hiểu (self-explanatory);
Sử dụng các phản hồi lỗi được chuẩn hóa;
Return resources được tạo ra bởi POST API;
Sử dụng PATCH thay vì PUT;
Khi thiết kế endpoint, đặt tên field và quyết định chấp nhận request và response nào, cần phải cụ thể một cách tối đa;
Sử dụng pagination;
Cho phép user tải dữ liệu liên quan bằng cách sử dụng tham số truy vấn expand.
(by MS)
Góc Database
Serverless computing là loại hình kiến trúc đang dần được phổ biến gần đây vì dễ dùng và dễ triển khai, đặc biệt là cho các ứng dụng đơn giản hoặc MVP. Khi sử dụng các dịch vụ Google Cloud Function hay AWS Lambda, chỉ với vài thao tác đơn giản trong 15-20 phút, bạn đã có ngay một API với khả năng tự động scale, tự quản lý bộ nhớ, tự động restart....
Bên cạnh serverless computing, một xu hướng cũng đang bắt đầu phổ biến gần đây là serverless database với các công nghệ điển hình như DynamoDB, Azure Cosmos DB, Google Cloud Datastore, Aurora... Tương tự như serverless computing, sử dụng serverless database sẽ giúp chúng ta tiết kiệm được thời gian và công sức quản trị hệ thống database.
Những dịch vụ serverless database đó được xây dựng như thế nào? Làm thế nào mà họ có thể scale dữ liệu nhanh và hiệu quả như vậy?
Trường hợp của team Cockroach, họ đã thay đổi một số điểm quan trọng trong kiến trúc của cluster CockroachDB, biến nó thành một serverless database service. Tiêu biểu nhất, team Cockroach đã tách tầng query (SQL) và storage (Key-value) ra thành các layer khác nhau và deploy trên các instance khác nhau.
Tầng query sẽ tập trung vào việc xử lý câu truy vấn, transaction... và sẽ được phân chia theo tenant.
Tầng storage sẽ tập trung vào việc đọc, ghi, partition dữ liệu.
Các instance của cả hai tầng query và storage đều được deploy trên Kubernetes, giúp scale dễ dàng hơn.
Mời các bạn cùng đọc bài blog được đăng trên CockroachLabs blog để hiểu thêm về những điều chỉnh này.
(by n^4)
Góc Lập Trình
Đề ra tuần này: Reverse Integer
Lời giải đề bài tuần trước:
Đề bài: Maximum Frequency Stack
Đề bài yêu cầu thiết kế một dạng cấu trúc dữ liệu tương tự như một ngăn xếp, trong đó thao tác pop (lấy dữ liệu ra khỏi ngăn xếp) sẽ lấy dữ liệu theo thứ tự từ phần tử có số lần xuất hiện lớn nhất trong ngăn xếp. Trong trường hợp có 2 phần tử có cùng số lần xuất hiện, thì phần tử được đưa vào ngăn xếp trước sẽ được lấy ra.
Để giải quyết, đầu tiên, ta thử quan sát ví dụ đề bài đưa ra.
Push: 5, 7, 5, 7, 4, 5
Pop 4 lần → 5, 7, 4, 5
Vì đề bài yêu cầu lấy dữ liệu theo thứ tự từ phần tử có số lần xuất hiện lớn nhất, ta cần tìm một cách để sắp xếp lại dữ liệu được đưa vào ngăn xếp theo số lần xuất hiện của nó. Thử sắp xếp như sau:
Push(5): → 1: 5
Giải thích: các phần tử đã xuất hiện 1 lần: 5
Push(7): → 1: 5, 7
Giải thích: các phần tử đã xuất hiện 1 lần: 5, 7 (Lưu ý: thứ tự này là thứ tự 2 phần tử được đưa vào ngăn xếp)
Push(5): → 1: 5 7 và 2: 5
Giải thích: các phần tử đã xuất hiện 1 lần: 5, 7; 2 lần: 5
Push(7): → 1: 5 7 và 2: 5 7
Push(4): → 1: 5 7 4 và 2: 5 7
Push(5): → 1: 5 7 4 và 2: 5 7 và 3: 5
Từ đó, ta thấy thứ tự khi thực hiện pop sẽ là thứ tự từ dưới lên, từ phải qua trái theo cách tổ chức dữ liệu như trên. Ta có thể sử dụng cấu trúc dữ liệu Map<Integer, Stack> để lưu trữ được cách sắp xếp dữ liệu như trên. Đồng thời sử dụng 1 biến max và 1 Map<Integer, Integer> lưu trữ số lần xuất hiện của mỗi phần tử, từ đó có thể xác định được phần tử có số lần xuất hiện lớn nhất trong ngăn xếp với thời gian O(1), dẫn đến thao tác push và pop đều có thể thực hiện với thời gian O(1).
Mời bạn đọc tham khảo một cách cài đặt bằng Java như sau.
https://pastebin.com/6UBF41fdi
(by ndaadn)
Code & Tools
Apache YuniKorn: Công cụ hỗ trợ schedule resource để chạy Big Data và ML trên K8S
DataHub: Nền tảng metadata cho data stack hiện đại
Chia sẻ
Mẹ ung thư bán hàng rong góp tiền mong hiến thận cứu con là kỹ sư IT — dantri.com.vn
Bạn Phạm Hoàng Vũ (SN 1988) là kỹ sư CNTT tại Việt Nam, không may bị suy thận mãn tính từ năm 2016 nên không thể tiếp tục làm việc như trước. Mẹ của Vũ cũng đã được chẩn đoán mắc ung thư nên chưa thể hiến tạng cứu con. Hai mẹ con Vũ đang trải qua giai đoạn rất khó khăn, vừa chiến đấu với căn bệnh, vừa cố gắng trang trải cuộc sống.
Grokking chia sẻ bài viết nhằm lan toả thông tin đến bạn đọc yêu mến công nghệ, và mong gia đình Vũ nhận được sự hỗ trợ của cộng đồng. Mời bạn xem thông tin chi tiết về trường hợp đặc biệt này và tài khoản tiếp nhận hỗ trợ trong link dưới đây.
Góc Sponsors
Fossil Việt Nam, tiền thân là Misfit, giữ vị thế là Trung tâm Nghiên cứu và Phát triển Công nghệ Thiết bị đeo thông minh trực thuộc Fossil Group. Từ những ngày đầu thành lập, đội ngũ kỹ sư Việt đã thiết kế và xây dựng hệ sinh thái thiết bị đeo thông minh phục vụ cuộc sống của hàng triệu người toàn cầu. Chúng tôi tự hào là những nhà đổi mới luôn bứt phá giới hạn của công nghệ và thời trang, tập trung phát triển 3 nhóm sản phẩm chủ lực: thiết bị, ứng dụng, và dữ liệu trên đám mây.
ĐIỀU FOSSIL TỰ TIN MANG ĐẾN CHO BẠN?
Tham gia nghiên cứu và phát triển Thiết bị đeo thông minh hàng triệu người dùng trên toàn thế giới. Với Fossil, mỗi việc bạn làm đều có thể mang lại thay đổi cho cuộc sống của rất nhiều người.
Lộ trình nghề nghiệp đa dạng, bất kể bạn muốn quản lý đội ngũ hay tập trung phát triển chuyên môn kỹ thuật.
Cơ hội làm việc và học hỏi từ các kỹ sư Google, Qualcomm, Citizen, v.v.
Bảo hiểm sức khỏe cao cấp, thu nhập và phúc lợi cạnh tranh mang đến trải nghiệm làm việc toàn diện nhất.
Môi trường làm việc linh hoạt để bạn thỏa sức học hỏi, phát triển và tạo ra tác động tích cực!
Fossil Việt Nam đang mở ra cơ hội với hàng loạt vị trí hấp dẫn
(Cloud Engineer, Android Engineer, Software Architect), mời bạn tham khảo chi tiết công việc tại ĐÂY.
Kết nối với Fossil Việt Nam
Email tuyển dụng: people@fossil.com
Linkedin: https://www.linkedin.com/company/fossilvietnamcareers
Quotes
“The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops.”
― Joseph Weizenbaum
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
Đánh giá của các bạn sẽ giúp chúng tôi liên tục cải thiện nội dung Newsletter!