设计一个库，带算法参数，用于多server环境

设计一个库，带算法参数，比如这样的库：input是一些页面，output是排序好的页面，库里边会根据页面的signal算一些score，最后按score排序，其中参数具体指的是：一些threshold或者加减一些数值，考虑到内部算法参数会适当调整或者做实验，因此这些参数不能写死。

方法1：做为命令行参数，当这个库被server或app所引用时，需要在启动的时候设一下，比如./server --filter_threshold=0.3 等。这种设计的好处是简单且调整参数方便。不好的地方是，这个库如果被多个server所用，且这几个server要互相call的时候共享了一个参数，就会有潜在的问题，一旦这个共享的参数变了，这几个用它的server必须同时重启，否则结果就会受影响。对于此类问题，通常只能在上线的时候人工注意一下，避免犯错。当然，最理想的，当然是在设计的角度避免这种多server共用一个参数的设计，后期维护会比较烦。

当然，如果几个server都只是重新独立调用该module，而非重用前面server的结果并继续计算，其实在逻辑上也是相互独立的，共享module是没有问题的。

方法2：做为函数参数。为了避免上述问题，可以做为函数参数传入，这样，无论多少个server来call，共用多少个函数，都没有问题。麻烦的就是，如果参数很多（50个以上），甚至不同的server会有不同的参数，但为了使用，每个server都必须设置别的所有server的参数，就麻烦。如果c++做，可以搞个struct把所有参数包起来，并在struct内设定默认值，另外如果嫌set啥的代码很罗嗦的话，可以考虑用c++的define之类的技巧减少这种模版式代码

方法3：flag有namespace的概念（需要调用code的时候人为设定），各server有不同的namespace，且只调用自己namespace的flag。同时module保证兼容各种namespace，这样一来，虽然flag冗余，但保证独立。也顺便给设计者压力，尽量减少share的flag

这个问题会延伸出另一个如何上线问题，如果负责算法的server更新了，如何保证各客户端（比如call它的其他server）都工作正常？举例：假设Server A, B 都call Server C (算法module只运行在C上)，如果算法module做了大改，怎么保证Server A和B运行依然正常，一方面是server不crash，另一方面是server处理数据的行为正常（比如结果的quality，如果跟钱有关，那revenue会不会有负面影响？）

在回答这个问题前，先解决一个简单的问题，如果只有server A和C，如何更新C：

上线(binary release)流程：C起码得2台机器，先更新一台，导部分traffic，看是否运行正常（比方说不crash之类的），一段时间后没问题，traffic都导过来，另一台也更新。如果是大公司，就有n个data center，同理，一个一个轮着更新好了，就是测试流程会繁琐一点。

实验(experiment)流程：如果改动很大，就需要分流traffic做对比实验，同样2台机器，比较log，设定指标，看quality或者revenue有啥变化。这个需要A和C同时配合才能进行。大体来说，分2种，各有千秋：

1. client(这里指Server A，下同)分流：client分流traffic，并传入experiment_id到server，server根据不同experiment_id改参数，然后client对比log看结果。简化的case是让版本号化的管理flag，这样client可以选择性地实验和升级。

2. server(这里指Server C，下同)分流：client传入event_id（区分log所用）到server，server来sample部分event_id来做对比实验，最后要根据event_id来把server和client的log join起来，对比结果。

好，已经搞定1对1的情况了，其实n对1的情况也同理，做对比实验的时候，同时看各client的log变化就可以了，如果都positive，恭喜恭喜，上线吧。如果有的client涨，有的跌，那就权衡或者继续tune算法module了。地球人都知道：有个合理的上线流程，会省掉很多大家的烦恼。