7月9日下午，CSDN TUP第十一期“架构师沙龙——互联网研发之道”在中国科学院计算技术研究所一层报告厅举行，本次活动邀请了业内研发实力很强的腾讯和豆瓣的嘉宾来分享互联网产品研发经验，业界超过300名技术管理者来到了现场。腾讯搜索运营部研发管理总监黎娟，腾讯R&D项目总监王晶，腾讯宠物客户端主程序、高级软件工程师黄朝兴，豆瓣网技术总监耿新跃，豆瓣网QA主管解彦博发表了精彩演讲。
以下是腾讯宠物客户端主程序、高级软件工程师黄朝兴的演讲实录(仅供参考)：
我是一个典型程序员，今天来的同学都是程序员，在这里就是进行一个程序员的交流会。最开始我们讲敏捷的课程，当时我们套用一个敏捷主题，我讲的是一个故事，从09年开始我们做了一个宠物客户端重构故事，故事里面有一些辛酸和喜悦，跟大家分享，两年前我做这个项目，5年前我还是一个学生，跟多数程序员一样写代码。我要与大家分享PPT的几个部分，第一是我们开始怎么启动这个项目，然后讲讲这个架构，最后讲一下我们运营效果。最后讲一下作为程序员我自己成长经历和感悟。
我是做客户端的，我想问一下，刚才王晶同学提到客户端可能有很多困难，最重要困难就是发布和普及，我们同学谁可以回答我一下通常情况下客户端普及需要多久？这个流程是很漫长，本身普及出去有可能是半年，有可能一年以后我们还有历史版本维护这些版本我们有很多包袱。所以说客户端同学不满意了，一个周期是多久，一周发23个版本我们很惊讶是不是非常羡慕，因为当时我们项目情况遇到比较大的危机，每周发布，每次从客户端发布遇到大量用户流失，三个月发一次版本，刚才说四个月，我们三个月发布一次，花一个月时间普及，通常客户端是比较普通效率还是太慢，然后我们客户端经常有问题，因为版本比较大，经常加班延期。
非常非常痛苦，程序员有谁感受到这种痛苦呢？所以我们要解决这些问题，套用这在黑暗中向往光明绝望中寻找希望，我们快速发布，快速普及无须安装？我们回答是可以做到这一点。我们看一个演示。客户端重构之前效果，可以数一下多少部署，通常情况下软件都是这样的，看一下我们重构后的效果。重构之前我们点了一下发布，重构以后我们第一步首先看到的是宠物图标，接着可以看到宠物形象，可以看到宠物上面按纽逐步出来，这个时候的话按纽出来的时候我们已经可以对这个按纽功能进行操作，可以进行喂食，洗澡这个是我们产品功能是逐步出来的。同时给这个架构起了一个比较牛的名字。
体验完产品功能以后，回顾一下宠物本身的历史PPT里面有几个线，有我们最高是活跃用户，下面是PCU，还有我们有效用户，其实这里面反映我们做得不错了，我们产品从以前逐渐到现在PCU接近300万，过去几年做得不错，我们想说我们遇到很多的危机，看看我们几个拐点，每一个拐点每一次发布我们产品带来的危机，第一个拐点当时我们发布了一个新版本，活跃用户降到历史新低，我们犯了一个错误，教训深深教育我们要去变革，我要说的是我们有这个架构刚才演示的，所有的问题困难，都可以快速反映解决它。
客户端架构分几个历史，第一代客户端架构跟初级程序员一样，一系列技术一个类有三万行代码。第二代架构我们进行分层设计，做网络层，逻辑层，分层设计。第三代架构我们已经实现了插件化，每功能插件包括自己UI，自己逻辑，数据协议我们称之为第三代架构，我们真正要说第四代架构，我们称之为微内核客户端架构，这个图左边部分就是我们客户端内核，中间是我们版本server右边是我们资源服务器。架构基本示意图就是左边内核是放在客户端的，所有插件资源放在服务器，按照表述加载这些插件，我们看到这个图宠物打工学习按纽背后就是两个插件而已，每个插件后面包括自己资源是放在服务器上面的，插件架构比普通多了一个把资源放在服务器，普通插件架构把功能资源放在本地，这个就是资源放在服务器，为了踏出这一小步，我们要做很多事情，而且每件事情必须做到极致，第一件就是插件体系，资源更新逻辑，还有最基础客户端功能的解耦，我们说插件用一个XML表述稳健的版本来实现客户端版本控制，一个版本对应一个表述文件，我们看一下我们的版本表述很简单，这是我们客户端表述，做了一个版本工具展示出来，后来发现是多余的。
这个插件背后有自己的插件配制，有三个原则就是简单通用和微小，为什么要足够小，因为小，才发布容易，简单才能保障可靠，不是适合某一个产品，所有产品都是通用的，最后设计出来我们内核只有600K很小。其实要保障资源更新逻辑和可扩性我们做了一个事情文件该名更新，是互联网行业做的一个简单经验，担心我们文件被互联网运营企业给我们分享。更新过后会形成垃圾，垃圾清理。这些都是小的过程，我们不说了，同时再回顾一小宠物客户端架构，简单分两部分，我们称内核放在本地，插件放在服务器上面，插件分成服务器插件和逻辑插件。
我会讲一下设计的思路，从客户端分服务器模块和逻辑性www.canadagoose-website.us模块，服务器模块可以看到下面这部分是简单基础模块，下面一部分包括宠物菜单典型UI服务，还有我们协议服务，数据服务，还有最重要一个部分我们解耦。上层才是我们插件逻辑，相互之间是完全不依赖，开发这个功能发布出去不会影响任何周边功能，完全没有依赖。架构基本组织方法我们要完成一件事情，第一是解耦，这个功能竖向划分。
在看一下传统客户端解耦方式，第二代客户端架构，横向划分。第三代我们这样划分竖向划分，一个特性就是一个模块有自己UI，自己逻辑，协议，这个为我们奠定了一个基础，可以把一个特性作为一个资源放在服务器上，作为一个资源包进行发布。再看一下刚才的宠物小特性，有一些什么，就是UI逻辑协议，后台数据库都是竖向划分逻辑，解耦基本逻辑一个系统里面有稳定所有功能部分，抽象出来，变成一个服务，一个接口，所有变化变成一个子节点一个逻辑可以独立发布是一个基本思路。我们为了进行解耦我们进行工作还是很多的。数据，协议，UI解耦这个东西我们作为程序员应www.canadagoose-website.us该知道，我们说一下互斥状态解耦，我们把竞争性资源桌面作为资源用的时候，社区要用，要用资源的时候，但是桌边资源同时时间只能有一个人用，我们传统做法某一个模块协调这些关系，做到所有模块谁来分配资源，让每个模块用，这个时候你用，这个模块依赖所有模块功能协调会非常复杂，我们做了一个事情桌面做一个互斥资源，你优先级高我就给你，让所有系统之间完成解耦我不知道你，你不知道我，我争取到这个资源就用，没有争取到你就回去吧。
现在毕业生也可以像搭积木一样做很简单。我们在简单对比一下我们本身架构和我们微架构区别，我们加载器是一个内核只有600K，表述语言是XML，加载对象是插件，简单说这是一个软件浏览器，把WEB架构本身搬到客户端去。
下面说一些运营数据讲一个小故事，周三我们发布架构出去，申请了一个腾讯奖项，重大技术突破奖领导也认同我们的贡献，让领导体验一下，宠物菜单增加一个退出按纽行不行，要讨论一下他们说可以，同意了我们就做，周一提出这个需求，最后什么时候发布出去的，最后是周四发布出去，因为我们每周四固定发布一个版本，这个菜单已经做好了，只需要一行代码就可以完成这个，为了我们运营结构需要不要太过分，把这个东西发布出去了，老板也是我们用户提了这个建议用户需求我们就加了上去。
从外一个层面，客户端每次发布自动增量升级，当时只有20、30K发布，节约成本还是比较多，对比一下懒加载系统和普通增量升级，我们不用关心现有的版本，不用关心升级体验，用户也无需参www.canadagoose-website.us与，体验是非常平滑的，我们发布一个web一样很简单。
客户端一天实现全网平滑升级，无损用户在线，当时发布之前一天用户一千多万，现在是三千多万，但是真正产品成功还是产品做得好，技术做到支撑，我们一个团队里面共同完成这件事情。挑战还是存在的架构当时还没搭建的时候，做这个架构要不要做P2P应用当时没有做是希望简单，用P2P技术不能保障可靠，P2P也太大了。我们当时有比较大的压力，我不愿意冒额外的风险也是从项目角度考虑，最重要原因我们文件很小，为什么选择P2P呢。讲我背后的故事了，当时在09年9月的时候，客户端存在刚才几个拐点我们促成比较大的压力，发布新版本活跃用户降低怎么办这个事情，我的领导提出我们是不是做一个Web宠物，我是做客户端我就不服气，我说为什么要做Web版的？
第二天很早来到公司把这个写出来，发布出去，程序员提出这个想法别人没有提出，也没有做过怎么得到人信服，没有多少人支持，召集所有产品测试，一起宣讲这个东西要做这个事情，得到结果就是有什么用，一方面是技www.canadagoose-website.us术和产品沟通始终是一个鸿沟，我们产品还是有一个好处，虽然不理解这个事情，你是技术负责人，你做这个事情吧，我顶多是不支持你，反对你，当时在我看来，当时我觉得有点愤愤不平，这么好的架构居然没有人理解，现在想起来，作为产品他们不阻碍我，就是对我最大支持，最后从09年年底的时候，我做了第一个版本，就回家过年，10年3、4月份做了两个迭代发布出去，我们提第三代客户端架构就是我们基础，已经把整个基础解耦到极致，整个插件化，我们只做一进事情有是把插件放在服务器上，以前基础以前团队锻炼都是非常好的基础，导致我们比较顺利，基础是团队比较好，另外我们执行非常谨慎。
我是10年3月份才接触到敏捷，觉得敏捷不错，就拿回去www.canadagoose-website.us用了一下，3月份、4月份进行了一个迭代，每次迭代目标还有迭代风险分析，还有一个迭代关键时间点，我们当时进行一对一迭代，做得比较谨慎一点就是每一个迭代都进行了风险分析，高风险高价值的特性我们优先保障完成，其他放在后面。执行敏捷以前已经这样做，我们带着自己团队做的时候，其实我们当时是为了规避可能遇到风险，我们是多线开发，正式版本在一个线上开发，重构版本在另外一个线上开发，我们当时顶着比较大的压力。一方面我觉得整个过程比较顺利是什么，最开始发布之前，当时已经做好了准备，希望测试产品所有同学跟我们体验，发布之前推动所有同学到不内部体验，其实非常谨慎，发布之前还做了一件事情还旅游一次，当时压力真得很大，笑的比较灿烂背后还是很辛酸的。
互联网产品本身运营，运营节奏提出比较高的要求，我们所有游戏基本上每周一个活动，你不搞运营，活动人家就走，客户端无论采用什么手段，所有面临客户端发布基本的方法，大家可以参考一下。另一个思考就是，我们架构是软件浏览器思想，用这套架构很容易解决这个问题，发布也很方便，有赖于我们同学推广一下。其实本身是一个程序员，我在学校里面打工做一些网站，对Web有一些了解，在腾讯做了几年客户端技术，对于技术深入理解相对比较深入一点，在这里面都是比较资深的同学，首先我们要对我们自己队伍负责，包括我自己提出很多想法，但是真正做出来也不多只有寥寥几个，还有另外一个意见，对初级程序员，我在北京面试几个同学，对他们提出几点建议，我们要做一个对美有追求的程序员，Web化客户端在未来可能是一个趋势。谢谢大家。