Ⅰ 使用Netty開發web項目可以嗎
netty不能開發web項目，他不是web伺服器，盡管他支持http協議。
netty是中間件。你要用netty開發web項目可以用webserver連netty通信實現業務處理。但是單獨用netty是不行的，他不具備webserver的一些特性。
Ⅱ 為自己搭建一個分布式 IM(即時通訊) 系統
CIM(CROSS-IM) 一款面向開發者的 IM(即時通訊)系統；同時提供了一些組件幫助開發者構建一款屬於自己可水平擴展的 IM 。
藉助 CIM 你可以實現以下需求：
下面來看看具體的架構設計。
整體主要由以下模塊組成：
cim-server
IM 服務端；用於接收 client 連接、消息透傳、消息推送等功能。
支持集群部署。
cim-forward-route
消息路由伺服器；用於處理消息路由、消息轉發、用戶登錄、用戶下線以及一些運營工具（獲取在線用戶數等）。
cim-client
IM 客戶端；給用戶使用的消息終端，一個命令即可啟動並向其他人發起通訊（群聊、私聊）；同時內置了一些常用命令方便使用。
整體的流程也比較簡單，流程圖如下：
所以當我們自己部署時需要以下步驟：
接下來重點看看具體的實現，比如群聊、私聊消息如何流轉；IM 服務端負載均衡；服務如何注冊發現等等。
IM 服務端
先來看看服務端；主要是實現客戶端上下線、消息下發等功能。
首先是服務啟動：
由於是在 SpringBoot 中搭建的，所以在應用啟動時需要啟動 Netty 服務。
從 pipline 中可以看出使用了 Protobuf 的編解碼（具體報文在客戶端中分析）。
注冊發現
需要滿足 IM 服務端的水平擴展需求，所以 cim-server 是需要將自身數據發布到注冊中心的。
所以在應用啟動成功後需要將自身數據注冊到 Zookeeper 中。
最主要的目的就是將當前應用的 ip + cim-server-port+ http-port 注冊上去。
上圖是我在演示環境中注冊的兩個 cim-server 實例（由於在一台伺服器，所以只是埠不同）。
這樣在客戶端（監聽這個 Zookeeper 節點）就能實時的知道目前可用的服務信息。
登錄
當客戶端請求 cim-forward-route 中的登錄介面（詳見下文）做完業務驗證（就相當於日常登錄其他網站一樣）之後，客戶端會向服務端發起一個長連接，如之前的流程所示：
這時客戶端會發送一個特殊報文，表明當前是登錄信息。
服務端收到後就需要將該客戶端的 userID 和當前 Channel 通道關系保存起來。
同時也緩存了用戶的信息，也就是 userID 和 用戶名。
離線
當客戶端斷線後也需要將剛才緩存的信息清除掉。
同時也需要調用 route 介面清除相關信息（具體介面看下文）。
IM 路由
從架構圖中可以看出，路由層是非常重要的一環；它提供了一系列的 HTTP 服務承接了客戶端和服務端。
目前主要是以下幾個介面。
注冊介面
由於每一個客戶端都是需要登錄才能使用的，所以第一步自然是注冊。
這里就設計的比較簡單，直接利用 Redis 來存儲用戶信息；用戶信息也只有 ID 和 userName 而已。
只是為了方便查詢在 Redis 中的 KV 又反過來存儲了一份 VK，這樣 ID 和 userName 都必須唯一。
登錄介面
這里的登錄和 cim-server 中的登錄不一樣，具有業務性質，
為了實現只能一個用戶登錄，使用了 Redis 中的 set 來保存登錄信息；利用 userID 作為 key ，重復的登錄就會寫入失敗。
獲取一台可用的路由實例也比較簡單：
當然要獲取 Zookeeper 中的服務實例前自然是需要監聽 cim-server 之前注冊上去的那個節點。
具體代碼如下：
也是在應用啟動之後監聽 Zookeeper 中的路由節點，一旦發生變化就會更新內部緩存。
群聊介面
這是一個真正發消息的介面，實現的效果就是其中一個客戶端發消息，其餘所有客戶端都能收到！
流程肯定是客戶端發送一條消息到服務端，服務端收到後在上文介紹的 SessionSocketHolder 中遍歷所有 Channel（通道）然後下發消息即可。
服務端是單機倒也可以，但現在是集群設計。所以所有的客戶端會根據之前的輪詢演算法分配到不同的 cim-server 實例中。
因此就需要路由層來發揮作用了。
路由介面收到消息後首先遍歷出所有的客戶端和服務實例的關系。
路由關系在 Redis 中的存放如下：
由於 Redis 單線程的特質，當數據量大時；一旦使用 keys 匹配所有 cim-route:* 數據，會導致 Redis 不能處理其他請求。
所以這里改為使用 scan 命令來遍歷所有的 cim-route:*。
接著會挨個調用每個客戶端所在的服務端的 HTTP 介面用於推送消息。
在 cim-server 中的實現如下：
cim-server 收到消息後會在內部緩存中查詢該 userID 的通道，接著只需要發消息即可。
在線用戶介面
這是一個輔助介面，可以查詢出當前在線用戶信息。
實現也很簡單，也就是查詢之前保存 」用戶登錄狀態的那個去重 set 「即可。
私聊介面
之所以說獲取在線用戶是一個輔助介面，其實就是用於輔助私聊使用的。
一般我們使用私聊的前提肯定得知道當前哪些用戶在線，接著你才會知道你要和誰進行私聊。
類似於這樣：
在我們這個場景中，私聊的前提就是需要獲得在線用戶的 userID。
所以私聊介面在收到消息後需要查詢到接收者所在的 cim-server 實例信息，後續的步驟就和群聊一致了。調用接收者所在實例的 HTTP 介面下發信息。
只是群聊是遍歷所有的在線用戶，私聊只發送一個的區別。
下線介面
一旦客戶端下線，我們就需要將之前存放在 Redis 中的一些信息刪除掉（路由信息、登錄狀態）。
IM 客戶端
客戶端中的一些邏輯其實在上文已經談到一些了。
登錄
第一步也就是登錄，需要在啟動時調用 route 的登錄介面，獲得 cim-server 信息再創建連接。
登錄過程中 route 介面會判斷是否為重復登錄，重復登錄則會直接退出程序。
接下來是利用 route 介面返回的 cim-server 實例信息（ip+port）創建連接。
最後一步就是發送一個登錄標志的信息到服務端，讓它保持客戶端和 Channel 的關系。
自定義協議
上文提到的一些登錄報文、真正的消息報文這些其實都是在我們自定義協議中可以區別出來的。
由於是使用 Google Protocol Buffer 編解碼，所以先看看原始格式。
其實這個協議中目前一共就三個欄位：
目前主要是三種類型，分別對應不同的業務：
心跳
為了保持客戶端和服務端的連接，每隔一段時間沒有發送消息都需要自動的發送心跳。
目前的策略是每隔一分鍾就是發送一個心跳包到服務端：
這樣服務端每隔一分鍾沒有收到業務消息時就會收到 ping 的心跳包：
內置命令
客戶端也內置了一些基本命令來方便使用。
比如輸入 :q 就會退出客戶端，同時會關閉一些系統資源。
當輸入 :olu(onlineUser 的簡寫)就會去調用 route 的獲取所有在線用戶介面。
群聊
群聊的使用非常簡單，只需要在控制台輸入消息回車即可。
這時會去調用 route 的群聊介面。
私聊
私聊也是同理，但前提是需要觸發關鍵字；使用 userId;;消息內容 這樣的格式才會給某個用戶發送消息，所以一般都需要先使用 :olu 命令獲取所以在線用戶才方便使用。
消息回調
為了滿足一些定製需求，比如消息需要保存之類的。
所以在客戶端收到消息之後會回調一個介面，在這個介面中可以自定義實現。
因此先創建了一個 caller 的 bean，這個 bean 中包含了一個 CustomMsgHandleListener 介面，需要自行處理只需要實現此介面即可。
自定義界面
由於我自己不怎麼會寫界面，但保不準有其他大牛會寫。所以客戶端中的群聊、私聊、獲取在線用戶、消息回調等業務(以及之後的業務)都是以介面形式提供。
也方便後面做頁面集成，只需要調這些介面就行了；具體實現不用怎麼關心。
cim 目前只是第一版，BUG 多，功能少（只拉了幾個群友做了測試）；不過後續還會接著完善，至少這一版會給那些沒有相關經驗的朋友帶來一些思路。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發： 721575865
群內提供免費的Java架構學習資料（裡面有高可用、高並發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間「來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
Ⅲ 如何搭建一個自己的IM即時通訊聊天軟體
搭建一個自己的IM即時通訊聊天軟體的框架如下：1、CIM 中的各個組件均採用 Spring Boot 構建。
2、採用 Netty + Google Protocol Buffer 構建底層通信。
3、Redis 存放各個客戶端的路由信息、賬號信息、在線狀態等。
4、Zookeeper 用於 IM-server 服務的注冊與發現。
搭建IM即時通訊聊天軟體建議咨詢容聯易通。容聯提供真正穩定的即時通訊雲平台，豐富的即時通訊、實時音視頻等功能呢，助力您的APP以及企業移動門戶構建即時通訊服務。
北京容聯易通信息技術有限公司以雲化和智能化的方式，為企業客戶提供全面的通訊服務。包括PaaS通訊能力（語音、簡訊等）、CC（雲客服與雲聯絡中心）、UC（IM即時通訊雲、融合通訊、視頻與會議）、行業新通訊解決方案和「通訊+AI」服務，助力企業提高溝通體驗和經營效率，驅動中國企業通訊產業實現互聯網化、雲計算化、能力化、融合化和智能化。
Ⅳ 如何寫一個即時通訊軟體
網易雲信致力於互聯網路技術的開發與研究，使開發者通過簡單集成客戶端SDK和雲端開放API，快速實現強大的移動互聯網IM和音視頻功能。在場景化方面，深入各行各業，狠抓痛點，第一時間包裝相應的場景方案，助力企業解決行業難題。同時，網易雲信...
2020-03-09回答者：網易(杭州)網路有...10
如何編寫一個即時通訊軟體
答：可以用bmob做後端，有即時通訊的demo 昨天下班前發布了最新的Bmob_IM_V1.1.2版本的SDK和應用Demo，還未正式通知大家，但還是有人察覺到了，那麼，這一次版本更新了什麼呢？ 主要是針對大家都比較關心的問題進行了集中解決。 一、更新功能： 1、...
2016-12-21回答者:C9006122個回答1
如何搭建一個自己的IM即時通訊聊天軟體？
問：如何搭建一個自己的IM即時通訊聊天軟體？
答：搭建一個自己的IM即時通訊聊天軟體的框架如下：1、CIM 中的各個組件均採用 Spring Boot 構建。2、採用 Netty + Google Protocol Buffer 構建底層通信。3、Redis 存放各個客戶端的路由信息、賬號信息、在線狀態等。4、Zookeeper 用於 IM-server ...
2018-09-03回答者:容聯雲5個回答1
怎麼用Java寫一個即時通訊軟體？
答：我看到過一個，鏈接給你，用websocket的 https://github.com/TooTallNate/Java-WebSocket 裡面有個example就是im的
2013-05-24回答者:micoud_104個回答1
寫一個簡單的即時通訊軟體需要掌握哪些基礎的網路知識
答：掌握TCP/UDP網路協議，還要知道Socket知識，會java或者C#或者C語言的編程，這樣就可以通過語言來實現網路的通訊。建議看看Openfire，採用的協議是XMPP。
2017-02-16回答者:天1234569411個回答
請問可以用哪些語言編寫即時通訊軟體？
問：並請說明那種語言最好
答：當然要用JAVA和C++等多程序開發. 你可以看這家企業即時通訊軟體www.kehutone.com
2007-03-14回答者:138138577983個回答
我要用java寫一個簡單的即時通訊軟體，該怎麼寫。...
問：我們打算先用http實現信息收發，有人會做嗎。有demo的話求發我感謝。
答：你是說電腦端手機端都要開發嗎，電腦端一般用socket, Android端用XMPP5通信
2015-03-10回答者:淪落人19921個回答
自己寫的小型的即時通訊軟體如何像QQ一樣實現聊天...
答：用socket或者serversocket，也可以使用數據包。必須要有這個，就可以在不同的計算機上實現即時通訊，但是，其功能與專業的聊天軟體差別比較大
2010-11-08回答者:孫74213個回答5
求大神幫寫用JAVA編寫一個即時通信的軟體有常 謝謝了
問：會的留言 可商量後再寫
答：描述得太不夠具體，，，，，是單對單、還是可以單對多；要不要分群；要不要圖片；等
2020-06-17回答者:知道網友2個回答1
開發一個即時通訊軟體需要什麼樣的人員?
問：開發一個即時通訊軟體需要什麼樣的人員?比如說需要幾個程序員,多少平面...
答：要看規模，不知道你要做多大的 架構師 起碼1個，如果大的話要兩個 資料庫設計 人員 美工1-2個 程序員依大小而定，小的話3，4個 大的話就每准了 如果作為產品的話，時間將會很長，自己玩，自己用的話，就很快了
Ⅳ 即時通訊IM系統開發
我於2014年開啟即時通訊的開發之路，歷經從服務端到客戶端，從第三方到自研，經歷過諸多的研發難題，都一一破解。現將經驗總結如下，希望對行業內從事IM開發的程序員有所幫助。
①P2P方式
P2P方式多用於區域網內聊天，這種方式在有種種限制和不便。一方面它只適合在線的點對點消息傳輸，對離線，群組等支持不夠。另一方面由於 NAT 的存在，使得不同區域網內機器互聯難度大大上升，在某些網路類型(對稱NAT)下無法建立連接。使用P2P方式的軟體在啟動後一般做兩件事情：
1、進行UDP廣播:發送自己信息和接受同區域網內其他端信息。
2、開啟TCP監聽:等待其他端進行連接。
②伺服器中轉方式
大部分的互聯網IM產品都採用伺服器中轉這種方式進行消息傳輸，相對於P2P的方式，具有有以下的優點:
1、支持更多P2P無法支持或支持不好的業務，如離線消息，群組，聊天室。
2、方便業務邏輯的拓展和新舊版本的兼容，當然它也有自己的問題，就是伺服器架構復雜，並發要求高。
通過以上的比較，建議我們在開發IM系統的時候使用伺服器中轉的方式。
IM的網路連接方式有基於TCP的長連接和基於HTTP短連接兩種:
①基於TCP的長連接
基於TCP長連接則能夠更好地支持大批量用戶，問題是客戶端和伺服器的實現比較復雜。也有一些改進，比如下行使用MQTT進行伺服器通知/消息的下發，上行使用HTTP短連接進行指令和消息的上傳。這種方式能夠保證下行消息/指令的及時性，但是在弱網路下上行慢的問題還是比較嚴重，早期的來往就是基於這種方式。
②基於HTTP短連接
常見於WEB IM系統(現在很多WEBIM都是基於WebSocket實現)，它的優點是實現簡單，方便開發上手，問題是流量大，伺服器負載較大，消息及時性無法很好地保證，對大規模的用戶量支持不夠，適合小型的IM系統。
IM常見的協議有：XMPP，MQTT，私有協議。各種協議優缺點情況如下：
①XMPP協議
優點：協議開源，可拓展性強，在各個端(有各種語言的實現，對於前期入門級的開發者是很好的選擇，方便進入IM開發的程序員快速上手。
缺點：XML表現力弱，有太多冗餘信息，流量大。
常見案例：Gtalk、新浪微博、Facebook。
②MQTT協議
優點：協議簡單，流量少。
缺點：不是一個專門為IM設計的協議，多使用於推送。
③私有協議
幾乎所有主流的IM APP都是使用私有協議。
優點：高效，節約流量(一般使用二進制協議)，安全性高，難以破解。
缺點：開發初期沒有現有樣列可以參考，對於參與IM開發的程序員的要求比較高。
常見案例：微信、釘釘。
根據以上的對比，我們得出結果，一個好的協議需要滿足高效、簡潔、節約流量、易於拓展等要求，同時又能夠和當前的開發團隊的技術堆棧匹配，不能選擇一個他們很難上手的。
這里再提一下，我當時開發IM系統的時候，上手用的是XMPP，在使用的過程中發現了很多問題，踩了很多坑。
①實時性原則
消息實時到達接收方，如果用戶在線，則消息實時到達，如果用戶不在線，則消息在用戶登錄後到達。由於網路波動，以及移動端操作系統對應用前後台切換的管理，如何實現用戶連接管理、消息實時推送，推送失敗的處理方式，客戶端重連機制，消息如何補齊等，都需要IM系統考慮。由於TCP開發略微復雜，早期的基於HTTP短輪詢、長輪詢的低效的技術方案，也無法達到實時性的要求。
②可靠性原則
是指我們經常聽到的「消息送達」，通常用消息的不丟失和不重復兩個技術指標來表示。可靠性是要確保消息被發送後，能夠被接收者收到。由於網路環境的復雜性，以及用戶在線的不確定性，消息的可靠性（不丟失、不重復）是IM系統的核心指標，也是IM系統實現中的難點之一。總體來說，IM系統的消息「可靠性」，通常就是指聊天消息投遞的可靠性（准確的說，這個「消息」是廣義的，因為還存用戶看不見的各種指令和通知，包括但不限於進群退群通知、好友添加通知等，為了方便描述，統稱「消息」）。
從消息發送者和接收者用戶行為來講，消息「可靠性」應該分為以下幾種情況：
1、發送失敗：對於這種情況要感知到，明確反饋給發送方。如果此消息沒有發送成功，發送方可以選擇重試或者稍後再試。
2、發送成功：如果接收方處在「在線」狀態，應該立即收到此消息。如果接收方處在「離線」狀態不能收到消息，一旦上線則立刻收到消息。
3、消息不能重復：簡言之就是發送的一條消息不能被重復收到多次。
③一致性原則
系統中要重視消息的時序問題，不能出現發送的消息順序顛倒的問題。通常出現時序的問題有以下的原因：
1、網路傳輸延遲導致時序不一致。不同用戶發送的消息到達伺服器的延時差異較大，給消息時序性帶來挑戰。早期開發過程中經常會遇到這種問題。
2、分布式系統的出現導致時序不一致。IM系統模塊眾多，接入層、消息邏輯層等、每層都分布式集群化，這些應用分布在不同的機器上，如何保證時序是個難點。
④擴展性原則
擴展性是IM系統後期要考慮的問題，包括功能的擴展，伺服器的擴展等，這次就先不展開闡述。
Mina和Netty都是Java領域高性能和高可伸縮性網路應用程序的網路應用框架。
Mina是 Apache 組織的項目，它為開發高性能和高可用性的網路 應用程序提供的框架。當前的Mina版本支持基於 Java NIO 技術的 TCP/UDP 應用程序開發、串口通訊程序。目前正在使用 Mina的 軟體有：Apache Directory Project、AsyncWeb、AMQP（Advanced Message Queuing Protocol）、RED5 Server（Macromedia Flash Media RTMP）、ObjectRADIUS、Openfire等。
Netty是由JBOSS提供的一個java開源框架。Netty提供非同步的、 事件驅動的網路應用程序框架和工具，用以快速開發高性能、高可靠性的網路伺服器和客戶端程序。也就是說Netty是一個基於NIO的客戶端和伺服器端框架，使用Netty可以確保你快速和簡單的開發出一個網路應用。
雖然我使用過Mina，但是建議開發選型上使用Netty 。因為Netty有對google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)。Mina更新到2.0就不再更新了，而Netty一直在更新，目前最新發布的版本已經更新到4.1，從版本更新角度可以看出Netty的社區很活躍，修復問題一直在持續，這將對我們選擇它進行開發帶來很多便利。
單體Netty IM系統，可以支持10萬並發，如果機器性能良好的情況下可以超過10萬。
分布式的Netty IM系統，可以支持更高的並發數。各組件的功能如下：
①IM Server 連接器：主要用來負責維持和客戶端的TCP連接。
②緩存：負責用戶、用戶綁定關系、用戶群組關系的緩存。 緩存臨時數據、加快讀速度。可以做成集群方式。
③資料庫：用戶、群組、離線消息。可以做成集群方式。
④消息隊列：用戶狀態廣播、群組消息廣播。可以做成集群方式。
開發環境推薦使用netty-4.1.30這個版本，jdk使用1.8及以上版本。如下所示：
io.netty
netty-all
4.1.30.Final
①開發框架採用Netty + Spring(Spring4.x)。
②Spring採用Spring cloud。基於restful 短連接的分布式微服務架構，完成用戶在線管理、單點登錄系統。
③消息隊列採用rocketMQ 高速隊列，整流作用。
④資料庫採用MYSQL。
⑤協議JSON +自定義數據包採用Fastjson。
基於Netty的IM開源代碼在網上有很多，這里就不列舉了，可以自行去git上下載。我認為關鍵是把概念理清楚，技術堆棧選好，總體框架定好，接下來就是開發一個適合中小企業的IM系統了，但是要考慮到後期的擴展性，因為一個好的產品不能自己用，要讓更多的人使用。
Ⅵ java web既然已經有了tomcat為什麼還要使用netty
但是nio直接使用比較難用，所以有了mina，netty這些針對網路io部分（tcp/udp-傳輸層）的封裝（nio也有非網路io部分），為了使nio更易用。
http是應用層的協議。
servlet3.0則是另外一種東西，不是對協議的封裝，javaee6眾多規范中的一個，但凡javaee6的實現（或者像tomcat這種web容器部分的實現），都會支持servlet3.0，servlet理論上可以支持多種應用層協議（不單單只是http），而servlet3.0以後提供的非同步特性與javase提供的nio或aio無直接關系，就是使用bio一樣可以實現servlet3.0中提供的非同步特性。
非同步只是一種概念，非同步與否要看，上層使用的非同步，而支持的下層完全可能是阻塞的。
netty跟tomcat是同樣的概念么？
不是
netty官方說是個框架，那他是否還需要web容器支持？
不需要
如果我客戶端使用netty,服務端使用tomcat也是能連上的吧？
可以，比如客戶端直接使用netty構造http協議與tomcat支持的servlet通信
是不是可以用netty 的客戶端和服務端 直接替換掉HttpAsyncClient和tomcat?
不是很明白你的意思...netty的客戶端和服務端、HttpAsyncClient、tomcat...三者之間似乎不存在關系...看你的通訊協議了
Ⅶ java web能用netty嗎求解答
當然可以。netty是優秀的JAVA網路應用程序框架，關鍵詞是NIO和非同步。它提供了對JAVA網路編程API的封裝，屏蔽了繁雜的編程細節，讓開發者可以更加專注於業務邏輯的實現。很多中間件都是基於netty來實現的，你可以用來實現一個web容器，也能寫一個游戲伺服器。學習netty能夠讓你更加熟悉網路編程，對個人好處還是比較大的。
但是需要提醒的是，你要根據你自己的需求決定用什麼技術，如果是做java web的通信，建議可以用activeMQ，使用要比neety簡單一點，而且這個是在應用層的通信架構，neety是協議層的通信架構。
Ⅷ java服務端怎麼主動給某用戶發送消息
總體來說 你現在要做這個東西 對於你來說還是困難了點
簡單來說 你要的東西 實例是很難給出的 需要你多多去論壇學習 這不是幾行代碼能夠描述的
專業點說 你先理解這個東西 :
HTTP協議的兩個特性：
1、無連接：無連接的含義是限制每次連接只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
2、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在伺服器不需要先前信息時它的應答就較快。
所以回答你的問題，表象的推送其實是客戶端定時請求伺服器的。
但是微信什麼的APP這樣的，APP是有一套推送機制的和WEB這樣的是有區別的