《微服務設計》讀書筆記

待作的：

學習框架：nameko、double、spring cloud、書

 

微服務的定義：

一些協同工做的小而自治的服務

 

微服務的核心思想：

1.自治：

    1）每一個微服務（APP）能夠獨立部署到PAAS（platform as a service）上

    2）做爲服務方，須要避免方暴露過多給消費而產生耦合，從而下降服務的自治性。要封裝好，服務方內部實現修改，不應影響到消費方。

2.細粒度：

    1）解耦：避免系統臃腫、難以維護

    2）內聚性：相同的東西放在一塊兒

3.隔離性：

    1）各服務直接均經過網絡調用進行通訊（而不是代碼調用），避免了緊耦合

    2）各服務之間經過API調用，API解耦性必需要好，以保證技術的選擇不被限制

    3）一個黃金法則：你是否可以修改一個服務並對其進行部署，而不影響其餘任何服務？（獨立部署）

 

微服務的優勢：

1.細粒度-》擴展性好-》能夠快速響應變化、快速交付-》能夠嘗試更多的新技術

2.增長了團隊的自治力

3.技術異構性。能夠根據不一樣的業務場景，選擇不一樣的技術，來構架服務。好比某個APP對性能有特別高的要求。或者某些APP對底層數據庫有特別的要求（圖數據庫、文檔數據庫、關係型數據庫）。這點須要APP足夠小，能夠快速重寫，從而下降風險。還有就是框架要支持多語言開發業務模塊。

4.彈性（穩定性、可用性）：第11章，詳解

5.擴展：能夠很容易把獨立的服務，分割出去獨立部署。經過構架來節省成本

6.簡化部署：各服務能夠獨立部署，單個服務出錯，也不會影響總體運行。風險可控，成本不高。

7.與組織結構匹配，能夠組建小團隊自治。第10章，詳解

8.可組合性，第5章，詳解

9.對可代替性的優化。能夠有信心，也比較容易重寫系統。（方便重構）

 

微服務的相關技術：

1.領域驅動設計

2.持續交付

3.按需虛擬化

    利用雲技術，按需建立機器並調整大小，方便擴展

4.基礎設施自動化

5.小型自治團隊

6.大型集羣系統

    分佈式系統

7.共享庫，要慎用，可能會成爲耦合點（第4章再介紹）

 

關於團隊：

1.拆成小團隊，對本身的服務的全生命週期負責

2.團隊自治

3.研究新技術，來實現本身的服務

 

構建微服務：

    設施自動化

 

    測試：

    自動化測試，服務接口跑測試腳本

 

    持續交付：

    自動部署（平常、線上），自動測試

 

    

關於業務層：

    1.使用「領域驅動設計」，先把業務場景肯定，而後進行領域設計抽取模型，而後按照模型設計系統

    2.業務邊界來肯定業務層各個APP的服務邊界。因此對業務邊界的劃分很重要。能夠根據領域驅動設計來劃分

    3.關於APP劃分的幾個思路：

        1）.時間維度：短期內能夠徹底重寫

        2）.複雜度維度：以爲夠小（可控），就能夠

        3）.團隊維度：保證在一個小團隊能夠維護的範圍內（康威定律，團隊的組成，決定系統的架構）

    4.APP越小，微服務帶來的優缺點就越明顯

    5.微服務，小APP的缺點：管理複雜

 

服務管理：

    1.接口管理：接口記wiwi、利用工具（？）

    

注意：

1.微服務的技術，比微服務的理念要變化快不少。因此要更多的關注設計思想，而不是某項技術

2.共享庫（lib,前端框架）在微服務框架裏，容易成爲一個耦合點。不必定是個好注意

 

待研究：

接口註冊，接口發現，統一管理

 

待學習：

1.持續交付理論

2.Alistair Cockburn 的 六邊形 架構 理論（ http:// alistair. cockburn. us/ Hexagonal+ architecture） 把 咱們 從 分層 架構 中 拯救 出來， 從而 可以 更好 地 體現 業務 邏輯。

3.尋找一款好的建模工具，用熟他

4.構架原則（根據本身環境制定） https://www.12factor.net/

 

思考&問題：

1.每一個服務端口的配置，接口URL是否可以統一管理？利用自動化部署工具，解決配置管理問題（平常和線上環境配置獨立維護）

 

2.解決服務接口管理的問題，就能夠大大下降服務管理的複雜性？尋找一個接口自動生成的工具，這解決了兩個研發中常見的問題：（運行時框架的接口採用了 GraphQL ，而且告別了手動寫接口的形式，所有利用視圖勾選生成）

    杜絕了手工約定接口時可能出現的拼寫等錯誤。

    能自動統計到全部對某一接口進行消費的頁面，一旦接口進行調整，能夠自動通知到下游，甚至能自動生成適配代碼，不影響下游。

 

關於數據庫：

    1.數據庫最好使用同一個技術棧的。除非有特殊的需求。方便管理和部署

 

關於技術異構與標準化：

    1.APP內部能夠實行技術異構，可是外部框架最好使用統一標準化的技術實現

 

關於構架師：

    1.保證團隊有共同的技術願景，幫助程序員向客戶交付他們想要要的系統

    2.構架師不像建築師，而像城市規劃師。

    3.構架師，不只要考慮系統、用戶。還要考慮開發者，運維人員的狀況。

    4.構架師，應該更多的關注服務的邊界和區域之間的事。至於服務內部，應該給業務留出足夠多的自治空間。（固然，最好也能提供一條框架模版）

    5.構架師必需要要有時間和開發者一塊兒工做，關注他們的開發效果和體驗

    6.構架師不少時候是在作取捨。而這些系統架構上的取捨，要根據如下幾個原則來制定：符合公司戰略目標、根據制定的原則（規範）、根據約定的實踐（用任種技術）。經過示例代碼和工具來實現

 

技術債務：

    系統避免不了會產生一些技術債務，多是臨時項目，多是系統目標發生改版。構架師應該要能察覺到它，並引到開發人員去消除技術債務。

 

代碼治理：

    1.範例。來自於真實案例，減小出錯的可能。你寫的漂亮代碼

    2.服務代碼模版（代碼庫如springboot、tornado）。不該該是構架團隊出，應該是業務團隊商量出，或者收集意見專人維護（如webx）。內部開源也是個很好的辦法。注意，它不該該是強制開發者使用的，不然會影響團隊士氣。代碼模板可能會帶來問題致使耦合（第4章討論）

 

格言：

1.「你總說起的那個詞， 它的含義與你想表達的意思並不同。」

2.「規則對於智者來講是指導，對於愚蠢者來講是聽從。」

3.治理經過評估干係人的需求、當前狀況 及下一步的可能性來確保企業目標的達成，經過排優先級和作決策來設定方向。對於已經達成一致的方向和目標進行監督。