1.所有團隊的程式模組都要通過 service inte***ce 方式將其資料與功能開放出來。
2.團隊間程式模組的資訊通訊，都要通過這些介面。
3.除此之外沒有其它的通訊方式。其他形式一概不允許：不能直接鏈結別的程式（把其他團隊的程式當做動態鏈結庫來鏈結），不能直接讀取其他團隊的資料庫，不能使用共享記憶體模式，不能使用別人模組的後門，等等。唯一允許的通訊方式是呼叫 service inte***ce。
4.任何技術都可以使用。比如：http、corba、pub/sub、自定義的網路協議等。
5.所有的 service inte***ce，毫無例外，都必須從骨子裡到表面上設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便未來把介面開放給全世界的程式設計師，沒有任何例外。
6.不這樣做的人會被炒魷魚。
1.分布式服務的架構需要分布式的團隊架構。
在亞馬遜，乙個服務由乙個小團隊（two pizza team 不超過 16 個人，兩張 pizza 可以餵飽的團隊）負責，從前端負責到資料，從需求分析負責到上線運維。這是良性的分工策略——按職責分工，而不是按技能分工。
3.沒有專職的測試人員，也沒有專職的運維人員，開發人員做所有的事情。
開發人員做所有事情的好處是——吃自己的**（eat your own dog food） 最微觀的實踐。自己寫的**自己維護自己養，會讓開發人員明白，寫**容易維護**複雜。這樣，開發人員在接需求、做設計、寫**、做工具時都會考慮到軟體的長期維護性。
4.運維優先，崇尚簡化和自動化。
為了能夠運維如此複雜的系統，亞馬遜內部在運維上下了非常大的功夫。現在人們所說的 devops 這個事，亞馬遜在 10 多年前就做到了。亞馬遜最為強大的就是運維，拼命地對系統進行簡化和自動化，讓亞馬遜做到了可以輕鬆運維擁有上千萬臺虛機的 aws 雲平台。
5.內部服務和外部服務一致。
無論是從安全方面，還是介面設計方面，無論是從運維方面，還是故障處理的流程方面，亞馬遜的內部系統都和外部系統一樣對待。這樣做的好處是，內部系統的服務隨時都可以開放出來。而且，從第一天開始，服務提供方就有對外服務的能力。可以想像，以這樣的標準運作的團隊其能力會是什麼樣的。
問題一：異構系統的不標準問題
這主要表現在：
軟體和應用不標準。
通訊協議不標準。
資料格式不標準。
開發和運維的過程和方法不標準。
不同的軟體，不同的語言會出現不同的相容性和不同的開發、測試、運維標準。不同的標準會讓我們用不同的方式來開發和運維，引起架構複雜度的提公升。比如：有的軟體修改配置要改它的.conf 檔案，而有的則是呼叫管理 api 介面。
在通訊方面，不同的軟體用不同的協議，就算是相同的網路協議裡也會出現不同的資料格式。還有，不同的團隊因為用不同的技術，會有不同的開發和運維方式。這些不同的東西，會讓我們的整個分布式系統架構變得異常複雜。所以，分布式系統架構需要有相應的規範。
比如，我看到，很多服務的 api 出錯不返回 http 的錯誤狀態碼，而是返回個正常的狀態碼 200，然後在 http body 裡的 json 字串中寫著個：error，bla bla error message。這簡直就是一種***的做法。我實在不明白為什麼會有眾多這樣的設計。這讓監控怎麼做啊？現在，你應該使用 swagger 的規範了。
再比如，我看到很多公司的軟體配置管理裡就是乙個 key-value 的東西，這樣的東西靈活到可以很容易地被濫用。不規範的配置命名，不規範的值，甚至在配置中直接嵌入前端展示內容……
乙個好的配置管理，應該分成三層：底層和作業系統相關，中間層和中介軟體相關，最上面和業務應用相關。於是底層和中間層是不能讓使用者靈活修改的，而是只讓使用者選擇。比如：作業系統的相關配置應該形成模板來讓人選擇，而不是讓人亂配置的。只有配置系統形成了規範，我們才 hold 得住眾多的系統。
再比如：資料通訊協議。通常來說，作為乙個協議，一定要有協議頭和協議體。協議頭定義了最基本的協議資料，而協議體才是真正的業務資料。對於協議頭，我們需要非常規範地讓每乙個使用這個協議的團隊都使用一套標準的方式來定義，這樣我們才容易對請求進行監控、排程和管理。
這樣的規範還有很多，我在這就不一一枚舉了。
問題二：系統架構中的服務依賴性問題
對於傳統的單體應用，一台機器掛了，整個軟體就掛掉了。但是你千萬不要以為在分布式的架構下不會發生這樣的事。分布式架構下，服務是會有依賴的，於是乙個服務依賴鏈上，某個服務掛掉了，會導致出現「多公尺諾骨牌」效應，會倒一片。
所以，在分布式系統中，服務的依賴也會帶來一些問題。
如果非關鍵業務被關鍵業務所依賴，會導致非關鍵業務變成乙個關鍵業務。
服務依賴鏈中，出現「木桶短板效應」——整個 sla 由最差的那個服務所決定。
這是服務治理的內容了。服務治理不但需要我們定義出服務的關鍵程度，還需要我們定義或是描述出關鍵業務或服務呼叫的主要路徑。沒有這個事情，我們將無法運維或是管理整個系統。
這裡需要注意的是，很多分布式架構在應用層上做到了業務隔離，然而，在資料庫結點上並沒有。如果乙個非關鍵業務把資料庫拖死，那麼會導致全站不可用。所以，資料庫方面也需要做相應的隔離。也就是說，最好乙個業務線用一套自己的資料庫。這就是亞馬遜伺服器的實踐——系統間不能讀取對方的資料庫，只通過服務介面耦合。這也是微服務的要求。我們不但要拆分服務，還要為每個服務拆分相應的資料庫。
問題三：故障發生的概率更大
在分布式系統中，因為使用的機器和服務會非常多，所以，故障發生的頻率會比傳統的單體應用更大。只不過，單體應用的故障影響面很大，而分布式系統中，雖然故障的影響面可以被隔離，但是因為機器和服務多，出故障的頻率也會多。另一方面，因為管理複雜，而且沒人知道整個架構中有什麼，所以非常容易犯錯誤。
你會發現，對分布式系統架構的運維，簡直就是一場噩夢。我們會慢慢地明白下面這些道理。
出現故障不可怕，故障恢復時間過長才可怕。
出現故障不可怕，故障影響面過大才可怕。
運維團隊在分布式系統下會非常忙，忙到每時每刻都要處理大大小小的故障。我看到，很多大公司，都在自己的系統裡拼命地新增各種監控指標，有的能夠新增出幾萬個監控指標。我覺得這完全是在「使蠻力」。一方面，資訊太多等於沒有資訊，另一方面，sla 要求我們定義出「key metrics」，也就是所謂的關鍵指標。然而，他們卻沒有。這其實是一種思維上的懶惰。
但是，上述的都是在「救火階段」而不是「防火階段」。所謂「防火勝於救火」，我們還要考慮如果防火，這需要我們在設計或運維系統時都要為這些故障考慮，即所謂 design for failure。在設計時就要考慮如何減輕故障。如果無法避免，也要使用自動化的方式恢復故障，減少故障影響面。
因為當機器和服務數量越來越多時，你會發現，人類的缺陷就成為了瓶頸。這個缺陷就是人類無法對複雜的事情做到事無鉅細的管理，只有機器自動化才能幫助人類。 也就是，人管**，**管機器，人不管機器！
問題四：多層架構的運維複雜度更大
通常來說，我們可以把系統分成四層：基礎層、平台層、應用層和接入層。
基礎層就是我們的機器、網路和儲存裝置等。
平台層就是我們的中介軟體層，tomcat、mysql、redis、kafka 之類的軟體。
應用層就是我們的業務軟體，比如，各種功能的服務。
接入層就是接入使用者請求的閘道器、負載均衡或是 cdn、dns 這樣的東西。
對於這四層，我們需要知道：
任何一層的問題都會導致整體的問題；
沒有統一的檢視和管理，導致運維被割裂開來，造成更大的複雜度。
很多公司都是按技能分工是，把技術團隊分為產品開發、中介軟體開發、業務運維、系統運維等子團隊。這樣的分工導致各管一攤，很多事情完全連不在一起。整個系統會像 「多公尺諾骨牌」一樣，乙個環節出現問題，就會倒下去一大片。因為沒有乙個統一的運維檢視，不知道乙個服務呼叫是如何經過每乙個服務和資源，也就導致我們在出現故障時要花大量的時間在溝通和定位問題上。
之前我在某雲平台的一次經歷就是這樣的。從接入層到負載均衡，再到服務層，再到作業系統底層，設定的 keepalive 的引數完全不一致，導致使用者發現，軟體執行的行為和文件中定義的完全不一樣。工程師查錯的過程簡直就是一場惡夢，以為找到了乙個，結果還有乙個，來來回回花了大量的時間才把所有 keepalive 的引數設定成一致的，浪費了太多的時間。
分布式系統的構建原則
什麼是構建乙個可維護和可擴充套件的系統的意義？在早期，乙個系統的形態，只是滿足使用者和伺服器資源之間的通道，唯一要擴充套件和維護的是系統後面的資源，保證資源的可用和夠用，而系統本身的壓力並不大。如今，開源元件已經成為構建一些企業系統的基石，伴隨著行業的發展，最佳實踐和圍繞這些系統架構的指導原則也逐漸...
分布式系統
分布式系統和計算機網路系統的共同點是 多數分布式系統是建立在計算機網路之上的，所以分布式系統與計算機網路在物理結構上是基本相同的。他們的區別在於 分布式作業系統的設計思想和網路作業系統是不同的，這決定了他們在結構 工作方式和功能上也不同。網路作業系統要求網路使用者在使用網路資源時首先必須了解網路資源...
分布式系統
分布式，一來就直接看書，除非你有比較深厚的技術功底，要不還是很晦澀難懂的。先想想為什麼會有分布式，分布式怎麼來的。傳統的電信 銀行業，當業務量大了之後，普通伺服器cpu io 網路到了100 請求太慢怎麼辦？最直接的做法，公升級硬體，反正也不缺錢，ibm小型機，大型機，採購了堆硬體。但是網際網路不能...