Có một số vấn đề khi đăng chéo vì phương ngữ đánh dấu trong bài đăng gốc. Đặc biệt là các sơ đồ không được hiển thị tồn tại trong bài viết gốc. Vì vậy, vui lòng kiểm tra cả bản gốc nếu bạn quan tâm. Tôi nghĩ bản gốc dễ hiểu hơn

Nâng cấp HBase trên đầu trang Tìm nguồn cung ứng sự kiện và kiến ​​trúc CQRS trong 3 tuần

TL; DR

• Chúng tôi đã sử dụng chiến lược triển khai màu xanh lam-xanh lục cho việc nâng cấp phiên bản HBase trên hệ thống Tìm nguồn cung ứng sự kiện và kiến ​​trúc CQRS.
• Phương pháp triển khai hoạt động khá tốt và chỉ mất tổng cộng 3 tuần để hoàn thành mục tiêu dự án. Trải nghiệm này thật mới mẻ và thú vị đối với chúng tôi. Vì vậy, tôi muốn chia sẻ nó :)

Giới thiệu về nâng cấp cơ sở dữ liệu

Nâng cấp cơ sở dữ liệu luôn rắc rối và bất cứ khi nào bạn đối mặt với những tình huống như vậy trong các tình huống sản xuất, bạn sẽ rất lo lắng (tôi muốn nói gấp 100 lần so với các hoạt động sản xuất khác mà bạn đang xử lý) .

Cảm giác này khó có thể chia sẻ với những người không có kinh nghiệm hoặc tiếp xúc với việc vận hành các môi trường Cơ sở dữ liệu. Và tôi nghĩ rằng 99,9% mọi người sẽ đồng ý nếu bạn có kinh nghiệm và đã trải qua thời gian khó khăn trong việc xử lý các hoạt động liên quan đến cơ sở dữ liệu. Nó rủi ro và tốn kém rất nhiều, nhưng bản thân nâng cấp không có nghĩa là nó cung cấp giá trị mới cho sản phẩm và mặc dù nó không được ưu tiên trong nhiều trường hợp trừ khi có lý do khẩn cấp nào đó.

Đồng thời, đó là một nguy cơ tiềm ẩn rất lớn nếu cơ sở dữ liệu trở nên "không thể chạm tới" và làm thế nào để giải quyết vấn đề này đã là một chủ đề, nhiều nhà phát triển và nhà điều hành đã phải vật lộn với những tình huống như vậy

Phương pháp nâng cấp

Nói chung, bạn sẽ có hai lựa chọn.

nâng cấp luân phiên

Một là bản nâng cấp cuốn chiếu. Nâng cấp từng phiên bản cơ sở dữ liệu theo cách tuần tự.
Tôi tìm thấy một lời giải thích tốt ở đây. Vui lòng đọc phần này nếu bạn không quen với từ này.

Nâng cấp liên tục trong phát triển phần mềm có nghĩa là gì?

• Thuận lợi

  • Dữ liệu ở một nơi. Vì vậy, bạn không cần phải suy nghĩ về cách đồng bộ hóa dữ liệu giữa các cụm khác nhau và cách đảm bảo quá trình đồng bộ hóa hoạt động hoàn hảo.

• Nhược điểm

  • Sau khi hoàn tất nâng cấp, không có cách nào dễ dàng để hoàn nguyên. Vì vậy, nếu việc nâng cấp gây ra vấn đề về hiệu suất bằng cách nào đó, bạn sẽ gặp rắc rối lớn.
  • Cơ sở dữ liệu lâu dài có một số trạng thái không mong muốn mà bạn không thể tạo lại trên môi trường thử nghiệm. Đôi khi bạn cần phải đối phó với vấn đề liên quan đến sản xuất. Và khả năng đó khiến bạn thực sự lo lắng.

triển khai xanh lam-xanh lá cây

Cái còn lại là một triển khai màu xanh lam-xanh lá cây. Trong trường hợp này, bạn phải cung cấp riêng cụm cơ sở dữ liệu đã nâng cấp và chuyển ứng dụng sang sử dụng cái mới vào một lúc nào đó.
Vui lòng kiểm tra bài đăng trên blog này nếu bạn không quen với từ "triển khai xanh lam".

BlueGreenDeployment

Tôi nghĩ rằng cách tiếp cận này phổ biến rộng rãi trong việc triển khai ứng dụng web, nhưng nếu bạn thay thế từ "bộ định tuyến" thành "ứng dụng" và "máy chủ web" thành "cơ sở dữ liệu", thì cách tiếp cận tương tự có thể được áp dụng để nâng cấp cơ sở dữ liệu.

