java開發(fā)搞了兩個(gè)月了，由于前后端都要打通，發(fā)現(xiàn)了一些以前沒(méi)注意的問(wèn)題。
對(duì)于常規(guī)的前后端開發(fā)方案，這篇文章提到了方案選擇：http://blog.csdn.net/yeyincai/article/details/51470475
我自己的經(jīng)驗(yàn)是這些：
RPC+Model：采用grpc+protobuf的方案，在android和ios之間都很方便通信，比起傳統(tǒng)的HTTP(s)+JSON方式，開發(fā)效率和運(yùn)行效率都要高很多，不過(guò)門檻比較高一點(diǎn)，工作兩年的程序員應(yīng)該能比較順暢的入門，主要是ios端配置方面稍微麻煩一些。

IPC：android多個(gè)應(yīng)用間的通信，測(cè)試過(guò)了aidl的方式，目前開發(fā)起來(lái)比較麻煩，報(bào)錯(cuò)系統(tǒng)做得太差了,沒(méi)有找到合適的插件工具處理在android studio中的問(wèn)題。估計(jì)后面干脆改成grpc的方式看看效果如何。

長(zhǎng)鏈接：打算使用netty，還要看看開發(fā)的難易程度。

開發(fā)模式：看樣子MVC真的已經(jīng)過(guò)時(shí)了。 
1. ios和android 都可以使用MVVM，比MVC解耦能力強(qiáng)得多。
2.服務(wù)器上，ESB容器外加OSGi組成SOA，也要方便很多。
3.linux客戶端，QT半殘廢，Xwindow主流包裝，已經(jīng)是gnome。

SQL：持久層和緩存層一般都是注冊(cè)和保存數(shù)據(jù)使用
1.注冊(cè)方案，鑒于zookeeper坑太多，偏向于選擇consul，consul不像zookeeper這么抽象，封裝了服務(wù)化的http  api，非常方便調(diào)用，并且增加了對(duì)服務(wù)健康檢查。
2.為什么不選用redis？沒(méi)深入研究redis。個(gè)人認(rèn)為codis方案（豆瓣開發(fā)的分布式緩存）能夠滿足實(shí)際場(chǎng)景的需求。