從16年10到現(xiàn)在回到上海工作有半年了，大概總結(jié)一下；

首先是服務(wù)化的問題，原來在阿里的時候用的是hsf，dubbo，服務(wù)化的問題已經(jīng)很成熟了，也不用自己操心，單元化，中心化這些都是已經(jīng)在中間件團(tuán)隊(duì)運(yùn)維的很成功，而現(xiàn)在來到小公司，首先要解決的是服務(wù)化的問題，在選型上，老板選擇了使用grpc來作為服務(wù)化的底層，而我要解決的是服務(wù)注冊，發(fā)現(xiàn)，路由及易于使用的問題，所謂前人開路，后人乘涼，在注冊和發(fā)現(xiàn)有許多成熟的方案了，借鑒spring cloud的consul注冊與發(fā)現(xiàn)，我們把注冊與發(fā)現(xiàn)基于spring boot實(shí)現(xiàn)了一個starter，而易用性的問題，我們開發(fā)了一個能夠生成interface和pojo的maven和gradle插件，結(jié)合起來初步解決了服務(wù)化的問題。但是在此做的過程中發(fā)現(xiàn)不是基于自己的序列化方式來做，許多時候是很費(fèi)力及不討好的，存在的問題有：

1:使用protobuf來做序列化的時候，null對象與empty對象很難區(qū)分

2:性能的確跟不上

好處有：

多語言的問題非常容易解決

其次是服務(wù)監(jiān)控及服務(wù)測試的問題，在此我們做了一個控制臺系統(tǒng)，能夠服務(wù)查詢，服務(wù)測試等等，本來還想把路由給添加上去的，老板把前端資源給撤走了，沒辦法繼續(xù)下去

再次是服務(wù)調(diào)用鏈監(jiān)控的問題，我們選擇使用了pinport來做apm，基于pinport開發(fā)了自己的插件，存在的問題有監(jiān)控?cái)?shù)據(jù)統(tǒng)計(jì)與分析的問題，這個很頭疼，基于hbase的數(shù)據(jù)分析與統(tǒng)計(jì)會讓開發(fā)人員陷入到實(shí)現(xiàn)老板各種各樣的報表需求中，目前也沒有一個好的解決辦法

還有一個就是elasicsearch與mysql數(shù)據(jù)同步的問題，這個也很麻煩，我的初衷是盡量不使用阿里云的binlog日志服務(wù)，盡量使用jdbc去拉取數(shù)據(jù)，根據(jù)數(shù)據(jù)庫時間字段來實(shí)現(xiàn)全量或增量的更新，但是最終落地卻是阿里云的dts與jdbc并存的方式，讓我頭大

回上海半年多了，大概的工作完成就這些，有許多感觸

1:做技術(shù)越做底層越感覺到自己能力不夠，比如說，在docker方面，僅僅停留在使用階段，而出了問題就歇菜了

2:許多東西與事情如果不做和不看了就會忘記，netty在阿里的時候閱讀了源碼，但是現(xiàn)在有點(diǎn)忘了差不多了，zk的源碼也閱讀過，現(xiàn)在也忘的差不多了

3:開源的軟件提issue百分之九十沒人理，這估計(jì)也是為啥要重復(fù)造輪子的重要原因吧

展望下半年

docker需要從使用到熟悉階段

許多原來的知識點(diǎn)需要再次進(jìn)行梳理及理解