• Thuận lợi

  • Bạn không chạm vào cơ sở dữ liệu sản xuất đang chạy trong khi nâng cấp. Điều đó làm cho cuộc sống của bạn dễ dàng hơn nhiều so với phương pháp nâng cấp luân phiên.
  • Bạn có thể dễ dàng hoàn nguyên về cụm cũ khi một số sự cố không mong muốn xảy ra. Và bạn cũng có thể phân phối các yêu cầu dần dần để có thể giảm thiểu phạm vi trong trường hợp bạn gặp một số vấn đề (Tuy nhiên, để làm điều này, như trong "Nhược điểm", bạn cần phải đồng bộ hóa dữ liệu từ cụm mới sang cụm cũ)
  • Do yếu tố trên, bạn có thể rút ngắn phần nào quá trình thử nghiệm tải trên môi trường thử nghiệm và có thể tiến hành dự án một cách nhanh chóng.

• Nhược điểm

  • Bạn cần đảm bảo dữ liệu được đồng bộ hóa giữa cả hai cụm cơ sở dữ liệu. Không chỉ từ cụm cũ sang cụm mới, mà còn từ cụm mới sang cụm cũ nếu bạn muốn hoàn nguyên một cách dễ dàng sau khi nâng cấp. Nhưng việc sao chép dữ liệu lẫn nhau là khá khó khăn trong nhiều trường hợp. Có thể ghi vào hai cụm trên mọi thao tác, nhưng bạn cần chuẩn bị khi chỉ có một cụm gặp sự cố và thao tác với chỉ cụm đó không thành công. Việc xử lý đó sẽ thực sự phức tạp.
  • Bạn cần có các máy chủ có kích thước gấp đôi trong khi chạy cả hai cụm. Điều đó sẽ tốn một khoản tiền và có thể khó khăn nếu hệ thống của bạn không sử dụng cơ sở hạ tầng đám mây.

Cách tiếp cận của chúng tôi

Về cơ bản, cách tiếp cận của chúng tôi là triển khai xanh lam-xanh lục. Và bởi vì chúng tôi có Kafka ở phía trước dưới dạng bus tìm nguồn sự kiện, nên việc giải quyết vấn đề đồng bộ hóa dữ liệu trong "Nhược điểm" được liệt kê ở trên dễ dàng hơn nhiều.

Kiến trúc hiện tại

Đầu tiên, tôi xin giới thiệu về kiến ​​trúc cơ bản. Btw, chúng tôi gọi toàn bộ hệ thống phụ tin nhắn trò chuyện là "Falcon". Đó là lý do tại sao biểu tượng chim ưng có trong biểu đồ.

1. khi người dùng cuối đăng một tin nhắn trò chuyện, write-api đưa dữ liệu tin nhắn vào Kafka
2. read-model-updater (viết tắt là "rmu") tìm nạp dữ liệu từ Kafka, chuyển đổi nó thành mô hình đọc và đưa nó vào HBase
3. khi người dùng cuối đọc tin nhắn trò chuyện, read-api lấy dữ liệu tin nhắn từ HBase

Tôi không giải thích lý do tại sao chúng tôi chọn CQRS trong bài đăng này. Vì vậy, vui lòng xem các slide bên dưới nếu bạn muốn biết chi tiết hoặc nếu bạn chưa quen với khái niệm CQRS.
Kafka Summit SF 2017 - Dịch vụ nhắn tin có thể mở rộng và phục hồi trên toàn thế giới với Kafka và Kafka Streams
Dịch vụ nhắn tin có khả năng mở rộng và phục hồi trên toàn thế giới của CQRS và Nguồn cung ứng sự kiện sử dụng Akka, Kafka Streams và HBase

Quy trình nâng cấp cơ sở dữ liệu

Bây giờ, tôi sẽ giải thích cách chúng tôi đã thực hiện nâng cấp cơ sở dữ liệu trên đầu kiến ​​trúc này

Bước 1: Chuẩn bị các cụm mới và thực hiện khôi phục ban đầu từ bản sao lưu.

Bước 2: Chuẩn bị một người tiêu dùng khác (rmu2 trong sơ đồ này) để đồng bộ dữ liệu từ Kafka sang cụm cơ sở dữ liệu mới. Bạn sẽ chơi lại các sự kiện Kafka cũ bắt đầu từ trước đó sau khi khôi phục ban đầu. Đảm bảo rằng bạn triển khai tính hiệu quả đối với người tiêu dùng của mình. Ý tôi là, hệ thống cần hoạt động bình thường ngay cả khi cùng một sự kiện được sử dụng nhiều lần.

Bước 3: Khi người tiêu dùng mới (rmu2) đã bắt kịp các thông báo Kafka mới nhất, hãy chuẩn bị một dữ liệu kéo đọc-api khác từ cụm cơ sở dữ liệu mới. Và dần dần gửi yêu cầu đến read-api mới.

Sẽ có một số khác biệt về trạng thái giữa cụm cũ và cụm mới ngay cả khi quá trình đồng bộ hóa dữ liệu kết thúc sau vài mili giây. Chúng tôi đã gặp một vấn đề nhỏ do sự khác biệt này, vì vậy bạn cần xác nhận và chạy kiểm tra đánh giá để xem loại vấn đề nào có thể được kích hoạt thông qua sự khác biệt giữa các cụm và logic ứng dụng của bạn trước đó. Hoặc nếu bạn có một số lớp tốt ở phía trước read-api để phân phối yêu cầu theo thuộc tính người dùng hoặc thứ gì đó (ví dụ:định tuyến qua Nginx hoặc Envoy như proxy), bạn có thể chỉ cần đặt quy tắc thích hợp trong đó và sự khác biệt có thể được xử lý hiệu quả và nó sẽ không thành vấn đề.

