從0開始學微服務

01講到底什麼是微服務？

 微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分，每一個拆分出來的服務各自獨立打包部署，並交由小團隊進行開發和運維，從而極大地提升了應用交付的效率，並被各大互聯網公司所廣泛採用。

 

02講從單體應用走向服務化

核心是服務的拆分

縱向：業務緯度

橫向：獨立功能

 

03講初探微服務架構

 

04講如何發佈和引用服務？

• RESTful API

• XML配置

• IDL文件

•  

05講如何註冊和發現服務？

 

 

 

 

06講如何實現RPC遠程服務調用？

• 通訊框架。它主要解決客戶端和服務端如何創建鏈接、管理鏈接以及服務端如何處理請求的問題。

• 通訊協議。它主要解決客戶端和服務端採用哪一種數據傳輸協議的問題。

• 序列化和反序列化。它主要解決客戶端和服務端採用哪一種數據編解碼的問題。

 

07講如何監控微服務調用？

監控的對象是什麼？

業務、jvm、操做系統

具體監控哪些指標？

次數 qps

響應時間 tp90 tp99 ..

從哪些維度進行監控？

集羣、機器、時間、核心

 

監控系統主要包括四個環節：數據採集、數據傳輸、數據處理和數據展現

 

08講如何追蹤微服務調用？

 服務追蹤系統的鼻祖：Google發佈的一篇的論文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，裏面詳細講解了服務追蹤系統的實現原理。它的核心理念就是調用鏈：經過一個全局惟一的ID將分佈在各個服務節點上的同一次請求串聯起來，從而還原原有的調用關係，能夠追蹤系統問題、分析調用數據並統計各類系統指標。

 基本概念：traceId、spanId、annonation等

traceId是用於串聯某一次請求在系統中通過的全部路徑，spanId是用於區分系統不一樣服務之間調用的前後關係，而annotation是用於業務自定義一些本身感興趣的數據，在上傳traceId和spanId這些基本信息以外，添加一些本身感興趣的信息。

 

09講微服務治理的手段有哪些？

服務治理的手段是最經常使用的手段，它們從不一樣角度來確保服務調用的成功率。節點管理是從服務節點健康狀態角度來考慮，負載均衡和服務路由是從服務節點訪問優先級角度來考慮，而服務容錯是從調用的健康狀態角度來考慮，可謂是異曲同工。

 

10講Dubbo框架裏的微服務組件

 

 

11講服務發佈和引用的實踐

 

12講如何將註冊中心落地？

 

13講開源服務註冊中心如何選型？

知足兩個條件

高可用：

集羣部署

數據一致性：

CP型註冊中心

ZooKeeper，etcd，Consul

AP型註冊中心

Eureka

 

14開源RPC框架如何選型

完整的RPC框架主要有三部分組成：通訊框架、通訊協議、序列化和反序列化格式 

dubbo

 

spring cloud

 

 

thrift

 

 

 15講如何搭建一個可靠的監控系統？

ELK

 

 

 

16講如何搭建一套適合你的服務追蹤系統？

業界比較有名的服務追蹤系統實現有阿里的鷹眼、Twitter開源的OpenZipkin，還有Naver開源的Pinpoint，它們都是受Google發佈的Dapper論文啓發而實現的。

 

17講如何識別服務節點是否存活？

心跳開關保護機制

服務節點摘除保護機制

靜態註冊中心

 

18講如何使用負載均衡算法

隨機算法
輪詢算法
加權輪詢算法
最少活躍鏈接算法
一致性hash算法

 

19講如何使用服務路由？

服務路由就是服務消費者在發起服務調用時，必須根據特定的規則來選擇服務節點，從而知足某些特定的需求。

 

20講服務端出現故障時該如何應對？

三種故障：集羣故障、單IDC故障、單機故障，而且針對這三種故障我給出了分別的解決方案，包括降級、限流、流量切換以及自動重啓。

 

21講服務調用失敗時有哪些處理手段？

超時、重試、雙發、熔斷

 

22講如何管理服務配置

在實際選擇的時候，Spring Cloud Config做爲配置中心的功能比較弱，只能經過git命令操做，並且變動配置的話還須要手動刷新，若是不是採用Spring Cloud框架的話不建議選擇。而Disconf和Apollo的功能都比較強大，在國內許多互聯網公司內部都有大量應用，其中Apollo對Spring Boot的支持比較好，若是應用自己採用的是Spring Boot開發的話，集成Apollo會更容易一些。

 

23講如何搭建微服務治理平臺

 

 

能夠說一個微服務框架是否成熟，除了要看它是否具有服務治理能力，還要看是否有強大的微服務治理平臺。由於微服務治理平臺可以將多個系統整合在一塊兒，不管是對開發仍是運維來講，都能起到事半功倍的做用，這也是當前大部分開源微服務框架所欠缺的部分，因此對於大部分團隊來講，都須要本身搭建微服務治理平臺。不過好在微服務治理平臺自己的架構並不複雜，你能夠根據本身的實際須要，來決定微服務治理平臺具有哪些功能。

 

24講微服務架構該如何落地

