問題

最近做的工作，似乎沒有太大難度，以至于讓我在技術(shù)方面有些迷茫。而且，基于阿里的平臺，很多技術(shù)方面的事情變得很容易。有時甚至可以輕輕松松地搭建起一個分布式應(yīng)用，能支撐起RT在5ms以內(nèi)，QPS在10w以上的訪問。

另外一個問題是，有很多框架，各種層出不窮的新東西，學(xué)也學(xué)不盡。那么，怎么才能算是掌握核心技術(shù)呢？

回顧

首先回顧一下最近半年內(nèi)的技術(shù)經(jīng)歷。

去年9月中旬，轉(zhuǎn)崗到另一個部門。從Python技術(shù)轉(zhuǎn)到Java方向，一切都是新奇的。

校招時本打算找Java方面的工作，但一直以來沒有Java方面的項目經(jīng)驗，而對Java的了解也就只在Leetcode上刷題和基本的語法方面，于是直接被阿里刷掉了。后來找到了Python方向的工作，但也擔(dān)心Python以后的發(fā)展，甚至因為這個事情給一些比較有名的Python工程師發(fā)過郵件咨詢。其中一位這么給我說：

首先不要想著自己是一個Python工程師，應(yīng)該想著自己是一個后端工程師，然后才是Python工程師。

覺得他說的在理，對以后用Python做主力語言也不是那么抗拒了。但9月份因為一些不可抗力因素要轉(zhuǎn)崗，原以為也是Python，不過轉(zhuǎn)崗面試時都問的是Java，然后我基礎(chǔ)還可以，于是就這么轉(zhuǎn)到新部門，技術(shù)也切到了Java方向。

1. 遷移

最開始接觸的是一個后臺系統(tǒng)，Mentor說是前不久離職的兩個同事留下來的項目，以后就交我維護。那是第一個真正接觸的Spring MVC項目。之前我用的是Python的Django/Flask/Tornado框架，雖然也聽說過Spring MVC，但很是嫌棄Java框架一直以來笨重的xml配置(相比Django/Ruby On Rails/Grails那種慣例優(yōu)于配置的輕便易用)。但是，既然上了Java的賊船，就不能不用Spring MVC，可等我在本地把那個系統(tǒng)用Tomcat運行起來，一個更重要的項目開始了。

之前離職的同事還負責(zé)另外一個項目，就是數(shù)據(jù)入庫系統(tǒng)，而這些從任務(wù)分配上來講都該由我接手。同時，因為大項目的需要，我們這個系統(tǒng)要遷移到另外一個平臺上，于是我就開始了這段近四個月的遷移歷程。

原系統(tǒng)架構(gòu)

如圖，算法組在HDFS文件系統(tǒng)中儲算法數(shù)據(jù)，這些數(shù)據(jù)需要存入Hbase/Redis/Memcache中，提供給線上服務(wù)使用。大項目將算法遷移到了ODPS平臺(阿里的OLAP平臺，學(xué)堂在線上有專門對這個進行介紹)，也將數(shù)據(jù)存儲到了ODPS上，但是我們的服務(wù)還是要從Hbase/Redis/Memcache里取數(shù)據(jù)，這需要我們把數(shù)據(jù)由ODPS上存到具體的數(shù)據(jù)庫中。

1.1 插件攻城獅

集團有自己的異構(gòu)數(shù)據(jù)傳輸工具Datax(該工具在Github上已經(jīng)開源)，可以將數(shù)據(jù)在各種不同的數(shù)據(jù)庫之間進行傳輸。該工具采用插件的方式使用，例如我需要向Hbase寫數(shù)據(jù)，則必須向Datax提供Hbase的寫插件。集團的Datax已經(jīng)默認提供了Hbase1.1和Hbase0.94的寫插件，但是但是，我們的Hbase是0.98版本的，經(jīng)過測試發(fā)現(xiàn)不兼容。另外，Datax沒有Redis和Memcache插件。本來，這個事情由另一團隊負責(zé)支持我們，但由于各種原因，最后他們提供了Redis的寫插件，我們則自己開發(fā)了Hbase0.98和Memcache的寫插件。

