eBay Architecture(9)–Automate Everything

IT系统也不是刺绣，手工制作的才值钱。工程师是很贵的，自动化系统不容易出错，方便维护，所以能够自动化最好了，最好是自适应的自动化系统，目标函数是利润最大化！

• Prefer Adaptive/Automated Systems to Manual Systems
• Motivations

如果看了我前面的BLOG就这到这个方法论了，从架构师关心的5个方面来分析问题：

•  
  • Scalability
    1. Can scale with machines, not human
  • Availability / Latency
    1. Can adapt to changing environment more rapidly
  • Cost
    1. Machines are far less expensive than humans
    2. Can learn / improve / adjust over time without manual effort
  • Functionality
    1. Can consider more factors in decisions
    2. Can explore solution space more thoroughly and quickly

Automation Patterns
– Adaptive Configuration
– Machine Learning

 

 

Automate Everything[Adaptive Configuration]

其实这个思想很清楚，就是希望系统能够根据需求自己调整配置，很多时候配置文件是这样的：

NumThreads=5
HostName=Arrowpig
LoadPeriod=15 min
…

这些参数需要工程师手动设置，这些配置值得设置需要有对系统的工作机制的理解做后盾，而这些细节的理解会耗费Operation Team很大的精力，而他们更关心的是系统的性能，而性能的描述并不是这样的，更直接的方式会是：我希望在15秒内完成所有的事物处理；我希望事务延迟不超过2个小时；我希望我的系统资源利用率达到80%…

第二个方面是如果系统要求有变化，比如说碰到新品上市，系统Traffic一下子增大，系统能够自动调整配置，而不是需要手工一个一个server去重新调整。

最二个方面是来自外部的需求改变，而第3个方面就是如果系统内部的结构，Capacity，部署等发生变化，系统也能自我调整。

举个具体的例子，就是前面提到的Event Consumer的配置

 

我们希望Event Consumer能够：

1. 直接使用"需求"来定义配置
2. 能够对外部变化自适应调整配置
3. 能够对内部变化自适应调整配置

Pattern: Adaptive Configuration

• Define service-level agreement (SLA) for a given logical event consumer
  1. E.g., 99% of events processed in 15 seconds
• Consumer dynamically adjusts to meet defined SLA with minimal resources
  1. Event polling size and polling frequency
  2. Number of processor threads
• Automatically adapts to changes in
  1. Load (queue length)
  2. Event processing time
  3. Number of consumer instances

Automate Everything[Machine Learning]

这是个eBay经常问自己的问题：如何才能提高用户的搜索体验？如果学过自动控制的同学应该都知道，系统自我完善的一个常见的方法就是引入反馈系统，设计反馈系统的时候首先要设定一个目标，我们的目的就是要是系统的输出尽量接近这个目标，然后讲误差返回给输入，由系统进行自我调整，使得下一次的输出比上一次更加接近目标。

同理，eBay的搜索引擎希望展示给用户的页面，模块，物品正是用户想要的，最近引入Best Match也是在往这个方向努力。可是问题是人跟人是不一样的，这个用户想要的并不一定是那个用户想要的，所以eBay要收集一切可能有利于搜索引擎的反馈系统作出正确判断的信息，比如用户行为view page,bid item,view related item, popular query…，然后离线分析，再把分析后的结果部署出去使得下一次做判断的时候可以使用更新的决策数据。

由于变化太多了，这样复杂多变的系统很难由人工来调整参数从而达到最优的。而且你也很难论证我们的反馈模型就真实地模拟了站点上的情况，模拟了用户的行为。于是实践出真知，每次决策系统可以推荐几个候选方案，让一部分用户使用方案1，一部分使用方案2… 然后看，哪个方案效果好，如果1好，以后1被推荐的机率就会加大…Does That Make Sense？

我们看一下图和Randy的英文解释:

Pattern: Machine Learning

• Dynamically adapt experience
  1. Choose page, modules, and inventory which provide best experience for that user and context.
  2. Order results by combination of demand, supply, and other factors (“Best Match”).
• Feedback loop enables system to learn and improve over time
  1. Collect user behavior.
  2. Aggregate and analyze offline.
  3. Deploy updated metadata.
  4. Decide on and serve appropriate experience.
• Best Practices
  1. "Perturbation" for continual improvement.
  2. Dampening of positive feedback.

好了，到现在，策略3–Automate Everything就简单的介绍完了，下一篇开始介绍最后一个Principle Strategy： Remember Everything Fails 。