微服務的原始動機在於解決monolithic 系統的擴展性為題，因為monolith的系統有兩個問題：
- 對整個系統的一個小地方的改動，都要對整個系統重新build 和 deploy
- 做scale的時候，擴充的是整個系統，而不是整個系統中最需要擴容的那個點。
微服務可以很好的解決上面的問題，而且不通的微服務還可以使用不同的編程語言來實現。
- 通過服務化的方式來實現組件化。這個是相比傳統的 通過library的方式來做組件化來說的。
- 根據業務上提供的不通能力來組織這些micro service
- 做產品而不是做項目。核心區別在於做項目的方式，做完了項目就交付給運維去運維，然而做產品意味着，開發要在產品的整個生命周期中承擔一些運維職責。
- 比SOA中ESB相比更智能更輕量的服務相互調用。所謂smart endpoints and dumb pipes，這些endpoint都是解耦的，完成一個業務調用串起這些micro service就像是linux系統中通過管道串起一系列命令。
- 自治的管理。各思其政 的選擇技術實現，不同的service可以根據各自的需要選擇不同的技術棧來實現其業務邏輯。
- 去中心化的數據管理 意味着不同的微服務使用的不是同一個數據庫，這樣做的目的只要是為了實現各業務之間的松耦合，提現清晰的業務邊界，對數據的更新只能通過其所屬業務的service實現，而不用直接訪問數據庫。這樣做的一個好處是可以允許各個業務使用自己喜歡的存儲方式來完成存儲，可以是用各種nosql的方案，單同時也使得數據一致性不能通過傳統的事務方式來實現。在微服務架構中的折中方案通常是最終一致性。容忍暫時的不一致情況出現，通過補償機制來達成最終一致性。
自動化架構，各流程的自動化
- 充分考慮故障的設計。相比monolith架構，微服務架構用service的方式替換library來實現了組件化。引入了更多的service后，與此同時也引入了更多可能發生的故障。這就要求微服務架構要建立充分的監控和響應機制來應對可能發生的故障。監控機制要包括系統級的和業務級的，同時還要配合logging來快速定位問題，從而加以解決。
- 支持持續演進的設計。The key property of a component is the notion of independent replacement and upgradeability - which implies we look for points where we can imagine rewriting a component without affecting its collaborators.