写在最前
大会干货很多，讲师阵容也很强大，一场接着一场，连续两天，还是学到了不少东西的，用主持人的话说就是我们干货很干，硬广很硬。不过窃以为讲师里面还是夹杂了“合作方”的，推销一些平台和书籍，不过无伤大雅，权作休息。
不过由于时间和地点的原因不少朋友没能及时参加，今年也不知道是否会有大会视频，所以我打算根据现场朋友用打赏堆出来的排名来对大会进行一个简单的总结，自己复习巩固一下，也希望能给其他人一些帮助。
瓜子后端技术架构的变迁（纪鹏程）
这个分享是热度最高的，原因可能在于它是最接地气的。不仅完整的介绍了瓜子二手车架构一步步由小到大的发展过程，以及这期间的经验教训，还逐条分享了各种最佳实践，可以说他的分享基本可以指导一个新兴业务，技术架构的快速发展方向。
石器时代，业务发展早期
这段时期的第一目的、最高目的是活下去
技术人员要把精力集中在业务上，快速迭代，实时响应业务需求，可能要做不少Quick but dirty work。此时也不要忙着造轮子和优化，能花钱买就花钱买，能用开源的就用开源的
过早优化和造轮子是万恶之源 —— 尼古拉斯·赵四
也不要着急上缓存。一是多一层依赖就多一层的风险，早期快速迭代时，尽量保持架构的简单。二是缓存可能隐藏掉一些代码性能、逻辑缺陷，导致一些性能问题可能到架构复杂到一定程度时才暴露出来，此时的修改的成本就十分高昂了。
尽早确定数据库规范、数据字典。因为在后期业务代码还有修改空间，底层数据库和一些约定一旦养成是很难改动的。
保密工作也要做好。对外开放的数据一定要做好加密和脱敏工作，前期激烈竞争阶段，一个泄密可能拖垮一个公司。
guazi-01.png
这个阶段的问题也很突出。代码质量差，文档缺失，新人上手难度高。基础服务脆弱，缺少各种管理平台（日志、部署）。不过没关系，坚持过这个阶段，业务只要能活下来，这些问题都不是问题。
铁器时代，业务发展期
熬过业务早期，进入快速发展阶段后，业务种类与规模会迅速增加，各种通用服务的重要性也逐渐显现，同时用户量也会大幅增长，服务性能压力开始出现。这个时期的架构也要做出相应的调整。
- 业务拆分。包括代码和数据库，业务之间通过http接口调用
- redis集群。使用Twemproxy来做中间代理
- php性能监控。使用xhprof和各种日志，指定统一的日志规范
guazi-02.png
这个阶段常见的问题是，业务快速调整，接口混乱，调用方式混乱、性能缺乏监控；还缺少可靠的持续交付流程
蒸汽时代，业务稳定期
各项业务逐渐稳定，各种痛点持续的暴露。
- 业务进行细分，通用服务、业务独立管理。
- 统一的接口调用方式，性能监控。
- 规范持续交付流程，代码的上线、回滚，数据库的建立、评审，统一的监控、测试框架，代码之间的隔离
- 健壮的第三方，一些通用平台没必要由专人维护，可以使用第三方平台，不过最好同时使用多家
guazi-03.png
工作效率实践
本部分讲师分享了实践过程中能够提高效率一些经验方法，比较实用
代码的艺术
- 代码分层，遵循psr1 psr2 psr4规范
- 代码提交添加统一hook，控制格式
- compsor，包括封装公司的内部库
单测
单测的重要性被反复提及。完整的单测是代码发布、升级的重要支撑。尤其是核心代码，覆盖率要保证。这里他推荐使用PATest代替PHPUnit作为主要单测工具
guazi-04.png
RPC
业务庞大后RPC的场景必不可少。最重要最基本的要求是调用方式统一。业界通用的解决方案一般是使用http接口，他们使用了guzzle基础上进行封装，支持了签名、并发请求和超时设置。另一个常用的方案是鸟哥开源的Yar
最后再啰嗦一句。RPC方法一定要跟普通的方法有明确区别！！！，否则可能被误用、滥用
服务解耦
服务级别，Rabbitmq & Kafka
数据表级别，Canal+Kafka
guazi-05.png
前后端分离
使用nodejs负责UI层展示与数据准备。php则负责业务逻辑与架构。明确职责范围，提高各自效率。
guazi-06.png
网友评论