插件的開發(fā)過程是不連續(xù)的，跟大項目的推進進度有關(guān)，需得算法提供ODPS上已經(jīng)就緒了的數(shù)據(jù)，我才可以遷移。最開始給我的是入Hbase的數(shù)據(jù)，但是Datax上Hbase能用的插件版本跟我們的Hbase不匹配。如果不解決這個問題，我們根本遷移不了。最終我們決定自己開發(fā)Datax的Hbase0.98版本寫插件。

開發(fā)插件這個事情應(yīng)該是我主動要求來做的，因為當(dāng)時數(shù)據(jù)已經(jīng)有了，然而我卻入不了Hbase，心里比較著急。不記得當(dāng)時是否跟組長說過這個事情我來做，反正我主動去看了下Hbase0.94的代碼，查看了Datax插件的開發(fā)文檔，又去網(wǎng)上查了下0.94和0.98的區(qū)別，擼起袖子就開干。其實0.98的主要是底層依賴的庫與0.94的代碼不一樣，其他層面只需要對0.94的代碼做些改動即可，而1.1版本的區(qū)別就大了，這也是我選擇0.94來參考的原因。這時也是我第一次接觸Java的構(gòu)建工具Maven。

代碼改好之后，讓部署的同學(xué)幫忙部署。然而，測試的時候遇到了一個奇怪的錯誤：有個方法找不到。由于在Java上比較沒有經(jīng)驗，死活沒找出來是啥問題，就去尋找Mentor的幫助。他看了一下錯誤信息，然后弄了個jd-gui的小工具，將那Hbase和Hadoop的依賴包反編譯了下，在里面發(fā)現(xiàn)找不到的那個方法存在，但是沒有符合那個參數(shù)的。當(dāng)時我也不明白這是啥問題---那個錯誤的異常我沒完全看懂，因為參數(shù)的部分是我從沒見過的信息，當(dāng)時Mentor又找了好久，可能他有其他方面的懷疑，反正我沒看懂。

夜晚回家的路上就想，如果這個方法這個包里面沒有，那么很有可能是依賴的包不對，正確的包應(yīng)該在哪呢？要被遷移的入庫任務(wù)也是用Java從HDFS上讀數(shù)據(jù)寫入Hbase，那么那些代碼里面肯定有。第二天我去了，然后就看了那個pom文件，把開發(fā)的插件的依賴的Hadoop版本給換掉了，再一部署測試，沒問題了!

特別感謝我的Mentor，他幫我很多，要不是他我也不曉得可能是依賴包出了問題。這個事情讓我覺得Java的依賴有時候會出現(xiàn)很大的問題，做好依賴管理可能就是開發(fā)Java程序時比較重要的一環(huán)，也是讓人感覺超級蛋疼的一環(huán)。

Hbase0.98就這么開發(fā)出來了，感覺我組長還有整個大項目的負責(zé)人都比較開心，后者還專門找我問了一下這個插件的情況。這也是我第一次真正用Java做個東西出來。

接下來我受到了鼓勵，覺得開發(fā)這個插件也不是很難嘛，決定自己做Redis的寫插件開發(fā)。我先調(diào)研了原先那個入庫代碼里面對Redis的寫入情況以及對應(yīng)的API，然后花了一個周末的時間把東西開發(fā)出來，并且測試、部署都沒問題。但是周一上班的時候，我把這事情告訴組長，他說Redis插件和Memcache插件就另一個團隊來開發(fā)，就不用我的了。話說，當(dāng)時確實有點沮喪...

后來就跟另一個團隊的開發(fā)同事溝通Redis寫插件的需求問題，由他來給我們提供Redis寫插件，但我負責(zé)在我們的環(huán)境中測試他的插件。他是一個很好哥們，哈哈，和他合作很愉快，雖然這個插件不用我的了，可我也沒啥話可說。

