打开浏览器，输入一个网址，敲下回车，页面出来了。这个过程背后至少有七八台服务器在同时干活——有的负责解析域名，有的负责转发请求，有的专门渲染页面。你看到的那个搜索框，可能来自一台服务器；你点击搜索后返回的结果列表，来自另一台。这些机器之间靠HTTP协议说话，而它们提供的这套能力，就叫Web服务。

说白了，Web服务就是让程序跟程序之间通过互联网互相调用。它不负责好看，不负责交互，只负责在收到请求后返回数据。比如你手机上的天气App，它自己不会算温度，而是向气象服务商发一个请求，对方返回JSON格式的数据，App再把它渲染成你看到的界面。这个“气象服务商”提供的就是Web服务。

我去年帮一个做餐饮的朋友搭过一套点餐系统。前端是小程序，后端拆成了三个服务：菜单服务、订单服务、支付服务。菜单服务只干一件事——把菜品信息从数据库里捞出来，转成JSON吐给小程序。订单服务接收下单请求，写库，然后通知支付服务。支付服务对接微信支付接口，处理完回调再通知订单服务改状态。三个服务各跑各的进程，通过HTTP互相调用。好处很明显：菜单服务挂了，支付照样能用，只是点不了菜；支付服务要升级，不影响菜单浏览。这就是Web服务拆分的价值——故障隔离和独立部署。

但别以为Web服务就是RESTful API加JSON。它可以是SOAP，用XML传数据，笨重但严谨，银行和电信系统里还大量活着。也可以是GraphQL，让客户端自己决定要哪些字段，省得返回一堆用不上的数据。甚至gRPC也算，用Protocol Buffers二进制传输，速度比JSON快不少，微服务内部通信常用。选哪种，看场景。对外公开的API，RESTful加JSON最省事，文档好写，调试方便。内部服务之间追求性能，gRPC更合适。

有个细节值得注意：Web服务本身不处理业务逻辑之外的“状态”。HTTP是无状态的，每次请求都是独立的。你登录后拿到的token，得在每次请求时带上，服务端才知道你是谁。有人觉得这麻烦，但正是这种无状态特性，让服务可以水平扩展——加一台机器，流量分过去就行，不用同步session。我见过一个团队非要在服务端存session，结果扩容时折腾了一周，最后老老实实改回token方案。

另一个常被忽略的点是超时和重试。Web服务调用是网络操作，网络就会抽风。你不设超时，一个慢请求能把线程池占满，整个服务雪崩。你设了超时但不设重试，偶尔的抖动就变成用户可见的失败。重试也不能瞎重试，得配合退避策略，不然会把下游服务打垮。这些经验，文档里往往不写，踩过坑才知道疼。

Web服务听起来是个技术概念，其实它更像一种组织协作方式。把功能拆成一个个独立的服务，每个服务由一个小团队维护，接口定义清楚，各自迭代。Amazon内部早年强制要求所有团队通过服务接口通信，不许直接读对方数据库，就是这个道理。接口就是契约，契约稳定，协作才顺畅。

下次你打开一个App，看到内容加载出来，可以想想背后有多少个Web服务在接力。它们不露脸，但撑起了整个互联网的运转。