這本書是2023年的，有些舊，畢竟springcloud更新速度還是挺快的，不過基礎的東西變化不太大。
讀後感：這本書語言風趣，用來入門還是可以的。這本書的側重點不在於技術，而是在於工作經驗，難得的好書。
這本書一共11章，216頁，算是很精簡了，介紹肯定不全面，也不會太深入，但是對於想快速了解springcloud的人，比如我，就很適合。
第一部分 微服務解惑篇
第一章、微服務架構
第二章、為何選擇微服務
第三章、拆分
第四章、如何使用微服務
第五章、微服務的朋友圈
第二部分 技術實現篇
第六章 spring boot
第七章 spring cloud
第八章 其他相關技術和工具
第九章 測試相關
第三部分 專案實戰篇
第十章 三個典型系統案例
第11章 開發管理『
第一章：微服務架構
微服務的特點：元件化（面向單一的服務、業務功能集中、小組件五臟俱全，對內高內聚，對外低耦合）、獨立自治（團度獨立、技術選型靈活、資料庫分離、獨立部署、容錯）、靈活易擴充套件、流程化（拆分成流水線）
缺點：1、各個開發團隊之間，溝通困難
2、時效性不好
3、一致性不好
4、開發重複的功能
5、架構和維護更複雜，需要投入更多精力
難點：1、落地：包括paas、docker等環境準備，這個直接用阿里雲即可，可忽略
2、規劃：梳理業務，進行微服務劃分，這部分比較重要，但是也不算艱難，有個熟悉業務的人就好
3、開發、測試、運維，包括如下：
介面規範、契約一致性、服務編排、容錯、運營管理
第二章、如何選擇微服務
第三章、如何拆分
先了解拆分等原則、粒度和邊界問題，然後分析業務，自然而然就知道**該拆，拆成什麼樣。
根據1：資料模型和業務模型
根據2：金字塔結構圖
關鍵指標：
1、拆分公共服務
2、拆分重點業務
3、對系統影響大大業務功能
粒度不是越細越好，乙個微服務是同一種業務能力，是一系列功能的組合，而不是小到乙個功能。
已解決實際問題為出發點避免為拆而拆，拆的時候要考慮拆的意義，以及拆完之後維護的難度。
邊界一定要清晰，分工一定要明確：乙個微服務只負責自己的一塊業務
如果不清楚，那麼步子小一點，拆分的少一點，慢慢拆。
第四章、如何使用微服務
如何規劃：全域性性，針對性，良性發展（技術架構促進業務的發展），格局大
第五章、微服務的朋友圈
1、容器解決了微服務的部署問題
2、devops，我一直在考慮乙個開發到底需不需要學習運維領域的k8s，原來這種人還是需要的
3、全棧式開發
第六章、spring boot
第七章、spring cloud（這一章是重點）
註冊中心eureka：
閘道器zuul：提供乙個統一的服務出口，同時負責鑑權、認證、安全、跳轉等作用
正向****的是客戶端，反向****的是服務端；
正向**，服務端不知道客戶端是誰
反向**，客戶端不知道服務端是誰
如何區分？就看這個**是客戶的（比如vpn）還是服務商的（比如nginx）。
客戶端負載均衡 ribbon：主要功能是提供客戶端的軟體負載均衡演算法，將各服務連線起來，有連線超時、重試等功能
斷路器hystrix：失敗則呼叫fallback介面
分布式配置中心 spring cloud config：
本地儲存配置的方式通過設定屬性spring.profiles.active=native 來實現。
資源檔案的命名按照如下規範進行。
label 是可選的，如trunk 、branch 等。
服務之間呼叫 feign：
feign 內部整合了ribbon ，所以它自帶負載均衡功能。
feignclient 裡面己經包含了hystrix ， 所以不
需要增加hystrix 的依賴，也不需要開啟＠enablecircuitbreaker。
服務追蹤 sleuth：乙個請求是乙個traceid，每經過乙個服務是乙個spanid
日誌聚合zipkin:需要配合sleuth使用
第八章、其他相關技術和工具
liquibase 是乙個用於跟蹤、管理和應用資料庫變化的開源的資料庫重構工
具。它將所有資料庫的變化（包括結構和資料）都儲存在xml 、json 等格式的
檔案中，便於版本控制。
許可權 spring security：
微服務架構的通訊方式：kafka，rabbitmq
服務編排：這個還是用k8s吧。
第九章、單元測試
junit
mock：框架mockito
mock 與lnjectmocks 的區別：
**質量管理工具：sonar
第三部分、專案實戰篇
第十章、三個典型系統案例
1、梳理業務，畫金字塔圖和業務泳道圖
2、拆取公共服務（包括基礎服務、規則服務、驗證服務、計算服務等）
3、拆分業務主體，如果業務影響大，可以採用分批逃跑法
4、其他：收取前端和資料庫的判斷邏輯，更新外掛程式（比如訊息中介軟體），更改介面呼叫方式等
第11章、開發管理
管理原則：
1、小團隊易於管理，溝通成本低，交付質量容易控制
2、盡量不要使用虛擬團隊、遠端協作
3、部署服務時應該分批上，不要一次性上太多，容易定位問題
每日站會：
1、昨天工作進展
2、遇到的問題
3、今天準備做什麼
**質量：
1、不斷優化，持續改進，減少重複**和難以理解的**
2、盡可能正規的單元測試
3、不確定的需求要確認，不確定的方案要請他人審核
工作方式：
1、別急著動手，先明確要做什麼，為什麼做，怎麼做
2、別急著動手，業務需求細節要理解準確，否則請確認該需求的細節，不重要又難以實現的細節是否可以砍掉或換個方式
3、別急著動手，方案設計要適當，不確定時要請他人（業務大牛和技術大牛）審核
4、別急著提交，單元測試和自測要全面
開發人員的工作原則：
1、先找輪子，找不到就開發可復用的輪子
2、邊開發邊清理邊優化邊寫單元測試
3、盡可能增加**而不是修改現有**
4、業務功能一般照著做，有個參照物，不容易出錯
5、不僅要知道如何做，還要知道為什麼做
6、經常對開發內容進行討論，避免理解不一致的情況
ba（business analyst）的職責：
需求要明確，讓每個人知道要做什麼和為什麼做。
sa（system analyst）的職責：
選擇技術、框架、標準化工具，管理**質量，提供工具類。
微服務的那些事
服務提供者如何發布乙個服務，服務消費者如何引用這個服務。具體來說，就是這個服務的介面名是什麼？呼叫這個服務需要傳遞哪些引數？介面的返回值是什麼型別？以及一些其他介面描述資訊 最常見的服務發布和引用的方式有三種 restful api 一般對外 xml配置 對內 idl檔案 跨語言，thrift,gr...
c 那些事 筆記
c 那些事 修飾變數 常量 相比 define，可以節省空間，避免 define定義的常量在記憶體中有若干個拷貝 防止被修改 型別檢查 修飾指標 不同位置作用不同，在變數前代表指標不可改變，其他位置代表指標指向的內容不可變 修飾引數 不可修改引數 修飾函式 函式體不可修改類物件 修飾函式返回值 返回...
微服務 筆記
spring boot 在啟動的時候會幹這幾件事情 spring boot 在啟動時會去依賴的 starter 包中尋找 resources meta inf spring.factories 檔案，然後根據檔案中配置的 jar 包去掃瞄專案所依賴的 jar 包。根據 spring.factorie...