摘要：從主關(guān)注點中分離出橫切關(guān)注點是面向側(cè)面的程序設(shè)計的核心概念。最終我們采用的是通過的模塊來將以面向側(cè)面的思路耦合。原文使用優(yōu)化面向側(cè)面的架構(gòu)

面向側(cè)面的程序設(shè)計（aspect-oriented programming，AOP），通過將解決特定領(lǐng)域問題的代碼從業(yè)務(wù)邏輯中獨立出來，從而提高代碼的可維護(hù)性。

從主關(guān)注點中分離出橫切關(guān)注點是面向側(cè)面的程序設(shè)計的核心概念。分離關(guān)注點使得解決特定領(lǐng)域問題的代碼從業(yè)務(wù)邏輯中獨立出來，業(yè)務(wù)邏輯的代碼中不再含有針對特定領(lǐng)域問題代碼的調(diào)用，業(yè)務(wù)邏輯同特定領(lǐng)域問題的關(guān)系通過側(cè)面來封裝、維護(hù)，這樣原本分散在在整個應(yīng)用程序中的變動就可以很好的管理起來。 - 維基百科

示例是根據(jù)最近正在負(fù)責(zé)的 APP 后端項目簡化版，需求簡單說如下：

APP 端會對所有請求進(jìn)行加密，服務(wù)器端要對加密結(jié)果進(jìn)行校驗，確保正確以及未篡改；

通過手機號來登錄，采用基本的 token 機制驗證登錄；

有企業(yè)、小組以及員工的層級關(guān)系，后期必須考慮根據(jù)公司來分表/集群；

提供涉及到權(quán)限的 REST 風(fēng)格的接口（某種程度上類似 Postgrest，但是進(jìn)行了拓展，后面會有專門文章介紹）

思路：首先整個目前項目的主關(guān)注點 (core concern) 是 REST 風(fēng)格的資源服務(wù)器 —— 即通過約定俗成的風(fēng)格來對應(yīng)具體的數(shù)據(jù)/資源操作。在這個功能外，需要完成的其他關(guān)注點包括：

所有請求加密校驗

登錄驗證

資源的權(quán)限管理以及獲取

于是，在 Sinatra 中，可以通過 extensions 的方式將請求加密校驗完成，配合 before 來進(jìn)行統(tǒng)一處理：

require "sinatra/base"

module Sinatra

  module RequestHeadersVerify

    module Helpers
      def headers_valid?
        # 此處省略真實業(yè)務(wù)代碼
        false
      end
    end

    def self.registered(app)
      app.helpers RequestHeadersVerify::Helpers

      app.before do
        unless headers_valid?
          halt 400, json(ResponseErrror::InvalidHeadersError.new)
        end
      end
    end
  end

  register RequestHeadersVerify
end

最終采用"中間件"的方式，在請求的最前面一層（橫切關(guān)注點 crosscutting concerns）將非法請求進(jìn)行攔截。

于是緊接著第二個流程，驗證用戶是否登錄，與獲取當(dāng)前聯(lián)系人所在的公司、小組、以及其管理的小組信息一樣，這里最快速/方便的做法就是通過 helpers 來實現(xiàn)：

require "sinatra/base"

module Sinatra 
  module UserSessionHelpers
    HTTP_USER_TOKEN_KEY = "HTTP_AUTH_TOKEN"

    def current_user
      @current_user ||= (
        user = User.first token: env[HTTP_USER_TOKEN_KEY]
        halt 400, json(ResponseErrror::InvalidTokenError.new) unless user
        user
      )
    end
  end

  module OrganizationHelpers
    # 這里省略掉相關(guān) helpers 代碼
  end

  helpers UserSessionHelpers
  helpers OrganizationHelpers
end

最終在 REST 相關(guān)的構(gòu)建代碼中，就不需要去考慮用戶請求加密的內(nèi)容，也不需要去考慮用戶是否登錄（因為如果需要使用到用戶信息但是用戶沒有登錄，會直接拋出錯誤返回）。只需要按照約定的設(shè)計風(fēng)格，把請求的內(nèi)容在校驗了內(nèi)容和權(quán)限后，轉(zhuǎn)成對應(yīng)的數(shù)據(jù)庫操作，最終再按照約定的內(nèi)容返回。