但是在Memcache寫插件的測試過程中出了點問題。由于他提供的是在Datax的另一個插件的基礎(chǔ)上修改的插件，底層依賴的是spymemcached包，而我們這邊用的是xmemcached包……最開始我也不知道我們用的是這個，后來看了代碼才知道，但這時候他已經(jīng)結(jié)束了Memcache插件的開發(fā)。他的插件也可以使用，但是效率低的出奇---我得開1000個線程才能滿足傳輸速率。當(dāng)時就想，很可能就是兩邊的依賴的庫不一樣導(dǎo)致的。然后一個周末的下午和夜晚，我用了大概8個小時，開發(fā)出基于xmemcached包的Memcache寫插件，那天我還記得，最后是學(xué)校自習(xí)室的保安把我趕走了，因為待的太晚……

第二天部署測試，效率杠杠的：傳輸速率提高了100多倍，花費時間減少了100多倍。后來我們就果斷采用我這個插件了。

當(dāng)然，開發(fā)還是很開心的，尤其是做了比較有用的事情，這使我們這個遷移項目推進的速度加快了，且風(fēng)險降低了。

這里面還有其他故事。由于其他組的業(yè)務(wù)需要，我還給他們開發(fā)了Redis讀插件。另外，還有一個其他部門的高級工程師，經(jīng)常找我咨詢Hbase的事情，因為他負責(zé)他們部門的數(shù)據(jù)遷移，而Hbase標準插件不滿足他的需求，然后就找我來幫他開發(fā)。當(dāng)然，我們也有自己的需求，后來我給Hbase0.98寫插件增加了一些功能，例如支持動態(tài)列，支持列名可空。可能是幫他太多了，那哥們說要請我吃飯，哈哈，我是那么好意思的人嗎？果斷說他太客氣了，不需要請吃飯的。而且那陣子經(jīng)常收到來自杭州的電話，因為有一個部門需要Hbase0.98的讀插件，需要我支持……然后花了點時間給他們寫了個讀的。現(xiàn)在還在做他們的支持，因為動不動就找我。

這事情讓我感覺還是很好玩，一是開發(fā)比較開心，另外被需要會讓人感覺自己很重要，我也會有這種迷之虛幻感，哈哈。不過最重要的是讓我感覺到，我終于在Java方面邁出了第一步。

1.2 簡陋的入庫系統(tǒng)

原系統(tǒng)架構(gòu)

在上面這個架構(gòu)圖上，三臺入庫機里面的入庫任務(wù)和調(diào)度，都是用shell寫的。話說我當(dāng)時看到這個很簡陋的入庫系統(tǒng)時，真想要把它拆了重寫才好，至少要弄個Web界面，配置什么的直接在界面上操作，而不需要每次都要登錄入庫機，修改xml配置文件---那么長的配置文件，蛋疼啊。不過我們的全部入庫任務(wù)都會遷移到集團的調(diào)度平臺，重寫也沒啥用處。于是遷移過程中我一直在梳理這些入庫Shell的流程，然后把業(yè)務(wù)邏輯遷移到集團的調(diào)度平臺(D2)上。

這個系統(tǒng)主要承擔(dān)以下幾方面的功能：

• 創(chuàng)建新的入庫任務(wù)：主要是通過增加xml配置文件、Shell任務(wù)文件、Crontab執(zhí)行項實現(xiàn)
• 調(diào)度任務(wù)：執(zhí)行時檢查HDSF上的數(shù)據(jù)是否存在，如果不存在則等待數(shù)據(jù)，按照一定的等待時間重試；且如果機器上的資源不足，則等待再執(zhí)行
• 報警：入庫失敗則給相關(guān)負責(zé)人員發(fā)郵件

那么這些是怎么實現(xiàn)的呢？

首先crontab里面會設(shè)定某個入庫任務(wù)的執(zhí)行時間，以及對應(yīng)的shell腳本。然后shell腳本里面會有檢查HDFS文件是否存在的邏輯，有等待邏輯，還有失敗發(fā)送郵件的邏輯，但最關(guān)鍵的是給出了入庫的Java的執(zhí)行命令及參數(shù)---這兒會依賴一個jar包，該包里面實現(xiàn)具體的入庫邏輯。另外，還需要配置xml文件。Java代碼會讀取xml文件里面配置的executor，producer、processor和output。executor包含producer、processor和output三個參數(shù)，它表示一個完整的入庫處理流程。producer表示產(chǎn)生數(shù)據(jù)，這個數(shù)據(jù)可能是HDFS上的數(shù)據(jù)，也可能是本地數(shù)據(jù)。processor表示處理過程，可能把數(shù)據(jù)轉(zhuǎn)換成一定的格式，也可能不做處理。output則是將數(shù)據(jù)入到某個數(shù)據(jù)庫中，可能是Hbase的入庫代碼，也可能是Redis或者Memcache。