Và trong quá trình hồi cứu dự án này, chúng tôi nhận thấy rằng nếu bạn có thể phản chiếu các yêu cầu từ api hiện có sang api mới, bạn có thể thực hiện kiểm tra tải bằng cách sử dụng lưu lượng truy cập sản xuất mà không ảnh hưởng đến người dùng cuối.

Bước 4: Chuyển sang read-api mới 100% và tắt các cụm và ứng dụng cũ khi bạn chắc chắn rằng mọi thứ hoạt động hoàn hảo.

Tại sao tôi nghĩ cách tiếp cận này tốt hơn

Hãy để tôi giải thích sự khác biệt với cách tiếp cận màu xanh lam-xanh lá cây thông thường. Một vấn đề đối với màu xanh lam bình thường là bạn cần đảm bảo rằng dữ liệu được đồng bộ hóa trên cả hai cụm, lý tưởng nhất là không chỉ trước khi nâng cấp mà còn sau khi nâng cấp. Trong cách tiếp cận này, thay vì sử dụng chức năng sao chép mà cơ sở dữ liệu cung cấp, các bản cập nhật cơ sở dữ liệu được áp dụng riêng biệt thông qua ứng dụng mà chúng tôi viết và chuẩn bị. Cách tiếp cận này mang lại cho chúng tôi rất nhiều lợi ích.

Đầu tiên, vì chúng hoạt động riêng lẻ nên bạn không cần quan tâm đến cách dữ liệu được đồng bộ hóa trên từng giai đoạn. Đặc biệt, bạn sẽ cần thêm một số nỗ lực (và khá khó khăn trong hầu hết các trường hợp) trong việc đồng bộ hóa dữ liệu từ cụm mới sang cụm cũ nếu bạn muốn có một cách dễ dàng để hoàn nguyên sau khi nâng cấp. Nhưng trong cách tiếp cận này, họ chỉ làm việc độc lập. Vì vậy, bạn chỉ có thể hoàn nguyên để sử dụng những cái cũ trong trường hợp một số sự cố không mong muốn bắt đầu xảy ra sau khi nâng cấp.

Thứ hai, bạn không cần bận tâm về khả năng tương thích phiên bản giữa các cụm cũ và cụm mới. Nếu bạn sử dụng chức năng đồng bộ hóa dữ liệu cụm mà cơ sở dữ liệu cung cấp, sẽ có một số hạn chế về phiên bản và vấn đề tương thích có thể xảy ra trong một số trường hợp cạnh. Nhưng trong cách tiếp cận này, tất cả những gì bạn cần làm là chuẩn bị ứng dụng độc lập đưa dữ liệu vào từng cơ sở dữ liệu. Tôi nghĩ rằng đó là vấn đề bạn có thể giải quyết dễ dàng hơn nhiều trong hầu hết các trường hợp. Và về lý thuyết, không chỉ cập nhật phiên bản cơ sở dữ liệu mà bạn còn có thể chuyển cụm mới sang một cụm hoàn toàn khác (ví dụ:DynamoDB) bằng cách sử dụng cùng một phương pháp. Trong trường hợp đó, bạn không thể sử dụng dữ liệu sao lưu để thiết lập ban đầu và cần chuẩn bị chương trình di chuyển dữ liệu ban đầu. Điều đó sẽ mất một thời gian, nhưng tôi nghĩ đó là mặt hàng hợp lý để giải quyết.

Kết luận

CQRS và các chủ đề tìm nguồn cung ứng sự kiện thường được thảo luận trong kiến ​​trúc phần mềm. Từ quan điểm hoạt động, việc có thêm một lớp khi bus sự kiện sẽ làm tăng độ phức tạp của cơ sở hạ tầng và chi phí vận hành. Thành thật mà nói, tôi không thích cách tiếp cận này cho lắm so với quan điểm đó trước đây. Nhưng chúng tôi nhận thấy rằng nó cũng thay đổi cách chúng tôi vận hành cơ sở hạ tầng và mang lại cho chúng tôi sự yên bình trong hoạt động cơ sở dữ liệu. Và vâng, bây giờ tôi rất thích CQRS và tìm nguồn cung ứng sự kiện :)

Thử thách tiếp theo

Bạn có thể thắc mắc chúng tôi sẽ nâng cấp Kafka (bus tìm nguồn cung ứng sự kiện) những gì? Vâng, đó sẽ là thử thách tiếp theo của chúng tôi. Tôi hy vọng tồn tại một cách tiếp cận tốt hơn so với nâng cấp luân phiên bình thường và triển khai màu xanh lam. Cuộc sống kỹ sư vẫn tiếp diễn!