技術專家寫代碼-以點帶面談作開發

靜兒歷時8個月終於如願迴歸寫代碼的生活。但願這8個月的成長能對本身的碼磚起到必定的指導意義。下面就介紹一下靜兒迴歸後的第一次碼磚經歷。

 

如下是靜兒的方案設計：

 

01

— 

方案設計

 

背景：

DNS綁定會有必定的失敗率。失敗緣由包括但不只限於：

• dnsupdate服務只進行基本的ip和域名惟一對應合法性檢查：add操做，若是已存在域名的正解或ip的反解，則會更新失敗。

• dnsupdate服務因爲各類緣由形成的不可用或處理錯誤

針對上面狀況須要作一個補單

 

調查：

dnsupdate域名更新服務API接口說明 對此文檔，針對dns.add，返回結果舉例以下：

XXXXX

此例子來源於線上日誌，新美大日誌中心地址：

XXXXX

其中返回值中有個status='init'字段。經過向雲計算部門XXX同窗瞭解，對於dns綁定和解綁，都是異步操做，先提交任務，而後再查詢任務執行狀態。實際執行線上目前要跟X臺dns服務器更新數據。校驗不經過，狀態碼是400；在狀態碼200的狀況下，若是能拿到taskid，status，就說明任務是校驗經過，理論上應該執行成功的，後來查詢到status時failed，多是dns服務器異常，或者已經有了相關記錄。

 

自身優化：

XXX裏的

public boolean dnsAction(String action, String ip, String host, String domain) 和

public void add(String ip, String name, String host)

public void delete(String ip, String name, String host)

作了一樣的工做，可是dnsAction沒有cat埋點，統一用dns.add和dns.delete，並添加cat埋點。

XXX的封裝，這個封裝判斷成功的依據是能夠獲取到更新dns的request id。可是做爲補單來講能夠作更細粒度的處理，此處須要優化。

 

技術調研：

• MQ：

由於hulk-config項目中已經使用了mafka，根據項目穩定須要儘可能減小依賴的原則，因此一開始考慮使用mafka作延時消息隊列，調研結果支持延時時間區間沒有確認是否能符合要求。

延遲消息隊列	發展歷史	是否BG隔離	部署機房	延遲精度	是否考慮時鐘漂移	支持延時時間區間	線上接入業務	線上接入量	KV雙寫	單點故障	是否有容災演練
mafka延遲隊列delayserver	2016年中旬至今	是，每一個BG都有單獨集羣	北京側：dx,yf,gh均有部署 上海側：gq	100ms	考慮了	5s-7天	金融支付，到餐退款，外賣等均有接入	600+topic 15000+qps	無	有，優化方案已開發完畢	有
rabbitmq延遲隊列 koala	2016年末至今	只接入外賣業務	dx處於使用狀態 yf冷備	1s	未考慮	不限制	外賣配送業務	共有105個隊列 10000+qps	有	無	有

beanstalked無團隊維護，技術團隊在主推mafka，逐漸淘汰rabbitmq。因此若是考慮支持延時時間區間不符合要求採用MQ代替方案。

• Redis:

由於實際上只須要一個隊列，延遲能夠控制客戶端的消費頻率來實現。而redis裏有List結構來實現消息隊列,理論上是能夠實現的，而項目中已經依賴了squirrel，不會產生新的依賴。以前在樂視作過redis cluster的map結構性能壓測，在一個map超過萬級的時候，性能惡化很是嚴重。list同map同樣，也存在集羣的性能優點不能發揮做用的問題。性能方面有待測試（Mark），目前問題不大，數據量增大可用多個list橫向擴展解決，還避免了MQ的分片上限影響擴展性。

• 下游支持

涉及公司內部信息，此處省略

 

補單處理：

• 邏輯梳理

針對調用XXXX，結果分爲下面幾種狀況：

*注意：第三方 的報警設置，加上，請求url，參數，返回參數。若cat沒法支持此種報警策略，可考慮自定義大象。

 

整體採用mafka延時隊列實現

1>查詢時間間隔：（1）5s，（2）5s，（3）5s，（4）5s

最長查詢時間20s，設置MCC開關控制,最大重試4次

2>補單時間間隔：（1）5s，（2）10s，（3）60s，（4）10*60s，（5）20*60s，（6）30*60s