總結來說就是，首先你必須組建一支合適的技術團隊，這其中不只要包含資深的架構師，還須要包含業務的開發者。在選擇業務進行微服務架構改造時，不能追大求全，正確的作法應當是先以一個適當規模的業務進行微服務改造，走完整個微服務架構落地的過程，從而找出問題，不斷打磨到成熟可用的狀態，再推廣到更多更重要的業務當中。在改造的過程當中，要作好技術取捨，以團隊人員的實際狀況以及業務的實際需求爲準繩，切忌追新立異，避免給業務引入不可控因素，留下「架構債」。同時，微服務架構的過程，也是團隊組織變革的過程，傳統意義上的開發、測試和運維明確的分割線會被打破，出現一種DevOps工程師的角色，他須要對服務全生命週期負責。爲了作到這一點，就須要一個統一的微服務治理平臺，融合服務治理和運維的各類功能。

 

25講微服務爲何要容器化？

基礎環境層。這一層定義操做系統運行的版本、時區、語言、yum源、TERM等。
運行時環境層。這一層定義了業務代碼的運行時環境，好比Java代碼的運行時環境JDK的版本。
Web容器層。這一層定義了業務代碼運行的容器的配置，好比Tomcat容器的JVM參數。
業務代碼層。這一層定義了實際的業務代碼的版本，好比是V4業務仍是blossom業務。

 

26講微服務容器化運維：鏡像倉庫和資源調度
鏡像倉庫幫咱們解決的是Docker鏡像如何存儲和訪問的問題，在業務規模較大時，各個業務團隊都須要搭建本身的私有鏡像倉庫。相似Harbor這種開源解決方案能很好地解決權限控制、鏡像同步等基本問題，關於高可用性的要求以及上雲支持等業務場景，你能夠參考我給出的解決方案，它是通過微博實際線上業務驗證過的。

資源調度幫咱們解決的是如何整合來自不一樣的集羣的資源的問題，若是你的業務不止在內部私有云上部署，在公有云上也有部署，甚至是採用了多家公有云，那麼資源的調度將會是很是複雜的問題，尤爲是在公司內部已經存在一套對接內部集羣的運維管理平臺的狀況下，是升級已有的運維平臺以支持公有云，仍是直接開發另一套新的可以實現多雲對接，這是一個很現實的問題。個人建議是單獨開發一套新的運維平臺先來接管公有云，而後逐步遷移內部集羣的管理工做到新的運維平臺中。

27講微服務容器化運維：容器調度和服務編排
Kubernetes

 

28講微服務容器化運維：微博容器運維平臺DCP.html

 

29講微服務如何實現DevOps

 

要實現DevOps，就必須開發完成代碼開發後，能自動進行測試，測試經過後，能自動發佈到線上。對應的這兩個過程就是CI和CD，具體來說就是：

• CI（Continuous Integration），持續集成。開發完成代碼開發後，能自動地進行代碼檢查、單元測試、打包部署到測試環境，進行集成測試，跑自動化測試用例。

• CD（Continuous Deploy），持續部署。代碼測試經過後，能自動部署到類生產環境中進行集成測試，測試經過後再進行小流量的灰度驗證，驗證經過後代碼就達到線上發佈的要求了，就能夠把代碼自動部署到線上。

30講如何作好微服務容量規劃

容量規劃系統的做用是根據各個微服務部署集羣的最大容量和線上實際運行的負荷，來決定各個微服務是否須要彈性擴縮容，以及須要擴縮容多少臺機器。

 

31講微服務多機房部署實踐

微服務多機房部署時要面臨的三個問題，一是多機房訪問時如何保證負載均衡，二是多機房之間的數據如何保證同步，三是多機房之間的數據如何保證一致性

 

32講微服務混合雲部署實踐

混合雲部署必須解決的三個問題：跨雲服務的負載均衡、跨雲服務的數據同步、跨雲服務的容器運維

 

33講下一代微服務架構ServiceMesh

Service Mesh是一種新型的用於處理服務與服務之間通訊的技術，尤爲適用以雲原生應用形式部署的服務，可以保證服務與服務之間調用的可靠性。在實際部署時，Service Mesh一般以輕量級的網絡代理的方式跟應用的代碼部署在一塊兒，從而以應用無感知的方式實現服務治理。

 Service Mesh以輕量級的網絡代理的方式與應用的代碼部署在一塊兒，用於保證服務與服務之間調用的可靠性，這與傳統的微服務架構有着本質的區別

好處：

跨語言

輕量級（無SDK侵入）

第一代開源實現 Linkerd：

 

service mesh 實現原理

Service Mesh實現的關鍵就在於兩點：一個是上面提到的輕量級的網絡代理也叫SideCar，它的做用就是轉發服務之間的調用；一個是基於SideCar的服務治理也被叫做Control Plane，它的做用是向SideCar發送各類指令，以完成各類服務治理功能。

a、Side Car

 

 b、Control Plane

 

34講Istio：ServiceMesh的表明產品

• 相比Linkerd，Istio引入了Control Plane的理念，經過Control Plane能帶來強大的服務治理能力，能夠稱得上是Linkerd的進化，算是第二代的Service Mesh產品。

• Istio默認的SideCar採用了Envoy，它是用C++語言實現的，在性能和資源消耗上要比採用Scala語言實現的Linkerd小，這一點對於延遲敏感型和資源敏感型的服務來講，尤爲重要。

• 有Google和IBM的背書，尤爲是在微服務容器化的大趨勢下，雲原生應用愈來愈受歡迎，而Google開源的Kubernetes能夠說已經成爲雲原生應用默認採用的容器平臺，基於此Google能夠將Kubernetes與Istio很天然的整合，打形成雲原生應用默認的服務治理方案。