前言

文章就是那種隔一段時間拿出來看看，總能獲得新收穫的文章。James Lewes和Martin Flower這篇就應該屬於這一類，第一次讀這篇文章應該是在2015年吧，讀完了感覺雲裡霧裡的，感覺懂了又感覺有點蒙，尤其是關於Product not Project那部分以及圍繞業務組織團隊。經過三年再看的時候才感覺到確實如此，所以本週就把重讀一遍的收穫在這裡寫一下，也算是一種特別的體驗

核心內容

1.元件化的服務
服務這個概念本身就沒有明確的定義，這裡定義了元件化的方式，並非是函式或模組或庫而是獨立的服務。
在文章中首先探討了微服務與意外模組化設計的本質卻別是將服務作為元件來對待的，這樣的元件粒度是之前比較少見的。

2.圍繞業務組織團隊
與傳統的前端，後端，資料庫的劃分不同，微服務主張以業務為劃分的依據而非技術
When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval.

這一點得益於技術的發展使得技術本身不再是開發中的最大瓶頸，而以往根據技術來劃分團隊帶來的弊端漸漸超過了其技術優勢，這一點是與傳統開發模式最大的不同一點。
3.以產品而非專案
where the aim is to deliver some piece of software which is then considered to be completed.
主要是因為對於專案團隊和公司沒有優化和改進的動力，這樣微服務帶來的動態設計以及對於擴充套件的良好支撐則完全發揮不出來。因此在微服務技術初期，微服務是不適合用於專案開發的。
但現在情景已經不同了，基於Spring生態體系構建的SpringCloud等微服務一站式框架的成熟為微服務架構走向專案開發開啟了道路。
4.端點更厲害，簡化通道Smart endpoints and dumb pipes
這一點主要是與沉重的ESB相互對比的特性。
5.去中心化的管理
這裡的管理主要是組織機構的管理，這一點有反應了康威定律。
6.去中心化的資料管理
各個微服務各自管理資料以及業務模型，一切圍繞業務
7.基礎設施的自動化
用以解決服務增多造成的測試，聯調，部署的複雜性問題，這一大塊在14年確實是個巨大的痛點，這也是限制微服務專案應用的關鍵點，但現在各種框架的出現大大減少了這方面的 複雜度，當然對比單體應用要複雜。
8.主動應對故障
這是分散式系統所必然面對的問題，這個不是針對微服務而出現的，實際上故障是分散式系統中最為古老的棘手問題。
9.動態設計
業務是動態的，設計也並非是靜止的，動態的設計和擴充套件性是微服務最大的優勢之一。

總結

關鍵還是看人，
A poor team will always create a poor system - it’s very hard to tell if microservices reduce the mess in this case or make it worse.