本周六很荣幸参加了快狗打车的闭门交流会，能和关注已久的沈剑老师面基感觉特别荣幸。我想在介绍交流会内容的同时，谈谈自己的思考。
交流会主要有三大主题：快狗打车的业务发展和创新、快狗打车的产品路线、快狗打车架构演进，分别由三位老师分享。我将重点回顾「快狗打车的业务发展和创新」与「快狗打车架构演进」这两部分内容。
快狗打车的业务发展和创新
沈剑老师从58同城的论坛业务开始谈起。
58从一开始做二手交易类目，逐步演进出房产、招聘、二手车、黄页等垂直板块的服务。
为什么会演化出这么多业务呢？因为有大量的用户需求，通过数据分析梳理出了不同的服务品类，比如租房类招聘类。把单品类服务做到更好，提供了更加垂直的服务，增强了用户粘性，也有了更多的变现方式。
这个阶段，58同城主要的变现方式之一是广告，通过精细的品类和地理位置，给用户提供更精确的推送服务。打个比方，立水桥的一家饭店招聘厨师，只需要在58同城招聘中发布一个厨师招聘的职位，58同城就可以根据C端用户的地理位置，给他推送这条招聘信息。
这时，58同城存在一些痛点：
- 信息质量无法保证。比如说有人在58同城发布了一个卖手机的公告，别人和他联系之后，线下去交易手机，手机有可能是有质量问题的。
- 无法形成交易闭环。最终交易基本都是在线下完成的，这让平台对交易环节无法进行质量把控，无法保证用户体验。
为了解决上述问题，各个垂类方向做了一些探索：
- 孵化出“转转”，保证二手交易质量，实现交易闭环。
- 孵化出“到家”，保证服务质量，实现交易闭环。
题外话：百度出来创业的人，成功率更高，有一部分原因是他们有流量，通过搜索词能准确定位用户需求。
快狗打车的当前定位是短途实时货运平台。然后还讲了一些快狗打车的下一步发展方向。
从沈老师的分享中，了解了快狗打车业务是怎么一步一步演化而来的。沈老师说“没有天才般的构想，业务都是一步步做出来的”，可以感受到他们是在切实解决用户的真实需求的，技术团队能随着业务的发展而成长是我们技术人的幸运。
之前我也参与过一些创业项目，对其中的坎坷还是挺有感触的。在我们决定启动一个新业务新项目的时候，可以先问自己一些问题：
- 产品能解决哪类用户的需求？
- 他们的需求是否有其它的替代方案？
- 用户如何才能为我们的服务买单？
- 如果是零和游戏，如何才能营造共赢的局面？
- 项目的关键路径是什么？是否可行？
- 关键路径是决定项目成败的核心
- 尽量以较低的成本验证其可行性
- 这个环节也是最具挑战的。首先关键路径就很难找，其次验证过程还会受到环境和人的影响
一个创业项目可以分为以下阶段：立项前、测试商业模式、准备融资、迅速增长。当我们选择加入一个创业项目或创业公司时，可以评估下它当前处于哪个阶段。阶段越往后，创业成功的可能性往往越高（但这只是个参考值，具体情况还需具体分析）。
快狗打车架构演进
这部分是快狗打车的技术委员会主席为大家分享的，主要内容概括如下：
快狗打车从一开始的“货的”业务开始，因为有原来的一些框架基础，所以直接跨过了all in one的MVC架构而采用分层架构。此外，将第三方接口封装成独立服务，既方便以后更换服务方，又方便对单个服务部署合适的副本数。
后来有了多块业务，更多业务模块的基础功能先从“货的”复制而来；内部服务放弃HTTP，采用公司自研的RPC框架，这样可以使内部服务的调用更高效。
随着功能模块的增多，服务之间的调用逻辑变得越来越复杂。为了统一管理服务之间的调用关系，开发了注册中心，整体架构升级到了SOA模式。
为了应对公司接下来的业务发展，当前正在探索ServiceMesh架构。
大家也问了一些问题，我结合老师的回答和自己的理解阐述一下。
- 服务如何平滑上线？这是一个系统性的复杂问题。
- 首先确保数据库的变化是向前兼容的
- 如果模块之间有上下游关系，需要先发布下游模块再发布上游模块
- 对于单个模块的平滑上线，首先服务要有多个副本，确保每个副本预留足够的QPS。上线时，先保证一个副本不再接收新的请求，让其处理完已接收的全部请求之后，再发布新代码，代码生效之后即可接入新流量。依次处理其它副本。
- 如何做压测？线上同流量的压测主要采用TCPCopy方案
- 如何区分需求是在中台做还是在业务部门做？这没有一个严格的标准，但是可以根据功能的可复用性来决定，如有必要可以咨询架构师或技术总监。切记，不能因为谁强势就把工作推给另外一方。
总结
通过此次交流，了解到了快狗打车的业务发展和技术演进，这对自己以后的工作有一定的指导和借鉴意义。我还向沈老师咨询了写公众号和做技术架构的一些问题，受益匪浅。期待下一次。
