1. 監控
能夠清晰的描繪出跨服務系統的健康狀態非常重要，這必須在系統級別而非單個服務級別進行考慮。往往在需要診斷一個跨服務的問題或者想要了解更大的趨勢時，你才需要知道每個服務的健康狀態。
簡單起見，作者建議確保所有服務都是用相同的方式報告健康狀態及其它監控相關的指標數據。
2. 統一服務接口技術
選擇少數幾種（甚至一種）明確的接口技術有助於新消費者的集成。
3. 架構安全性
一個運行異常的服務可能毀了整個系統，我們需要保證每個服務能夠應對上游服務的錯誤響應。
這通常需要引入一個斷路器，而斷路器根據一定的規則來運行，需要我們制定一些固定的規則；比如讓斷路器根據HTTP返回碼來工作，那上游服務就必須按照HTTP狀態碼的語義來返回狀態碼，不能混用4xx和5xx。一般我們需要對以下幾種請求情況做不同處理：
- 正常響應，並且正確處理。
- 正常響應，但被服務識別出是錯誤請求。
- 響應超時，目標服務宕機。
4. 代碼治理
聚在一起，就如何做事情達成共識是一個好主意。但是，花時間保證人們按照這個共識來做事情就沒那麼有趣了，因爲在各個服務中使用標準做法會成爲開發人員的負擔。所以至少應該做到以下幾點：提供範例和服務代碼模板。
提供範例是很用的，無論你是通過可運行的代碼還是文檔形式提供。如果你有一些很好的實踐希望別人採納，那麼給出一系列的代碼範例會很有幫助，這可以幫助他們快速模仿，而且不會錯的太離譜。
提供服務代碼模板。當開發人員想要創建一個新服務時，所有實現基本功能的代碼都應該是現成的，開發人員能夠複製模板進而快速編寫業務代碼。
針對自己的開發實踐裁剪出一個服務代碼模板，不但可以提高開發速度，還可以保證服務質量，團隊需要保持模板的更新。
5. 團隊也應該擁有自治性
作者說到：每個組織都是不同的，他合作過的某些公司有高度自治的團隊，能夠得到公司的充分信任，對於這種情況，原則都是很輕量級的。但部分公司的組織結構化較強，開發人員擁有較小的自由度，這個時候需要【例外管理】來保證規則的合理性。
我理解的作者這裏的態度是：架構師或技術主管不應該對開發人員有過多的限制，因爲這也會限制現有架構/原則的合理性。
6. 集中治理和領導
微服務架構的領導者（架構師或技術主管）的一部分職責是治理。什麼是治理：
治理通過評估干係人的需求、當前情況及下一步的可能性來確保企業目標的達成，通過排優先級和做決策來設定方向。
對已經達成一致的方向和目標進行監督。
領導者的一些職責：
- 確保有一個技術願景，而治理就是要確保我們構建的系統符合這個願景，在需要的時候對願景進行演化。
- 確保有一個可以指導開發的原則，且以這些指導原則衍生出來的實踐不會給開發人員帶來痛苦。
- 需要不斷的瞭解新技術，指導什麼時候做怎樣的取捨（也就是（原則/願景的）演化）。
- 讓開發同事也理解這些決策和取捨，並執行下去。
- 需要和團隊一起工作，甚至是編碼，從而瞭解到所做的決策對團隊造成了怎樣的影響。
一般來說，治理是一個小組活動，它可以是與一個小團隊進行非正式聊天，也可以是在比較大的範圍內，與一個有正式成員的小組進行正式例會，在這些會議上，可以討論前面提到的原則，有必要的話也可以進行修改。當然，會議應該由技術專家領導，並且要有一線開發人員的參與。整個小組應該持續負責跟蹤和管理技術風險。
有時候領導者可能不認同小組做出的決定，這時候應該怎麼辦？作者提到，大多數時候他都是認同小組的決定，因爲一個小組通常比單個人更加聰明，而且你給一個小組權力去做決定，但最後忽略了這個決定，那小組就毫無意義了。
必要的時候，領導者需要對小組施加影響，領導需要指定什麼時候可以做什麼，不能做什麼，這是很關鍵的。
7. 建設團隊
引用作者原話：
對於一個系統技術願景的主要負責人來說，執行願景不僅僅等同於做技術決定，和你一起工作的那些人自然會做這些決定。
對於技術領導人來說，更重要的事情是幫助你的隊友成長，幫助他們理解這個願景，並保證他們可以積極地參與到願景的實現和調整中來。
在單應用系統中，開發人員爲某些事情負責的機會十分有限，而在微服務架構中存在多個自治的代碼庫，每個代碼庫都有着自己獨立的聲明週期，這就給更多人提供了對單個服務負責的機會，而當這些人在單個服務上面得到足夠鍛鍊之後，就可以給他們更多的責任，從而幫助他們逐步達成自己的職業目標，同時通過分擔職責也可以防止某一個人的負擔過重。
我堅定地相信，偉大的軟件來自於偉大的人，所以如果你只擔心技術問題，那麼恐怕你看到的問題遠遠不及一半。