今年真的是郁悶透頂了。項(xiàng)目組居然叫我去做我從來(lái)沒(méi)有做過(guò)的接口方面的編程，搞得我焦頭爛額。
因?yàn)闆](méi)有經(jīng)驗(yàn)，寫(xiě)的代碼亂七八糟，出了好多問(wèn)題，不過(guò)，也學(xué)了不少東西。
首先就是Socket的編程，我只是在學(xué)習(xí)JAVA時(shí)寫(xiě)了一些socket方面的例子，從來(lái)就沒(méi)有仔細(xì)研究過(guò)，組長(zhǎng)居然叫我設(shè)計(jì)一個(gè)JAVA的接口平臺(tái)。胡弄了一通之后，系統(tǒng)上線了。但是問(wèn)題就來(lái)了。
首先第一個(gè)問(wèn)題，長(zhǎng)連接必須有心跳。因?yàn)橹皡f(xié)議中沒(méi)有定義心跳協(xié)議，而我又沒(méi)有經(jīng)驗(yàn)，所以等真正上線之后才發(fā)現(xiàn)，如果長(zhǎng)連接沒(méi)有心跳，很容易導(dǎo)致在Socket連接中，長(zhǎng)時(shí)間沒(méi)有通訊的話，就會(huì)導(dǎo)致連接雖然保持，但不能正常通訊的問(wèn)題。
第二個(gè)問(wèn)題，必須加入流量控制。這個(gè)問(wèn)題出現(xiàn)在業(yè)務(wù)高峰期時(shí)，會(huì)接收到大量請(qǐng)求，這時(shí)業(yè)務(wù)系統(tǒng)的處理速度跟不上請(qǐng)求發(fā)起方，導(dǎo)致大量請(qǐng)求積壓在Socket服務(wù)器端，導(dǎo)致JVM崩潰。這個(gè)問(wèn)題我之前是使用了JAVA5中所帶的ExecutorService，通過(guò)設(shè)置固定的線程池?cái)?shù)量的方式做流量控制，后來(lái)發(fā)現(xiàn)不行，線程會(huì)不斷增加，導(dǎo)致JVM崩潰。不知道是我代碼問(wèn)題還是ExecutorService本身的問(wèn)題。建議使用BlockingQueue來(lái)做隊(duì)列，我目前用起來(lái)還是比較穩(wěn)定。
第三個(gè)問(wèn)題，是由上面的問(wèn)題衍生出來(lái)的一個(gè)問(wèn)題，就是效率問(wèn)題。我之前的線程處理方式是每接到一個(gè)請(qǐng)求，會(huì)在主線程實(shí)例化一個(gè)線程實(shí)例，再把線程放到線程池中運(yùn)行，這個(gè)方式除了導(dǎo)致上面的問(wèn)題以外，而且效率很慢，我稱(chēng)之為“推”的方式。現(xiàn)在經(jīng)過(guò)改良后，在服務(wù)起來(lái)之后，先事先運(yùn)行固定數(shù)量的線程，然后所有線程都從同一個(gè)BlockingQueue中獲取指令，我稱(chēng)之為“拉”的方式。這種方式讓程序效率提高了很多，省去了每次生成對(duì)象的過(guò)程。而且這個(gè)設(shè)計(jì)本身也實(shí)現(xiàn)了處理量的控制。
第四個(gè)問(wèn)題，就是指令的返回問(wèn)題。在處理每個(gè)異步指令的過(guò)程時(shí)，對(duì)于返回指令，通常的做法是將返回結(jié)果指令放入隊(duì)列中，然后再逐一返回。這個(gè)做法就存在了一個(gè)隱患，就是當(dāng)服務(wù)器的進(jìn)程core掉，或者因其它原因中斷，所有的返回指令都會(huì)丟失。建議的做法是在得到返回指令之后，將要返回的結(jié)果指令持久化，通常是放入數(shù)據(jù)表或者緩存文件中，然后再操作，這樣的話，當(dāng)重啟進(jìn)程，也可以重新讀取返回指令，最大可能保證接口的數(shù)據(jù)準(zhǔn)確性。
第五個(gè)問(wèn)題，其實(shí)跟上面有一些接近，就是做接口程序，有一個(gè)大原則，就是一切有跡可尋。在受理時(shí)要寫(xiě)日志，執(zhí)行業(yè)務(wù)時(shí)要記錄、返回結(jié)果時(shí)要入庫(kù)。總之讓運(yùn)維人員可以很方便的定位問(wèn)題，排除問(wèn)題。否則，只能麻煩自己啦！
至于其它錯(cuò)誤我就不一一羅列了，總之在錯(cuò)誤中進(jìn)步，還是學(xué)到不少知識(shí)。呵呵～～