建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
1.背景
安圖網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。
本文續(xù)上篇《Java 帝國(guó)之消息隊(duì)列》
自從張家村的ZhangMQ問(wèn)世以來(lái)，大家都看到了消息隊(duì)列在分布式系統(tǒng)中的巨大好處，紛紛另起爐灶搞一套自己的消息隊(duì)列，各種MQ產(chǎn)品如雨后春筍班出現(xiàn)，各家都瘋狂的宣傳自己的寶貝。
為了吸引程序猿來(lái)使用， 各家八仙過(guò)海，各顯神通，定義了各式各樣的API, 由于是獨(dú)立發(fā)展，這些API協(xié)議多樣，互不兼容， 學(xué)習(xí)成本高，使用起來(lái)非常不方便。
這是帝國(guó)所不能容忍的 !
其實(shí)Java 帝國(guó)非常擅長(zhǎng)搞出標(biāo)準(zhǔn)的協(xié)議和接口， 之前的JDBC就是一個(gè)典型的例子(參見(jiàn)文章《JDBC的誕生》)， 制定了協(xié)議以后， 讓各個(gè)產(chǎn)品廠商去實(shí)現(xiàn), 實(shí)現(xiàn)了針對(duì)數(shù)據(jù)庫(kù)編程的統(tǒng)一接口。
既然數(shù)據(jù)庫(kù)可以這么干， 消息隊(duì)列肯定也沒(méi)問(wèn)題!
由于張家村開(kāi)發(fā)了***個(gè)消息隊(duì)列產(chǎn)品， 帝國(guó)把制定標(biāo)準(zhǔn)接口的光榮使命交給了張家村。
2.消息隊(duì)列接口設(shè)計(jì)
張家村經(jīng)驗(yàn)豐富的老村長(zhǎng)又把任務(wù)分給了小張， 告訴他我們要做的是一個(gè)廠商獨(dú)立的標(biāo)準(zhǔn)接口， 讓他先去調(diào)研一下時(shí)下流行的MQ的現(xiàn)狀。
小張先找到了某大廠著名MQ, 它占據(jù)了企業(yè)級(jí)市場(chǎng)不少份額， 但是直接使用它的 Java API 編程的話(huà)就不那么容易了， 大家可以快速瀏覽下：
小張能看的出這是在發(fā)送一個(gè)消息，但這MQEnvironment， openOptions，MQPutMessageOptions 看起來(lái)讓小張心煩，特別是還得理解Queue Manager這樣的概念，有點(diǎn)不容易。
小張又找了一個(gè)以開(kāi)源吸引人的RabbitMQ ， 這個(gè)看起來(lái)清爽多了：
但是這queueDeclare方法 和 basicPublish 方法小張總覺(jué)得的不爽。
只看了兩個(gè)消息隊(duì)列， 小張就不想再看了， 他去找村長(zhǎng)說(shuō)： 這差別也太大了，根本無(wú)法統(tǒng)一。
村長(zhǎng)說(shuō)：”不要被紛繁的現(xiàn)象迷住了雙眼， 要看透背后的本質(zhì)， 做出適當(dāng)?shù)某橄蟛趴梢??！?/p>
又是抽象! 小張暗自嘆氣， 這抽象實(shí)在是太難了。
”你深入思考下“ 村長(zhǎng)看出了小張的困難， 鼓勵(lì)他說(shuō)： ”其實(shí)也沒(méi)那么難， 我們先搞出幾個(gè)最基本的概念, 記不記得操作系統(tǒng)中學(xué)過(guò)的生產(chǎn)者-消費(fèi)者模型? 我們完全可以應(yīng)用到這里來(lái)啊， 消息生產(chǎn)者(Message Producer)， 消息消費(fèi)者 (Messge Consumer) ， 生產(chǎn)者提供發(fā)送消息的方法， 消費(fèi)者提供接收消息的方法， 如果加上消息隊(duì)列 (Message Queue) 的話(huà)就是這樣：“
小張說(shuō)：”這也太抽象了吧， 我看人家還有什么Queue Manager, Connection ,Channel 之類(lèi)的“
村長(zhǎng)說(shuō)： ”別急啊， 你看不管是生產(chǎn)者向隊(duì)列發(fā)送消息，還是消費(fèi)者去接收消息， 其實(shí)都是在和消息隊(duì)列進(jìn)行交互， 所以我們?cè)僖胍粋€(gè)會(huì)話(huà)(Session)的概念出來(lái) ?！?/p>
”奧， 我有點(diǎn)明白了 ，Session 可以創(chuàng)建消息， 還可以引入事務(wù)的支持呢“ 小張思維敏捷
“不錯(cuò)， 其實(shí)消息生產(chǎn)者/消費(fèi)者也應(yīng)該由Session來(lái)創(chuàng)建，因?yàn)樗麄円l(fā)送/接收消息肯定是在一個(gè)會(huì)話(huà)中， 另外你想想， Session對(duì)象由誰(shuí)來(lái)創(chuàng)建?”
小張說(shuō)： “應(yīng)該是Connection ” 說(shuō)著小張畫(huà)了一張圖：
“你看這概念不就出來(lái)了，是不是很簡(jiǎn)單? ” 村長(zhǎng)笑著說(shuō)。
小張撓撓頭說(shuō)： “會(huì)者不難，難者不會(huì)啊， 對(duì)了，我們還缺乏最關(guān)鍵的連接參數(shù)(ip地址，端口等)還有隊(duì)列的名稱(chēng)之類(lèi)的信息。 這些信息怎么辦?”
“這確實(shí)有點(diǎn)復(fù)雜，各個(gè)廠商的具體情況差別太大?！?村長(zhǎng)也表示犯難 ，“你讓我想想， 下午再聊?！?/p>
3.配置和代碼的分離
小張中午吃飯的時(shí)候也在想， 這些復(fù)雜的配置參數(shù)該怎么辦， 要是都讓程序員在代碼里寫(xiě)，那就太丑陋了吧， 因?yàn)椴煌腗Q產(chǎn)品，配置都不一樣啊。
下午的時(shí)候，看到村長(zhǎng)一副喜氣洋洋的表情， 小張知道問(wèn)題解決了。
村長(zhǎng)說(shuō)： “我想到了一個(gè)辦法， 一個(gè)很簡(jiǎn)單，但是有效的辦法?！?/p>
小張說(shuō)：“別賣(mài)關(guān)子了，快說(shuō)吧”
”其實(shí)也是又老又俗的辦法了， 這個(gè)辦法就是把配置和代碼分開(kāi)， 你不是說(shuō)這些連接參數(shù)很復(fù)雜，各個(gè)廠商不同嗎? 那就作為配置信息把它放到Web容器里，對(duì)外只提供一個(gè)簡(jiǎn)單的ConnectionFactory的接口，由這個(gè)ConnectionFactory來(lái)創(chuàng)建Connection， 當(dāng)然了各個(gè)廠商必須實(shí)現(xiàn)這個(gè)ConnectionFactory“
"那怎么才能得到這個(gè)ConnectionFactory ?"
"這就簡(jiǎn)單了， 對(duì)程序員來(lái)講，通過(guò)JNDI 就可以輕松拿到了， 例如："
”這辦法不錯(cuò)，把細(xì)節(jié)都隱藏起來(lái)了， 既然ConnectionFactory可以這么搞， 隊(duì)列(Queue)的配置信息也可以這么辦啊?！?/p>
村長(zhǎng)說(shuō)：”所以ConnectionFactory, Queue 就是隔離細(xì)節(jié)的抽象層。”
4.再次抽象
標(biāo)準(zhǔn)接口初具模型，小張很高興，晚上請(qǐng)喜歡的張二妮吃飯， 忍不住得瑟了一下。
張二妮說(shuō)：“你們兩個(gè)老土，定義的標(biāo)準(zhǔn)接口，都已經(jīng)過(guò)時(shí)了!”
小張很生氣： “怎么可能呢?”
二妮說(shuō)：“告訴你們吧， 你們搞的這個(gè)叫Point to Point模型，就是一個(gè)發(fā)送方，對(duì)應(yīng)一個(gè)接收方， 現(xiàn)在外邊有很多人在用 發(fā)布/訂閱 的模型，你們知道不? ”
“一個(gè)客戶(hù)端(Client1)對(duì)一個(gè)Topic發(fā)布了消息， 很多訂閱了這個(gè)Topic的客戶(hù)端(Client2, Client3) 都可以接收到這個(gè)消息的副本?！?/p>
小張呆住了， 這和以前ZhangMQ的方式完全不同， 隊(duì)列都不見(jiàn)了， 引入了一個(gè)新的主題(Topic)的概念。
第二天， 小張趕緊去找村長(zhǎng)， 告訴他發(fā)生了新情況。
村長(zhǎng)說(shuō)： “你呀，還是太年輕， 慌什么，深入思考一下， 這個(gè)發(fā)布/訂閱的本質(zhì)和我們之前的生產(chǎn)者/消費(fèi)者沒(méi)什么不同。 ”
小張說(shuō)： “那人家還有Topic的概念呢。”
“我們可以把Topic和Queue 變成一個(gè)更抽象的概念，他們都是消息的目的地， 嗯， 就叫做Destination吧，這個(gè)Destination的細(xì)節(jié)也是需要配置出來(lái)的， 通過(guò)JNDI來(lái)獲取?！?/p>
“那訂閱怎么處理?”
村長(zhǎng)說(shuō)： “原來(lái)我們定義的是MessageConsumer, 現(xiàn)在增加一個(gè)新概念叫做 TopicSubscriber ， 可以從Destination獲取消息，這不就行了， 其實(shí)從本質(zhì)上來(lái)講Subscriber也是消息消費(fèi)者的一種而已。”
“那怎么才能實(shí)現(xiàn)訂閱的功能呢?”
“別忘了， 我們只定義接口行為， 具體的實(shí)現(xiàn)需要由各個(gè)產(chǎn)品來(lái)負(fù)責(zé)!”
小張看著這幅圖， 深感抽象的威力巨大， 這么多的細(xì)節(jié)***變成了這幾個(gè)簡(jiǎn)單的概念!
小張還特意寫(xiě)了一段代碼，展示上面的概念：
張家村把這個(gè)設(shè)計(jì)交了上去， 帝國(guó)很滿(mǎn)意，把它起名為Java Message Service (JMS)， 隨后強(qiáng)制各大產(chǎn)品實(shí)現(xiàn)JMS， 否則就不頒發(fā)進(jìn)京證， 沒(méi)這個(gè)證別想在帝國(guó)做生意!
JMS由于設(shè)計(jì)良好，概念清晰，其實(shí)不用怎么強(qiáng)制，很快就流行開(kāi)了，成為了Java 帝國(guó)的事實(shí)標(biāo)準(zhǔn)。
【本文為專(zhuān)欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)coderising獲取授權(quán)】
網(wǎng)站題目：Java帝國(guó)之JMS的誕生
網(wǎng)頁(yè)鏈接：http://m.5511xx.com/article/dppoice.html
