溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
原創文章，歡迎轉載。轉載請注明：轉載自IT人故事會，謝謝！
原文鏈接地址：『高級篇』docker之微服務架構帶來的問題（五）之前已經說了微服務的概念，相信老鐵對微服務有了一個深刻的概念，從此以后咱們深入微服務，一步步來分析使用微服務會給我們帶來哪些問題，或者說使用微服務需要解決哪些問題，以及微服務在業界的解決方案
微服務間如何通信的？
可以考慮下，如果是單體架構會不會有這樣的問題，在什么情況下服務和服務之間如何通迅，調用什么樣的接口，依賴什么樣的數據，單體架構這種情況是很少見的，一個系統在一個應用可能已經完成了相應的功能，也不排除一些系統的數據是來此其他的系統的，單體架構的常用的方式有幾種，直接鏈接地址拿過來直接嵌入到頁面里面，我們使用httpclient調用對方的接口拿到返回的數據，這是比較常見的方案，微服務要重點考慮，因為微服務他們接口比較多，他們的調用非常的頻繁，所以我們必須事先設計好如何快捷高效的微服務通信。
微服務如何發現彼此
單體架構如何發現彼此，用過dubbo的同學應該知道，dubbo其實就是發現一種服務，web端的調用者需要對dubbo的提供者進行一次發現的，發現是通過zookeeper等，類似一個中間人的身份，服務的提供者，提供者告訴中間人。消費者通過中間人拿到提供者的地址，就能夠完成服務的發現了。如果是用dubbo直接確定微服務就可以了。但是我們使用的微服務可能涉及到各種語言讀取方式，dubbo只限java語言的通信，所以彼此發現是我們需要提前設定和解決的問題。
還是從單體架構來想，這跟每個公司的方式不同，有的直接通過ftp工具直接把war包上傳，執行命令執行重啟；有的可能用到了自動部署工具直接從master節點通過jenkens生成war包在準生產服務器指定目錄生成，沒有問題然后通過腳本的方式，對拷到生產環境。然后重啟。如果是微服務不一定少，一個完整的服務可能需要幾十來配合修改，如果在一個個手動來進行部署運維人員都崩潰死了。所以微服務的部署更新成為我們要解決的問題。
PS：先拋出問題，然后下次咱們說具體的問題分析。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
