『高階篇』docker之微服務架構帶來的問題(四)
之前已經說了微服務的概念,相信老鐵對微服務有了一個深刻的概念,從此以後咱們深入微服務,一步步來分析使用微服務會給我們帶來哪些問題,或者說使用微服務需要解決哪些問題,以及微服務在業界的解決方案
微服務架構引入的問題和解決方案
-
微服務間如何通訊的?
可以考慮下,如果是單體架構會不會有這樣的問題,在什麼情況下服務和服務之間如何通迅,呼叫什麼樣的介面,依賴什麼樣的資料,單體架構這種情況是很少見的,一個系統在一個應用可能已經完成了相應的功能,也不排除一些系統的資料是來此其他的系統的,單體架構的常用的方式有幾種,直接連結地址拿過來直接嵌入到頁面裡面,我們使用httpclient呼叫對方的介面拿到返回的資料,這是比較常見的方案,微服務要重點考慮,因為微服務他們介面比較多,他們的呼叫非常的頻繁,所以我們必須事先設計好如何快捷高效的微服務通訊。
-
微服務如何發現彼此
單體架構如何發現彼此,用過dubbo的同學應該知道,dubbo其實就是發現一種服務,web端的呼叫者需要對dubbo的提供者進行一次發現的,發現是通過zookeeper等,類似一箇中間人的身份,服務的提供者,提供者告訴中間人。消費者通過中間人拿到提供者的地址,就能夠完成服務的發現了。如果是用dubbo直接確定微服務就可以了。但是我們使用的微服務可能涉及到各種語言讀取方式,dubbo只限java語言的通訊,所以彼此發現是我們需要提前設定和解決的問題。
-
微服務怎麼部署?更新?擴容
還是從單體架構來想,這跟每個公司的方式不同,有的直接通過ftp工具直接把war包上傳,執行命令執行重啟;有的可能用到了自動部署工具直接從master節點通過jenkens生成war包在準生產伺服器指定目錄生成,沒有問題然後通過指令碼的方式,對拷到生產環境。然後重啟。如果是微服務不一定少,一個完整的服務可能需要幾十來配合修改,如果在一個個手動來進行部署運維人員都崩潰死了。所以微服務的部署更新成為我們要解決的問題。
PS:先丟擲問題,然後下次咱們說具體的問題分析。
百度未收錄
>>原創文章,歡迎轉載。轉載請註明:轉載自IT人故事會,謝謝!
>>原文連結地址: