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