Martin Fowler
-
服務組件化：在微服務架構中，需要我們對服務進行組件化分解，服務是一種進程外的組件，它通過HTTP等通信協議進行協作，而不是像傳統組件那樣鑲入式的方式協同工作，每一個服務都獨立開發、部署、可以有效避免一個服務的修改引起整個系統的重新部署。
-
按業務組織團隊：在實施微服務架構時，需要采用不同的團隊分割方法。由於每一個服務都是針對特定的業務的寬棧或者全棧實現的，既要負責數據的持久化存儲，又要負責用戶接口定義等各種跨專業領域的職能。因此面對大型項目的時候，對於微服務團隊的拆分更加建議按業務線的方法進行拆分，一方面可以有效的減少服務內部修改所產生的內耗，另一方面，團隊邊界可以變得更為清晰。
-
做“產品”的態度：在微服務架構團隊中，每個小團隊都應該以做產品的方式，，對其整個生命周期負責，而不是像傳統項目開發那樣，交付給測試，運維為目標。
-
智能端點與啞管道：由於各個服務不在一個進程中，組件間的通信模式發生了改變，原本進程內的方法調用變成了RPC方式的調用，會導致微服務之間產生煩瑣的通信，使得系統表現更為糟糕，所以我們需要更粗粒度的通信協議：HTTP的RESTful API或者輕量級的消息發送協議、消息隊列（Message Queue）用於業務解耦，極度強調性能的情況下，還有可能使用二進制的消息發送協議如protobuf。
-
去中心化治理：在整個微服務架構，通過采用輕量級的契約定義接口，使得我們隊服務本身的具體技術平台不再那么敏感，這樣整個微服務架構系統中的各個組件就能針對不同的業務特點選擇不同的技術平台。
-
去中心化管理數據：在實施微服務架構時，希望每一個服務自己來管理其數據庫，這就是數據管理的去中心化，雖然數據管理的去中心化讓數據管理更加細致化，讓數據存儲和性能達到最優，但是不同的數據庫實例，數據一致性也成了微服務架構中亟待解決的問題之一，分布式事務本身實現的難度就非常大，所以在微服務架構中，我們更強調各服務之間進行”無事務“的調用，而對數據一致性，一般只強調“最終一致性”。
-
基礎設施自動化：在微服務架構中，務必從一開始就構建起“持續繼承”、”持續交付“平台來支撐整個實施過程。
-
容錯設計：在微服務架構中，快速檢測出故障源並盡可能地自動恢復服務是必須被設計考慮的，通常我們都希望在每個服務中實現監控和日志記錄的組件。比如日志報警、服務熔斷、服務降級等。