第一版已經(jīng)盡可能的考慮到 解決特定領(lǐng)域問題的代碼從業(yè)務(wù)邏輯中獨立出來。但是現(xiàn)實開發(fā)里面經(jīng)常會涉及到多人開發(fā)、跨語言合作、更快速的迭代等等的問題，最終需要把他們拆成獨立的低耦合度的 Server。于是隨之而來的是如何在服務(wù)間進(jìn)行通訊/共享數(shù)據(jù)。

這里的方案選擇通常會根據(jù)實際業(yè)務(wù)以及難易程度來權(quán)衡，例如最快捷的 webServer 的方式內(nèi)部通信，稍微復(fù)雜點的基于 TCP 的 RPC 通信方案（例如 thrift），或者某些特殊的情景，例如是生產(chǎn)者/消費者關(guān)系的話，則可能通過 MQ 來進(jìn)行通信。最終我們采用的是通過 Nginx 的 lua 模塊來將 server 以面向側(cè)面的思路耦合。

首先，Nginx 的 Lua 模塊可以做什么？如果可以，單純 nginx 和 lua 就可以完成完整的 web 服務(wù)。可以連接 redis、memcache、postgresql 等等，同時可以取得請求的所有內(nèi)容，可以設(shè)置返回的頭部、正文。配合 lua 的對數(shù)據(jù)處理能力，基本功能都可以實現(xiàn)。同時 nginx 的 lua 模塊整體都是異步，所以性能也相對較好。當(dāng)然也可以通過 lua 腳本來控制權(quán)限，如果驗證通過則繼續(xù)下面的操作，例如是 proxy_pass 代理，簡單的示例如下文：

location = /foo {
    access_by_lua_block {
        -- check the client IP address is in our black list
        if ngx.var.remote_addr == "132.5.72.3" then
            ngx.exit(ngx.HTTP_FORBIDDEN)
        end

        -- check if the URI contains bad words
        if ngx.var.uri and
            string.match(ngx.var.request_body, "evil")
        then
            return ngx.redirect("/terms_of_use.html")
        end

        -- tests passed
    }

    proxy_pass http://blah.blah.com;
 }

不過，我們這里將用到的主要還是 proxy_pass, 和 ngx.location.capture，基本代碼如下：

if string.sub(ngx.var.uri, 2, 2) == "_" then
  ngx.exit(404)
end

local cjson = require "cjson"

local custom_header_prefix = "V-"
local request_args = ngx.req.get_uri_args(64)
local request_body = ngx.req.read_body()
local request_path = ngx.var.uri
local request_method = ngx["HTTP_"..ngx.req.get_method()]

for header, _ in pairs(ngx.req.get_headers()) do
  if string.upper(string.sub(header, 1, 2)) == crm_header_prefix then
    ngx.req.clear_header(header);
  end
end

function res_with_json(body, status)
  ngx.header["Content-Type"] = "application/json"
  ngx.print(body)
  return ngx.exit(status)
end

function request_to_server(uri)
  
  res = ngx.location.capture(uri..request_path, {
    body = request_body,
    args = request_args,
    method = request_method,
  })
  local json_response = cjson.decode(res.body)

  
  if not json_response.next == true then
    res_with_json(res.body, res.status)
  end
  for key, value in json_response.params do
     ngx.req.set_header(custom_header_prefix..string.upper(key), value)
  end
  return false
end

上面的代碼主完成了清理用戶惡意提交的請求頭，以及 request_to_server 的代碼，實現(xiàn)了將原請求內(nèi)容轉(zhuǎn)發(fā)給另一個接口并獲得請求后的內(nèi)容。得到請求結(jié)果后，驗證請求的參數(shù)。

同時在 nginx 里面通過 stream 和 proxy_pass 的方式來配置多個內(nèi)部地址：

upstream authentication-server {
    server 192.168.21.1:6011;
    server 192.168.21.2:6011;
}

server {
    location /_authentication {
      proxy_redirect off;
      proxy_set_header Host      $host;
      proxy_set_header X-Real-IP $remote_addr;

      rewrite  ^/_authentication/(.*)  /$1 break;
      proxy_pass http://authentication-server;
    }
}

于是，將兩個結(jié)合起來，就可以實現(xiàn)通過 lua 腳本把原請求的所有參數(shù)，包括頭部、正文、請求地址、請求方法都帶過去，請求另一個地址（和 proxy_pass 類似），并且可以得到最終返回的結(jié)果處理。

擁有這個能力后，便是本文的重點了：在 Sinatra 的第一版本中，最終都是 ruby 代碼不斷調(diào)用方法，來完成整個請求的流程。那如果我們把整個流程的打通交給 Nginx 的話該如何實現(xiàn)呢？

