码迷,mamicode.com
首页 > 其他好文 > 详细

谈nginx配置

时间:2019-09-07 12:26:41      阅读:77      评论:0      收藏:0      [点我收藏+]

标签:www   内容   功能   red   情况   def   说明文档   location   业务逻辑   

近日看《许式伟的架构课》中一段关于系统分解的描述所有思考,略记于此。

原文片段如下:

系统设计,简单来说就是 “对系统进行分解” 的能力。这个阶段核心要干的事情,就是明确子系统的职责边界和接口协议,把整个系统的大框架搭起来。

那么怎么分解系统?

首先我们需要明确的是分解系统优劣的评判标准。也就是说,我们需要知道什么样的系统分解方式是好的,什么样的分解方式是糟糕的。

最朴素的评判依据,是这样两个核心的点:

  • 功能的使用界面(或者叫接口),应尽可能符合业务需求对它的自然预期;
  • 功能的实现要高内聚,功能与功能之间的耦合尽可能低。

在软件系统中有多个层次的组织单元:子系统、模块、类、方法 / 函数。子系统如何分解模块?模块如何分解到更具体的类或函数?每一层的分解方式,都遵循相同的套路。也就是分解系统的方法论。

......

一个程序员的系统分解能力强不强,其实一眼就可以看出来。你都不需要看实现细节,只需要看他定义的模块、类和函数的使用接口。如果存在大量说不清业务意图的函数,或者存在大量职责不清的模块和类,就知道他基本上还处在搬砖阶段。

无论是子系统、模块、类还是函数,都有自己的业务边界。它的职责是否足够单一足够清晰,使用接口是否足够简单明了,是否自然体现业务需求(甚至无需配备额外的说明文档),这些都体现了架构功力。

完整原文 https://time.geekbang.org/column/article/117783

佩服作者对系统设计这样大问题的能简化到2个朴素的判断依据,而不是学院式的抽象含糊的说明。

近期由于工作内容需要,也常思考业务需求对接口的预期是什么?

对于服务端软件而言,接口在形式上比有UI交互的前端软件更加稳定且标准;然而对于业务需求的预期有时会缺少思考,设计上更倾向于技术的可行便利。

当然这两者并不矛盾,如果业务在接口标准上达成共识,就能取得很好的效果。

对于服务端软件,软件配置的组织与设计是一个重要而容易被忽视的接口。

以nginx软件为例,个人认为nginx配置方式的设计对业务需求的表达有时就不够自然清晰。甚至在某些场景下功能配置的耦合情况不少。

示例1

# 示例例来源 http://nginx.org/en/docs/http/websocket.html
http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        ...

        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }
}

上面这段示例的目的是实现WebSocket的代理,但从配置上看不出WebSocket的任何信息,而是依赖于配置人员对WebSocket升级流程与Nginx代理流程十分了解的基础上才能判断出这段配置能实现WebSocket代理。

示例2

# 示例例来源 http://nginx.org/en/docs/http/converting_rewrite_rules.html
location / {
    root       /var/www/myapp.com/current/public;

    try_files  /system/maintenance.html
               $uri  $uri/index.html $uri.html
               @mongrel;
}

location @mongrel {
    proxy_pass  http://mongrel;
}

上面这段示例目的是优先尝试本地文件,不存在再像后端获取。其中的location @mongrel {}块部分是涉及到nginx开发中subrequest的概念。

subrequest的设计在代码内部很好的处理复杂请求的业务流程,是nginx开发中模块解耦,降低开发复杂度,并保持高性能的重要利器。

而这样一个重要特性却可能会造成配置片段的隔离性,当这个特性被大量使用时,配置文件看上去就显得特别复杂。与公司运维童鞋交流过程中也收到过反馈,说ngxin配置的格式,看着特别像代码而不是配置项。

关于subrequest更多信息可以参考http://nginx.org/en/docs/dev/development_guide.html#http_subrequests


然而这个视角的分析太片面。从另一个视角看,nginx的配置是提供了足够的灵活性和可扩展性,为实现各类不同的业务提供了可能性。nginx的配置不仅是业务需求的展示,而且还能承载业务逻辑,实现灵活扩展的功能。openresty的ngx_http_lua_module就是一个很好的实例。

# 示例来自 https://github.com/openresty/lua-nginx-module/
location = /request_body {
    client_max_body_size 50k;
    client_body_buffer_size 50k;

    content_by_lua_block {
        ngx.req.read_body()  -- explicitly read the req body
            local data = ngx.req.get_body_data()
            if data then
            ngx.say("body data:")
            ngx.print(data)
            return
            end

            -- body may get buffered in a temp file:
            local file = ngx.req.get_body_file()
            if file then
            ngx.say("body is in file ", file)
            else
            ngx.say("no body found")
            end
    }
}

在配置文件上承载业务逻辑,对于配置的管理与维护就提出了新的挑战。

孰是孰非,我并没有明确的倾向性,在实际项目中还要考虑组织结构、协作流程、历史数据、现有架构等等因素……才能设计出一个恰如其分的方案。

再看开头提到徐大牛提出的2个判断依据。接口满足业务预期;功能高内聚低耦合。用于判断方案的合理性确实是一个很不错的标准。

谈nginx配置

标签:www   内容   功能   red   情况   def   说明文档   location   业务逻辑   

原文地址:https://www.cnblogs.com/atskyline/p/11479766.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!