問題一：異構(gòu)系統(tǒng)的不標(biāo)準(zhǔn)問題
這主要表現(xiàn)在：軟件和應(yīng)用、通訊協(xié)議稠肘、數(shù)據(jù)格式、開發(fā)和運維的過程和方法不標(biāo)準(zhǔn)萝毛。
不同的語言會出現(xiàn)不同的兼容性和不同的開發(fā)项阴、測試、運維標(biāo)準(zhǔn)笆包。比如：有的軟件修改配置要改它的.conf 文件环揽，而有的則是調(diào)用管理 API 接口。
通訊：不同的軟件用不同的協(xié)議庵佣，就算是相同的網(wǎng)絡(luò)協(xié)議里也會出現(xiàn)不同的數(shù)據(jù)格式歉胶。還有，不同的團(tuán)隊因為用不同的技術(shù)巴粪，會有不同的開發(fā)和運維方式通今。這些不同的東西粥谬，會讓我們的整個分布式系統(tǒng)架構(gòu)變得異常復(fù)雜。所以辫塌，分布式系統(tǒng)架構(gòu)需要有相應(yīng)的規(guī)范漏策。…
數(shù)據(jù)通訊協(xié)議臼氨。通常來說掺喻，協(xié)議有協(xié)議頭（最基本的協(xié)議數(shù)據(jù)）和協(xié)議體（真正的業(yè)務(wù)數(shù)據(jù)）。協(xié)議頭储矩，統(tǒng)一標(biāo)準(zhǔn)定義感耙，才容易對請求進(jìn)行監(jiān)控、調(diào)度和管理持隧。
問題二：系統(tǒng)架構(gòu)中的服務(wù)依賴性問題即硼。
如果非關(guān)鍵業(yè)務(wù)被關(guān)鍵業(yè)務(wù)所依賴，會導(dǎo)致非關(guān)鍵業(yè)務(wù)變成一個關(guān)鍵業(yè)務(wù)舆蝴。
服務(wù)依賴鏈中谦絮，出現(xiàn)“木桶短板效應(yīng)”——整個 SLA 由最差的那個服務(wù)所決定。
服務(wù)治理需要定義出服務(wù)關(guān)鍵程度和關(guān)鍵業(yè)務(wù)或服務(wù)調(diào)用的主要路徑洁仗。否則無法運維或是管理整個系統(tǒng)层皱。
數(shù)據(jù)庫方面也需要做相應(yīng)的隔離：避免非關(guān)鍵業(yè)務(wù)把數(shù)據(jù)庫拖死，那么會導(dǎo)致全站不可用赠潦。系統(tǒng)間不能讀取對方的數(shù)據(jù)庫叫胖，只通過服務(wù)接口耦合。這也是微服務(wù)的要求：拆分服務(wù)和相應(yīng)數(shù)據(jù)庫她奥。
問題三：故障發(fā)生的概率更大
故障恢復(fù)時間過長/影響面過大才可怕瓮增。
系統(tǒng)里添加各種監(jiān)控指標(biāo)是在“使蠻力”。信息太多等于沒有信息哩俭，要定義出關(guān)鍵指標(biāo)绷跑。
設(shè)計時就要考慮如何減輕故障。如果無法避免凡资，也要使用自動化的方式恢復(fù)故障砸捏，減少故障影響面。
問題四：多層架構(gòu)的運維復(fù)雜度更大
基礎(chǔ)層：機(jī)器隙赁、網(wǎng)絡(luò)和存儲設(shè)備等垦藏。
平臺層：中間件層，Tomcat伞访、MySQL掂骏、Redis、Kafka 之類的軟件厚掷。
應(yīng)用層：業(yè)務(wù)軟件弟灼，比如级解，各種功能的服務(wù)。
接入層：接入用戶請求的網(wǎng)關(guān)袜爪、負(fù)載均衡或是 CDN蠕趁、DNS 這樣的東西薛闪。
沒有統(tǒng)一的視圖和管理辛馆，導(dǎo)致運維被割裂開來，造成更大的復(fù)雜度豁延。
技術(shù)團(tuán)隊分為產(chǎn)品開發(fā)昙篙、中間件開發(fā)、業(yè)務(wù)運維诱咏、系統(tǒng)運維等子團(tuán)隊苔可。整個系統(tǒng)會像 “多米諾骨牌”一樣，一個環(huán)節(jié)出現(xiàn)問題袋狞，就會倒下去一大片焚辅。因為沒有一個統(tǒng)一的運維視圖，不知道一個服務(wù)調(diào)用是如何經(jīng)過每一個服務(wù)和資源苟鸯，花大量的時間在溝通和定位問題上同蜻。
分工不是問題，問題是分工后的協(xié)作是否統(tǒng)一和規(guī)范早处。
