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月
