mirror of
https://github.com/oldratlee/translations.git
synced 2026-04-13 17:51:58 +08:00
translate figure-01
This commit is contained in:
@@ -60,7 +60,7 @@
|
||||
|
||||
宏观上看,用户通过它们浏览器发送请求与`Google`交互。请求进入`Google`的服务系统后,会先后被多个服务处理(运行在服务器上的程序),然后产生面向用户的结果页。比如,可能有一个服务决定与查询最相关的原生搜索结果,另一个服务决定与查询最相关的广告,还有一个服务将原生搜索结果和广告结果组织到结果页,返回给用户。见图1。一方面,这种模块化可以让我们降低延时(不相互依赖的过程可以并行),显然,原生的搜索过程与广告搜索过程是相互独立的,并能更快速的试验(每个服务都可以独立地进行,并且模块化的测试可以进行更快速的发布)。另一方面,如果要求每个请求最多只进入一个实验,那么模块化就需要更精心地设计。可能存在的问题有流量饥饿(上游模块的实验可能优先处理了所有请求,导致下游模块的实验没有请求),和偏置(`bias`)(比如,上游模块的实验处理了所有英语的请求,导致下游模块的实验就只有非英语请求)。
|
||||
|
||||

|
||||

|
||||
**图1**:一个请求经过多个模块的例子,信息(和时间)都是从左流向右
|
||||
|
||||
每个服务都有二进制推送和数据推送。二进制推送是指发布新的程序(`Bug`修复、性能提升、新特性,等等),它一定时期进行一次(比如每周)。数据推送更频繁(比如,按需或是每几小时推送一次),并且这还涉及了推送更新的数据到相应的程序。数据推送中还包含了默认参数配置,参数是用来配置程序如何运行,比如,控制结果如何展示的服务也许有一个参数是决定顶部广告块的背景色。再比如,预测`CTR`的服务可能有参数是控制学习速度和收敛速度的。程序可能有几百个参数。新的特性可能会添加一个或多个参数:最简单的场景是,一个参数可以控制打开或关闭新特性,在更复杂的场景中,也许有多个参数决定新特性如果展示,有数值阈值决定新的特性是否被展示,等等。将程序和数据分离,意味着如果我们可以找到合适的分离方式,我们就可以同时得到快速影响线上服务的通路,和慢速影响线上服务的通路(程序是慢的通路,改变参数值是快速的通路)。
|
||||
|
||||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
Reference in New Issue
Block a user