【转】FreeWheel 于晶纯 架构四原则

从DoubleClick的DART网络广告系统，到FreeWheel的MRM系统，无论是从产品创意还是系统架构，于晶纯都不讳言从DART系统有所借鉴。在DoubleClick的那些经验和教训，形成她对架构独特的认识，并将其应用到MRM系统架构中。

　　原则一：搞清用户是谁

　　设计一个系统，必须搞清楚用户是谁？和哪些其他应用有关系？比如MRM，它的用户是视频网站、内容提供商和广告商。MRM的架构会考虑这些视频网站的架构，但是又不局限于某一网站架构。因此，明智的选择是开放型的，比如HTTP接口、XML格式等。

　　原则二：理顺业务逻辑

　　什么是MRM架构遇到的最大难题？于晶纯的回答是业务逻辑的复杂性。虽然一致性的地方是有，也存在规律可循，但是MRM作为一个发明和创造，其独特之处在于视频是作为内容整体。相比于传统媒体广告，广告内容是固定在一个位置的，不论是报纸、杂志、广告牌还是电视机屏幕。但是视频广告是流动的，各个视频网站都有可能播放同一个内容，用到同一个广告。如何实现这样复杂的业务逻辑是MRM架构最大的难题。

　　原则三：高度抽象共性

　　开发一个系统或软件，如何确保精准实现功能、更低代码Bug，如何在高流量、高性能的压力下运转自如？实现这些靠的是架构设计。

　　开发高效能、高稳定的软件系统是有一定共性的。在设计中要充分考虑并高度抽象这些共性，避免犯别人犯过的错误。于晶纯在DoubleClick工作十余年，目睹并亲身参与改造DART系统，看到它从一台角落里的服务器到遍布全世界的数据中心，日数据处理量达190亿Bit，故障率达到99.9% Uptime。正是这些从经验和教训中抽象出来的共性，保证了MRM的高性能、高流量设计实现。

　　原则四：架构需要监控

　　2007年，于晶纯带着自己的团队开始按照自己想象中的需求设计MRM系统的架构。幸运的是，闭门造车的结果还算令人满意，MRM系统基本满足用户80%的需求，这些得益于整个团队对业务的深刻理解和于晶纯在DoubleClick的相关经验。

　　在于晶纯眼里，架构是有生命的，是不断变化的。因此，她认为，设计架构不能只想着要考虑到所有的问题，设计出一个能够包容所有可能问题的架构，这几乎是不可完成的任务。因为变化是绝对的，架构总会需要修改，关键问题在于何时改？一定不能在系统问题频出、已经来不及补救的时候才去考虑修改，而要在潜伏的问题逐渐露出端倪之前展开行动。因此，架构是需要监控的。通过监控各项指标，在最适当的时候对架构进行最适当的修改，以满足变化的需求。