【IT168 专稿】

    于晶纯是业界少有的女CTO。虽然在谈到自己个人发展时，她提到模糊性别。但是，模糊性别本身就说明性别的存在，那就正视性别吧。所以，介绍于晶纯时，依然会说这是一位女程序员、女架构师、女CTO。

    在事业的高峰，于晶纯选择了从DoubleClick离开创办自己的FreeWheel，选择了放弃高额的分红开始充满未知数的创业。从目前的情况看，她的选择是正确的。FreeWheel独创的MRM（Monetization Right Management）系统一推出就获得用户订单。从今年1月产品上线，已与CBS、华纳兄弟在内的20多家视频内容提供商、传播商和广告商签约。对于未来，于晶纯充满了自信。这种自信来自于对公司3位创始人的完美组合，来自于对开发团队能力的肯定，更来自于对MRM系统本身的自信。

    从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的相关经验。

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