Shadow proxy và TIP pattern

Chắc chưa nhiều bạn từng nghe đến 2 cụm từ shadow proxy và TIP pattern.
Cụm từ shadow proxy thì có lẽ không thông dụng bởi vì nó được dùng chủ yếu ở Nhật, khi mà thông tin chủ yếu là bằng tiếng Nhật.
Cụm từ TIP pattern thì tất nhiên là các bạn không biết rồi, vì tôi nghĩ ra mà :v

Shadow proxy rất đơn giản , chỉ đơn thuần là một server giúp chúng ta nhân đôi request lên, vậy thôi :D.
Vậy còn TIP pattern? Cụm từ này còn đơn giản hơn nữa

TIP pattern = Test In Production pattern

=)))

Nhiều bạn sẽ thắc mắc là tại sao lại cần nhân đôi request lên, request nhân đôi lên thì nó sẽ đi đâu, tốn tài nguyên, dẹp!
Cơ mà tôi sẽ thuyết phục bạn là bạn sẽ cần shadow proxy trong một số trường hợp :D.

Khi bạn code lại hay refactoring lại một đoạn logic cực kì quan trọng. Tất nhiên là sự đúng đắn của logic sẽ được đảm bảo bằng nhiều cách khác nhau như unit test, integration test .. Tuy nhiên có những thứ mà bạn khó có thể đảm bảo được như là: Performance với cùng một kiểu access giống như production hay là tính đa dạng của kiểu access. Chung qui lại, bạn ước là

"Giá" mà có thể "forward" toàn bộ access của production server vào test server để xem nó ra sao thì sướng quá.

Shadow proxy sẽ giúp bạn trong trường hợp này :D.
Và việc sử dụng shadow proxy sẽ giúp bạn thực hiện TIP pattern, hay là Test in Production pattern =))

Về cơ bản thì Shadown proxy chỉ là một việc rất đơn giản là : nhận request, và ném request đó ra 1 production server + N sandbox server khác.Kết quả trả về cho client sẽ được lấy từ production server.
Bạn có thể tự viết một cái shadow proxy của riêng bạn, tôi rất hoan nghênh, cơ mà nếu thời gian không có nhiều thì bạn có thể dùng một số hàng "có sẵn". Hiện tại thì mình đang sử dụng một gem gọi là kage.

Gem này về cơ bản là wrapper của một gem khá nổi tiếng khác là em-proxy, và thêm cho chúng ta một số DSL để dễ sử dụng hơn.
Cách dùng khá đơn giản là bạn chỉ cần cài kage

gem instal kage

Sau đó viết đoạn script để sử dụng kage

require 'kage'

def compare(a, b)
  p [a, b]
end

Kage::ProxyServer.start do |server|
  server.port = 8090
  server.host = '0.0.0.0'
  server.debug = false

  # backends can share the same host/port
  server.add_master_backend(:production, 'localhost', 80)
  server.add_backend(:sandbox, 'localhost', 80)

  server.client_timeout = 15
  server.backend_timeout = 10

  # Dispatch all GET requests to multiple backends, otherwise only :production
  server.on_select_backends do |request, headers|
    if request[:method] == 'GET'
      [:production, :sandbox]
    else
      [:production]
    end
  end

  # Add optional headers
  server.on_munge_headers do |backend, headers|
    headers['X-Kage-Session'] = self.session_id
    headers['X-Kage-Sandbox'] = 1 if backend == :sandbox
  end

  # This callback is only fired when there are multiple backends to respond
  server.on_backends_finished do |backends, requests, responses|
    compare(responses[:production][:data], responses[:sandbox][:data])
  end
end

Chắc bạn nào đã quen với ruby thì nhìn đoạn code trên chúng ta có thể hiểu được kage có thể làm được gì. Mình sẽ tóm tắt lại ở dưới đây:

• kage có thể add thêm master backend (là server dùng để trả request về cho client) , và có thể add thêm N sandbox backend, chính là các server bạn muốn "test" một logic nào đó
• kage có thể chỉ nhân request ra với một method nào đó (ví dụ là GET), và không làm gì với các request còn lại. Lý do bạn nên làm việc này là shadow proxy chỉ thích hợp để test với các request "không thay đổi database", vì nếu có thay đổi database thì sẽ không thể nhân request ra được, vì việc đó sẽ làm loạn "trạng thái" của hệ thống.
• kage có thể add thêm header
• kage có thể hook vào khi xử lý đã thực hiện xong và làm gì đó (ví dụ so sánh request)

Kết luận

Giờ chúng ta đã có thể thoải mái "test trên production" được rồi, vì đã có shadow proxy :v