當(dāng)一個請求進(jìn)入后，通過 request_to_server 的能力，把請求依次轉(zhuǎn)發(fā)給負(fù)責(zé) 橫切關(guān)注點 的服務(wù)，例如用戶請求校驗以及登錄校驗服務(wù)、用戶的組織架構(gòu)服務(wù)，最終再去調(diào)用主關(guān)注點，即本文中的資源服務(wù)器；

每次請求完后，根據(jù)前一個流程的返回值決定是否進(jìn)入下一個流程，例如示例中的 lua 腳本是通過返回的 json 里面的 next 參數(shù)來決定是否繼續(xù)往下走。如果沒有這個參數(shù)則直接返回當(dāng)前服務(wù)的返回值不再繼續(xù)請求下去；

如果出現(xiàn)了 next: true 這個關(guān)鍵字，則將返回值中的其他內(nèi)容以請求頭的形式傳遞給下一個服務(wù)，且每個服務(wù)都會完全信賴這些請求頭（所以請求剛進(jìn)來的時候需要做一些請求頭和請求地址處理）。

如果到這里都沒有太大問題，你應(yīng)該可以理解我的意圖了。即 Nginx 通過 Lua 腳本來依次請求 橫切關(guān)注點服務(wù)器，如果一路順暢（每次都有 next: true），最終會把攜帶有 橫切關(guān)注點服務(wù)返回的內(nèi)容的 headers 帶給主關(guān)注點服務(wù)。

于是，在本需求里面，為了保證可拓展性和低耦合性，最終分為了三個服務(wù)：

負(fù)責(zé)請求加密鑒權(quán)，用戶登錄、密碼修改的用戶驗證服務(wù)

負(fù)責(zé)管理企業(yè)結(jié)構(gòu)、獲取用戶權(quán)限的組織架構(gòu)服務(wù)

負(fù)責(zé)具體的 REST 請求處理的資源服務(wù)

當(dāng)一個用戶登錄的請求過來，因為密碼錯誤或者加密鑒權(quán)失敗，會在用戶驗證服務(wù)就直接返回錯誤。因為返回內(nèi)容中沒有 next: true 字段，所以直接返回結(jié)果；

當(dāng)一個用戶發(fā)起了一個發(fā)送短信驗證碼的服務(wù)，這個只是用戶驗證服務(wù)的職能，沒有必要繼續(xù)向下走，于是返回了一個沒有 next: true 字段的返回值，于是 Nginx 直接返回結(jié)果；

當(dāng)用戶登錄的時候，雖然通過了用戶驗證服務(wù)的校驗，但是該服務(wù)無法獲取更多的用戶信息，于是把該請求繼續(xù)傳遞到組織架構(gòu)服務(wù)，組織架構(gòu)服務(wù)在請求頭中拿到了手機號信息，于是直接返回了該手機號所對應(yīng)的詳細(xì)信息；

現(xiàn)在發(fā)起了一個資源操作的請求，因為用戶驗證服務(wù)無法識別，所以只返回了手機號給 nginx，nginx 繼續(xù)請求組織架構(gòu)服務(wù)，因為組織架構(gòu)服務(wù)也不能處理，所以繼續(xù)返回了詳細(xì)的個人信息給 nginx，nginx 最終拿到這些信息，都通過頭部請求了資源服務(wù)，然后因為這里是主關(guān)注點，也是流程里面最后一個節(jié)點，所以通過 proxy_pass 給了資源服務(wù)。

最終，這樣做的優(yōu)勢：

利用 Nginx 異步的優(yōu)勢來彌補 ruby 服務(wù)先天性 IO 處理的不足；

目前只實現(xiàn)了第一條線，即從用戶驗證 -> 組織信息 -> 資源服務(wù)器的順序，后面如果有需要，可以隨時實現(xiàn)其他順序，而只需要按照在請求頭里面加上相應(yīng)的參數(shù)即可，減低耦合性；

三個模塊都有各自的業(yè)務(wù)和特點，可以針對模塊去設(shè)計緩存方案，而且可以分模塊去設(shè)計集群方案；

對于開發(fā)者而言，更容易完成單個服務(wù)的測試用例，而不需要過多在開發(fā)過程中關(guān)注聯(lián)調(diào)。

原文: 使用 Nginx 優(yōu)化面向側(cè)面的架構(gòu)