web服务器的配置不是后端也应该知道的「 web 服务、子服务、服务的部署」

链接:webfe.kujiale.com/draft-fu-wu-bu-shu-fen-xiang/

什么是网络服务

1.定义

我们先来看一个很流行的定义，来源于wiki。

Web服务是指一个平台通过Web向其他平台提供服务。

更专业的定义呢？让我们来看看W3C对web服务的定义。

网络服务是一个软件系统，它使不同的机器能够在网络之间交互操作。

2.元素

要实现一个平台在网络之间调用另一个平台的服务，至少要明确三点:

如何将平台上的代码作为服务暴露出去供其它平台调用；使用什么样的网络协议通信；使用什么样的格式作为通信内容。

从WSDL了解网络服务的要素

为了回答上述问题，我们可以简单地理解什么是WSDL、网络服务描述语言和网络服务描述语言。我们知道服务的提供者实际上是由代码编写的，而服务的调用者通过发起网络请求来调用服务。一般来说，WSDL所做的是描述如何根据调用者发送的网络请求找到服务提供者，然后找到要运行的代码，从而得到结果并返回给调用者。

WSDL是一个基于XML格式的文档，它包括两部分，抽象定义和具体定义。

WSDL的抽象定义

WSDL的抽象定义独立于服务平台和服务实现语言，它定义了服务用来与呼叫者通信的网络协议和消息格式。网络协议不限，可以是http、ftp、smtp等网络传输协议，但大多数情况下我们用的是http协议。消息格式也各不相同。最初唯一广泛使用的消息格式是基于XML格式的SOAP和简单对象访问协议。后来REST流行起来，出现了基于REST+XML的消息格式，然后发展成现在应用最广泛的REST+JSON。

WSDL的具体定义

WSDL的具体定义与平台和语言有关，定义了具体的服务调用，请求参数和返回参数是什么，代码的哪一部分可以得到结果。

咖啡馆的比喻

我们用咖啡馆来比较WSDL的工作原理。咖啡厅是服务商，提供点餐、取餐、付费等服务。Cafe的员工手册相当于提供服务的代码，客户是服务的调用方。WSDL的抽象定义定义了顾客如何找到咖啡馆的位置，以及顾客和咖啡馆员工使用何种语言进行交流等。WSDL的具体定义定义了每一个具体的服务，比如下面的订单服务，客户需要提供什么，员工可以在员工手册的哪一页找到下单的操作流程，员工会给客户返回什么等等。

WSDL文档可以由服务实现代码自动生成，相反，代码框架可以由已定义的WSDL文档生成。

3.应用模式

两种最常见的网络服务是远程过程调用和REST表达状态转换。本质上，两者都定义了规范，一个是面向过程的远程调用规范，一个是面向资源的远程调用规范。

远程过程调用

RPC，远程过程调用，远程过程调用，定义了平台间面向过程的服务调用的规范。它的基本思想是在一个平台上提供多个函数过程，作为另一个平台调用的服务。因此，基于RPC的服务需要关注“我该怎么办？”。RPC规范与协议无关，可以使用各种网络协议来实现。

REST表达状态转移

那么什么是REST呢？不知道REST也没关系。如果您已经接触过GET、POST、PUT和DELETE等请求，请不要怀疑我们通常调用的这些http请求大多基于REST规范。基于REST规范设计的api也称为RESTful api。这样的api的主题一定是资源，它关注的是“我想对某个资源执行什么样的操作”。REST为什么能流行起来？这也是我们为什么要用面向对象的思维来编程的原因。一切都是对象，一切都是资源。在这里，我推荐一篇非常热门的解释REST规范的文章，向我老婆解释RESTful是什么。

RPC与REST的比较

一般来说，PRC与网络协议无关，而与流程有关。REST基于http协议，与资源有关。下图说明了REST服务(左)和RPC服务(右)对于与用户相关的相同操作的设计差异。

那么在具体的使用场景中应该如何选择这两个设计规范呢？我觉得两者的取舍可以类比为函数式编程和面向对象编程，各有适合自己的场景，甚至在某些场景下，两者都有可能使用，各有利弊。重要的是要了解这两个设计规范的本质和初衷，并根据实际场景和个人使用习惯进行初步选择。

网络服务和子服务

在谈子服务之前，我们继续之前咖啡馆的假设，从而了解什么是子服务，为什么需要子服务。

我们为什么需要服务

试想一家咖啡馆的正常运营需要以下职能人员的参与。

前台：负责创建、修改、删除客户的订单收银员：收取订单相应的费用、找零、管理咖啡馆的日常支出服务生：为客户配送咖啡到相应的座位上，回收餐具清洁工：维护店内清洁、桌椅摆放、空调灯光等硬件设施经理：保证店铺正常运行，解决问题和异常情况

对于这些职能人员，有三个核心要素:

