Shadow proxy và TIP pattern
Ruby
104
White

huydx viết ngày 06/08/2015

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

What ?

alt text

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

=)))

Why ?

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 =))

How ?

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

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

huydx

115 bài viết.
855 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
135 8
Introduction (Link) là một cuộc thi ở Nhật, và cũng chỉ có riêng ở Nhật. Đây là một cuộc thi khá đặc trưng bởi sự thú vị của cách thi của nó, những...
huydx viết hơn 1 năm trước
135 8
White
109 14
Happy programmer là gì nhỉ, chắc ai đọc xong title của bài post này cũng không hiểu ý mình định nói đến là gì :D. Đầu tiên với cá nhân mình thì hap...
huydx viết gần 3 năm trước
109 14
White
86 10
(Ảnh) Mở đầu Chắc nhiều bạn đã nghe đến khái niệm oauth. Về cơ bản thì oauth là một phương thức chứng thực, mà nhờ đó một web service hay một ap...
huydx viết hơn 2 năm trước
86 10
Bài viết liên quan
White
8 6
Chưa xem phần 2? Xem (Link) Trong bài viết này tôi giới thiệu cho các bạn về khái niệm function arity, một cách gọi mĩ miều của số lượng argument ...
Lơi Rệ viết hơn 2 năm trước
8 6
White
8 1
Tiếp theo (Link) Mình sẽ hướng dẫn cách test căn bản cho API mình tạo. Thật ra mà nói thì mình phải viết test trước khi làm nhưng mà để tránh việc...
My Mai viết hơn 2 năm trước
8 1
White
4 2
__Chú thích__: Đây là bản dịch tiếng Việt của bài viết gốc của tôi. Nếu bạn muốn xem bản tiếng Anh, xin hãy trỏ tới URL (Link) Lời mở (Link) là ...
Lơi Rệ viết gần 3 năm trước
4 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
115 bài viết.
855 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!