PHPCon是由think技术社区发起的一年一次的PHP开发者大会，为期两天，印象中每年都在上海举行。
大会议题众多，挑几个印象深刻的做记录，总结下来有以下几个方面感触
01 PHP生态下，大家都在使用Swoole扩展
02 分布式，服务化架构是业界趋势
03 沟通交流，依然是学习成长的有效路径
PHP开发生态绕不开Swoole
基于PHP做深度开发的互联网公司都在使用Swoole扩展，基于此扩展做协程，异步，实时消息推送相关的业务。
可以说基于PHP的开发生态已经绕不开Swoole。
另外说一下Swoole团队本身也在做一些商业化的尝试，效果并不明显。负责人介绍说，貌似互联网公司有一种屌丝气质，能免费，绝对不用收费的。
商业化的网址在这里，其中有一些免费的工具可以尝试使用 https://www.swoole-cloud.com/，还有一个名为《Swoole微课程》的微信公众号
服务化是业界趋势
云原生，微服务，容器化是今年技术方面的总体趋势。
我个人在上个月调研了很多关于服务治理的资料，分Java生态的和PHP生态两个维度。Java语言的主要是Dubb0和SpringCloud，基于PHP语言的分布式服务治理框架很少，这次大会上主要推荐了两个。
一个是有腾讯背书的TARS，github地址 https://github.com/TarsPHP/TarsPHP
另一个是Hyperf https://www.hyperf.io/
当时我调研了PHP生态下的熔断案例后，发现基于PHP的熔断案例和开源项目很少，得出了一个思考
从两方面来看这个事：
一，业界基本没有这样的使用场景和技术案例，为什么没有，因为PHP语言生态不适合做这块，能做吗，或许能做，但是不适合，不是强项。
二，如果有类似的需求，我们不应该选择PHP来做这块，因为整个业界都没有这样做的，我们应该把经历花在更有意义的选择上。
这个结论是当时的直观感受，或许有些极端和偏颇。现在我想尝试下TARSPHP这个微服务框架，通过实践加深对微服务的实践理解。只有真正用过才知道具体的优势和不足在什么地方。
基础能力构建，应用场景，中台CICD升级持续进行
2345公司PHP的应用实践的讲演给我留下深刻的印象，讲师从业务基础服务，业务风险管控，业务场景实践，和业务中台升级4部分阐述了PHP在2345的业务实践。
业务基础服务就是非产品需求，对于整个研发体系运转又是必不可少的，服务于研发团队内部的基础设施服务，主要包括日志收集服务和服务资源监控等系统。
业务风险管控主要提出团队内部要进行CodeReview，并且提倡把CodeReview时间纳入开发整体的时间评估之内，也就是说开发评估时间时，就把Review代码的时间算上，以此提高团队代码的一致性，提高代码质量，这样的时间付出是值得的。
持续学习，变成优秀的人
大会第二天的下午引入了两个关于团队和个人学习的议题，学而思的团队负责人介绍了团队内部每天学习100分钟的学习方式，团队成员由听众各个变为主讲参与者的经历。好习惯逐渐养成，团队成员也能感受到成长。
学习总是一件需要坚持，并切枯燥的事。
PHP届的鸟哥因为高铁周六停运，没有感到现场，远程视频参与了分享。同样记录几点
关于项目和时间管理：对结果负责，不需要过多关注细节，在有限的时间内不要为自己揽太多事
关于35岁年龄，业界并不是不要35岁以上的从业人员，而是不要35岁没有能力的人
关于PHP转型，本质上是一个个人的选择问题，过多的关注 能够通过PHP的从业历程扩展经历，建立自信，提高能力
PHP官方为什么没有把Swoole纳入，PHP官方和Swoole开发者都讨论过这个问题，最终的结论是Swoole作为一个扩展在PHP官方外围发展更加灵活，不会失去控制权。
这次大会时间真好是遇到台风侵袭上海，为了参加大会我也是冒着台风去，跟着台风离开，希望通过现场参与，沟通交流的方式突破一下自己。认识一些朋友，更新一些理念，总是值得的。
几个小的知识
全局请求编号小作用
01 用于全系统的请求链路跟踪，日志里的跟踪器
思考 您开发的系统会增加全局请求编号这个参数吗？
02 作为服务端的请求参数，为实现幂等性做贡献
服务端做强制超时的小技巧
01 请求头增加请求请求时间和处理时间，如果服务端接收到请求的处理时间已经约定的DeadLine时间，都不需要进入接口逻辑，直接返回处理超时。
小知识归小知识，其实我想说的是只有在开发系统中持续加码，才能在稳定性，健壮性上更有保证。
大会的官方议程表，方便回顾查看
https://mp.weixin.qq.com/s/Zb1eP3-5p13ja_vjFsDJGQ
再附上几张风景图，来年回忆用
end 2019年8月