xml文件中的配置

xml文件中需要為每個任務(wù)需要配置一個executor，一個executor里面需要配置好producer、processor和output。比較好的是依賴的jar包里面已經(jīng)把相關(guān)的代碼寫了，很少需要更新jar包---除非有了新的需求，比如更改了數(shù)據(jù)格式，這就要增加processor的處理類，在該類里面實現(xiàn)具體的數(shù)據(jù)格式處理。整個老入庫系統(tǒng)維護過程中，我只處理了一次這樣的需求，升級了一次jar包，這說明這個jar包的代碼寫的還是比較有擴展性的。

這個系統(tǒng)的問題在于以下幾個方面：

• 每個任務(wù)都要增加shell文件、xml中的executor配置，時間久了，shell文件會非常多，xml長的非常長，crontab也會非常長
• 沒有機器的資源使用監(jiān)控，有一次有個算法同事改了代碼，不知道哪里寫錯了，開了三萬個線程并且不關(guān)閉，其他任務(wù)沒資源執(zhí)行，且因為沒有資源，也沒有給我們發(fā)報警郵件，還是API調(diào)用部分發(fā)現(xiàn)沒數(shù)據(jù)我們才發(fā)現(xiàn)這個問題……
• 手工操作太多，有一次修改xml，文件格式弄錯了，最后弄的很多入庫任務(wù)都入庫失敗……

其實這只需要一個管理系統(tǒng)而已。如果這個系統(tǒng)沒有遷移，我會做如下開發(fā)：

• 任務(wù)腳本改用Python，不用shell，shell可讀性弱，且Python還有很多庫可以使用
• 任務(wù)腳本根據(jù)配置自動生成
• 配置改用MySQL管理，開發(fā)Web界面
• 增加機器資源監(jiān)控
• 支持增加機器及指定機器執(zhí)行，之前系統(tǒng)的3臺機器是隨著任務(wù)的增多一臺臺增加的
• 再往后面就是往分布式調(diào)度方面開發(fā)了

哈哈，都是我的假想，并沒有做這樣的一個東西。但是遷移到D2平臺已經(jīng)基本滿足的這樣的需求，但D2也有一點不好，每次整體上的一點小變化，都要修改成百上千個任務(wù)節(jié)點，沒有批量改的操作接口，真是累啊。在維護這些任務(wù)的過程中，我改過好幾次每次上百個文件的任務(wù)節(jié)點配置。這讓我體會到，工作上的有很多事情都是重復(fù)性的，沒有開發(fā)創(chuàng)造那么有意思。

1.3 MR的虛幻感

這個遷移項目還有后面一步關(guān)鍵，就是數(shù)據(jù)轉(zhuǎn)換。

入庫過程

這是原始的入庫流程。當(dāng)算法的數(shù)據(jù)遷移到ODPS上了之后，我們即使有了Datax和對應(yīng)的寫插件，也還存在一個巨大的問題，就是數(shù)據(jù)處理過程。API從Hbase/Memcache/Redis取得的數(shù)據(jù)都是有一定的格式，而算法給的數(shù)據(jù)卻是原始的數(shù)據(jù)。同時，ODPS支持通過SQL對其之中的數(shù)據(jù)進行查詢，也支持通過MapReduce對其進行處理。于是我們遷移之后的流程就成了這樣：

遷移后的流程

于是我遷移過程就變成了：

1. 在入庫的Java程序中尋找每一個shell任務(wù)對應(yīng)的executor和它的具體配置，然后查看processor配置的類里面的具體處理方法
2. 根據(jù)1中的處理方法，改寫成MapReduce，在ODPS上處理

