https://www.161616.top/tags/web-middleware/ Recent content in Web Middleware on Cylon's Collection Hugo -- 0.125.7 zh Fri, 29 Nov 2024 23:00:36 +0800 https://www.161616.top/ngx-map/ Sat, 04 Nov 2023 00:00:00 +0000 https://www.161616.top/ngx-map/ 引言 在 NGINX 中常用一种 “比较变量” 的手法，在编程语言中称为 “多路分支” (Case statement)，也就是 nginx map，需要注意的一点是，太低版本 NGINX MAP 中只能使用单变量 Before version 0.9.0 only a single variable could be specified in the first parameter. [1] 下面将了解下 nginx map 的具体使用方式 nginx map使用 Nginx 配置主要是声明性的，这同样应用于 MAP 指令，NGINX MAP 是定义在 http{} 级别，最大的特点是仅在引用时进行处理， 如果请求未触及使用 NGINX MAP 变量的配置部分，则不会执行该 map 变量查找。换句话来理解，当在上下文 server, Location, if 等中使用结果变量时（指定的不是计算结果，而是在需要时计算该结果的公式），才会被使用，在 NGINX 需要使用该变量之前，NGINX MAP 不会给请求增加任何开销。 NGINX MAP 用于根据另一个变量的值创建一个变量，如下所示： text 1 2 3 4 map $variable_to_check $variable_to_set { "check_if_variable_matches_me" "variable_matches_checked_value"; default "no_match"; } 在上面的例子中， 变量 $variable_to_set 的被设置的结果为：如果 $variable_to_check 值为 “check_if_variable_matches_me”， 那么 $variable_to_set 将被设置为值 “variable_matches_checked_value” ， 否则将设置为 “no_match”。 https://www.161616.top/ingress-nginx-default-backend-status-code/ Thu, 21 Sep 2023 00:00:00 +0000 https://www.161616.top/ingress-nginx-default-backend-status-code/ 什么是 default backend default backend 是 ingress-nginx 中的一个服务，主要用于处理 nginx controller 无法识别的而请求的服务 主要提供了两个接口 /healthz that returns 200 /that returns 404 如何改default backend 状态码 需求：修改 default backend 状态码 404 为 403 原理：nginx-controller 启动时指定了一个 default backend 容器，如下所示 bash 1 2 3 4 5 6 7 8 9 10 11 12 containers: - args: - /nginx-ingress-controller # 这里指的是 default-backend 的名称 {namespace_name}/{service_name} - --default-backend-service=$(POD_NAMESPACE)/ingress-nginx-ext-defaultbackend - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ext-controller - --election-id=ingress-controller-leader - --ingress-class=nginx-yewu-ext - --configmap=$(POD_NAMESPACE)/ingress-nginx-ext-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key 通常情况下在通过定义配置文件方式改变是不容易做的，ingress-nginx 提供了一种自定义方式 “custom-error-pages“ 可以完成 ，完成后该 defaultBackend 支持使用 X-code方式自定义任意的错误页即错误码。 https://www.161616.top/nginx-proxy_pass/ Sat, 20 May 2023 00:00:00 +0000 https://www.161616.top/nginx-proxy_pass/ 场景 在配置代理后，GET 请求的变量全部失效，配置如下 text 1 2 3 location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是，/fw/ 的都发往 2952端口，但实际情况是404，原因为“在没有指定 URI 的情况下，在1.12版本后会传递原有的URI” 这时会导致一个404错误，因为我的后端接口本身就是 /fw/xxx/ 会出现重复 接下来做了一个变量传递 text 1 2 3 location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题，就是 GET 请求的变量无法传递过去 解决 nginx 官方给出一个样例，说明了，存在某种情况下，nginx 不会确定请求 URI 中的部分参数 使用正则表达式时 在 localtion 名称内 例如，在这个场景下，proxy_pass 就会忽略原有的请求的URI，而将拼接后的请求转发 text 1 2 3 4 location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题，nginx官方给出了使用方式 当在 proxy_pass 中需要变量，可以使用 $request_uri; 另外也可以使用 $is_args$args 参数 来保证原有的请求参数被传递 https://www.161616.top/ngx-in-docker-500/ Thu, 18 May 2023 00:00:00 +0000 https://www.161616.top/ngx-in-docker-500/ vue项目部署在裸机Linux上运行正常，部署在docker中nginx出现下列错误 text 1 Nginx "rewrite or internal redirection cycle while internally redirecting to "/index.html" 表现在用户界面 500 Internal Server Error 原因：nginx配置路径不对，改成正确的后恢复 https://www.161616.top/opentracing-nginx/ Sat, 02 Jul 2022 00:00:00 +0000 https://www.161616.top/opentracing-nginx/ Background NGINX 是一个通用且流行的应用程序。也是最流行的 Web 服务器，它可用于提供静态文件内容，但也通常与其他服务一起用作分布式系统中的组件，在其中它用作反向代理、负载均衡 或 API 网关。 分布式追踪 distributed tracing 是一种可用于分析与监控应用程序的机制，将追踪在从源到目的的整个过程中的单个请求，这与仅通过单个应用程序域来追踪请求的形式不同。 换句话说，我们可以说分布式追踪是对跨多个系统的多个请求的拼接。拼接通常由一个或多个相关 ID 完成，并且跟踪通常是一组记录的、跨所有系统的结构化日志事件，存储在一个中心位置。 在这种背景的情况下， OpenTracing 应运而生。OpenTracing 是一个与应用供应商无关的 API，它可帮助开发人员轻松地跟踪单一请求的域。目前有多种开源产品都支持 OpenTracing（例如，Jaeger, skywalking 等），并将其作为一种检测分布式追踪的标准化方法。 本文将围绕，从0到1实现在nginx配置分布式追踪的架构的简单实例说明。本文实例使用的组件为 nginx v1.22 jaeger-all-in-on v1.38 nginx-opentracing v1.22 jaeger-client-cpp v0.9 源码构建nginx-opentracing 准备nginx-opentracing nginx-opentracing 仓库中可以看到，官方为每个nginx版本都提供了一个编译好的动态库（Nginx1.19.13+），我们可以直接拿来使用这个动态库，如果你想将这个利用Nginx 提供的编译参数 --add-module=/path/to/module 构建为nginx的内置功能的话，可能会出现一些问题，例如下面的一些错误： text 1 ngx_http_opentracing_module.so/config was found bash 1 2 3 /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp In file included from /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp:1:0: /root/nginx-opentracing-0.25.0/opentracing//src/load_tracer.h:3:38: fatal error: opentracing/dynamic_load.h: No such file or directory 根据 issue 中查询得知 nginx-opentracing 需要嵌入到nginx中，是需要一些 opentracing-cpp 因为对c++不熟，尝试调试很久还是上面的错误，故直接使用了官方提供的动态库。 https://www.161616.top/traefik-on-physical/ Sun, 04 Oct 2020 00:00:00 +0000 https://www.161616.top/traefik-on-physical/ traefik概述 traefik-现代反向代理，也可称为现代边缘路由；traefik原声兼容主流集群，Kubernetes，Docker，AWS等。官方的定位traefik是一个让开发人员将时间花费在系统研发与部署功能上，而非配置和维护。并且traefik官方也提供自己的服务网格解决方案 作为一个 modern edge router ，traefik拥有与envoy相似的特性 基于go语言研发，目的是为了简化开发人员的配置和维护 tcp/udp支持 http L7支持 GRPC支持 服务发现和动态配置 front/ edge prory支持 可观测性 流量管理 … traefik 术语 要了解trafik，首先需要先了解一下 有关trafik中的一些术语。 EntryPoints 入口点，是可以被下游客户端连接的命名网络位置，类似于envoy 的listener和nginx的listen services 服务，负载均衡，上游主机接收来自traefik的连接和请求并返回响应。 类似于nginx upstream envoy的clusters Providers 提供者，提供配置文件的后端，如文件，consul，redis，etcd等，可使traefik自动更新 routers 路由器，分析请求，将下游主机的请求处理转入到services middlewares: 中间件，在将下游主机的请求转入到services时进行的流量调整 traefik部署安装 traefik为go语言开发的，可以直接下载运行即可。此处介绍直接运行二进制程序 后端环境准备,此处为docker运行的两个后端。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 version: '3' services: webserver1: image: sealloong/envoy-end:latest ports: - 91:90 networks: envoymesh: aliases: - v1_server - default_server environment: - VERSION=v1 - COLORFUL=blue expose: - 90 webserver2: image: sealloong/envoy-end:latest ports: - 92:90 networks: envoymesh: aliases: - v1_server - default_server environment: - VERSION=v1 - COLORFUL=blue expose: - 90 networks: envoymesh: {} traefik配置说明 Traefik中的配置可以引用两种不同的内容： https://www.161616.top/envoy-mutual-tls/ Tue, 29 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-mutual-tls/ 环境准备 主机 角色 数量 front-envoy front envoy 1 service envoy 作为内部后端的envoy 2 end 后端应用程序 2 访问 / front-envoy ==> end * 2 访问 /red/colorful ==> end red 不验证客户端证书 单项tls 访问 /gray/colorful ==> end gray 验证客户端证书 双项tls docker-compose text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 version: '3' services: front-envoy: image: envoyproxy/envoy-alpine:v1. https://www.161616.top/envoy-access-log/ Tue, 22 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-access-log/ text 1 2 3 4 5 6 7 access_log: - name: envoy.listener.accesslog typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /var/log/envoy.log log_format: text_format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\"\n" https://www.161616.top/envoy-real-ip/ Tue, 22 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-real-ip/ 在envoy作为前端代理时，用户ip的获取很重要，一般获取ip的方式。都是通过Header中的 X-Forward-For、 X-Real-IP或 Remote addr 等属性获取，但是如果确保Envoy可以获取到的ip是真实的用户ip呢？本篇继续解密！ 概念说明 Remote Address 是nginx与客户端进行TCP连接过程中，获得的客户端真实地址。Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。 一般情况下，在Envoy作为最外层代理时，此IP为真实的IP客户端IP X-Real-IP 是一个自定义头。X-Real-Ip 通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP，这个设备可能是其他代理，也可能是真正的请求端。X-Real-Ip 目前并不属于任何标准，代理和 Web 应用之间可以约定用任何自定义头来传递这个信息。 X-Forwarded-For X-Forwarded-For 是一个扩展头。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP，现在已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。通常，X-Forwarded-For可被伪造，并且使用CDN会被重写 Envoy中如何获取真实IP 在Envoy中，涉及到客户端IP的配置如下： use_remote_address： 默认值false，设置为true，使用客户端连接的真实远程地址，false是使用x-forwarded-for skip_xff_append： 设置为true，则不会将远程地址附加到x-forwarded-for中 request_headers_to_add 添加请求头 request_headers_to_remove 删除一个请求头 实验环境配置准备 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 admin: access_log_path: /dev/null address: socket_address: { address: 0. https://www.161616.top/outlier-detection/ Tue, 15 Sep 2020 00:00:00 +0000 https://www.161616.top/outlier-detection/ outlier detection 在异常检测领域中，常常需要决定新观察的点是否属于与现有观察点相同的分布（则它称为inlier），或者被认为是不同的（称为outlier）。离群是异常的数据，但是不一定是错误的数据点。 在Envoy中，离群点检测是动态确定上游集群中是否有某些主机表现不正常，然后将它们从正常的负载均衡集群中删除的过程。outlier detection可以与healthy check同时/独立启用，并构成整个上游运行状况检查解决方案的基础。 此处概念不做过多的说明，具体可以参考官方文档与自行google 监测类型 连续的5xx 连续的网关错误 连续的本地来源错误 更多介绍参考官方文档 outlier detection 离群检测测试 说明，此处只能在单机环境测试更多还的参考与实际环境 环境准备 docker-compose 模拟后端5个节点 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1. https://www.161616.top/initiative-health-check/ Mon, 14 Sep 2020 00:00:00 +0000 https://www.161616.top/initiative-health-check/ 实验文件 docker-compose yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1.15-latest environment: - ENVOY_UID=0 - HEALTHY=ok ports: - 80:80 - 443:443 - 82:9901 volumes: - . https://www.161616.top/envoy-v3-api-tls/ Sun, 13 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-v3-api-tls/ 方案架构 本次实例与官方Envoy front_proxy Example相似，首先会有一个Envoy单独运行。ingress的工作是给其他地方提供一个入口。来自外部的传入连接请求到这里，前端代理将会决定他们在内部的转发路径。 图源自Envoy官网文档 front_proxy 生成证书 text 1 openssl req -nodes -new -x509 -keyout certs/server.key -out certs/server.crt -days 365 -subj "/C=CN/ST=Guangdong/L=Guangzhou/O=studyenvoy/OU=studyenvoy/CN=*.studyenvoy.cn" envoy配置说明 v3 api中envoy去掉了tls_context的配置，配置tls首先需要熟悉envoy的如下两个术语 Downstream：下游主机连接到 Envoy，发送请求并或获得响应。 Upstream：上游主机获取来自 Envoy 的链接请求和响应。 本次使用的是ingress的代理，需要配置的即为 Downstream v3api中使用的是transport_socket，transport_socket为 listeners 当中某一个 filter_chains 中上线文中的配置。 transport_socket 官方说明为： (config.core.v3.TransportSocket) Optional custom transport socket implementation to use for downstream connections. To setup TLS, set a transport socket with name tls and DownstreamTlsContext in the typed_config. If no transport socket configuration is specified, new connections will be set up with plaintext. https://www.161616.top/envoy-example-failed/ Sat, 12 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-example-failed/ 镜像内安装包失败处理 方法一：修改Dockerfile，在Dockerfile中增加如下 ubuntu示例 text 1 2 RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list RUN sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list apline示例 text 1 RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories 方法二：使用http代理， ubuntu 参考 命令行使用代理 下载镜像失败处理 方法一：docker宿主机使用ss，开启局域网可连接。同局域网中的都可直接连此代理 方法二： docker systemd的 service文件中增加http代理 可看到已经可以成功运行envoy example示例 cannot bind ‘0.0.0.0:80’: Permission denied docker-compose文件 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1.15-latest volumes: - . https://www.161616.top/envoy-tls-configuration/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-tls-configuration/ official front proxy 在一个Services Mash内部中，都会存在一到多个微服务，为了将南北向流量统一引入网格内部管理，通常存在单独运行的envoy实例。 Envoy的listener支持面向下游客户端一侧的TLS会话，并可选地支持验正客户端证书； listener中用到的数字证书可于配置中静态提供，也可借助于SDS动态获取; tls_context 是 listeners 当中某一个 filter_chains 中上线文中的配置，tls_context 配置在哪个 listeners当中就隶属于哪个listeners。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 listeners: ... filter_chains: - filters: .. tls_context: common_tls_context: {} # 常规证书相关设置； tls_params: {} # TLS协议版本，加密套件等； tls_certifcates: [] # 用到的证书和私钥文件； - certifcate_chain: {} filename: # 证书文件路径; private_key: {} # 私钥; filename: # 私钥文件路径; password: {} # 私钥口令； filename: # 口令文件路径； tls_certifcate_sds_secret_configs: [] # 要基于SDS API获取TLS会话的相关信息时的配置； require_client_certifcate: # 是否验证客户端证书； 例如，下面示例将前面的Ingress示例中的Envoy配置为通过TLS提供服务，并将所有基于http协议的请求重定向至https； https://www.161616.top/envoy-deployment/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-deployment/ 常用的构建方法 https://skyao.io/learning-envoy/ 手动配置构建环境，手动构建Envoy。 使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy 使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy，并直接将Envoy程序打包成Docker镜像 提供Bootstrap配置文件，存在使用xDS的动态资源时，还需要基于文件或管理服务器向其提供必须的配置信息 也可使用Envoy的配置生成器生成示例性配置 基于Bootstrap配置文件启动Envoy实例 直接启动二进制Envoy 于Kubernetes平台基于Sidecar的形式运行Envoy，或运行单独的Envoy Pod（Edge Proxy） 启动Envoy 启动Envoy时，需要通过（-c 选项为其指定初始配置文件以提供引导配置（Bootstrap configuration），这也是使用v2APl的必然要求； text 1 envoy -c <path to config>.{json,yaml,pb,pb_text} 扩展名代表了配置信息的组织格式； 引导配置是Envoy配置信息的基点，用于承载Envoy的初始配置，它可能包括静态资源和动态资源的定义 静态资源（static_resources）于启动直接加载 动态资源（dynamic_resources）则需要通过配置的xDS服务获取并生成 通常，Listener 和 Cluster 是Envoy得以运行的基础，而二者的配置可以全部为静态格式，也可以混合使用动态及静态方式提供，或者全部配置为动态； 一个yaml格式纯静态的基础配置框架类似如下所示： yaml 1 2 3 4 5 6 7 8 9 10 11 static_resources: linteners: - name: ... address: {} filter_chains: [] clusters: - name: ... type: ... connect_timeout: {} lb_policy: ... load_assignment: {} Listener 简易静态配置 侦听器主要用于定义Envoy监听的用于接收Down streams请求的套接字、用于处理请求时调用的过滤器链及相关的其它配置属性;目前envoy仅支持tcp的协议 yaml 1 2 3 4 listeners: - name: address: socket_address: { address: . https://www.161616.top/envoy-administartion/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-administartion/ envoy内建了一个管理接口，它支持查询和修改操作，甚至有可能暴露私有数据（例如统计数据、集群名称和证书信息等）因此非常有必要精心编排期访问控制机制，以避免非授权访问。 administration interface 属于 bootstrap 配置文件中的==顶级配置字段==使用。 administration interface offical document yaml 1 2 3 4 5 6 7 8 admin: access_log_path: .. # 管理接口的访问日志文件路径，无须记录访问日志使用/dev/null profile_path: ... # cpu_profile的输出路径，默认为/var/log/envoy/envoy.prof; address: socket_address: # 监听的套接字 protocol: .. address: ... prot_value: ... 下面是一个简单的配置示例 yaml 1 2 3 4 admin: access_log_path: /tmp/admin_access.log address: socket_address: { address: 127.0.0.1, port_value: 9901 } admin接口内置了多个 /path ，不同的path可能会分别接受不同的GET或POST请求 GET /help ：打印所有可用选项； / : Admin home page /certs : GET 列出在的所有TLS相关的信息； /clusters : upstream cluster status GET，格外支持使用 /clusters? https://www.161616.top/envoy-fundamental/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-fundamental/ 服务网格的基本功能 控制服务间通信：熔断、重试、超时、故障注入、负载均衡和故障转移等。 服务发现：通过专用的服务总监发现服务端点。 可观测：指标数据采集、监控、分布式日志记录和分布式追踪。 安全性：TLS/SSL通信和秘钥管理。 身份认证和授权检查：身份认证，以及基于黑白名单或RBAC的访问控制功能。 部署：对容器技术的原生支持，例如Docker和Kubernetes等。 服务间的通信协议：HTTP1.1 HTTP2.0和gRPC等。 健康状态监测：监测上游服务的健康状态。 …. 服务网格的部署模式有两种：主机共享代理和Sidecar容器 主机共享代理 适用于同一主机存在许多容器的场景，并且还可以利用连接池来提高吞吐量。 带一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务。 实现方式中，常见的是允许为Kubernetes之上的 DaemonSet。 Sidecar容器 代理进程注入每个Pod定义以与住容器一同运行。 Sidecar进程应该尽可能轻量且功能完善。 实现方案：Linkerd、Envoy和Conduit。 What IS Enovy Enovy是工作与OSI模型的7层代理 在实现上，数据平面的主流解决方案有Linkerd、Nginx、Envoy、HAProxy和Traefik等，而控制平面的实现主要有Istio、Nelson和SmartStack等几种口Linkerd ●由Buoyant公司于2016年率先创建的开源高性能网络代理程序（数据平面），是业界第一款Service Mesh产品，引领并促进了相关技术的快速发展 ·Linkerd使用Namerd提供控制平面，实现中心化管理和存储路由规则、服务发现配置、支持运行时动态路由等功能 Envoy 核心功能在于数据平面，于2016年由Lyft公司创建并开源，目标是成为通用的数据平面 云原生应用，既可用作前端代理，亦可实现Service Mesh中的服务间通信 Envoy常被用于实现APIGateway（如Ambassador）以及Kubernetes的Ingress Controller（例如gloo等），不过，基于Envoy实现的Service Mesh产品Istio有着更广泛的用户基础 Istio ·相比前两者来说，lstio发布时间稍晚，它于2017年5月方才面世，但却是目前最火热的Service Mesh解决方案，得到了Google、IBM、Lyt及Redhat等公司的大力推广及支持 ·目前仅支持部署在Kubernetes之上，其数据平而由Envoy实现 envoy适用于现代大型面向服务架构的动态组织应用程序的7层代理应用程序，其典型特性： 运行在架构进程之外 支持3/4层过滤器 支持HTTP协议7层过滤器 支持HTTP协议7层高级路由功能 envoy在现代服务体系架构当中的适用位置既可以为一组服务提供代理，作为整个服务统一的api网关来进行接入，同时也可以对每一个微服务单独实现作为代理，此时需要以sidecar的形式运行在应用程序前端。进而与最前端的apigateway组织成所谓的服务网格（Sevice Mesh）。而在每一个Envoy实例内部都要接受请求。这个请求可能是来自互联网或服务网格之外的客户端，称之为南北流量；也可能是来自网格当中的其他服务的请求，称之为东西流量。 在Envoy当中类似于Nginx或者haproxy的功能术语： listeners ：面向客户端一侧提供监听并接受客户端请求的组件。类似于nginx的server或haproxy的frontend 。 cluster：面向后端测，将多个被代理的实例分成组，统一进行负载均衡调度的组。 cluster definltions：cluster的归类。 filter chains：过滤器链，可以将多个链以流水线方式依次进行处理。 面向客户端提供服务/监听的套接字，lintener内部包含一到多个filter组成filter chains，称之为过滤器链。过滤器是lintener内部的子组件。envoy支持4层过滤器和7层过滤器。 envoy 术语 主机（Host）：能够进行网络通信的实体（如手机，服务器等上的应用程序）。在这个文档中，主机是一个逻辑网络应用程序。一个物理硬件可能有多个主机上运行，只要他们可以独立寻址。 下游（Downstream）：下游主机连接到Envoy，发送请求并接收响应。 上游（Upstream）：上游主机接收来自Envoy的连接和请求并返回响应。 监听器（Listener）：侦听器是可以被下游客户端连接的命名网络位置（例如，端口，unix域套接字等）。Envoy公开一个或多个下游主机连接的侦听器。 filters chains，过滤器链L4/L7 route：完成对客户请求进行分类 群集（Cluster）：群集是指Envoy连接到的一组逻辑上相似的上游主机。Envoy通过服务发现发现一个集群的成员。它可以通过主动健康检查来确定集群成员的健康度，从而Envoy通过负载均衡策略将请求路由到相应的集群成员。 网格（Mesh）：协调一致以提供一致的网络拓扑的一组主机。在本文档中，“Envoy mesh”是一组Envoy代理，它们构成了由多种不同服务和应用程序平台组成的分布式系统的消息传递基础。 https://www.161616.top/envoy-health-check/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-health-check/ 官方文档 healthy_check Envoy的服务发现并未采用完全一致的机制，而是假设主机以最终一致的方式加入或离开网格，它结合主动健康状态检查机制来判定集群的健康状态； 健康与否的决策机制以完全分布式的方式进行，因此可以很好地应对网络分区； 为集群启用主机健康状态检查机制后，Envoy基于如下方式判定是否路由请求到一个主机； 发现失败，单健康检查正常，此时，无法添加新主机，但现有主机将继续正常运行。 Discovery Status Health Check OK Health Check Failed Discovered Route Dont’t Route Absent Route Don’t Route / Delete 故障处理机制 Envoy提供了一系列开箱即用的故障处理机制： 超时（timeout） 有限次数的重试，并支持可变的重试延迟 主动健康检查与异常探测 连接池 断路器 所有这些特性，都可以在运行时动态配置；结合流量管理机制，用户可为每个服务/版本定制所需的故障恢复机制； 健康状态监测 健康状态检测用于确保代理服务器不会将下游客户端的请求代理至工作异常的上游主机； Envoy支持两种类型的健康状态检测，二者均基于集群进行定义： 主动检测（Active Health Checking）：Envoy周期性地发送探测报文至上游主机，并根据其响应判断其健康状态；Envoy目前支持三种类型的主动检测： HTTP：向上游主机发送HTTP请求报文 L3/L4：向上游主机发送L3/L4请求报文，基于响应的结果判定其健康状态，或仅通过连接状态进行判定； Redis：向上游的redis服务器发送Redis PING； 被动检测（Passive Health Checking）：Envoy通过异常检测（Outlier Detection）机制进行被动模式的健康状态检测； 目前，仅htp router、tcp proxy和redis proxy三个过滤器支持异常值检测； Envoy支持以下类型的异常检测： 连续5XX：意指所有类型的错误，非htp router过滤器生成的错误也会在内部映射为5xx错误代码； 连续网关故障：连续5XX的子集，单纯用于http的502、503或504错误，即网关故障； 连续的本地原因故障：Envoy无法连接到上游主机或与上游主机的通信被反复中断； 成功率：主机的聚合成功率数据阀值； 主动健康状态监测 集群的主机健康状态检测机制需要显式定义，否则，发现的所有上游主机即被视为可用； 定义语法 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 clusters: - name: . https://www.161616.top/envoy-traffic-management/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-traffic-management/ 灰度发布 概述 新版本上线时，无论是出于产品稳定性还是用户接受程度等方面因素的考虑，直接以新代旧都充满风险；于是，通行做法是新老版本同时在线，且一开始仅分出较小比例的流量至新版本，待确认新版本没问题后再逐级加大流量切换。 灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段，对于Envoy来说，灰度发布仅是流量治理的一种典型应用；以下是几种常见的场景口金丝雀发布 - 蓝绿发布 - A/B测试 - 流量镜像 灰度策略 需要在生产环境发布一个新的待上线版本时，需要事先添加一个灰度版本，而后将原有的生产环境的默认版本的流量引流一部分至此灰度版本，配置的引流机制即为灰度策略，经过评估稳定后，即可配置此灰度版本接管所有流量，并下线老版本。 常用的策略类型大体可分为 “基于请求内容发布”和“基于流量比例发布”两种类型 基于请求内容发布：配置相应的请求内容规则，满足相应规则服务流量会路由到灰度版本；例如对于http请求，通过匹配特定的Cookie标头值完成引流 Cookie内容： 完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本； 正则匹配：此处需要您使用正则表达式来匹配相应的规则； 自定义Header： 完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本； 正则匹配：此处需要您使用正则表达式来匹配相应的规则；可以自定义请求头的key和value，value支持完全匹配和正则匹配； 基于流量比例发布：对灰度版本配置期望的流量权重，将服务流量以指定权重比例引流到灰度版本；例如10%的流量分配为新版本，90%的流量保持在老版本。这种灰度策略也可以称为AB测试； 注：所有版本的权重之和为100； 灰度发布的实现方式 基于负载均衡器进行灰度发布 在服务入口的支持流量策略的负载均衡器上配置流量分布机制 仅支持对入口服务进行灰度，无法支撑后端服务需求 基于Kubernetes进行灰度发布 根据新旧版本应用所在的Pod数量比例进行流量分配，不断滚动更新旧版本Pod到新版本（先增后减、先减后增、又增又减）；服务入口通常是Service或Ingress。 基于服务网格进行灰度发布 对于Envoy或lstio来说，灰度发布仅是流量治理机制的一种典型应用。通过控制平面，将流量配置策略分发至对目标服务的请求发起方的envoy sidecar上即可。 支持基于请求内容的流量分配机制，例如浏览器类型、cookie等。 服务访问入口通常是一个单独部署的Envoy Gateway。 Envoy中流量转移 新版本上线时，为兼顾到产品的稳定性及用户的接受程度，让新老版本同时在线，将流量按需要分派至不同的版本； 蓝绿发布 A/B测试 金丝雀发布 流量镜像 …. HTTP路由器能够将流量按比例分成两个或多个上游集群中虚拟主机中的路由，从而产生两种常见用例： 版本升级：路由时将流量逐渐从一个集群迁移至另一个集群，实现灰度发布； 通过在路由中定义路由相关流量的百分比进行； A/B测试或多变量测试：同时测试多个相同的服务，路由的流量必须在相同服务的不同版本的集群之间分配；通过在路由中使用基于权重的集群路由完成；另外，匹配条件中，结合指定标头或也能够完成基于内容的流量管理； 流量迁移是指，通过在路由中配置运行时对象选择特定路由以及相应集群的概率的变动，从而实现将虚拟主机中特定路由的流量逐渐从一个集群迁移到另一个集群。 runtime_fraction yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 route: - match: prefix|path|regex: runtime_faction: # 额外匹配指定的运行时键值，每次评估匹配路径时，必须低于此字段指示的百分比，支持渐进式修改。 default_value: # 运行时键值不可用时，则使用此默认值。 numerator: # 指定分子，默认0 denominator: # 指定分母，小于分母时，最终百分比为1， 分母可使用 HUNDRED（默认） TEN_THOUSAND和MILLION， runtime_key: routing. https://www.161616.top/envoy-router-management/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/envoy-router-management/ HTTP 链接管理 envoy处理用户请求逻辑 ① 用户请求报文到达七层过滤器链处理机制后，首先根据请求HTTP报文中的 Host 首部来完成虚拟主机的选择；② 由此虚拟机主机内部的 Route 表项进行处理。③ 后由 match 进行匹配; Match 是与请求URL的 PATH 组成部分或请求报文的标头部分 header 。④ 最后才可到达 Route 进行 direct_response 、redirect 等。 官方手册 Envoy通过内置的L4过滤器HTTP连接管理器将原始字节转换为HTTP应用层协议级别的消息和事件，例如接收到的标头和主体等，以及处理所有HTTP连接和请求共有的功能，包括访问日志、生成和跟踪请求ID，请求/响应头处理、路由表管理和统计信息等； 支持HTTP/1.1、WebSockets和HTTP/2，但不支持SPDY; 关联的路由表可静态配置，亦可经由 xDS API 中的 RDS 动态生成； 内建重试插件，可用于配置重试行为; Host Predicates Priority Predicates 内建支持302重定向，它可以捕获302重定向响应，合成新请求后将其发送到新的路由匹配（match）所指定的上游端点，并将收到的响应作为对原始请求的响应返回客户端 支持适用于HTTP连接及其组成流（constituent streams）的多种可配置超时机制 连接级别：空闲超时和排空超时（GOAWAY）； 流级别：空闲超时、每路由相关的上游端点超时和每路由相关的 gRPC 最大超时时长； 基于自定义集群的动态转发代理； HTTP协议相关的功能通过各HTTP过滤器实现，这些过滤器大体可分为编码器、解码器和编/解码器三类； router envoy.router 是最常的过滤器之一，它基于路由表完成请求的转发或重定向，以及处理重试操作和生成统计信息等； HTTP 路由 Envoy基于HTTP router过滤器基于路由表完成多种高级路由机制，例如: 将域名映射到虚拟主机； path的前级 prefix 匹配、精确匹配或正则表达式匹配； 虚拟主机级别的TLS重定向； path级别的 path/host 重定向； direct_response ，由Envoy直接生成响应报文 ； 显式 host rewrite； prefix rewrite； 基于HTTP标头或路由配置的请求重试与请求超时； 基于运行时参数的流量迁移； 基于权重或百分比的跨集群流量分割； 基于任意标头匹配路由规则； 基于优先级的路由； 基于hash策略的路由； 路由配置和虚拟主机 路由配置中的顶级元素是虚拟主机 https://www.161616.top/service-mesh-security/ Wed, 02 Sep 2020 00:00:00 +0000 https://www.161616.top/service-mesh-security/ 服务网格安全框架 Microservice Security Basics 零信任安全 | 什么是零信任网络？ 零信任是一种安全模型，其基础是维护严格的访问控制并且默认不信任任何人，即便是已在网络边界内的人。零信任安全 IAAA (Identification and Authentication, Authorization and Accountability Identification: 必须支持多个身份和属性 Your name, username, ID number, employee number, SSN etc. “I am Thor”. Authentication: 必须支持多种认证方式以及委托认证方式 Authorization: 对于单个请求的授权可以在请求路径中的多个点确认 Accountability: 从API中捕获相关安全数据或元数据 服务网格常见安全解决方案 网络级别控制 Network Level Contros local isolation 主机隔离 Network segementation 网络分割 意味着新人底层的服务器及网络设施，信任隔离机制及实现过程且信任网段内的所有组件； SSL/TLS mTLS、spiffe/spire 应用级别控制 Network Level Contros 传统网络令牌认证 Traditional Web Tokens API-oriented Tokens OAuth 2.0 OpenID Connect JWT TokenTypes Opaque tokens Transparent tokens 基于cookie的会话 cookie based sessions SAML Security Assertion Markup Language 一种基于XML开源标准的数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。 Envoy的身份认证机制 传输认证 传输认证：即服务组件的认证，它基于双向TLS实现传输认证（即mTLS），包括双向认证、信道安全和证书自动管理；每个服务都需要有其用于服务间双向认证的标识，以实现此种认证机制； https://www.161616.top/traefik-ingresscontroller/ Wed, 23 Oct 2019 00:00:00 +0000 https://www.161616.top/traefik-ingresscontroller/ Kubernetes Ingress Kubernetes Ingress是路由规则的集合，这些规则控制外部用户如何访问Kubernetes集群中运行的服务。 在Kubernetes中，有三种方式可以使内部Pod公开访问。 NodePort：使用Kubernetes Pod的NodePort，将Pod内应用程序公开到每个节点上的端口上。 Service LoadBalancer：使用Kubernetes Service，改功能会创建一个外部负载均衡器，使流量转向集群中的Kubernetes Pod。 Ingress Controller： Node Port是在Kubernetes集群中每个节点（Node）上开放端口，Kubernetes直接将流量转向集群中Pod。Kubernetes集群中使用NodePort，则需要编辑防火墙规则，但是NodePort是范围在Kubernetes集群中默认设置的范围为 30000–32767，最终导致流量端口暴露在非标准端口之上。 LoadBalancer一般应用于云厂商提供的Kubernetes服务，如果自行在机器上部署Kubernetes集群，则需要自行配置LoadBalancer的实现， Kubernetes Ingress，为Kubernetes中的抽象概念，实现为第三方代理实现，这种三方实现集合统称为Ingress Controller。Ingress Controller负责引入外部流量并将流量处理并转向对应的服务。 Kubernetes IngressController功能实现 上面只是说道，在Kubernetes集群中，如何将外部流量引入到Kubernetes集群服务中。 负载均衡 无论在Kubernetes集群中，无论采用什么方式进行流量引入，都需要在外部负载均衡完成，而后负载均衡将流量引入Kubernetes集群入口或内部中， 通常情况下，NodePort方式管理繁琐，一般不用于生产环境。 服务的Ingress选择 Kubernetes Ingress是选择正确的方法来管理引入外部流量到服务内部。一般选择也是具有多样性的。 Nginx Ingress Controller，Kubernetes默认推荐的Ingress，弊端①最终配置加载依赖config reload，②定制化开发较难，配置基本来源于config file。 Envoy & traefik api网关，支持tcp/udp/grpc/ws等多协议，支持流量控制，可观测性，多配置提供者。 云厂商提供的Ingress。AWS ALB，GCP GLBG/GCE，Azure AGIC Traefik介绍 traefik-现代反向代理，也可称为现代边缘路由；traefik原声兼容主流集群，Kubernetes，Docker，AWS等。官方的定位traefik是一个让开发人员将时间花费在系统研发与部署功能上，而非配置和维护。并且traefik官方也提供自己的服务网格解决方案 作为一个 modern edge router ，traefik拥有与envoy相似的特性 基于go语言研发，目的是为了简化开发人员的配置和维护 tcp/udp支持 http L7支持 GRPC支持 服务发现和动态配置 front/ edge prory支持 可观测性 流量管理 … traefik 术语 要了解trafik，首先需要先了解一下 有关trafik中的一些术语。 EntryPoints 入口点，是可以被下游客户端连接的命名网络位置，类似于envoy 的listener和nginx的listen services 服务，负载均衡，上游主机接收来自traefik的连接和请求并返回响应。 类似于nginx upstream envoy的clusters Providers 提供者，提供配置文件的后端，如file，kubernetes，consul，redis，etcd等，可使traefik自动更新 routers 路由器，承上启下，分析请求，将下游主机的请求处理转入到services middlewares: 中间件，在将下游主机的请求转入到services时进行的流量调整 在Kubernetes中使用traefik网关作为Ingress Traefik于2019年9月发布2. https://www.161616.top/tomcat/ Sat, 02 Jun 2018 00:00:00 +0000 https://www.161616.top/tomcat/ tomcat介绍 Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，它早期的名称为catalina，后来由Apache、Sun 和其他一些公司及个人共同开发而成，并更名为Tomcat。 java体系结构 java程序设计语言（编程） java类文件格式 java api java vm java 纯面向对象语言 obj：以指令为中心，围绕指令组织数据 面向对象：以数据为中心，围绕数据组织指令 Tomcat核心组件： Catalina：servlet container在tomcat中用于实现servlet代码的被称作Catalina Coyote：一个http连接器，能够接受http请求并相应http请求的web服务器 jasper：JSP Engine jsp翻译器 Tomcat组成部分 Tomcat支持Servlet和JSP1的规范，它由一组嵌套的层次和组件组成，一般可分为以下四类： 顶级组件：位于配置层次的顶级，并且彼此间有着严格的对应关系； 连接器：连接客户端（可以是浏览器或Web服务器）请求至Servlet容器， 容器：包含一组其它组件； 被嵌套的组件：位于一个容器当中，但不能包含其它组件； tomcat常见组件 服务器(server) 服务器(server)顶级组件：Tomcat的一个实例，通常一个JVM只能包含一个Tomcat实例；因此，一台物理服务器上可以在启动多个JVM的情况下在每一个JVM中启动一个Tomcat实例，每个实例分属于一个独立的管理端口。这是一个顶级组件。 server相关属性 className：用于实现此Server容器的完全限定类的名称，默认为 org.apache.cataliana.core.StandardServer; port：接收shutdown指令的端口，默认仅允许通过本机访问，默认为8005 shutdown：发往此Server用于实现关闭tomcat实例的命令字符串，默认为SHUTDOWN 服务(service) Service主要用于关联一个引擎和此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收入站请求将其转发至关联的引擎进行处理，因此，Service要包含一个引擎（Engine）、一个或多个连接器（Connector）。 定义一个名为Catalina的Service，此名字也会产生相关的日志信息时记录在日志文件当中。 xml 1 <Service name="Catalina"> Service相关属性 className：用于实现service的类名，一般都是 org.apache.catalina.core.StandardService name：此服务的名称，默认为Catalina。 连接器(connectors) 分析并接收用户请求，并把它转换成本地jsp文件代码的请求。负责连接客户端（可以是浏览器或Web服务器）请求至Servlet容器内的Web应用程序，通常指的是接收客户发来请求的位置及服务器端分配的端口。 默认端口通常是HTTP协议的8080，管理员也可以根据自己的需要改变此端口。一个引擎可以配置多个连接器，但这些连接器必须使用不同的端口。默认的连接器是基于HTTP/1.1的Coyote。同时，Tomcat也支持AJP、JServ和JK2连接器。 进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类： Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache IIS Nginx。 Tomcat作为独立服务器：请求来自与web浏览器。 Tomcat应该考虑工作情形并为相应情形下的请求分别定义好需要的连接器才能正确接收来自于客户端的请求，一个引擎可以有一个或多个连接器，以适应多种请求方式。 定义连接器可以使用多种属性，有些属性也只是适用于某种特定的连接器类型， 一般来说，常见于server.xml中的连接器类型通常有4种： HTTP连接器 SSL连接器 AJP 1.3连接器 proxy连接器 xml 1 2 3 <Connector port="8080" protocol="HTTP/1. https://www.161616.top/tomcat-log-path/ Sat, 02 Jun 2018 00:00:00 +0000 https://www.161616.top/tomcat-log-path/ 修改logging.properties text 1 /usr/local/apache-tomcat-8.5.32/conf/logging.properties bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ 1catalina.org.apache.juli.AsyncFileHandler.level = FINE 1catalina.org.apache.juli.AsyncFileHandler.directory = /data/logs 1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina. 2localhost.org.apache.juli.AsyncFileHandler.level = FINE 2localhost.org.apache.juli.AsyncFileHandler.directory = /data/logs 2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost. 3manager.org.apache.juli.AsyncFileHandler.level = FINE 3manager.org.apache.juli.AsyncFileHandler.directory = /data/logs 3manager.org.apache.juli.AsyncFileHandler.prefix = manager. 4host-manager.org.apache.juli.AsyncFileHandler.level = FINE 4host-manager. https://www.161616.top/apache-httpd/ Sun, 16 Oct 2016 00:00:00 +0000 https://www.161616.top/apache-httpd/ httpd下载地址：Historical releases 安装httpd bash 1 2 3 4 5 6 7 $ ls ABOUT_APACHE buildconf emacs-style INSTALL LICENSE os srclib acinclude.m4 CHANGES httpd.dep InstallBin.dsp Makefile.in README support Apache.dsw config.layout httpd.dsp LAYOUT Makefile.win README.platforms test build configure httpd.mak libhttpd.dep modules README-win32.txt VERSIONING BuildAll.dsp configure.in httpd.spec libhttpd.dsp NOTICE ROADMAP BuildBin.dsp docs include libhttpd.mak NWGNUmakefile server httpd 编译参数 参数选项 注释说明 ./configure 配置源代码树 –prefix=/usr/local/apache2 体系无关文件的顶级安装目录PREFIX，也就Apache的安装目录。 –enable-module=so [-enable-deflate] 打开so模块，so模块是用来提DSO支持的apache核心模块 –enable-deflate=shared [-enable-expires] 支持网页压缩 –enable-expires=shared [-enable-rewrite] 支持缓存过期控制 –enable-rewrite=shared 支持URL重写 –enable-cache 支持缓存 –enable-file-cache 支持文件缓存 –enable-mem-cache 支持记忆缓存 –enable-disk-cache 支持磁盘缓存 –enable-static-support 支持静态连接(默认为动态连接) –enable-static-htpasswd 使用静态连接编译htpasswd–管理用于基本认证的用户文件 –enable-static-htdigest 使用静态连接编译htdigest–管理用于摘要认证的用户文件 –enable-static-rotatelogs 使用静态连接编译rotatelogs–滚动Apache日志的管道日志程序 –enable-static-logresolve 使用静态连接编译logresolve–解析Apache日志中的IP地址为主机名 –enable-static-htdbm 使用静态连接编译htdbm–操作DBM密码数据库 –enable-static-ab 使用静态连接编译ab–Apache服务器性能测试工具 –enable-static-checkgid 使用静态连接编译checkgid –disable-cgid 禁止用一个外部CGI守护进程执行CGI脚本 –disable-cgi 禁止编译CGI版本的PHP –disable-userdir 禁止用户从自己的主目录中提供页面 –with-mpm=worker 让apache以worker方式运行 –enable-authn-dbm=shared 对动态数据库进行操作。Rewrite时需要。 以下是分门别类的更多参数注解，与上面的会有重复 用于apr的configure脚本的选项： 可选特性 –enable-experimental-libtool 启用试验性质的自定义libtool –disable-libtool-lock 取消锁定(可能导致并行编译崩溃) –enable-debug 启用调试编译，仅供开发人员使用。 –enable-maintainer-mode 打开调试和编译时警告，仅供开发人员使用。 –enable-profile 打开编译profiling(GCC) –enable-pool-debug[=yes|no|verbose|verbose-alloc|lifetime|owner|all] 打开pools调试 –enable-malloc-debug 打开BeOS平台上的malloc_debug –disable-lfs 在32-bit平台上禁用大文件支持(large file support) –enable-nonportable-atomics 若只打算在486以上的CPU上运行Apache，那么使用该选项可以启用更加高效的基于互斥执行 的原子操作。 –enable-threads 启用线程支持在线程型的MPM上必须打开它 –disable-threads 禁用线程支持，如果不使用线程化的MPM，可以关闭它以减少系统开销。 –disable-dso 禁用DSO支持 –enable-other-child 启用可靠子进程支持 –disable-ipv6 禁用IPv6支持 **可选的额外程序包** –with-gnu-ld 指定C编译器使用GNU ld –with-pic 只使PIC/non-PIC对象[默认为两者都使用] –with-tags[=TAGS] 包含额外的配置 –with-installbuilddir=DIR 指定APR编译文件的存放位置(默认值为：’${datadir}/build’) –without-libtool 禁止使用libtool连接库文件 –with-efence[=DIR] 指定Electric Fence的安装目录 –with-sendfile 强制使用sendfile(译者注：Linux2.