《微服務設計》讀書筆記（關於微服務的一點想法）

一、在學習軟件構造、設計相關知識時，你們應該有學習到內聚性的概念：即把因相同緣由而變化的東西聚合到一塊兒，而把因不一樣緣由而變化的東西分離開來。而

微服務將這個理念應用在獨立的服務上。根據業務的邊界來肯定服務的邊界，這樣就很容 易肯定某個功能代碼應該放在哪裏。

我我的以爲，微服務就是將原來的單體應用安裝功能進行切分，而後各個服務之間經過通訊(跨進程、跨機器)來共同完成原來的單體應用所提供的功能。
微服務對比與原來的單體應用，有它的優點，如服務的自治性加強、但同時也會帶來一些其餘問題，如性能、複雜度等問題。

二、想要使用微服務，首先是要清楚哪些業務或者功能應該成爲單獨的服務。《微服務設計》一書中給了一些建議：

當你在思考組織內的限界上下文時，不該該從共享數據的角度來考慮，而應該從這些上下 文可以提供的功能來考慮。
這個上下文是作什麼用的。
組織結構和軟件架構會互相影響。

固然，書中列出的建議不止這些，我也想談一談我本身的一些想法。

• 我以爲首先要從業務出發(單獨的基礎服務，例如分佈式事務、數據庫同步服務例外)，這一塊業務咱們須要實現怎樣的功能，它在系統中處於什麼樣的位置，它須要與哪些服務進行交互(提供接口和消費接口)。知道了業務功能在整個系統的位置，有助於咱們進行決策。
• 其次，考慮業務極有可能的變化。業務功能可能由於產品進度等其它客觀因素致使其部分需求或功能在本次迭代中沒有提出，但能夠預見的是這些功能在很大程度上會在後面的迭代中補充，這些功能可能會對當前業務有影響，將這些狀況考慮進去在必定程度上會使得服務設計更加合理。在服務拆分、功能分配的時候可能會遇到這些狀況，但須要避免過分設計。
• 最後，也須要根據本身團隊的特色來設計微服務，例如組織架構會影響軟件架構、以及當團隊技術能力沒法保障多服務協做的正確性，能夠減小服務的拆分，將一些功能合併在一個服務內。

---

若有不正確的地方，歡迎指正交流。