嗯，總共179個入庫任務(wù)，雖然遷移過程中砍掉了一些，最終也有上百個。另外，ODPS的MapReduce感覺是給Hadoop的MapReduce增加了一層包裝，所以寫法略有不同。

當(dāng)然，這個過程中并不是MapReduce有多難寫，而是梳理Shell的處理流程，查找數(shù)據(jù)Parser的方法，才是特別耗費心力的。感覺就是苦力勞動吧。其中一個shell文件寫的特別復(fù)雜，我只好打印出來從紙上看，總計有6頁代碼。

Hadoop的MapReduce在研究生時代就寫過，并且用實驗室的機器搭建過Hadoop集群。另外，研究生畢業(yè)設(shè)計是用Spark來做推薦系統(tǒng)的數(shù)據(jù)處理，里面寫Map/Reduce真是簡單的都不知道怎么說好了，沒有對比就沒有傷害。

由于是使用MapReduce，這讓我有一種“MapReduce也就是這樣子啊，也沒剛出來的時候那么高大上”的感覺。我想可能是寫那種簡單的處理寫疲憊了……

其實Hadoop的HDFS/MapReduce的細節(jié)，包括設(shè)計，都是非常值得研究的，可惜現(xiàn)在沒時間去做這個了。也不止這個，因為我們的數(shù)據(jù)存儲主要是使用Hbase，這三樣正好對應(yīng)Google的那三篇論文，這可就不只是值得去好好研究的了，而是一定要去研究的。且待我有時間。

1.4 總結(jié)

花了四個月的時間，磕磕碰碰，從無到有，總算是獨自把這個遷移任務(wù)完成。感謝我的Mentor和我的組長，是他們在我遇到問題的時候給我提供信息，幫我理清思路，建議并指導(dǎo)我怎么去處理。這一個過程中感覺真的收獲了不少，讓我有了一定的Java開發(fā)經(jīng)驗。但這個過程中同樣暴露了我在Java技術(shù)方面的短板，即項目經(jīng)驗太少，需要掌握的東西很多，有時候處理的思路也有偏移，而且對于底層有點霧里看花的感覺---可能是寫的不夠多吧。這四個月中，大致做了這么些事情：

• 開發(fā)Datax插件、自己測試，并給需要的同學(xué)提供相關(guān)服務(wù)，包括Datax的使用方法
• 梳理舊的入庫系統(tǒng)邏輯，改造成MapReduce
• D2平臺上創(chuàng)建任務(wù)，包括入庫、MR處理等
• 推動算法組同學(xué)提供ODPS上的相關(guān)數(shù)據(jù)（因為這個事情阻塞不少時間）

2. 后臺維護

2.1 管理系統(tǒng)遷移

年后過來，接受了三個后臺管理系統(tǒng)往集團平臺上遷移的任務(wù)，Mentor協(xié)助我。這三個系統(tǒng)都是之前同事來維護的，順理成章，這些也該由我來遷移。其中Mentor幫我遷移了一個，自個兒完成了剩下的兩個。這三個系統(tǒng)都是由Spring MVC寫的，于是這次我才有功夫接觸一點Spring MVC方面的知識。遷移的關(guān)鍵點在于：

• 將原有的系統(tǒng)前端和后端合并成一個應(yīng)用
• 后臺數(shù)據(jù)庫的切換，web.xml中修改MySQL的配置
• 舊MySQL數(shù)據(jù)同步到集團的MySQL平臺中(idb4)
• 接入SSO替換原有的CAS系統(tǒng)，修改原有的權(quán)限邏輯
• 集成平臺(Aone)部署測試

這個過程中，遇到了一些問題，但是都被解決了，也對Spring MVC的整個項目的構(gòu)造以及容器、注解、AOP和配置有所了解了。如果現(xiàn)在讓我寫一個CURD的Spring MVC項目，我想應(yīng)該沒多大難度。但總感覺不踏實，因為我沒有把這個東西掌握到我十分熟悉的那種地步。

2.2 審核系統(tǒng)

遷移過程中審核系統(tǒng)變得無法使用，主要是算法那邊沒有提供審核信息。于是我們幾個相關(guān)環(huán)節(jié)的負責(zé)人把審核流程通了一遍。

