大家看到圖可能有點暈了，不怕現在我們一起梳理一下：從上面的圖，我們可以看出阿里巴巴將我們的應用進行了拆分：分成了服務提供者（provider）和服務消費者（consumer）；註冊中心專心做自己的註冊工作並暴露服務位址；監控中心進行對服務呼叫的情況進行統計，分別用圖形的形式展現出來。
具體乙個服務的呼叫過程情況，步驟如下（注意：一定要先執行註冊中心）：
1.服務提供者讀取自己配置的註冊中心位址，將本地的服務向註冊中心進行註冊，同時在本地的執行容器中生成例項；這裡暴露的只是服務介面位址，而例項是在本服務提供者中執行著（一般情況下都是按照singleton的方式）；
2.註冊中心收到服務提供的註冊資訊後，做相關的初始化呼叫的資訊，並生成呼叫位址儲存在註冊中心，若後有消費者需要的時候，分發下去；
4.註冊中心收此訊息，然後將對應的服務位址用通知的方式傳送到消費者那裡；
5.消費者這邊收到，通過架構的**呼叫服務的方式，進行呼叫相關服務（至於**服務如何找到，感興趣可以查閱dubbo的**）；
6.服務提供了多少，消費用了多少次，以及對應呼叫的時長都我們不知道；怎麼辦呢？我們需要用乙個監控中心，提供我們全方位的呼叫情況資料；因此，上圖中的5就是這個意思了；我們可以根據呼叫的情況進行分析、可以拆分服務到其他的服務提供者中，防止更多的訪問失敗的情況。
會說大家都會，好吧，下篇我們將編寫乙個例項，給大家演示一下。
推送平台架構
由於cc部門沒有乙個公共的推送平台，各個業務之間推送手機訊息會非常費勁，而且沿用了pc架構的侷限性，只有使用者建立連線到伺服器才會收到各種訊息，在當今移動為王的環境，如果使用者的手機進入了休眠或者退出應用之後就不能接收訊息的話，是非常被動非常滯後的。因此，乙個公共的推送平台就出現了。簡單解釋一下各個...
魅族推薦平台架構解析（三）
近線模組 該層主要是利用流式處理的技術對使用者實時產生的行為日誌進行加工，利用一些高效 高效能的演算法生產有價值的資料 如處理演算法資料召回 實時資料統計等等。如圖，近線模組 流式日誌資料傳輸分為以下幾個部分 資源排程管理 如下圖，機器動態劃分分組，可以按業務進行劃分，也可以按照模型資源情況進行劃分...
大資料平台架構
大資料架構分為 資料採集,傳輸,儲存,排程和處理這五個部分.其中任務定期執行和任務分配,分別使用azkaban和zookeeper，大資料平台整體架構如圖1所示，由圖1可知，大資料平台的基礎是伺服器 硬體 所有計算機相關的服務均是基於伺服器 或主機 伺服器是一切服務和資料的根本，用於儲存 通訊 提供...