他们所做的工作有明确的界限划分；他们互相之间可能需要进行交流；他们共同维护了咖啡馆的运作。

为什么一个非常厉害，无所不能的人不承担咖啡馆里所有的工作？这很容易理解:

首先厉害的人比普通人更加难找到；而且要同时兼顾这么多的工作内容是更加容易出错的；还有最重要的一点是，如果他生病了，整个店就完全没有办法运作下去。

那么把咖啡馆的例子映射到web服务，提供单一的web服务来支持整个咖啡馆的运营，自然是不合理的:

想要维护好一个大型的系统比维护好一个小型的系统更加困难；业务逻辑冗杂的系统更容易出错；如果这个系统的一小块内容出现问题很容易导致整个系统的崩盘。

那么如何拆分一个服务系统，答案是分服务。我们按照职能划分将整个系统分为五个子服务，分别对应上述五个职能人员。

订单管理服务账户管理服务餐具管理服务店内环境管理服务性能监控与异常处理服务

这些子服务的核心要素如下:

这5个子服务所提供的接口有明确的界限划分；子服务之间可以互相调用；共同保证了整个咖啡馆的运作。

在理解了子服务的概念以及web服务为什么需要子服务之后，一个新的问题出现了:如何合理的拆分子服务？如何管理多个儿童服务？子服务之间是如何通信的？

这里不得不提到SOA。

通过SOA架构组织子服务

SOA，Service Oriented Architecture，是一个面向服务的架构设计，也是一个规范，定义了如何管理服务的集合，以及服务之间如何进行通信。本质上与web服务和子服务没有绝对的依赖关系，甚至比web服务出现的更早。但是，人们已经在web服务中发现了它的用途，这意味着SOA正好可以在web服务的管理中体现它的价值。这样一来，几乎所有的SOA应用场景都与web服务相关，这也在一定程度上导致了这两个概念的混淆。

既然SOA框架管理服务的集合，那么它除了简单的拆分服务之外还做了什么？

让我们看看下面这个简单的例子。假设我们想把整个系统分成四个子服务:帐户、C2D、ASK和设计。左边是简单的服务拆分，右边是基于SOA框架的服务拆分。

左边：单纯的进行了服务拆分，形成了4个互独立的服务。这里其实就出现了两个问题：客户端需要关心我请求的 api 到底是属于哪个服务的，然后再往相应的服务端发送请求；虽然服务做了拆分，但是如果其中一个服务出现问题挂掉了，那么整个架构中的服务都不可用。右边：将这4个子服务作为一个服务的集合，并简单地应用了 SOA 架构。可以看到除了四个子服务之外，最上层还多了一个 gateway，而最下层也多了三个底层模块。最下层的三个底层模块很好理解，有一些工作是每个子服务都需要做的，比如版本控制、性能监控等，底层就是抽出了这样的公共模块以便子服务复用。最上层的 gateway，网关，顾名思义，你们如果想访问我管理的这些子服务，直接访问我就好了；也就是说客户端只需要向 gateway 发送请求，gateway 会根据所配置的规则将请求转发到正确的子服务上，这也就解决了上文所述左边的设计中遇到的两个问题。

子服务及其部署

1.服务的实现

Web服务是一个软件系统，由代码构成。那么这样的软件系统是如何从大量的代码转化为稳定的、可访问的、可更新的服务的呢？

具有一定流量的服务通常由这样的结构组成。

上层是负载平衡器，下层是多个相同的节点。

负载均衡器：将针对这个服务的请求，合理的分发到下面的某一个节点上，以尽量达到这样的目的：请求尽可能的被完成（例如其中一个节点没有正常运行不会导致请求失败）、每个节点承担均匀的压力（例如同时有一万个请求，不至于扎堆到同一个节点上去导致节点出现性能问题）。负责均衡器可以通过网络设备、虚拟 ip、nginx 反向代理、甚至仅仅是一段代码来实现。节点：每个节点都是等同的，每个节点上都运行着相同的服务，等待处理负载均衡器转发过来的请求。节点可以是一个物理机、虚拟机、也可以是一个 docker 容器。

2.服务部署

一个服务的部署就是简单的把服务的软件系统的最新代码克隆到每个节点上，然后在每个节点上运行服务。那么服务更新只不过是每个节点的重新部署。

但是不要忘记在一个节点上重新运行服务会导致该节点上服务的短暂罢工，那么在更新服务的同时如何保证服务不会为客户端挂机呢？这时候需要一定的部署策略。

注意:在下图中，绿色节点表示尚未更新的节点，蓝色节点表示已更新的节点

1)滚动部署

滚动部署，一次只更新n个节点，等待前n个节点部署完毕，再更新下n个节点，以保证最多n个节点同时不可用。

以下四个图是滚动部署过程的示例，其中n为1。

首先更新第一个节点。