Giới thiệu
Nếu bạn giống tôi, có lẽ bạn đã từng lướt qua vô số danh sách công cụ và framework, tự hỏi, "Chúng ta có thực sự cần thêm một cái nữa không?" Hãy chuẩn bị tinh thần, vì hôm nay tôi sẽ khởi động một chuỗi blog mới, nơi tôi xây dựng một nền tảng chụp dữ liệu thay đổi (CDC) cho cơ sở dữ liệu Oracle—một cách công khai. Hãy xem đó như là "xây dựng công khai" gặp "nhà khoa học điên trong garage." Tôi sẽ chia sẻ những thăng trầm, những khoảnh khắc "aha!", và có lẽ một vài lời thú nhận "tại sao tôi lại nghĩ đây là một ý tưởng hay?" trong suốt hành trình này.
Tại sao lại là CDC?
Tôi có thể nghe thấy tiếng thở dài tập thể: "Đã có rất nhiều công cụ CDC hiện có! Một số là mã nguồn mở, và—kỳ diệu thay—một số thậm chí hoạt động như đã quảng cáo!" Điểm hợp lý. Vậy tại sao tôi lại thêm vào đống công cụ đó? Đơn giản:
"Sự tò mò trí tuệ giống như một cơn ngứa đòi hỏi phải được gãi—cho đến khi nó trở thành một cuộc phiêu lưu đầy thú vị." —Tôi, đang kênh nhạy cảm triết lý của mình trong khi nhìn vào mã code vào lúc 2 giờ sáng.
Chúng ta đều đã say mê những blog thiết kế hệ thống lấp lánh, xem các video hướng dẫn trên YouTube, và hoàn thành các khóa học trực tuyến hứa hẹn biến chúng ta thành những pháp sư kiến trúc. Sau hai thập kỷ (hoặc hơn) trong ngành phần mềm, một sự thật phổ quát nổi bật lên: Không có hệ thống nào hoàn hảo! Không, ngay cả trong những công ty Fortune 500 sang trọng nhất, bạn sẽ gặp những con quái vật di sản đang ẩn nấp trong bóng tối—những hệ thống chậm chạp mà sẽ khiến một sinh viên CS mới ra trường phải khóc.
Những di sản này đầy rẫy các mẫu thiết kế xấu mà cảm giác như là sự phản bội đối với mọi thứ mà chúng ta coi trọng trong kỹ thuật phần mềm. Nhưng thực tế không phải là một cuốn sách giáo khoa; nó là một hỗn hợp hỗn độn của thời hạn chặt chẽ, ngân sách eo hẹp, và logic "nó vẫn hoạt động tốt hôm qua." Và đó chính là lý do tại sao chúng ta lại phát minh ra những công cụ mà, ngay từ cái nhìn đầu tiên, có vẻ như thừa thãi. Hãy để tôi giới thiệu về chụp dữ liệu thay đổi: người hùng không được ca ngợi thì thầm, "Này, có điều gì vừa thay đổi trong cơ sở dữ liệu—bạn có muốn biết không?"
Thực tế về CDC
Trong một thế giới lý tưởng, nếu bạn có một dịch vụ ghi duy nhất, hành xử tốt xử lý tất cả các cập nhật đến cơ sở dữ liệu của bạn, dịch vụ đó chỉ cần thông báo các thay đổi qua một bus sự kiện doanh nghiệp để mọi người khác nghe thấy. Thật dễ dàng, đúng không? Nhưng thực tế luôn thích đưa ra những cú ném bất ngờ. Thử tưởng tượng bạn có hai dịch vụ ghi? Hoặc ba? Hoặc—trời ơi—một đoàn xiếc gồm chúng, một số từ các nhà cung cấp bên thứ ba mà bạn không thể điều chỉnh mã nếu cuộc sống của bạn phụ thuộc vào đó? Đột nhiên, bạn đang chơi trò whack-a-mole với các cơ sở mã, cố gắng vá chỗ chụp sự kiện ở khắp mọi nơi. Điều đó thật mệt mỏi, không hiệu quả, và thú vị như việc gỡ lỗi regex của người khác.
Đó là lúc bạn chuyển sang nguồn sự thật: chính cơ sở dữ liệu. Theo dõi các thay đổi nơi chúng được sinh ra, và voila—vấn đề (hầu như) được giải quyết. Nhưng đây là một điểm bất ngờ: nhiều thiết lập di sản này yêu thích những cơ sở dữ liệu quan hệ cổ điển, và Oracle? Ồ, Oracle là vua trong thế giới RDBMS. Nó đã được kiểm nghiệm trong chiến tranh, mạnh mẽ, và... nổi tiếng khó khăn khi xử lý CDC. Chắc chắn, Oracle cung cấp các giải pháp độc quyền sang trọng như GoldenGate hoặc XStream, nhưng nếu bạn là một startup tự lực hoặc một lập trình viên độc lập đang làm việc từ văn phòng tại nhà, những giấy phép đó có thể được định giá bằng nước mắt của kỳ lân. Vượt quá tầm với!
Giải pháp cho lập trình viên
Vậy, một lập trình viên tò mò nên làm gì? Xắn tay áo lên và xây dựng một nền tảng CDC mã nguồn mở, chất lượng doanh nghiệp, có khả năng mở rộng cao dành riêng cho Oracle (và hey, nếu mọi thứ thuận lợi và tôi không hết cà phê, có thể mở rộng cho các cơ sở dữ liệu khác nữa). Nó giống như quyết định tự làm bánh mì vì sản phẩm mua sẵn không đáp ứng được nhu cầu—ngoại trừ cái bánh này phải nuôi một đội quân đói dữ liệu mà không bị sụp đổ dưới áp lực.
Trong chuỗi bài viết này, tôi sẽ là người dẫn đường cho bạn trong toàn bộ hành trình. Chúng ta sẽ đi sâu vào các quyết định thiết kế (tại sao kiến trúc này hơn kiến trúc kia?), lựa chọn framework (spoiler: không có viên đạn bạc nào ở đây), lựa chọn thư viện (những cái tốt, cái xấu, và cái "tại sao tôi lại nhập cái này?"), mẫu thiết kế (bởi vì ai mà không thích một vài mẫu observer chắc chắn?), và các sự đánh đổi không thể tránh khỏi—những chiến công chức năng so với những yêu cầu không chức năng như khả năng mở rộng, độ tin cậy, và cái phép màu "nó chỉ hoạt động" khó nắm bắt.
Mục tiêu của chuỗi bài viết
Hãy mong đợi những trận cười dọc đường—có thể là ở cái giá của tôi khi tôi đụng phải một bức tường (hoặc một sự kỳ quặc khó chịu của Oracle). Tôi sẽ chia sẻ các đoạn mã, sơ đồ mà có vẻ như được vẽ bởi một con sóc caffeinated, và những cuộc nói chuyện chân thực về những gì đi sai (bởi vì điều đó sẽ xảy ra). Ai biết được? Bạn có thể thậm chí nhận được một mẹo hoặc hai cho các dự án của riêng bạn.
Vậy hãy cầm lấy đồ uống ưa thích của bạn, đăng ký nếu bạn cảm thấy mạo hiểm, và hãy biến cơn ngứa này thành một điều gì đó vĩ đại. Đầu tiên: Khám phá những điều cơ bản. Hãy theo dõi—chúng ta chỉ mới bắt đầu!
