对于链家，在最近两年对公司的架构也做了很大的调整，可以分为两个阶段：
作者分享了几点的经验;
第一，服务源自需求。只有业务需要的才是值得做的，只有多个业务线都需要的，才是值得拿出来做成平台服务的。多去关注业务，寻找业务线研发团队共性部分，才能发现需求，通过与业务线的沟通才能发现做平台服务的价值，所以做平台服务的技术角色切忌闭门造车，只有把自己当做半个业务线的RD才能感受到业务线的痛点。
第二，“第三选择”。常见行业内做公共服务的同学与业务线同学有些碰撞，双方各持观点，对一些边界问题拿捏不清。此时大家秉持第三选择，一起寻找更好的解决办法，目标达成一致，问题便可化解。当然第三选择的解决办法用在哪里都是合适的。
第三，服务的解耦。这是平台化服务的基本原则，服务间的解耦、服务内部的功能解耦，都是在日常设计、开发中需要注意的，只有将一块事情拆成多个点，才好做点与点之间的联系，以有限的功能点构建出无限的能力。这是老生常谈的点了，但依然值得再提一遍。
要想设计一个 日志方案，有以下几点需要关注：数据的收集、数据的处理、数据的存储、数据的展示。
系统对于系统监控和日志监控的比较，存在几点差异：
面向人群
系统监控主要面向运维角色，RD角色关注较少，RD对于系统监控，更关注报警。日志监控主要面向RD、QA角色，他们关注业务日志某些字段出现的频次、某些值的最大最小值等，同时也可以设置基于日志的业务报警。
数据源
系统监控更多收集syslog、机器设备数据； 日志监控 主要手机业务线自己打的日志内容。
两者互补，在需要了解业务所属的服务器信息时候，在系统监控上查看；想了解业务数据情况时，在这套日志监控平台上看。
链家在做线上线下结合的过程中，最大的挑战应该有两点：传统业务的梳理与互联网化改造，线上业务与传统业务的融合。
传统业务的梳理与互联网化改造，链家网从创立之初就在践行，至今仍是重点工作之一，可见难度并非一般。在几次与经纪人业务侧的PM交流后，深感房产交易的复杂性，就北京而言交易中的一个环节可能会有30多种角色参与，全国各个城市政策不一，更是难上加难，而链家网在努力优化流程，给业主、用户提供清晰明了的房产业务体验。这方面的挑战折射在技术上，就是复杂的业务流程控制、风控体系、数据安全等技术难点。
线上业务与传统业务的融合，存在于在To C业务与To B业务存在交集的部分。To C业务是我们所长，但如何让还未进入房产交易流程内的普通用户，快速了解链家房产信息、交易流程，让普通用户在有需求时第一时间通过链家网、掌上链家APP发起沟通、交易，这都是挑战。折射在技术上就是如何保证好线上用户如何快速、满足需求的查找到信息、如何与经纪人快速建立有效沟通、如何沉淀意向客户并建立起关系等等的技术问题。
文中部分图片和部分总结摘自原文，如有不适，请联系15227013954