服务调用流程服务调用异常请检查业务参数( 三 ) _服务

RS处理并且应答该请求，这个回报的源地址为RS的RIP地址，目的地址为DIP地址，此时的地址二元组为<src:RIP A,dst:DIP> 。

DS在收到该应答包之后，将报文应答客户端，此时修改应答报文的源地址为VIP地址，目的地址为CIP地址，此时的地址二元组为<src:VIP,dst:CIP> 。

做为七层负载均衡的Nginx在开始展开讨论之前，需要简单说一下正向代理和反向代理。
所谓的正向代理（proxy），我的理解就是在客户端处的代理。如浏览器中的可以配置的访问某些网站的代理，就属于正向代理，但是一般而言不会说正向代理而是代理，即默认代理都是正向的。
而反向代理（reverse proxy）就是挡在服务器端前面的代理，比如前面LVS中的DS服务器就属于一种反向代理。为什么需要反向代理，大体的原因有以下的考量：

负载均衡：希望在这个反向代理的服务器中，将请求均衡的分发到后面的服务器中。
安全：不想向客户端暴露太多的服务器地址，统一接入到这个反向代理服务器中，在这里做限流、安全控制等。
由于统一接入了客户端的请求，所以在反向代理的接入层可以做更多的控制策略，比如灰度流量发布、权重控制等等。

反向代理与所谓的gateway、网关等，我认为没有太多的差异，只是叫法不同而已，做的事情都是类似的。
Nginx应该是现在用的最多的HTTP 七层负载均衡软件，在Nginx中，可以通过在配置的server块中定义一个域名，然后将该域名的请求绑定到对应的Upstream中，而实现转发请求到这些Upstream的效果。
如：
upstream hello { server A:11001; server B:11001;}location / { root html; index index.html index.htm; proxy_pass http://hello;}这是最简单的Nginx反向代理配置，实际线上一个接入层背后可能有多个域名，如果配置变动的很大，每次域名以及对应的Upstream的配置修改都需要人工干预，效率会很慢。这时候就要提到一个叫DevOps的名词了，我的理解就是开发各种便于自动化运维工具的工程师。
有了上面的分析，此时一个提供七层HTTP访问接口的服务架构大体是这样的：

文章插图
服务发现与RPC
前面已经解决单机服务器对外提供服务的大部分问题，来简单回顾：

域名系统解决了需要记住复杂的数字IP地址的问题。
PB类软件库的出现解决协议定义解析的痛点。
网关类组件解决客户端接入以及服务器横向扩展等一系列问题。

然而一个服务，通常并不见得只由本身提供服务就可以，服务过程中可能还涉及到查询其他服务的流程，常见的如数据类服务如Mysql、Redis等，这一类供服务内调用查询的服务被成为内部的服务，通常并不直接暴露到外网去。
面向公网的服务，一般都是以域名的形式提供给外部调用者，然而对于服务内部之间的互相调用，域名形式还不够，其原因在于：