流程

如上圖所示，整個流程就是數(shù)據(jù)通過ODPS入到MySQL，審核人員通過Web界面審核數(shù)據(jù)，把修改存入到MySQL中，然后定時將全量的MySQL審核數(shù)據(jù)同步到ODPS上，最后生成的審核數(shù)據(jù)，會被算法用于過濾。這樣，同事提供了數(shù)據(jù)，我配置好了相關(guān)的Datax任務(wù)，整個系統(tǒng)就運行起來了。這里面流程雖然簡單，但是各方面都要通知到，尤其是使用最后的數(shù)據(jù)的同學(xué)。

2.3 用戶變身

用戶變身是為了給算法測試提供的一個功能，實際上就是在小結(jié)ＵID替換器的實現(xiàn)里面介紹的功能。

用戶變身

本身功能是對特定用戶的ID進行替換，如果請求中帶有我們定義的ID，則替換成我們定義的該ID的替換ID，推薦算法根據(jù)替換后的ID計算出推薦結(jié)果。這實際上就起到了用戶變身的效果。

功能要求：

• 要有管理界面，能對我們要替換的ID和最終替換成的ID進行管理，一個這樣的映射對定為一個規(guī)則
• 要能停止和啟用某個規(guī)則
• 要能使修改后的規(guī)則立即在線上起作用，也就是要添加這樣的一個按鈕：使規(guī)則生效

如上圖所示，在管理后臺修改了規(guī)則之后，可以點擊使規(guī)則生效按鈕。這個按鈕會調(diào)用線上API的每臺機器的同一個接口，也就是圖中的刷新接口。刷新接口又會調(diào)用管理系統(tǒng)的數(shù)據(jù)接口(HTTP)，加載所有啟用了的規(guī)則信息到線上API中的一個全局HashMap中。線上的請求打過來的時候，會根據(jù)請求中的ID在HashMap中做匹配，如果匹配上了，則替換掉，如果沒有，則略過。

這是我用到的第一個規(guī)范的使用MySQL數(shù)據(jù)影響高訪問量API的設(shè)計。如果不這樣做，而是每次請求進行MySQL查詢，再替換，則MySQL肯定會掛。 之所以能這么設(shè)計，是因為少量的過濾數(shù)據(jù)是可以加載到內(nèi)存中，而且使用HTTP協(xié)議加載數(shù)據(jù)，實現(xiàn)了兩個系統(tǒng)之間的松耦合。

這個功能是獨自參考系統(tǒng)原有的黑名單功能做出來的，前前后后，包括寫管理系統(tǒng)、修改線上API、測試部署等花了近5天。當(dāng)然，代碼本身寫的不多，但在項目的哪個地方寫，該寫哪些東西才是花時間比較多的。

3. 實時跟蹤系統(tǒng)

實時跟蹤系統(tǒng)是大系統(tǒng)架構(gòu)換新的一個關(guān)鍵服務(wù)，已經(jīng)由另一個團隊的同事們寫好，交由我們使用，且當(dāng)前由我負責(zé)。這個系統(tǒng)里面用了集團的很多產(chǎn)品，好在開源界有很多替換方案，此處就用開源方案給出設(shè)計圖：

實時跟蹤系統(tǒng)

系統(tǒng)本身功能是對用戶的點擊、瀏覽記錄進行跟蹤，跟蹤數(shù)據(jù)要實時提供給算法使用。點擊等日志會通過Kafka的發(fā)布和訂閱服務(wù)，傳遞給我們的實時跟蹤系統(tǒng)。實時跟蹤系統(tǒng)中取得日志中的數(shù)據(jù)，解析某些關(guān)鍵數(shù)據(jù)，存儲到Redis集群中---Redis中的數(shù)據(jù)量十分大，預(yù)估是5T左右。同時，實時跟蹤系統(tǒng)通過Dubbo分布式服務(wù)框架提供RPC服務(wù)接口，返回Redis集群中存儲的數(shù)據(jù)。

