乙個架構常識：當呼叫方需要關心執行結果，通常使用rpc呼叫。
ret = passportservice::userauth(name, pass);
switch(ret){
case(yes) : return yeshtml();
case(no) : return nohtml();
case(jump) : return 304html():
default : return 500html();
登入頁面呼叫passport服務，會根據passport服務的返回結果，區別執行登入成功，登入失敗，執行錯誤。呼叫方關注執行結果時，不宜使用mq通訊。
使用mq通訊，呼叫方不能直接告之使用者登入成功又或失敗，阻塞住等待mq通知**不但使得編碼複雜，還會引入訊息丟失的風險，中間多加入一層，多此一舉，基本沒有人這麼玩。
但如果呼叫方不關心執行結果，卻仍然使用rpc呼叫，會引發上下游極大的耦合與瓶頸。
場景還原
有乙個通用的上游服務，例如「帖子發布」服務，負責公司通用的帖子發布業務。有一些個性化的業務關心「使用者發布帖子」這個事件，例如：
使用者發布帖子後，大資料部門要更新使用者的畫像
使用者發布帖子後，資訊質量部門要非同步檢查帖子是否合規
招聘業務最近在做使用者促活，如果使用者發布的是招聘帖子，要增加積分
個性化下游關注這個事件，但下游對事件的執行結果，「帖子發布」服務卻並不關心，如果「帖子發布」服務通過rpc的方式去通知下游，就會有很大的問題。
耦合為何存在？
帖子發布服務，這本來應該是乙個非常基礎的服務，上游upper通過rpc呼叫將事件同步給事件關注業務方biz1/biz2/biz3：
一旦有新的業務需求要關注這個事件，修改**的是通用上游upper，此時通用服務的owner就在心裡罵娘了「為何有需求的是你，修改**的卻是我」
一旦業務側出問題，會影響上游通用基礎服務，此時通用服務的owner又在心裡罵娘了「我ca，穩定性的kpi，全被兄弟部門毀了」
一旦業務側介面公升級，上游基礎服務需要配合公升級，此時通用服務的owner可能又會抱怨「為何被動公升級的人總是我」
架構不合理，簡直痛不欲生。
如何解耦呢？
如果事件發出方不關心訂閱方的執行結果，不能用rpc，應該用mq。
mq能夠做到上下游物理上和邏輯上都解耦：
物理上解耦，增加mq之後，上游互不知道彼此的存在，不會建立物理連線了，大家都只與mq建立物理連線
邏輯上解耦，事件發布方甚至不用知道哪些下游訂閱了這個訊息，新增訊息的訂閱方只需要連線mq就行了，不需要上游關注
mq是乙個非常常見的物理上解耦、邏輯上也解耦的利器。
關注下游執行執行結果，用rpc；
不關注下游執行結果，用mq，不用rpc；
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...
網際網路架構
使用者在同一時間內大量的訪問伺服器，tomcat伺服器併發能力為 200 250左右 jvm調優為1000 硬體條件 物理伺服器處理能力 網路頻寬 2.1 分布式計算 由多個執行緒，共同來完成某項特定的任務，拆合問題 2.2 分布式系統 distributed system 是建立在網路之上的軟體系...
大型網際網路架構概述
一 dns 1 當使用者在 瀏覽器中輸入 位址 後，瀏覽器會檢查 瀏覽器快取 中是否存在對應 網域名稱的解析結果 如果有，則解析過程結束 否則進入下乙個步驟 2 瀏覽器查詢 作業系統快取 中是否存在這個 網域名稱的解析結果 這個快取的內容 就是作業系統的 hosts檔案 如果有，則解析過程結束 否則...