馬丁福勒 關於微服務特色的描述

微服務的原始動機在於解決monolithic 系統的擴展性爲題，由於monolith的系統有兩個問題：

1. 對整個系統的一個小地方的改動，都要對整個系統從新build 和 deploy
2. 作scale的時候，擴充的是整個系統，而不是整個系統中最須要擴容的那個點。

微服務能夠很好的解決上面的問題，並且不通的微服務還能夠使用不一樣的編程語言來實現。

1. 經過服務化的方式來實現組件化。這個是相比傳統的 經過library的方式來作組件化來講的。
2. 根據業務上提供的不通能力來組織這些micro service
3. 作產品而不是作項目。核心區別在於作項目的方式，作完了項目就交付給運維去運維，然而作產品意味着，開發要在產品的整個生命週期中承擔一些運維職責。
4. 比SOA中ESB相比更智能更輕量的服務相互調用。所謂smart endpoints and dumb pipes，這些endpoint都是解耦的，完成一個業務調用串起這些micro service就像是linux系統中經過管道串起一系列命令。
5. 自治的管理。各思其政 的選擇技術實現，不一樣的service能夠根據各自的須要選擇不一樣的技術棧來實現其業務邏輯。
6. 去中心化的數據管理 意味着不一樣的微服務使用的不是同一個數據庫，這樣作的目的只要是爲了實現各業務之間的鬆耦合，提現清晰的業務邊界，對數據的更新只能經過其所屬業務的service實現，而不用直接訪問數據庫。這樣作的一個好處是能夠容許各個業務使用本身喜歡的存儲方式來完成存儲，能夠是用各類nosql的方案，單同時也使得數據一致性不能經過傳統的事務方式來實現。在微服務架構中的折中方案一般是最終一致性。容忍暫時的不一致狀況出現，經過補償機制來達成最終一致性。

7. 自動化架構，各流程的自動化

8. 充分考慮故障的設計。相比monolith架構，微服務架構用service的方式替換library來實現了組件化。引入了更多的service後，與此同時也引入了更多可能發生的故障。這就要求微服務架構要創建充分的監控和響應機制來應對可能發生的故障。監控機制要包括系統級的和業務級的，同時還要配合logging來快速定位問題，從而加以解決。
9. 支持持續演進的設計。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.