通過RPC服務(wù)使用Redis數(shù)據(jù)的消費者是算法組的同學(xué)，他們使用用戶的實時數(shù)據(jù)進行推薦。這個系統(tǒng)對性能要求比較高，要求RPC調(diào)用數(shù)據(jù)響應(yīng)時間在5ms以內(nèi)，并且支持7w每秒的QPS。

這個服務(wù)運行的還不錯，但很快就接到了新的需求：日志結(jié)構(gòu)更改和提供HTTP的數(shù)據(jù)訪問接口。

日志結(jié)構(gòu)更改就是通過Kafka訂閱的日志結(jié)構(gòu)跟之前的不一樣，需要重新寫解析方法---當(dāng)然我是看了源代碼之后才知道要改解析方法。提供HTTP接口的原因是RPC服務(wù)在算法平臺上可能無法使用。

大概花了兩天半的時間完成了這個任務(wù)。當(dāng)然，最開始還是有點慌張的，因為對這個東西一無所知，僅僅知道它叫“實時跟蹤系統(tǒng)”，用了RPC服務(wù)框架(因為是Java菜鳥，RPC服務(wù)本身原理我沒深入研究過，僅僅知道這個是做什么的)。但我答應(yīng)了組長三天之內(nèi)把這個東西修改好，部署并測試，還要跑成功。所謂的跑成功就是在我們的APP上有點擊瀏覽記錄，我能通過RPC服務(wù)和HTTP服務(wù)看到我的點擊足跡。

其實看了代碼之后就有了思路。但是對于集團的一些產(chǎn)品不熟悉(設(shè)計圖中給的全部是開源的產(chǎn)品，集團內(nèi)部用的不是這些，另外還有些開關(guān)和限流服務(wù)，都是第一次接觸)，以及測試完全是在生產(chǎn)環(huán)境下的，抓包找自己的設(shè)備的ID花了很長時間。好在比較快速地完成了這個任務(wù)，當(dāng)時給組長說已經(jīng)沒問題了時，他說：好，非常好。

這個服務(wù)的代碼不是我寫的，但是寫的不錯，接下來我會把它的代碼再仔細看一遍。但我感覺到，這個用8臺機器運行的應(yīng)用，并有5臺機器的緩存(類Redis)集群，在集團提供了好用的平臺的情況下，增加功能和維護變得容易，但也屏蔽了我對具體架構(gòu)的了解和學(xué)習(xí)。就像這種感覺：如果一件事變得容易，那么肯定是有其他東西幫助你做好了很多事情。這也會造成對這個平臺更加依賴。

思考

經(jīng)歷回顧帶來了什么

• 讓我知道自己為什么會有一種虛的感覺

• 代碼寫的不多。沒有一次完整的開發(fā)整個項目的經(jīng)驗，基本零敲碎打，而自己也沒有總結(jié)一些代碼的良好的框架設(shè)計。但是，在大型的項目中，基本上每個人都負責(zé)一部分模塊的開發(fā)，要一個人完全把所有功能做好，也不太現(xiàn)實。
• 同時，好的平臺，讓人可以專注于業(yè)務(wù)開發(fā)，但也屏蔽了對更深層技術(shù)的感知。這是好事還是壞事呢？如果有一天，需要從零開始搭建一個基礎(chǔ)平臺，只會業(yè)務(wù)代碼，能Hold住嗎？

• 讓我知道過去的半年內(nèi)到底做了哪些東西

以上的工作歷程，本質(zhì)上是干活和學(xué)習(xí)結(jié)合在一起的。這樣的學(xué)習(xí)是有幫助的，比如后臺系統(tǒng)中的一個處理我把它用在實時跟蹤系統(tǒng)的改造中了。同時，這個總結(jié)也讓我梳理了一下在Java技術(shù)方向半年以來做了哪些事情。當(dāng)然，這些事情有些有價值，有些不一定有價值，但對我來說也是比較重要的成長經(jīng)歷，對自己的技術(shù)經(jīng)歷要清晰。

• 讓我開始去思考接下來要處理哪些事情

什么是項目經(jīng)驗

• 開發(fā)經(jīng)驗
• 維護和擴展經(jīng)驗

什么是核心技術(shù)

接下來該怎么做