本文是WOT2016互联网运维与开发者大会的现场干货，新一届主题为WOT2016企业安全技术峰会将在2016年6月24日-25日于北京珠三角JW万豪酒店隆重召开！

  2016年4月14-15日，在北京珠三角JW万豪酒店，51CTO举办了WOT互联网运维与开发者峰会。WOT秉承专注技术，服务技术人群的理念，自 2012年首次举办以来，历经八届，积累了大量的技术资源，成为广大技术从业者和技术爱好者一致认可的技术分享大会、交流和人脉拓展平台。会后，记者专访了本次大会监控与性能优化专场的沈剑讲师，他分享的内容是勇于探索商业模式的公司快速搭建立体化监控平台之路。

  沈剑，58到家技术委员会主席、首席技术官。曾任百度高级工程师，58高级架构师，C2C技术部负责人，58技术学院优秀讲师。目前，他主要负责58到家后端的技术管理工作，比如说架构部、后端平台部、基础服务部、DBA，还有测试平台等相关偏后台的技术工作。

  在本次WOT峰会上，沈剑老师分享了《勇于探索商业模式的公司快速搭建立体化监控平台之路》。沈老师是2015年9月份加盟58到家，当时整个到家的技术监控体系还没有搭建起来，他结合这几个月在到家做的一个监控系统来分享创业性公司如何快速搭建监控平台这一技术主题，比如58到家是如何小成本快速建立起服务器监控、进程监控、端口监控、接口监控、错误日志监控、业务系统监控等立体化监控体系，有怎样的经验及实践。

  记者：您的从业经历很丰富，高级工程师、架构师、技术讲师，您更偏向于哪个角色?您是如何轻轻松松实现各个角色间的切换?

  沈剑：我更倾向于架构师的角色，因为架构师需要帮助应用线解决应用中的实际问题，能够给公司带来很大的收益，而且在处理问题的过程中，我个人也有成长和提高，非常有成就感。技术讲师，也是我们技术委员会的一个工作职责，这一个角色是因为我个人很喜欢总结并将学到的一些技术点跟大家分享。

  沈剑：技术委员会日常负责招聘、技术培养和训练、职级发展等工作，具体包括社会招聘，人才教育培训，校招生的培训，各个职级人员的培训、职位晋升。其中很多工作是人力部门同事来主导，但是一些技术方面的工作，比如说技术的评审需要高阶的技术人员来评判，包括校园招聘，一些技术试卷的产出和一些技术面试等。技术委员会还有一项核心的工作职责，就是对公司技术发展趋势的把关和重点项目、重点系统的技术方案把关，对公司的技术战略发展提出建议。

  记者：您经历的几个产品线，它们的架构设计亮点有哪些，有哪些成功经验可以分享?

  沈剑：我就分享几个我曾经负责过的系统的一些特点，比如我之前负责过即时通信系统，即时通信系统和站点系统、电商系统不一样的地方是它是基于通知的系统，站点系统、电商系统都是用户往站点去发一个请求，实现响应一个页面。但是即时通讯系统，比如QQ，你即使没有向QQ服务发送任何请求，但是你的客户端会收到请求，它是基于通知的系统，要有独立通知的通道，这就需要有一个TCP长连接。所以，即时通讯系统的在线量、并发量，包括响应处理时间上面临很多技术挑战。

  我再举一个例子是推荐系统，原来在58同城负责推荐系统的架构设计，推荐系统和其他系统不一样的地方在于它是一个在线和离线相结合的系统。离线状态下，系统能计算出一些推荐结果，当用户实时访问的时候将会获取该推荐的结果，同时要支持分流的系统。普通的系统，任何用户去访问一个页面，可能获得的结果是相同的。但是对于推荐系统，每个用户访问同一个页面，系统根据该用户的历史行为、兴趣返回的页面，推荐出来的结果是不一样的。这就要求架构师在做架构设计的时候，要支持一个流量过来的时候，能够分配到不同的子系统，实现不同的页面推荐策略，获取不同的推荐结果。

  还有，针对因某些热门活动引发的短期瞬间流量过大，架构师在架构设计中要提前考虑到，对互联网的高并发在可用性、扩展性上做有明确的目的性的设计。为了应对高并发，系统要有很强的扩展性，比如能够最终靠增加机器，就能增加系统的性能，扩展性很好时，流量增加的时候，系统只要简单增加机器就可以。怎么样才能做好设计上的预留呢?常见的架构设计分为三层，站点层、服务层和数据层。站点层和服务层的设计准则，就是说服务无状态，系统不能保存任何数据，只要不保存任何数据，没有状态，通过加机器就可以简单实现扩充性能。数据层有状态，系统要做好水平切分，不能将所有的数据都保存在一台机器上，要水平分布在不同机器上，这样也能够最终靠增加机器扩充系统容量。这是比较专业的架构设计注意点。

  记者：最后一个问题，58到家技术发展中，您遇到的最严重的问题是什么?您和您的团队是如何通过架构设计解决的?

  沈剑：58到家是一个初创的公司，到现在发展不到两年的时间，创业的公司初期基本是业务跑得非常快，为了应对业务的加快速度进行发展，技术上的支持上也是怎么快怎么来，可能用了一些开源的方法。每个团队使用不相同的方法，帮助业务快速的迭代和发展，但是各团队各做一套，在整体的框架之内，有些事情可能就做重复了。比如说监控系统，A业务线实现了一个小的监控系统，B业务线也实现了一个小的监控系统，快速满足初期监控需求，但是在公司层面、更高层面，这个小监控系统就做重复了。我现在负责后端的一些部门，希望从底层架构设计上进行框架统一，在框架层面上就把这个监控系统实现了，涉及到这个监控系统的部门都能够正常的使用这一统一的监控框架，不需要每个业务部门单独去开发小监控系统了。以后，这些公用的工具平台和框架，能够在一定程度上帮助各个业务线去解决他们通用的痛点问题。