专访吕毅：链家网技术架构的演进之路
声明：本文选自InfoQ对于链家网架构师吕毅的专访的技术架构相关内容
原文：http://www.infoq.com/cn/news/2016/07/lianjia-architect-plantform
InfoQ：您提到链家网这两年在架构上做了很多的调整，可以谈谈链家网的架构演进历程吗？
吕毅： 链家网的架构演化的确从未停歇，从技术团队建立至今的两年时间，架构上大致分为两个阶段，如下图：
2014~2015年技术上关注两件事，一块是将链家集团曾交付外包实现的面向经纪人业务改造为自主研发，另一块是从零打造面向用户的业务链家网与掌上链家APP（目前已改名为链家APP），即第一年的技术架构重在业务的建设。 2015年至今，业务的逐渐成熟，引入了新的挑战。业务方向内的子业务细化伴随着链家新业务的开展，此时迫切希望抽离公共技术部分，避免重复造车的同时也希望由公共服务来支撑好业务线发展，让业务线更好的满足产品迭代。从2015年开始，一系列的公共服务的建设，构建成了整体技术架构上的服务层，同时也扩展了公司基础技术能力，并推动着建设起了系统、日志级的监控。
InfoQ：您对目前的架构满意吗？下一步优化的方向是什么？
吕毅： 从技术架构的演化可见链家网成立的两年间，技术架构从无到有、从有到完善，一切都在快速的发展着。我们目前的技术架构是充分满足当前的业务发展情况的。要说对架构是否有不满，的确是有的。如今链家网业务各个方向发展迅猛，技术架构上的压力不小，理想状态是希望技术架构在支撑业务时，时刻游刃有余，但这会是条任重道远的路。 下一步的调整与优化方向，还是配合业务上一起做好服务化。业务层面希望将目前打包在一起的功能逐渐服务化，而技术架构上需要提前调整与优化，提供服务维护、服务治理、服务监控、服务通信等一系列围绕产品服务、技术服务的周边技术支持，这块是明确的方向。然而，一些未知的方向，还得与业务线、管理者们常沟通，不断摸索，按需计划着开展。
InfoQ：服务层的优化已经进行一年多，这过程中有什么经验可以和大家分享的吗？
吕毅： 在来链家网前到现在，算起来的确有一年多在做平台化、公共服务这些事情，伴随着自我成长，感慨的确很多，列三点深刻感受的在这里与大家共勉。 第一，服务源自需求。只有业务需要的才是值得做的，只有多个业务线都需要的，才是值得拿出来做成平台服务的。多去关注业务，寻找业务线研发团队共性部分，才能发现需求，通过与业务线的沟通才能发现做平台服务的价值，所以做平台服务的技术角色切忌闭门造车，只有把自己当做半个业务线的RD才能感受到业务线的痛点。 第二，“第三选择”。常见行业内做公共服务的同学与业务线同学有些碰撞，双方各持观点，对一些边界问题拿捏不清。此时大家秉持第三选择，一起寻找更好的解决办法，目标达成一致，问题便可化解。当然第三选择的解决办法用在哪里都是合适的。 第三，服务的解耦。这是平台化服务的基本原则，服务间的解耦、服务内部的功能解耦，都是在日常设计、开发中需要注意的，只有将一块事情拆成多个点，才好做点与点之间的联系，以有限的功能点构建出无限的能力。这是老生常谈的点了，但依然值得再提一遍。
InfoQ：请讲讲你们的日志分析平台架构吧？目前的日志处理流程是怎么样的？处理的日志大概是怎样的数量级？
吕毅： 日志分析平台在前面技术架构图中，属于纵向的监控部分中的“日志监控”环节，主要解决业务模块、服务模块日志字段的数据收集、展示、监控。架构设计引用公开资料中的这张截图来说明。
日志通过Kafka收集，根据日志所属RD配置的统计、监控规则通过Apache Storm实时分析日志，并将结果集数据存储数据库，实时分析期间若触发了监控规则阈值，则触发报警。数据库中的数据可以做实时的数据展示，整套方案可以让研发、测试角色实时查看日志情况，避免了大家日常合并日志文件再做shell统计的问题，并提供平台可以持续使用。 目前日志平台每秒处理的30万行日志，处理结果的展示与报警延迟在2s以内，并且这套解决方案有计划在后续开源，让业内同学低学习成本掌握并构建到生产环境中。
InfoQ：要设计一个高可用、高吞吐的日志平台，您认为需要重点考虑和解决哪几个方面的问题？
吕毅： 设计这样一套日志方案，有以下几点需要关注：数据的收集、数据的处理、数据的存储、数据的展示。 其中数据的收集部分行业内部不少用flume采集日志，我们最早期的beta版本也是如此，但在我们方案中缓存日志数据的组建Kafka在年初版本中发布了Kafka Connector功能，实现了类似flume能力，故我们上线前就改用Kafka全套解决日志收集问题。 数据的处理，因为要求实时性，行业内也有两套方案，Spark Streaming与Apache Storm。两者共性很多，但选择Storm的原因主要是Storm的设计与Feature更专注实时运算，而Spark做离线的大并发流式处理是不错的，例如流式批运算、图片处理等等。 数据的存储，选型比较多，大家做DB选型时需关注企业级日志系统需要有大批量数据写入，特别是业务高峰时期，那么选择一个良好支持高并发写入特性的DB即可，我们使用的HBase。 数据的展示，这块就比较灵活，根据自己需求，从DB中选择数据通过组织拼装成格式化数据，配合上前端特效展示即可。
InfoQ：在你们的平台中，日志数据会采集哪些信息？你们是如何统一其他开发人员的日志格式和信息的？
吕毅： 如日志平台的架构图所示，数据的采集基本是全量的，日志文件大部分是研发关注的信息，这些被关注的日志文件都会被收集，用作实时分析计数。 在日志格式这块，我们在接入层做了统一日志格式，故这份日志将会是所有业务的请求日志全集。对于业务模块、服务模块自己的日志，我们会给予建议，但没有强制规定日志格式，这部分有差异的日志格式，会在日志平台中研发角色配置统计规则时，通过正则匹配自助扣取想要的日志字段用作统计、监控。
InfoQ：与日志监控相比，系统级监控对业务层、服务层的监控指标及目的是怎样的？
吕毅：系统监控和日志监控比较，有这么几点差异：
- 面向人群： 系统监控 主要面向运维角色，RD角色关注较少，RD对于系统监控，更关注报警。 日志监控 主要面向RD、QA角色，他们关注业务日志某些字段出现的频次、某些值的最大最小值等，同时也可以设置基于日志的业务报警。
- 数据源： 系统监控 更多收集syslog、机器设备数据； 日志监控 主要手机业务线自己打的日志内容。
两者互补，在需要了解业务所属的服务器信息时候，在系统监控上查看；想了解业务数据情况时，在这套日志监控平台上看。
相关文章：
1. 2016php大会的ppt （包含吕毅大牛的日志分析平台分享）