最長補單時間1小時，設置MCC開關控制,最大重試6次

3>流控初期先用開關控制，後續能夠考慮作熔斷。

4>須要在XXXX表裏作標記

• CAT埋點方案

調用dnsupdate服務先後埋點記錄輸入和輸出

 

後續TODO：

• 出一個DNS調用數據，預估須要DNS服務要支持的容量，看是否須要推進DNS服務的擴容、性能優化。

• 須要DNS服務的兄弟給出細化的錯誤緣由

 

 

02

—

開發

 

    代碼開發很簡單，靜兒整個開發階段（不算測試和聯調）實際上耗時兩小時。這裏主要談談遇到的問題和一些思考。

 

程序沒法啓動

    在開發過程當中最不肯意遇到的問題就是環境問題。靜兒代碼開發完了，想啓動驗證效果，程序啓動不起來。在啓動以前

1. 靜兒新拿到服務，以前沒有啓動過

2. 作了一些修改

3. 其餘同事用的是外部配置的jetty啓動，我直接在pom文件裏添加了個jetty控件啓動的

4. 肯定了其餘同窗拿到代碼沒有作任何修改直接能夠啓動

 

    這時候我是否是應該慌里慌張的新拉一下原始分支試一試是否是本身改出來的問題？答案是「No」，爲何呢？

    從報錯來看，日誌堆棧最上面是最表面現象，最下面是直接緣由。表面現象是數據庫鏈接問題，最下面有定位到一個點評框架的代碼。直接來看和我新寫的代碼沒有關係。

    之因此選用mafka是由於項目原本就用到了，因此我新開發的代碼不存在引入新的中間件問題。新配置了一個遠程調用的服務，是啓動時加載的，可是原來也是有調用，調用方式不一樣，並未引入新的jar包，也不存在少引用的問題。

    錯誤和代碼之間沒有直接關係，先不考慮新修改代碼的影響。直接根據堆棧信息找錯誤緣由。

    堆棧裏報的最直接的cause是一個NPE（空指針異常），定位了一個報錯代碼位置，可是因爲不是直接引用，因此不能點進入定位緣由，那就先作一個依賴。依賴後點擊進入一個反解析後的代碼，代碼是使用點評的配置框架。配置須要依賴一個本地文件。

    這時候內心的想法是一般這種問題可能和我使用的mac本須要寫入受權有關。找到本地文件的路徑，果真在磁盤上沒有這個問題。因此受權了整個目錄全部權限，重啓仍是沒有這個文件。手動建立文件，再次啓動仍是一樣錯誤。

    這時候想的是：這應該是一個使用這個點評框架的通用問題，美團同事會常遇到這個坑。因此這時候我根據問題去美團的wiki上搜索，果真搜到須要進行一個文件配置，裏面要寫內容。

    因此我跟一個項目的同事要了他的文件，將內容寫入，啓動成功。

 

測試用例啓動報錯

    程序能夠起來了，可是咱們是一個後臺系統，測試不能點頁面作黑盒測試，咱們都是本身寫測試用例作白盒測試。測試用例跑不起來？

    報錯ClassDefNotFound，少jar包？引用衝突？問了同一組的哥哥，他那邊沒有任何修改能夠正常啓動。先無論這些，少什麼加什麼，既然正常程序沒有問題，新加的pom引用scope都是test，添加了三個引用，啓動成功，問題是why?

    我將本身沒有修改過的原分支在其餘地方從新下載一份。將兩個分支的mvn dependency:tree作對比：

發現我手動添加的三個引用

|  \- org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile

[INFO] |  |     +- org.codehaus.plexus:plexus-utils:jar:3.0.24:compile

[INFO] |  |     \- org.apache.xbean:xbean-reflect:jar:4.5:compile

在原分支的

com.dianping.squirrel:squirrel-client:jar

這裏面作了間接引用。而新分支我添加一個exclusion:

而後直接引用了這個jar包：

問題是：

我沒有exclusion掉cat啊？結果卻成了：

why?

這是maven的傳遞性依賴，具體請參考：https://www.cnblogs.com/wuchanming/p/5403135.html

 

　　

靜兒的博客近期會進行一些改版，在博客園的文章只有技術乾貨，分離出「總結與思考」、「跑題時間」在每次本身我的公衆號上單獨發表。

　　靜兒我的公衆號：

本期文章：