待做的：
學習框架：nameko、double、spring cloud、書
微服務的定義：
一些協同工作的小而自治的服務
微服務的核心思想：
1.自治：
2）作為服務方，需要避免方暴露過多給消費而產生耦合，從而降低服務的自治性。要封裝好，服務方內部實現修改，不該影響到消費方。
2.細粒度：
1）解耦：避免系統臃腫、難以維護
2）內聚性：相同的東西放在一起
3.隔離性：
1）各服務直接均通過網路呼叫進行通訊（而不是**呼叫），避免了緊耦合
2）各服務之間通過api呼叫，api解耦性必須要好，以保證技術的選擇不被限制
3）乙個**法則：你是否能夠修改乙個服務並對其進行部署，而不影響其他任何服務？（獨立部署）
微服務的優點：
1.細粒度-》擴充套件性好-》可以快速響應變化、快速交付-》可以嘗試更多的新技術
2.增加了團隊的自治力
4.彈性（穩定性、可用性）：第11章，詳解
5.擴充套件：可以很容易把獨立的服務，分割出去獨立部署。通過構架來節省成本
6.簡化部署：各服務可以獨立部署，單個服務出錯，也不會影響整體執行。風險可控，成本不高。
7.與組織結構匹配，可以組建小團隊自治。第10章，詳解
8.可組合性，第5章，詳解
9.對可代替性的優化。可以有信心，也比較容易重寫系統。（方便重構）
1.領域驅動設計
2.持續交付
3.按需虛擬化
利用雲技術，按需建立機器並調整大小，方便擴充套件
4.基礎設施自動化
5.小型自治團隊
6.大型集群系統
分布式系統
7.共享庫，要慎用，可能會成為耦合點（第4章再介紹）
關於團隊：
1.拆成小團隊，對自己的服務的全生命週期負責
2.團隊自治
3.研究新技術，來實現自己的服務
構建微服務：
設施自動化
測試：自動化測試，服務介面跑測試指令碼
持續交付：
自動部署（日常、線上），自動測試
關於業務層：
1.使用「領域驅動設計」，先把業務場景確定，然後進行領域設計抽取模型，然後按照模型設計系統
1）.時間維度：短時間內可以完全重寫
2）.複雜度維度：覺得夠小（可控），就可以
3）.團隊維度：保證在乙個小團隊可以維護的範圍內（康威定律，團隊的組成，決定系統的架構）
服務管理：
1.介面管理：介面記wiwi、利用工具（？）
注意：2.共享庫（lib,前端框架）在微服務框架裡，容易成為乙個耦合點。不一定是個好注意
待研究：
介面註冊，介面發現，統一管理
待學習：
1.持續交付理論
2.alistair cockburn 的 六邊形 架構 理論（ http:// alistair. cockburn. us/ hexagonal+ architecture） 把 我們 從 分層 架構 中 拯救 出來， 從而 能夠 更好 地 體現 業務 邏輯。
3.尋找一款好的建模工具，用熟他
4.構架原則（根據自己環境制定）
思考&問題：
1.每個服務埠的配置，介面url是否能夠統一管理？利用自動化部署工具，解決配置管理問題（日常和線上環境配置獨立維護）
2.解決服務介面管理的問題，就可以大大降低服務管理的複雜性？尋找乙個介面自動生成的工具，這解決了兩個研發中常見的問題：（執行時框架的介面採用了 graphql ，並且告別了手動寫介面的形式，全部利用檢視勾選生成）
杜絕了手工約定介面時可能出現的拼寫等錯誤。
能自動統計到所有對某一介面進行消費的頁面，一旦介面進行調整，可以自動通知到下游，甚至能自動生成適配**，不影響下游。
關於資料庫：
1.資料庫最好使用同乙個技術棧的。除非有特殊的需求。方便管理和部署
關於技術異構與標準化：
關於構架師：
1.保證團隊有共同的技術願景，幫助程式設計師向客戶交付他們想要要的系統
2.構架師不像建築師，而像城市規劃師。
3.構架師，不僅要考慮系統、使用者。還要考慮開發者，運維人員的情況。
5.構架師必須要要有時間和開發者一起工作，關注他們的開發效果和體驗
6.構架師很多時候是在做取捨。而這些系統架構上的取捨，要根據以下幾個原則來制定：符合公司戰略目標、根據制定的原則（規範）、根據約定的實踐（用任種技術）。通過示例**和工具來實現
技術債務：
系統避免不了會產生一些技術債務，可能是臨時專案，可能是系統目標發生改版。構架師應該要能察覺到它，並引到開發人員去消除技術債務。
**治理：
1.範例。來自於真實案例，減少出錯的可能。你寫的漂亮**
2.服務**模版（**庫如springboot、tornado）。不應該是構架團隊出，應該是業務團隊商量出，或者收集意見專人維護（如webx）。內部開源也是個很好的辦法。注意，它不應該是強制開發者使用的，否則會影響團隊士氣。**模板可能會帶來問題導致耦合（第4章討論）
格言：1.「你總提及的那個詞， 它的含義與你想表達的意思並不一樣。」
2.「規則對於智者來說是指導，對於愚蠢者來說是遵從。」
3.治理通過評估干係人的需求、當前情況 及下一步的可能性來確保企業目標的達成，通過排優先順序和做決策來設定方向。對於已經達成一致的方向和目標進行監督。
微服務設計讀書筆記
微服務架構的優勢 1 較小的粒度 2 在解決問題的方法上能夠給予更多的選擇 相比動態庫更新，相關的依賴都要更新是乙個很大的優點。3 微服務定義為可以在2周之內改寫乙個服務，這種粒度的頻繁更新引入風險的可能性較單一系統有較大的改善 微服務設計 沒有明確邊界的時候，可以設定的粒度比較大，當服務內部的邊界...
微服務設計 讀書筆記 一
1.1 什麼是微服務 微服務就是一些協同工作的小而自治的服務。1.1.1 專注於做好一件事 隨著新功能的增加，庫會越變越大。時間久了 庫會非常龐大，以至於想要知道該在什麼地方做修改都很困難。在乙個單塊系統內，通常會建立一些抽象層或者模組來保證 的內聚性，從而避免上述問題。內聚性是將相關 放在一起，在...
微服務設計 讀書筆記（一）
微服務就是一些協同工作的小而自治的服務。微服務將單一職責原則應用到了獨立的服務上，根據業務範圍來確定服務的邊界，乙個服務專注於乙個業務範圍，避免 庫過大。一般來講，乙個微服務應該在兩周之內可以完全重構，但不能盲目追求小，乙個微服務的業務範圍越小，獨立性帶來的好處就越多，整個系統所需管理的服務就越多。...